OS X Leopard Firewall Flawed 300
cycoj writes with a report in the German IT magazine Heise, taking a look at the new OS X Leopard firewall. They find it flawed. When setting access to specific services and programs to only allow SSH access, for example, they found that a manually started service was still accessible. From the article: "So the first step after starting Leopard should be to activate the firewall. The obvious choice to do so is the option to 'Set access to specific services and programs,' which promises more control over network traffic. Mac OS X automatically enters all shared resources set up by the user, such as 'Remote login' for SSH servers, into the list of accessible resources... However, initial functional testing quickly dispels any feeling of improved security. A service started for testing purposes was able to be addressed from outside without any difficulty. The firewall records this occurrence... Even with the firewall set to 'Block all incoming connections' ports to netbios, ntp and other services were still open... Specifically these results mean that users can't rely on the firewall."
As any new OS (Score:4, Interesting)
Re:Never put your eggs in one basket. (Score:5, Interesting)
Also, FYI, a hardware firewall is just a dedicated software firewall.
Re:OS Firewalls (Score:1, Interesting)
Anyone tested this? (Score:3, Interesting)
Re:Investigation flawed, more like (Score:2, Interesting)
If you are testing software and don't want it accessible from the outside world, Leopards trust be damned, you want it blocked. I agree with the author here, even if he managed to miss the obvious text: any hole in the firewall should be put there explicitly via the administrator of said firewall (or the machine it is on), not left default by the OS and it's own preferences. If MS didn't the same thing everyone would get pissed. If Linux did the same thing [I'd hope] everyone would get pissed. If *BSD did the same thing, the devs would probably get brutalized by their own fanatics.
Re:Never put your eggs in one basket. (Score:1, Interesting)
Never assume that you are 100% safe. There are always ways around things...
It made me wish I worked at a place like this [ctrlaltdel-online.com] just so I could tell them where to stick their virus protection.
Re:Anyone tested this? (Score:3, Interesting)
Do a
sudo lsof -iUDP
and you will see all the services listening on UDP ports.
bye, ju
Wait a second... (Score:5, Interesting)
Re:OS Firewalls (Score:4, Interesting)
Unfortunatly, Apple's apparently company line (based on what I've heard from Apple sales reps) is that you don't need any "3rd party security software". Specifically, I overheard a salesperson speaking to a customer who was buying a notebook computer for his daughter (who was going to college), saying that the customer didn't need to purchase any of that kind of software, because OS X had no security holes. I did restrain myself from taking the salesperson to task for this in front of the whole store - but only because I didn't want to get kicked out of the store - as I hadn't completed my purchase yet. If I'd already gotten my iPod, I would have, as least, brought this to the manager's attention. As it is, it'd been a long day, and I wanted to get my iPod and go, so didn't make a deal about it.
In retrospect, I should have made a bit of a fuss about it, and were the situation to happen today, especialy with what I learned from TFA, I would certainly have called the salesperson on this (albeit after I'd gotten my iPod - I'd rather not get kicked out of the store before I made my purchase).
Re:Never put your eggs in one basket. (Score:2, Interesting)
Re:Investigation flawed, more like (Score:5, Interesting)
Er, yeah, but... these are Mac users you're talking about. The people who've been sold a computer that ordinary people can use without being computer experts, and which doesn't get viruses like Windows does. (Not counting the Linux refugees, of course.)
Re:I am not convinced (Score:3, Interesting)
The NTP port is easy enough to explain. NTP is a UDP-based protocol, so there aren't any connections. When operating properly, the time interval between packet exchanges with the time servers is long so maintaining the equivalent of a TCP masquerading map isn't feasible (you either need unreasonably long timeouts leading to odd behavior when the entries become invalid but aren't timed-out, or you tend to time out active entries). Since NTP packets are fairly simple and, being UDP, arrive in a single message with the length known as the packet is read, NTP clients aren't generally subject to buffer overflow attacks. Since they also default to not trusting or accepting synchronization from any hosts other than those they're configured to use and to only accept packets from those hosts that're in response to a known request from the client, and serving time up to random clients is considered safe for the server, it's not considered a risk to have them accessible and it simplifies the firewall rules considerably to just leave the NTP port open to the world.
Re:Investigation flawed, more like (Score:3, Interesting)
Apple is the one company on the market who I trust to actually do user tests. I'm also fairly sure they found out that Joe Average clicks on "block incoming connections" and still expects stuff to work. Which is why they made it behave that way, put the info into the help file for those of us who RTFM and give you commandline access and ipfw if you really know what you're doing.
Re:Never put your eggs in one basket. (Score:3, Interesting)
Re:Anyone tested this? (Score:2, Interesting)
Re:Investigation flawed, more like (Score:3, Interesting)
I know what a stateful firewall is.. but the fact is that for UDP, there's no such thing. Some stateful firewalls were do protocol inspection to fake state by figuring out when to expect a DNS packet, but UDP is by definition stateless. Without reading the protocol at a higher layer, there's no way to tell state from only the UDP headers.
As for source and destination ports, that's irrelevant. A request from my machine going to the DNS server will have source port > 1024 and destination port 53. The response will reverse those - source port 53, destination port > 1024. How exactly am I to tell by looking at that information if a packet destined for a high port on my machine from UDP 53 is truly a reply or not? The only reliable way is to read outbound packets for requests, and keep a faux-state -table of what I should expect in response. It works similar to state, but is not the same, and has a non-trivial amount more overhead.
Might also be a flawed analysis... (Score:4, Interesting)
Specifically that the open|filtered may mean the ports are in a stealth mode... which is what you want!
I did a port scan of my Leopard machine from a Tiger machine and didn't see any open ports at all. I'm not running the firewall either -- but I don't have any services turned on right now. That's the way OS X ships by default (and has since as least 10.2).
Not arguing that things couldn't be better communicated by Apple, but I think an article claiming they're taking a Microsoft-esque tact toward security is more than likely politically loaded.