Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'I'm afraid...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
I'm afraid...
Authored by: marook on Mar 13, '06 03:40:39PM

Well, as already mentioned above, if the app/service/deamon that would respond to the Incoming port is not running, then no service/port is open on that port - unless it's registred with launchd and then auto-open when traffic comes in on that port (as it has told launchd to respond to that port)

What the firewall does, is allow the traffic from the low-level network layer to reach the application layer if any app is listening on the given port.

So: Quit the app = port closed!


[ Reply to This | # ]
I'm afraid...
Authored by: Whyatt on Mar 13, '06 04:08:04PM
Well, I do see denied traffic in the ipfw logs for traffic from ports for apps which are currently running. This shows that unless you open up the port manually in the ipfw preferences, there will be denied traffic on these ports.

And leaving the ports open in the ipfw configuration leaves them always open. I've also seen this from denied traffic to these ports logged in the ipfw logs when these apps aren't running.


[ Reply to This | # ]
A better solution...
Authored by: tbo on Mar 13, '06 05:04:41PM

A port is only "open" if an application is listening on the port, and the port is not blocked by a firewall. If the port is not open, you are not vulnerable on that port (unless your network stack itself is vulnerable, in which case you're very, very screwed and a software firewall probably won't save you).

One of two things can happen if a remote computer tries to open a connection to a port on your computer that's not open. Normally, your computer will simply send a RST packet, telling the remote computer that that port is closed. This is what happens with no firewall, or with the Apple firewall (ipfw) in Apple's default configuration. If you turn on "stealth" mode, no response at all is sent. Go grab yourself a copy of nmap and play around to learn how this all works.

Your script gains you essentially no security against network-based attacks, and leaves you highly vulnerable to local attacks. In particular, any local user could use a privlige escalation attack (of which there are apparently some unpublished against OS X) to gain access to your unencrypted password. Since your login password is probably the same as your keychain password, they now own all the passwords in your keychain. This is very bad.

A much, much better thing would be if your firewall intelligently and dynamically allowed inbound traffic only from hosts to which you had already established an outgoing connection. This is called a stateful firewall (because it keeps track of state, in the form of recently open connections). The good news is that ipfw supports this, but you'll have to do it on the command line. What's more, it's not trivial. Go check out the man pages for ipfw and learn how your firewall works. Test things with nmap. For a few ports, you may need to open up a somewhat broader hole in the firewall, but with care that will be OK. It's important to note that this is something that requires you to know what you're doing to some degree, since everyone's network setup and needs are different and a one-size-fits-all solution can't work.

See this link for some help with a simple stateful firewall.

[ Reply to This | # ]