Is it safe to unblock all incoming connections on firewall?

[pjny]

Hi, I am using 10.7.2 and Little snitch running. I just had to uncheck "Block all incoming connections" in the firewall and added the Omnifocus app to bypass the firewall so I can sync my to do list with my iPhone 4s.

Does unchecking "Block all incoming connections" still do the block all connections with the exception of the apps you add?

I checked "Automatically allowed signed software to receive incoming connections" and "enable stealth mode". Is this safe? I had previously blocked all incoming connections on 10.7.2.

I am using a Linksys WRT54GL Wireless Broadband Router.

Just want to be safe.

Thanks.

[KnightWRX]

This is my opinion, but frankly I find software firewalls running directly on the host completely useless. Let's face it, to get "attacked", you need an actual application listening on a socket. All software firewalls do is add a layer of ip filtering above and beyond what other mechanisms are already provided by those applications and even the system.

Looking at what is a potential attack vector on my system presently, I can see the following :

$ sudo lsof -n -i | grep LISTEN | grep -v 127.0.0.1 | grep -v IPv6
tcprelay    78           root    3u  IPv4 0xffffff800ca9a500      0t0    TCP *:10022 (LISTEN)
tcprelay    78           root    4u  IPv4 0xffffff800ca99de0      0t0    TCP *:italk (LISTEN)
tcprelay    78           root    5u  IPv4 0xffffff800ca996c0      0t0    TCP *:12346 (LISTEN)
Skype      222           user   56u  IPv4 0xffffff800ece4de0      0t0    TCP *:30718 (LISTEN)
X11.bin    511           user   10u  IPv4 0xffffff8011b946c0      0t0    TCP *:6000 (LISTEN)

2 of these processes (first name in the column) are running as my unprivileged user (3rd column). Skype and X11. Less worries there, X11 contains filtering rules as to who can give it display information through xauth, Skype could be a security whole if unpatched (or if the vendor isn't releasing patches for security issues) but the harm to the system is limited and a software firewall will simply "allow" traffic through anyhow since Skype is peer to peer and you can't really filter traffic if you want the application to work.

The other application, tcprelay, is not really indicative of what it is. To find out, we need to dig a bit deeper. It's running as root also, which can mean much more if an attacker successfully manages to exploit it to run code on the system (remote code execution). Let's see if the process can give us a few clues :

$ ps -fp 78
  UID   PID  PPID   C STIME   TTY           TIME CMD
    0    78     1   0  7Jan12 ??         0:00.01 /opt/nova/bin/tcprelay

Using the PID (2nd column), we can find out exactly what it is. This may not sound like much to you, but to me it says everything. This is part of nova, the technology Palm uses for their simulator for webOS. Basically, this is the daemon process that listens for connections from novaterm which is a shell to the simulator itself (which is a VM run under virtualbox).

Now, we can browse Secunia or SecurityFocus for any CVEs surrounding this process, or really, just stop it and prevent it to run if we're paranoid (and not actively working on a webOS project). Software firewalling it ? Why bother.

Other mitigating factors that the system provides are TCP wrappers. Most processes nowadays will make use of them. You can then define by process hosts that are allowed or denied, without filtering the rest of the incoming traffic.

A lot of "blocked" traffic is actually useful. People block ICMP like there's no tomorrow, thinking "ICMP = bad!" but they're quite wrong. ICMP, aside from the good old echo messages (ping if you like) speed up your connection. Yes, this is the way the Internet responds to your hosts and tells it of the many problems it can face so instead of waiting for timeouts to trigger or sending out sloppy packets, your system can adjust or fail gracefully right away. These include the following quite useful messages :

- ICMP unreachable (either network, host or port). If you block incoming ICMP unreachable messages, your stack will retry and retry to send packets until it reaches timeout. If your stack actually receives the unreachable message, it can fail immediately, thus you're not sitting there looking at a spinning something (depending on your system).

- ICMP fragmentation needed. An upstream router is telling you your MTU is too high and it has to fragment packets for you. This is costing it time and upping your latency to your destination. If you block this, the system can't react and optimize your frames to a size where no fragmentation is needed, lowering your overall latency to this destination.

- ICMP Time exceeded. Goes back to example number #1 but for a different reason. The TTL value is set too low for the number of hops you're going through. If your system doesn't know this, it'll retry and retry again, and you won't get a connection ever. This doesn't mean the remote host is not responding though, it just means your packets aren't getting there. If you had the Time exceeded message, the system could adjust, raise the TTL and get you the connection.

So frankly, your network is firewalled off by your NAT box (a side effect of running NAT/PAT, if you don't have translation rules from outside to inside, it's getting dropped anyhow) so unless you really have no confidence in the software listening on your host (and if you don't, why it is running and what filtering rules have you applied to it using existing mechanisms ?) there's really no issue in leaving your host "exposed" without a software firewall. Wireless network, again, a trust issue. Do you trust your wireless security ? And if it's broken, can an attacker on your network segment attack your host ? What do you do at a cafe ? Remember : A software firewall where you've allowed all your listening software is not protecting you anymore than nothing at all (except if the attacker is daft enough to forget the -P0 switch on his nmap command line, and then we're not exactly dealing with a genius here).

Again, my opinion.

[pjny]

Wow, thanks for the reply. I guess it will be ok to make an exception to the firewall since software-based firewalls are not airtight anyway.

Originally Posted by KnightWRX

This is my opinion, but frankly I find software firewalls running directly on the host completely useless. Let's face it, to get "attacked", you need an actual application listening on a socket. All software firewalls do is add a layer of ip filtering above and beyond what other mechanisms are already provided by those applications and even the system.

Looking at what is a potential attack vector on my system presently, I can see the following :

$ sudo lsof -n -i | grep LISTEN | grep -v 127.0.0.1 | grep -v IPv6
tcprelay    78           root    3u  IPv4 0xffffff800ca9a500      0t0    TCP *:10022 (LISTEN)
tcprelay    78           root    4u  IPv4 0xffffff800ca99de0      0t0    TCP *:italk (LISTEN)
tcprelay    78           root    5u  IPv4 0xffffff800ca996c0      0t0    TCP *:12346 (LISTEN)
Skype      222           user   56u  IPv4 0xffffff800ece4de0      0t0    TCP *:30718 (LISTEN)
X11.bin    511           user   10u  IPv4 0xffffff8011b946c0      0t0    TCP *:6000 (LISTEN)

2 of these processes (first name in the column) are running as my unprivileged user (3rd column). Skype and X11. Less worries there, X11 contains filtering rules as to who can give it display information through xauth, Skype could be a security whole if unpatched (or if the vendor isn't releasing patches for security issues) but the harm to the system is limited and a software firewall will simply "allow" traffic through anyhow since Skype is peer to peer and you can't really filter traffic if you want the application to work.

The other application, tcprelay, is not really indicative of what it is. To find out, we need to dig a bit deeper. It's running as root also, which can mean much more if an attacker successfully manages to exploit it to run code on the system (remote code execution). Let's see if the process can give us a few clues :

$ ps -fp 78
  UID   PID  PPID   C STIME   TTY           TIME CMD
    0    78     1   0  7Jan12 ??         0:00.01 /opt/nova/bin/tcprelay

Using the PID (2nd column), we can find out exactly what it is. This may not sound like much to you, but to me it says everything. This is part of nova, the technology Palm uses for their simulator for webOS. Basically, this is the daemon process that listens for connections from novaterm which is a shell to the simulator itself (which is a VM run under virtualbox).

Now, we can browse Secunia or SecurityFocus for any CVEs surrounding this process, or really, just stop it and prevent it to run if we're paranoid (and not actively working on a webOS project). Software firewalling it ? Why bother.

Other mitigating factors that the system provides are TCP wrappers. Most processes nowadays will make use of them. You can then define by process hosts that are allowed or denied, without filtering the rest of the incoming traffic.

A lot of "blocked" traffic is actually useful. People block ICMP like there's no tomorrow, thinking "ICMP = bad!" but they're quite wrong. ICMP, aside from the good old echo messages (ping if you like) speed up your connection. Yes, this is the way the Internet responds to your hosts and tells it of the many problems it can face so instead of waiting for timeouts to trigger or sending out sloppy packets, your system can adjust or fail gracefully right away. These include the following quite useful messages :

- ICMP unreachable (either network, host or port). If you block incoming ICMP unreachable messages, your stack will retry and retry to send packets until it reaches timeout. If your stack actually receives the unreachable message, it can fail immediately, thus you're not sitting there looking at a spinning something (depending on your system).

- ICMP fragmentation needed. An upstream router is telling you your MTU is too high and it has to fragment packets for you. This is costing it time and upping your latency to your destination. If you block this, the system can't react and optimize your frames to a size where no fragmentation is needed, lowering your overall latency to this destination.

- ICMP Time exceeded. Goes back to example number #1 but for a different reason. The TTL value is set too low for the number of hops you're going through. If your system doesn't know this, it'll retry and retry again, and you won't get a connection ever. This doesn't mean the remote host is not responding though, it just means your packets aren't getting there. If you had the Time exceeded message, the system could adjust, raise the TTL and get you the connection.

So frankly, your network is firewalled off by your NAT box (a side effect of running NAT/PAT, if you don't have translation rules from outside to inside, it's getting dropped anyhow) so unless you really have no confidence in the software listening on your host (and if you don't, why it is running and what filtering rules have you applied to it using existing mechanisms ?) there's really no issue in leaving your host "exposed" without a software firewall. Wireless network, again, a trust issue. Do you trust your wireless security ? And if it's broken, can an attacker on your network segment attack your host ? What do you do at a cafe ? Remember : A software firewall where you've allowed all your listening software is not protecting you anymore than nothing at all (except if the attacker is daft enough to forget the -P0 switch on his nmap command line, and then we're not exactly dealing with a genius here).

Again, my opinion.

[tyche]

I don't consider using a software firewall for blocking incoming 'attacks' or ensure your computer from compromise. What they are good for are blocking outgoing connections of software you want to use. I hate the amount of software and processes that chat away to foreign severs sending who knows what info.

I've never used little snitch like that but it sounds like its fine. You'd have to test it by turning off the signed option to test if it's blocking.

[robgendreau]

Thanks for all the information.

I'm no expert, hardly even knowledgeable user, but I got advice long ago to scrap the software firewall on my Macs and have never had a problem. Apple's implementation wasn't the clearest, in any case, and it often seemed to create more problems than it saved.

These days it seems it would be unlikely someone has a Mac connected to the outside world in such a way that you need the software firewall on.

Rob

[KnightWRX]

Originally Posted by tyche

I don't consider using a software firewall for blocking incoming 'attacks' or ensure your computer from compromise. What they are good for are blocking outgoing connections of software you want to use. I hate the amount of software and processes that chat away to foreign severs sending who knows what info.

You're talking about Application filters. So you want to use this software, but you'll block it. Unless it's software that works offline and you don't want it communicating to the outside world (scared of those activation servers are you ? ), then you probably just clicked "Allow" when the dialog popped up and asked you if you would let the software communicate to the Internet anyhow.

Know what you install, what is running and what is and isn't a vector for a potential attack. Education goes a long way.

And you do realise that OS X's firewall is not an application filter right ? It's a plain old port filter :



Notice the text. "Accepting incoming connections". Ah, good old port filter. It's just disguised as an "application filter" by automatically doing all the work I previously did (identifying listening services, tying them to applications and then asking you to setup "allow" or "deny" port filtering rules).