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 :
Code:
$ 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 :
Code:
$ 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.
), 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.