OS X firewall - how to make it actually work
in [UK Mac]
|
From: James Taylor on 21 Jan 2010 06:49 Richard Tobin wrote: > James Taylor wrote: > >> 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. -- James Taylor
From: James Taylor on 21 Jan 2010 06:57 Woody wrote: > James Taylor wrote: > >> 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. ;-) -- James Taylor
From: Graham J on 21 Jan 2010 06:57 "James Taylor" <usenet(a)oakseed.demon.co.uk.invalid> wrote in message news:7rqmlrF1v2U1(a)mid.individual.net... > Jim wrote: > >> 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. 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. -- Graham J
From: David Sankey on 21 Jan 2010 07:03 In article <7rqq7mFltfU1(a)mid.individual.net>, James Taylor <usenet(a)oakseed.demon.co.uk.invalid> wrote: > Jaimie Vandenbergh wrote: > > > James Taylor wrote: > > > >> 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? 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
From: Richard Tobin on 21 Jan 2010 07:22
In article <7rqt9tF7ftU1(a)mid.individual.net>, James Taylor <usenet(a)oakseed.demon.co.uk.invalid> wrote: >> 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 -- Please remember to mention me / in tapes you leave behind. |