Is it safe to unblock all incoming connections on firewall?

Discussion in 'Mac OS X Lion (10.7)' started by pjny, Jan 15, 2012.

  1. pjny, Jan 15, 2012
    Last edited: Jan 15, 2012

    pjny macrumors 6502a

    Feb 18, 2010
    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.

  2. KnightWRX macrumors Pentium


    Jan 28, 2009
    Quebec, Canada
    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 | 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.
  3. pjny thread starter macrumors 6502a

    Feb 18, 2010
    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.

  4. tyche macrumors 6502

    Jul 30, 2010
    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.
  5. robgendreau macrumors 68040

    Jul 13, 2008
    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.

  6. KnightWRX macrumors Pentium


    Jan 28, 2009
    Quebec, Canada
    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 :

    Screen Shot 2012-01-16 at 8.19.08 PM.png

    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).

Share This Page