 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / General / Networking / January 2010OS X firewall - how to make it actually work
Hi, I'm trying to find out how to get the OS X application firewall to block access to all incoming traffic except for one application, VMware. Unfortunately the OS X application firewall is essentially useless because it allows all manner of things to easily bypass it, either directly or by using a command line tool ushc as netcat. See: <http://www.h-online.com/security/news/item/Apple-documents-Leopard-firewall-func tionality-and-holes-733932.html> I know Apple are pretty clueless about security, but leaving all root owned listening processes open even when the firewall is fully locked? That's crazy! Can anyone tell me how to get the application firewall to actually do its job and block incoming access to everything but VMware? Equally, I'd like to disable completely (or at least block the incoming and outgoing traffic of) system daemons such as configd, mDNSResponder, the Finder using nmblookup and smbclient, DirectoryService, ntpd, and there may be others. I want total "silence on the wire". If anyone knows how to disable any of those chatty daemons I'd be very very grateful to hear how (launchd maybe?). I've been tinkering with this on and off for months. I'm getting desperate now. I'm on the point of wiping VMware and even OS X off my brand new MacBook Pro and installing Linux with KVM just so I can get a properly secured VM hosting environment for my work. Anyone know anything about Mac networking here?  SignatureJames Taylor > Hi, > [quoted text clipped - 9 lines] > > Anyone know anything about Mac networking here? Although I am sure that it is possible by configuring the applications themselves, if you are using your macbook entirely as a VM tool with no use of the host operating system, is there actuall much point keeping OSX on there? I mean you are not using it, and if you can't set it up the way you want, is it worth the effort to try when you are clearly OK running linux, so why not just run that? SignatureWoody > if you are using your macbook entirely as a VM tool with no > use of the host operating system, is there actually much point keeping > OSX on there? I mean you are not using it, and if you can't set it up > the way you want, is it worth the effort to try when you are clearly OK > running linux, so why not just run that? It's sorely tempting. The problem is in the inertia of time and money already invested in the current setup. I have already paid for VMware, I have some familiarity with it, and a number of VM guests in VMware format that I spent considerable time setting up. There is an increasing shortage of time pressing upon me with the work I'm doing, and I really don't want to have to spend yet more time familiarising myself with the KVM way of doing things and then rebuilding (or somehow translating) all the VM guests. I just want to be able to get on with building virtual servers on a hypervisor platform I know is unreachable (hopefully even undetectable) over the network. SignatureJames Taylor >> if you are using your macbook entirely as a VM tool with no >> use of the host operating system, is there actually much point keeping [quoted text clipped - 12 lines] > servers on a hypervisor platform I know is unreachable (hopefully even > undetectable) over the network. This is probably a hopelessly simplistic answer, but could you not simply put the Mac's network adaptor on a 10.x.y.z network, then put the VM's adaptors onto the realworld network? Jim Signaturehttp://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK "Get over here. Now. Might be advisable to wear brown trousers and a shirt the colour of blood." Malcolm Tucker, "The Thick of It" > This is probably a hopelessly simplistic answer, but could you not simply > put the Mac's network adaptor on a 10.x.y.z network, then put the VM's > adaptors onto the realworld network? Nice idea Jim, but sadly that doesn't stop OS X from Bonjouring everyone on the network about your machine name, IP address, listening services, etc, and thus it would be very easy for a malicious agent (virus, hacker, whatever) on the same LAN segment to see you and then attack the IP address you were on whatever you set it to. SignatureJames Taylor >> This is probably a hopelessly simplistic answer, but could you not simply >> put the Mac's network adaptor on a 10.x.y.z network, then put the VM's [quoted text clipped - 5 lines] > hacker, whatever) on the same LAN segment to see you and then attack the > IP address you were on whatever you set it to. Bother. Jim Signaturehttp://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK "Get over here. Now. Might be advisable to wear brown trousers and a shirt the colour of blood." Malcolm Tucker, "The Thick of It" > >> This is probably a hopelessly simplistic answer, but could you not simply > >> put the Mac's network adaptor on a 10.x.y.z network, then put the VM's [quoted text clipped - 7 lines] > > Bother. I use Waterroof to configure ipfw to block all the Bonjour stuff: http://www.hanynet.com/waterroof/ This has the added benefit of keeping the log files to a reasonable size! If you use this application, don't forget to use the "Install Startup Script" option once you have the rules tweaked the way you want, or you'll have to manually reload them after each restart. This is in addition to the appfirewall, which is currently set to "Allow only essential services". >> This is probably a hopelessly simplistic answer, but could you not simply >> put the Mac's network adaptor on a 10.x.y.z network, then put the VM's [quoted text clipped - 5 lines] > whatever) on the same LAN segment to see you and then attack the IP > address you were on whatever you set it to. Why not put the Mac on its own LAN segment? Set up an ethernet router between it and the rest of the LAN, then none of its broadcasts will get out. SignatureGraham J > Why not put the Mac on its own LAN segment? Set up an ethernet > router between it and the rest of the LAN, then none of its > broadcasts will get out. Yes, that's what I will do as a stopgap solution for now, because I really must make progress with my work on it. But ultimately I want to be able travel to client premises with it, and not have to worrying that the hypervisor OS is exposed. SignatureJames Taylor >> Why not put the Mac on its own LAN segment? Set up an ethernet >> router between it and the rest of the LAN, then none of its [quoted text clipped - 4 lines] > travel to client premises with it, and not have to worrying that the > hypervisor OS is exposed. Take the router with you to the client premises. OK so it needs another power, and you would have to connect it to the client's LAN by wire. In fact if you put a decent router (Vigor or Cisco) at the clients premises (for internet connection) then you could connect via VPN - so no need to visit at all. Would pay for itself on the first visit it saved! SignatureGraham J > Take the router with you to the client premises. OK so it needs another > power, and you would have to connect it to the client's LAN by wire. Not really practical, and I usually need to be on the same LAN segment as the client's machines, so no good being behind a router. > In fact if you put a decent router (Vigor or Cisco) at the clients premises > (for internet connection) then you could connect via VPN - so no need to > visit at all. Hehe, wouldn't that be nice! SignatureJames Taylor >> if you are using your macbook entirely as a VM tool with no >> use of the host operating system, is there actually much point keeping [quoted text clipped - 6 lines] >have some familiarity with it, and a number of VM guests in VMware >format that I spent considerable time setting up. Then stick with VMware rather than using KVM. Server is free on Linux, and all the VMwares use the same machine format. Cheers - Jaimie SignatureIf you own a jackhammer, every problem looks like hours of fun > Then stick with VMware rather than using KVM. Server is free on Linux, > and all the VMwares use the same machine format. Oh really? That's such good news. This should lower the barrier to switching considerably. If I'm unable to secure OS X, this is definitely a good second option. Thanks. SignatureJames Taylor > > Then stick with VMware rather than using KVM. Server is free on Linux, > > and all the VMwares use the same machine format. > > Oh really? That's such good news. I have used VMWare server. It does mostly work but there is a good reason it is free. For servers it is mostly ok. For use as a desktop it is sluggish to say the least (ignoring its faffyness to run and set up). SignatureWoody > I have used VMWare server. It does mostly work but there is a good > reason it is free. Oh dear, that doesn't bode well. > For servers it is mostly ok. For use as a desktop it is sluggish to say > the least (ignoring its faffyness to run and set up). I can do without faffyness. Time is too short for much of that. My immediate need for a VM platform is now so pressing that I will just have to put this machine into service in an insecure configuration on OSX, and worry about sorting out a Linux based system at a later date. It really would be a lot better if I could just find a way to disable the OSX network daemons (they're just not needed when VMware guests are bridged and have direct access to layer 2) or otherwise get the application firewall to work properly (which I expected to be easier). Frankly I'm astonished that the much advertised new Leopard firewall doesn't actually work and there doesn't seem to be a big stink about it. Indeed most Mac users believe their platform is the most secure system in existence when in fact the exact opposite is true. Apple must be doing some kind of mass hypnosis to pull off this scale of deception. SignatureJames Taylor > > I have used VMWare server. It does mostly work but there is a good > > reason it is free. [quoted text clipped - 5 lines] > > I can do without faffyness. Time is too short for much of that. Well, I did get it set up and probably the additional problems I had were becasue i had tomcat running, and it wanted to use that port so just failed to run. I didn't try it on linux, I put it on windows, where it failed to start all the services it needed. It worked when I started them though > immediate need for a VM platform is now so pressing that I will just > have to put this machine into service in an insecure configuration on > OSX, and worry about sorting out a Linux based system at a later date. Makes sense > It really would be a lot better if I could just find a way to disable > the OSX network daemons (they're just not needed when VMware guests are > bridged and have direct access to layer 2) or otherwise get the > application firewall to work properly (which I expected to be easier). Surely then you are just relying on the reliability of the firewall? I never trusted software firewalls, I mean if you allow the network you allow the network so you can fool the thing behind it > Frankly I'm astonished that the much advertised new Leopard firewall I obviously see different advertising than you as I have never seen an advert for the firewall? > doesn't actually work and there doesn't seem to be a big stink about it. > Indeed most Mac users believe their platform is the most secure system > in existence when in fact the exact opposite is true. Its not a fact though. It may be true, or it may not be, but it isn't a 'fact'. > Apple must be > doing some kind of mass hypnosis to pull off this scale of deception. Clearly that is the only possible answer, or maybe all mac users are retards. SignatureWoody >> It really would be a lot better if I could just find a way to disable >> the OSX network daemons (they're just not needed when VMware guests are >> bridged and have direct access to layer 2) or otherwise get the >> application firewall to work properly (which I expected to be easier). > > Surely then you are just relying on the reliability of the firewall? Oh sure. Disabling the daemon is always preferable. The firewall approach is just a fallback measure given that I can't work out how to disable the daemons, and in some cases they have to be running for the computer to work anyway. > I never trusted software firewalls, I mean if you allow the network you > allow the network so you can fool the thing behind it Agreed. The firewall itself is a potential point of vulnerability, but at least it should have been engineered very carefully to be small and robust as possible, and it should be better than leaving several different system daemons accessible. >> Apple must be doing some kind of mass hypnosis >> to pull off this scale of deception. > > Clearly that is the only possible answer, or maybe > all mac users are retards. I wasn't going to go *that* far. ;-) SignatureJames Taylor > > I never trusted software firewalls, I mean if you allow the network you > > allow the network so you can fool the thing behind it [quoted text clipped - 3 lines] > robust as possible, and it should be better than leaving several > different system daemons accessible. Hmm.. don't know. The system daemons are older than the firewall and have had greater testing. You would certainly like to think it had been written differently, but it is adding more software. SignatureWoody > > > I never trusted software firewalls, I mean if you allow the network you > > > allow the network so you can fool the thing behind it [quoted text clipped - 7 lines] > have had greater testing. You would certainly like to think it had been > written differently, but it is adding more software. My previous post suggested ways of configuring the firewall to do what you want. But turning off the unwanted daemons is also no bad thing. The NSA hardening guide describes what you need to do: <http://www.nsa.gov/ia/_files/factsheets/macosx_hardening_tips.pdf> Kind regards, Dave >My previous post suggested ways of configuring the firewall to do what >you want. But turning off the unwanted daemons is also no bad thing. > >The NSA hardening guide describes what you need to do: ><http://www.nsa.gov/ia/_files/factsheets/macosx_hardening_tips.pdf> There's a lot of good stuff over there. Browsing from http://www.nsa.gov/ia/guidance/security_configuration_guides/index.shtml is interesting. No mentions of Flash that I can find! Cheers - Jaimie Signature"Usenet is like a herd of performing elephants with diarrhea - massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." -- Gene Spafford > >My previous post suggested ways of configuring the firewall to do what > >you want. But turning off the unwanted daemons is also no bad thing. [quoted text clipped - 7 lines] > > No mentions of Flash that I can find! In addition to the two guides listed there there is also the Corsaire one <http://research.corsaire.com/whitepapers/080818-securing-mac-os-x-leopar d.pdf> but this isn't totally up to date (in particular the description of StartUpItems...) Kind regards, Dave > The NSA hardening guide describes what you need to do: > <http://www.nsa.gov/ia/_files/factsheets/macosx_hardening_tips.pdf> Oooh, nice find. I'll take a look. Thanks Hmmm, mind you, I hesitate to download and view a carefully crafted PDF file from the likes of the NSA!!! SignatureJames Taylor >> The NSA hardening guide describes what you need to do: >> <http://www.nsa.gov/ia/_files/factsheets/macosx_hardening_tips.pdf> [quoted text clipped - 3 lines] >Hmmm, mind you, I hesitate to download and view a carefully crafted PDF >file from the likes of the NSA!!! As long as you open it in something other than Adobe Reader you should be okay! Cheers - Jaimie Signature"I went to a planet where the dominant lifeform had no bilateral symmetry, and all I got was this stupid F-Shirt." -- Eric Pivnik >> Hmmm, mind you, I hesitate to download and view a carefully crafted PDF >> file from the likes of the NSA!!! > > As long as you open it in something other than Adobe Reader you should > be okay! Hehe. :-) SignatureJames Taylor >> > Then stick with VMware rather than using KVM. Server is free on Linux, >> > and all the VMwares use the same machine format. [quoted text clipped - 6 lines] >For servers it is mostly ok. For use as a desktop it is sluggish to say >the least (ignoring its faffyness to run and set up). I never had any of that, using Server on Windows or Linux. No faffyness, and no particular change to the product after the expensive pay-for original went free. Certainly no sluggishness issues, either of the servery stuff or the UI. OTOH, going back to Server on Linux now, after using Fusion with all its simplicity, might be a bit of a jerk. Not because Server has changed, but because my habits have - Server has a lot more to offer than Fusion, so it's more complex if you dive into it. Just migrating VMs back and forward is almost no effort at all. Cheers - Jaimie Signature"You hear someone break into your home. You pull out your chainsaw and crank it up. It makes its very distinctive chainsaw noise; he hears it. What criminal is going to stay in a house with someone that crazy?" -- Home defence with Franklin Hummel, rasfw > > if you are using your macbook entirely as a VM tool with no > > use of the host operating system, is there actually much point keeping [quoted text clipped - 6 lines] > have some familiarity with it, and a number of VM guests in VMware > format that I spent considerable time setting up. Oh ok, I assumed that there was a VMWare on linux and you could just transfer your VMs (and license) to linux. It makes more sense staying if there isn't SignatureWoody >Hi, > [quoted text clipped - 9 lines] >That's crazy! Can anyone tell me how to get the application firewall to >actually do its job and block incoming access to everything but VMware? You can't, it just doesn't do that. But you can get in at the ipfw interface - which happens lower down the stack, of course - and roll your own rules. Or use a UI, like Doorstop X. The firewall in 10.6 server is still ipfw based rather than application-centric, apparently. >Equally, I'd like to disable completely (or at least block the incoming >and outgoing traffic of) system daemons such as configd, mDNSResponder, >the Finder using nmblookup and smbclient, DirectoryService, ntpd, and >there may be others. I want total "silence on the wire". If anyone knows >how to disable any of those chatty daemons I'd be very very grateful to >hear how (launchd maybe?). Launchd it is. Lingon is a useful UI for managing these, though you can mess around in /System/Library/LaunchDaemons if you prefer. I have no idea what damage (if any) disabling them might do. For blocking, back up to ipfw. >I've been tinkering with this on and off for months. I'm getting >desperate now. I'm on the point of wiping VMware and even OS X off my >brand new MacBook Pro and installing Linux with KVM just so I can get a >properly secured VM hosting environment for my work. Honestly, I'm surprised you've left it so long! Cheers - Jaimie Signature220 mail.sessile.org ESMTP Sendmail 8.13.4 ICBM ENABLED ; Wed, 23 Jun 2005 15:04:40 GMT HELO spammers.org 250 mail.sessile.org MAIL FROM:<scumball@spammers.org> 550 you have four minutes to say goodbye to your family >> Can anyone tell me how to get the application firewall to actually >> do its job and block incoming access to everything but VMware? > > You can't, it just doesn't do that. You're confirming that the firewall doesn't do its job? So Apple's own flagship security feature is well known to be snake oil is it? > But you can get in at the ipfw interface The trouble is ipfw is a packet level firewall not an application firewall and it is therefore not useful to me. I want the VMware guests to be able to fully access the network (eg. for scapy packet crafting, nmap and nessus scanning, etc). I just want the the VM hypervisor OS itself to be invisible and unreachable, while allowing full access to the VM guests. On Linux I'd just disable all listening daemons and that would be the end of it, but on OS X this seems to be impossible, or at least I don't know how and nobody else does either. > The firewall in 10.6 server is still ipfw based rather than > application-centric, apparently. Unfortunately so. > Launchd it is. Lingon is a useful UI for managing these, I've spent a lot of time staring blankly into the lists of daemons in Lingon, and googling their names to get some idea of what they do, but not finding much information at all. I've tried experimentally disabling them, but managed to lock myself out of my computer, so I'm reluctant to try that again without more guidance. > I have no idea what damage (if any) disabling them might do. I can tell you that disabling DirectoryService prevents login. I had to put the machine into target disc mode and repair the .plist manually. >> I've been tinkering with this on and off for months. I'm getting >> desperate now. I'm on the point of wiping VMware and even OS X off my >> brand new MacBook Pro and installing Linux with KVM just so I can get a >> properly secured VM hosting environment for my work. > > Honestly, I'm surprised you've left it so long! It sticks in my craw that I purchased an expensive Mac, but OS X is so insecure it can't even be secured when you try very very hard. I feel let down by Apple on several aspects of security actually. They just don't seem to get it at all. SignatureJames Taylor >>> Can anyone tell me how to get the application firewall to actually >>> do its job and block incoming access to everything but VMware? [quoted text clipped - 3 lines] >You're confirming that the firewall doesn't do its job? So Apple's own >flagship security feature is well known to be snake oil is it? Nope. It does exactly what it says it does, which doesn't happen to be what you need. Cheers - Jaimie SignatureBE PURE BE VIGILANT BEHAVE >> You're confirming that the firewall doesn't do its job? So Apple's own >> flagship security feature is well known to be snake oil is it? > > Nope. It does exactly what it says it does, which doesn't happen to be > what you need. But it's an application firewall isn't it? So it should allow me to specify which processes are allowed incoming and outgoing network access. But all the system daemons get access regardless, even the ones running as root! And then any non system process, or malware, can get access through the firewall just by piping through netcat or similar. It really is hard to imagine what Apple were thinking the purpose of an application firewall is. They clearly weren't thinking that people would want to use it to harden their machine against unwanted network access. What in fact *does* the firewall do that you might conceivably want? SignatureJames Taylor >But all the system daemons get access regardless, even the ones >running as root! And then any non system process, or malware, can get >access through the firewall just by piping through netcat or similar. I don't follow this. Are you suggesting that some malware already on your machine would run netcat? What would this gain it? -- Richard SignaturePlease remember to mention me / in tapes you leave behind. >> any non system process, or malware, can get access through >> the firewall just by piping through netcat or similar. > > I don't follow this. Are you suggesting that some malware already > on your machine would run netcat? Yes. > What would this gain it? The kind of access to the network you had good reason to believe that the firewall would prevent. It could for instance connect back to the hacker and present him with a remote shell, send personal data, passwords, ssh keys, captured keystrokes, and all the other standard mischief. Maybe there's a third-party application firewall product that would work better. I already have LittleSnitch, which allows me to prevent outgoing connections, but I really need something to block incoming traffic too. SignatureJames Taylor >> I don't follow this. Are you suggesting that some malware already >> on your machine would run netcat? >Yes. Of course, you're already in trouble at this point. >The kind of access to the network you had good reason to believe that >the firewall would prevent. Why can netcat do things that the malware itself can't? Are you suggesting that netcat would be an application trusted by the firewall? >It could for instance connect back to the >hacker and present him with a remote shell, send personal data, >passwords, ssh keys, captured keystrokes, and all the other standard >mischief. You're talking about outgoing connections here. Does the application firewall concern itself with them at all? I would have thought it was too tedious to control outgiong connections by application (rather than port). -- Richard SignaturePlease remember to mention me / in tapes you leave behind. >>> I don't follow this. Are you suggesting that some malware >>> already on your machine would run netcat? > >> Yes. > > Of course, you're already in trouble at this point. Oh sure, but typically the initial infection vector is a small thing whose first job is to download the full malware. If you can detect and prevent that malware drop taking place then you're much better off. > Why can netcat do things that the malware itself can't? Are you > suggesting that netcat would be an application trusted by the > firewall? Apparently, Apple have pre-signed many of the standard OS components to allow them access through the firewall without needing explicit rules in the firewall or asking for user permission. Their logic seems to be that only newly dropped malware can do evil and only by accessing the net directly. It didn't occur to them that programs can call other programs to do evil. They should have put explicit allow rules in so users can see what is allowed by default and remove those rules to stop it. >> It could for instance connect back to the hacker and present him >> with a remote shell, send personal data, passwords, ssh keys, >> captured keystrokes, and all the other standard mischief. > > You're talking about outgoing connections here. Does the application > firewall concern itself with them at all? It certainly should, but maybe they deliberately left that for LittleSnitch so as not to put a third-party product out of business. I haven't tested that because I have LitteSnitch anyway. > I would have thought it was too tedious to control outgoing > connections by application (rather than port). No, that's the whole point of an "application" firewall as opposed to a network level firewall. SignatureJames Taylor >> Why can netcat do things that the malware itself can't? Are you >> suggesting that netcat would be an application trusted by the >> firewall? >Apparently, Apple have pre-signed many of the standard OS components to >allow them access through the firewall without needing explicit rules in >the firewall or asking for user permission. Is netcat such a component? But see below about web browsers. >> I would have thought it was too tedious to control outgoing >> connections by application (rather than port). >No, that's the whole point of an "application" firewall as opposed to a >network level firewall. I understand the distinction between application and network level firewalls. But for *outgoing* connections connections controlling it at the application level seems too tedious: there are hundreds of commonly used programs that make outgoing connections, but just a few that accept incoming ones. And many of those programs can, by design, connect to anything. For example, any web browser could be used to send data to an arbitrary port TCP on an arbitrary server - just tell it to go to http://myevilserver.com:666/[lots-of-secret-data] Are you considering a machine so locked down that it mustn't be able to run a web browser? If so, I would have thought a network-level firewall that only allowed connections to trusted hosts would be a better solution. -- Richard SignaturePlease remember to mention me / in tapes you leave behind. >> Apparently, Apple have pre-signed many of the standard OS components to >> allow them access through the firewall without needing explicit rules in >> the firewall or asking for user permission. > > Is netcat such a component? Yes. > I understand the distinction between application and network level > firewalls. But for *outgoing* connections connections controlling it > at the application level seems too tedious: there are hundreds of > commonly used programs that make outgoing connections, but just a few > that accept incoming ones. Well, there aren't *hundreds*, probably only a few tens, and with something like LittleSnitch, for instance, you only need to allow or deny each process the first time it tries, and it remembers this rule and doesn't ask again. It's really not so onerous. > And many of those programs can, by design, connect to anything. For > example, any web browser could be used to send data to an arbitrary > port TCP on an arbitrary server Sure, so with a web browser you'd probably allow it universal port 80 and 443 access with specific (perhaps temporary) overrides for other ports as the need arose. > Are you considering a machine so locked down that it mustn't be able > to run a web browser? In this case, yes, because I'll be running a virtual machine within which I do my general web browsing, and another separate one for online banking, and another one for web application development, and another one for network penetration testing (including web application testing), and so on. > If so, I would have thought a network-level firewall that only > allowed connections to trusted hosts would be a better solution. Sadly, no, because I need full access from the various VM guests while having no access to or from the VM master. This requires an application level firewall that can allow VMware while disallowing all else. SignatureJames Taylor >>> Apparently, Apple have pre-signed many of the standard OS components to >>> allow them access through the firewall without needing explicit rules in >>> the firewall or asking for user permission. >> Is netcat such a component? >Yes. As far as I (and spotlight) can see, netcat doesn't even exist on a vanilla Snow Leopard system. Where is it on your system? >> And many of those programs can, by design, connect to anything. For >> example, any web browser could be used to send data to an arbitrary >> port TCP on an arbitrary server >Sure, so with a web browser you'd probably allow it universal port 80 >and 443 access with specific (perhaps temporary) overrides for other >ports as the need arose. The bad guys could perfectly well use port 80 - in fact they probably would, since in many places it's one of the few ports open on a network-level firewall. I suppose just renaming the web browser would defeat most attempts to use it. -- Richard SignaturePlease remember to mention me / in tapes you leave behind. > The bad guys could perfectly well use port 80 - in fact they probably > would, since in many places it's one of the few ports open on a > network-level firewall. Yes, absolutely. Port 80 is where it all happens for better or worse. > I suppose just renaming the web browser would defeat most attempts to > use it. Nice idea, but I wonder how much that would help in practise. Often these exploits come in via the browser itself, so they inject malicious code into the running process of the browser in use regardless of what filename you gave it on disc. SignatureJames Taylor > >>> Apparently, Apple have pre-signed many of the standard OS components to > >>> allow them access through the firewall without needing explicit rules in [quoted text clipped - 6 lines] > As far as I (and spotlight) can see, netcat doesn't even exist on > a vanilla Snow Leopard system. Where is it on your system? 10.4.11: Last login: Sat Dec 19 09:52:18 on ttyp1 Welcome to Darwin! [tim ~]$ locate netcat /usr/share/zsh/4.2.3/functions/_netcat [tim ~]$ find netcat find: netcat: No such file or directory [tim ~]$ which netcat no netcat in /Users/tim /usr/local/bin /usr/local/lib /usr/local/share /usr/bin /usr/lib /bin /usr/X11R6/bin /usr/X11R6/lib /usr/local/sbin /usr/sbin /sbin /usr/share /etc] [tim ~]$ > >> And many of those programs can, by design, connect to anything. For > >> example, any web browser could be used to send data to an arbitrary [quoted text clipped - 12 lines] > > -- Richard Signature"I wear the cheese, it does not wear me." > 10.4.11: > > Last login: Sat Dec 19 09:52:18 on ttyp1 > Welcome to Darwin! > [tim ~]$ locate netcat > /usr/share/zsh/4.2.3/functions/_netcat Actually the binary is called nc not netcat. It is in /usr/bin. > [tim ~]$ find netcat > find: netcat: No such file or directory That's not how you use find. You should write: find /bin /sbin /usr -name nc or similar > [tim ~]$ which netcat > no netcat in /Users/tim /usr/local/bin /usr/local/lib /usr/local/share > /usr/bin /usr/lib /bin /usr/X11R6/bin /usr/X11R6/lib /usr/local/sbin > /usr/sbin /sbin /usr/share /etc] $ which nc /usr/bin/nc SignatureJames Taylor >> [tim ~]$ find netcat >> find: netcat: No such file or directory >That's not how you use find. That used to work on some unixes. It used a database similar to locate(1). See for example http://www.freebsd.org/cgi/man.cgi?query=find&apropos=0&sektion=1&manpath=SunOS+ 4.1.3&format=html -- Richard SignaturePlease remember to mention me / in tapes you leave behind. > > >>> Apparently, Apple have pre-signed many of the standard OS components to > > >>> allow them access through the firewall without needing explicit rules in [quoted text clipped - 6 lines] > > As far as I (and spotlight) can see, netcat doesn't even exist on > > a vanilla Snow Leopard system. Where is it on your system? It is called 'nc', not 'netcat'. % which nc /usr/bin/nc % man nc describes it as "The nc (or netcat) utility is used for just about anything under the sun involving TCP or UDP." SignatureDavid Empson dempson@actrix.gen.nz > >>> Apparently, Apple have pre-signed many of the standard OS components to > >>> allow them access through the firewall without needing explicit rules in [quoted text clipped - 6 lines] > As far as I (and spotlight) can see, netcat doesn't even exist on > a vanilla Snow Leopard system. Where is it on your system? It tends to go by the abbreviated name "nc": /usr/bin/nc SignatureBarry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** > >> Why can netcat do things that the malware itself can't? Are you > >> suggesting that netcat would be an application trusted by the [quoted text clipped - 19 lines] > commonly used programs that make outgoing connections, but just a few > that accept incoming ones. That is precisely what Little Snitch does. Its default mode of operation is to prompt you whenever anything makes an outgoing connection. It tells you the application and asks what you want to do about it. Choices are: - Deny or Allow connection - Once only, until application quits or forever - Specific port but any IP address, specific IP address but any port, specific port and IP address, or any network connection. You can also configure it to default to using a particular combination and create a temporary rule. As you use it to create "forever" rules it builds up a list of everything you have permitted and asks you questions less often. You can go and edit that list later, or temporarily enable/disable certain rules. If you are in a context where it can't display a dialog box (e.g. a full-screen game) then it automatically denies the connection and uses text-to-speech to tell you that "Little Snitch has automatically blocked an outgoing connection [with a description]". You can then edit the temporary rule after you get back to the normal user interface. SignatureDavid Empson dempson@actrix.gen.nz > If you are in a context where it can't display a dialog box (e.g. a > full-screen game) then it automatically denies the connection and uses > text-to-speech to tell you that "Little Snitch has automatically blocked > an outgoing connection [with a description]". You can then edit the > temporary rule after you get back to the normal user interface. Wow, I didn't know it did that too. Wow! You don't hapen to know whether it can be made to block incoming connections too do you? SignatureJames Taylor > > If you are in a context where it can't display a dialog box (e.g. a > > full-screen game) then it automatically denies the connection and uses [quoted text clipped - 6 lines] > You don't hapen to know whether it can be made to block incoming > connections too do you? I don't think so. Might be worth looking at Intego NetBarrier to block incoming connections. I think both NetBarrier and Little Snitch default to accepting all local connections, but can be configured not to do that. Signature<http://www.decohen.com> Send e-mail to the Reply-To address. Mail to the From address is never read. anybody tried Protemac NetMine?? I use this prog for firewall > >> You're confirming that the firewall doesn't do its job? So Apple's own > >> flagship security feature is well known to be snake oil is it? [quoted text clipped - 11 lines] > want to use it to harden their machine against unwanted network access. > What in fact *does* the firewall do that you might conceivably want? I've dipped into this thread from time to time and am slightly confused. From the Leopard security guide I see that Apple claim that the following system services that are still allowed to receive incoming connections: configd: Implements DHCP and other network configuration services. mDNSResponder: Implements Bonjour. racoon: Implements Internet Key Exchange (IKE). In deed if I look in /Library/Preferences/com.apple.alf.plist I see /usr/sbin/configd, /usr/sbin/mDNSResponder and /usr/sbin/racoon listed as the only exceptions. Your complaint certainly has included mDNSResponder, I don't recall if you also wanted to block configd and racoon at the hypervisor level. But otherwise I don't recall anything inconsistent with what Apple state. I would therefore suggest two things: Either delete these exceptions from /Library/Preferences/com.apple.alf.plist or, for Bonjour, configure ipfw to block udp 5353 in and out and enable it as per prescription in the security guide (but this of course is blocking them for your VMs as well). I'd play with the first suggestion first. I note en passant that /usr/bin/nc is in the explicitauths... Kind regards, Dave >> But it's an application firewall isn't it? So it should allow me to >> specify which processes are allowed incoming and outgoing network [quoted text clipped - 9 lines] > mDNSResponder: Implements Bonjour. > racoon: Implements Internet Key Exchange (IKE). There are others too, which they don't mention. > In deed if I look in /Library/Preferences/com.apple.alf.plist Oh you wonderful man! Thank you, thank you! I'm looking at it now. Perhaps a severe culling of this file is all I need. > I see /usr/sbin/configd, /usr/sbin/mDNSResponder and /usr/sbin/racoon > listed as the only exceptions. I see quite a few other things too. There are seven explicitauths including full languages that would provide quite a lot of power for an exploit to use for downloading code, connecting a reverse shell, or further scanning of the network all without any user warnings. There's also a section called signexceptions wit a lot of entries. I have to assume they've been signed in such a way that malware couldn't just modify or replace them. However, this begs the question of whether the non-signed "explicitauths" above can be modified or replaced by malware thus making a mockery of the firewall entirely. > Your complaint certainly has included mDNSResponder, I don't recall if > you also wanted to block configd and racoon at the hypervisor level. Yes I do. They're not needed. The hypervisor doesn't need any presence on the network. I only wish it to make the physical (layer 0) connection via ethernet or wi-fi and leave the rest to VMware's guests. > Either delete these exceptions from > /Library/Preferences/com.apple.alf.plist Great idea. Will do. > or, for Bonjour, configure ipfw to block udp 5353 in and out and enable > it as per prescription in the security guide (but this of course is > blocking them for your VMs as well). No, that's not what I want. I may actually be actively probing for or passively listening for MDNS in one of the guests. > I'd play with the first suggestion first. > > I note en passant that /usr/bin/nc is in the explicitauths... Indeed. I'm off to get something to eat, then there's going to be some savage butchery to this file when I get back. Thank you so much. SignatureJames Taylor > Indeed. I'm off to get something to eat, then there's going to be some > savage butchery to this file when I get back. Thank you so much. I think it goes without saying that you should probably back it up first..:-) Jim Signaturehttp://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK "Get over here. Now. Might be advisable to wear brown trousers and a shirt the colour of blood." Malcolm Tucker, "The Thick of It" > > Indeed. I'm off to get something to eat, then there's going to be some > > savage butchery to this file when I get back. Thank you so much. > > I think it goes without saying that you should probably back it up > first..:-) Pah - where is your sense of adventure? SignatureWoody >> > Indeed. I'm off to get something to eat, then there's going to be some >> > savage butchery to this file when I get back. Thank you so much. [quoted text clipped - 3 lines] > > Pah - where is your sense of adventure? Safely backed up at home, thank you. Jim Signaturehttp://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK "Get over here. Now. Might be advisable to wear brown trousers and a shirt the colour of blood." Malcolm Tucker, "The Thick of It" >>>> Indeed. I'm off to get something to eat, then there's going to be some >>>> savage butchery to this file when I get back. Thank you so much. >>> >>> I think it goes without saying that you should probably back it up >>> first..:-) It does go without saying. >> Pah - where is your sense of adventure? > > Safely backed up at home, thank you. Hahaha! Hilarious! :-D SignatureJames Taylor > >> You're confirming that the firewall doesn't do its job? So Apple's own > >> flagship security feature is well known to be snake oil is it? [quoted text clipped - 11 lines] > want to use it to harden their machine against unwanted network access. > What in fact *does* the firewall do that you might conceivably want? It does everything that ipfw does. My old server ran plain-jane OS X 3-4 years out in the open on the Web, logged thousands of "attacks" and was never breached (I doubt anybody tried very hard, it was lame botnet crap usually). Later I hid it behind a router using NAT for convenience in setting up a household LAN and all the "attacks" stopped, of course. http://www.freebsd.org/doc/handbook/firewalls-ipfw.html Some Mac-specific information which I hope is helpful: http://macdevcenter.com/pub/a/mac/2005/03/15/firewall.html http://developer.apple.com/internet/security/securityintro.html http://developer.apple.com/mac/library/documentation/Darwin/Reference/Man Pages/man8/ipfw.8.html http://xdeb.org/wiki/firewall Putting your computer behind a router with only the specifically needed open ports might be a simple and secure way to do what you want. Cheap, quick to set up and perhaps even much less frustrating. Good luck! Signature"I wear the cheese, it does not wear me." >> What in fact *does* the firewall do that you might conceivably want? > > It does everything that ipfw does. No, we are talking about the application level firewall (called alf I suppose), not the network level firewall called ipfw. > My old server ran plain-jane OS X 3-4 years out in the open on the > Web, logged thousands of "attacks" and was never breached Wha do you mean by attacks? SQL injection, probing for vulnerable scripts, port scans, ssh brute forcing, or something else? > (I doubt anybody tried very hard, it was lame botnet crap usually). You mean it was just random probes for specific open ports? > Later I hid it behind a router using NAT for convenience > in setting up a household LAN and all the "attacks" stopped, of course. Why do you say of course? You had a port forwarded through the NAT to reach it presumably, so why would the attacks stop? Maybe the NAT router simply prevented you from seeing all the probes and scans. > Putting your computer behind a router with only the specifically needed > open ports might be a simple and secure way to do what you want. Cheap, > quick to set up and perhaps even much less frustrating. As exaplained in another dusty corner of this thread. I want to be able to travel to customer premises with my laptop and often need to be on the same LAN segment for efficiency so a router is not a long term solution. It's just a stopgap while I'm working at my own desk. > Good luck! Thanks. SignatureJames Taylor > You're confirming that the firewall doesn't do its job? So Apple's own > flagship security feature is well known to be snake oil is it? Why is it the flagship security feature? they don't even mention it on their security page. Their flagship feature appears to be library randomization, sandboxing and code execute disable. SignatureWoody >> You're confirming that the firewall doesn't do its job? So Apple's own >> flagship security feature is well known to be snake oil is it? > > Why is it the flagship security feature? they don't even mention it on > their security page. Oh, then perhaps I just picked up the wrong impression from some of their marketing spin about how Leopard was a major security upgrade. > Their flagship feature appears to be library > randomization, sandboxing and code execute disable. I heard that, although those features are present, they're not widely used and thus the benefit is negligible. I don't have the expertise to test and verify that myself but, knowing Apple, it wouldn't surprise me. SignatureJames Taylor > I've been tinkering with this on and off for months. I'm getting > desperate now. I'm on the point of wiping VMware and even OS X off my > brand new MacBook Pro and installing Linux with KVM just so I can get a > properly secured VM hosting environment for my work. That's a good use of an expensive MBP. Why did you buy a Mac in the first place - there's lots of ways to run Linux cheaper. SignatureVery old woody beets will never cook tender. -- Fannie Farmer >> I've been tinkering with this on and off for months. I'm getting >> desperate now. I'm on the point of wiping VMware and even OS X off my [quoted text clipped - 3 lines] > That's a good use of an expensive MBP. Why did you buy a Mac in the > first place - there's lots of ways to run Linux cheaper. Well the thing is that my previous machine was a PowerBook, and it gave me a few years of great enjoyment. I learnt to love the Mac, despite some of it's less well thought out user interface design choices, and I would still be using that machine if I hadn't needed to run VMware on an Intel architecture for my work. So I bought the MacBook Pro because I expected to be able to have a smoother ride than if I'd bought a PC laptop to run Linux on top of Linux. Back then I didn't travel so much, and I knew a lot less about security. I had no idea it would prove so difficult to lock-down OS X. SignatureJames Taylor On Jan 21, 8:59 am, James Taylor <use...@oakseed.demon.co.uk.invalid> wrote: > Hi, > [quoted text clipped - 26 lines] > -- > James Taylor What about Little Snitch? Might that let you lock the system down enough for your tastes? > What about Little Snitch? Might that let you lock the system down > enough for your tastes? Yes, I have LittleSnitch. It's excellent. But as far as I know it only blocks outgoing traffic, and does not prevent incoming traffic aimed at one of the listening system services. If anyone knows otherwise please do tell me how. SignatureJames Taylor |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.