IPTables - The absolute minimum for a laptop?
 

What would be the minimum iptables rules for laptops that travel a lot, and might connect in potentially hostile networks? I came up with (log rules left out):

My questions are:
1) Is there missing anything essential?
2) Is the filter for invalid packets really necessary?
3) Are there special rules needed for VoIP (STUN, uPNP)?

(PS: There sure are many firewall scripts out there, and I used several, but IME they offer many options I don't need, but don't have the logging options I want.)

For a general use laptop setup that should be good. The basic idea is to block all inbound connections initiated by a remote source, allow all outbound connections, and return traffic from a connection initiated by the laptop. If you wanted to get more secure you could also lock down outbound connections to those you know are valid (ie only HTTP, HTTPS).

As for any problems with particular protocols my general feeling is setup on the more restrictive side, test everything I use, and then begin adding exceptions if I have any issues.

One important thing to keep in mind is that Linux is NOT Windows. In Windows, a firewall is an absolute necessity because applications are active by default and the ports that listen on them are also. With very few exceptions, this is not the case in Linux. In Linux, the default is for no ports to be listening, unless you have installed an application listening on them.

Having said that, installing a firewall is still a good idea. In fact, you should set it to default to drop inbound traffic and only open the ports that you desire services for. This acts as a protective wrapper against inadvertently or unknowingly opening a port. Your approach in this regard is correct.

A public network is no more or less hostile than you home network and in some ways may be less hostile. What I mean by this is that depending on how it is configured some hostile traffic may already be filtered out. In a public network, you have an increased potential for packet sniffing and other forms of eavesdropping which is fairly easy to secure against. On your home or business network, you are more likely to experience brute force attempts to guess passwords and force access to your machines.

For a laptop that travels a lot, I would recommend focusing on a good VPN arrangement that tunnels your traffic via a secure, encrypted connection. This can be as simple as an SSH tunnel or as complex as a full hardware based VPN.

Absolute minimum? Well, I'd say get rid of the rule for packets in state INVALID, as it's not necessary.

That is, an inbound packet (on an interface other than loopback) in state INVALID will run into your DROP policy regardless, as the RELATED/ESTABLISHED rule won't send it to ACCEPT.

Very interesting, that's why I asked, and sure it is logical. Nevertheless, every firewall script I've seen sets up a dozen rules for invalid ("dangerous") packets, with several combinations of SYN,RST,ACK,etc. checks, so I thought an INVALID check is necessary.
Why are those scripts doing that? Or is this something different?

Well, state INVALID means "that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any known connection", which is not the same as looking for weird TCP flag combinations (which is what those scripts you're making reference to do). If you weren't matching inbound packets of states RELATED/ESTABLISHED exclusively, then a match for INVALID packets would be beneficial, as there wouldn't be any other way to get them. For example:The above will send INVALID packets to ACCEPT, as long as they are TCP and have destination port 22 on them.

If, however, we specify the state like:...then we're making sure that packets in state INVALID don't ever get sent to ACCEPT, since they won't match any rule and will consequently run into the policy (which is DROP here). In your case, you aren't allowing inbound connections so it's an even simpler situation.

In short, the INVALID match and bad packet chains are two separate things. That said, one of the matches you typically see people include near the top of a bad packet chain is the INVALID one, as it's a no-brainer.

Thank you for this very informative post.

In conclusion, apart from using the "--state NEW" condition for eventually opened ports (as an alternative to a general INVALID filter at the top), it seems that I should add bad packet chains to my minimum configuration. I hope I'll understand these without reading the RFCs for TCP/IP ;-) , but of course I can copy them from a firewall script.

HTH! BTW, I once tried to go in the opposite direction (that is, I tried to create a good packet chain instead of a bad packet chain), but I lost interest and gave up on it (as you can see if you visit the linked thread). I also didn't have much luck finding other LQ members who were into that sort of thing. Just thought I'd mention it in case you get bored and would like to give it a shot. But I digress, as none of this is in the same ballpark as "absolute minimum for a laptop".