iptables good packet chain (instead of bad packet chain)
 

Almost anyone who's used Netfilter/iptables for packet-filtering is familiar with "bad packet chains". They are user-built chains with rules that match packets with characteristics you consider to be "bad", mainly unusual TCP flag combinations. Essentially, a bad packet chain is a packet blacklist (default allow).

I've often wondered if anyone has ever taken the opposite approach. That is, use a whitelist (default deny) to create a "good packet chain" instead. Default deny has shown to be a much more solid approach than default allow when it comes to information security in general, and I would like to know if it is feasible to use it in this particular context.

Some specific questions I have might be: Would it be asking for trouble? Would it take too much work to build this kind of chain? Is it worth the effort? Your opinions on these and any other relevant questions would be greatly appreciated.

Its definitely worth the effort. It is more secure especially if you default deny on all 3 main chains (input, forward, output). When you are first setting it up make sure you do it on a local machine that you have console access because more than likely you'll lock yourself out network wise at least once. Usually people only need a few "good" rules, though output can be messy which leads most people to just doing the deny on input and forward (which is still a good idea).

It seems you've misunderstood my question. I'm not referring to default policies for the built-in chains. I'm referring specifically to user-built chains designed to filter packets with bad TCP flag combinations. These chains are AFAICT always designed using a default allow approach (not a policy, as user-built chains don't have policies). My question is about changing from a "match all packets with weird TCP flag combinations" approach to a "match all packets with proper TCP flag combinations" one. Whatever you've got set as a default policy for your built-in chains is irrelevant in this case. Thanks for your reply, though, as it allows me to clarify my question - something I was expecting I would need to do.

hehe, glad I could be of some service at least, sorry it wasn't to answer the question :)

You can see an example of a typical bad packet chain here:As you can see, the chain sends to LOG and then to DROP any packets which are determined to have a weird combination of TCP flags. There are, of course, much more lengthy bad packet chains out there - this is just an example.

The idea I've been kicking around is to do the inverse, kinda like this:As you can see, this would send to ACCEPT any packet with a valid TCP flag combination, and those which don't have one will get sent to LOG and then to DROP. I've only used one possible ACCEPT rule to illustrate, the idea is of course to have enough rules to cover all proper TCP flag combinations (instead of trying to cover as many bad ones as possible).

Okay, I decided to go for it and get started with a proof-of-concept. I've made a CHECK_FLAGS chain with matches for the TCP flag combinations which AFAIK I need for the handshake, data transfer, and termination phases. Here's the rules I'm using to test right now, with INPUT policy set to DROP and OUTPUT policy set to ACCEPT. This is on my laptop, which does run one service (BitTorrent), so the TCP flags I'm checking include both client and server angles.
A few things to note: I'm only checking packets in the ESTABLISHED state, as the check for packets in state NEW is a one-liner (they need to have the SYN bit set and the RST, ACK, and FIN bits unset, which is what the --syn match does). Since I know that for my laptop all incoming packets in state RELATED should be ICMP, I'm just sending to DROP any which aren't. Of course, every packet sent to DROP is sent to LOG first so that I may spot problems. So far the CHECK_FLAGS chain seems to be working just fine, but I'm expecting that I'll need to make changes after I've tested it more thoroughly.

Okay, after a couple days worth of testing, I've concluded that the whitelist approach is feasible. I can also say somewhat less conclusively (I still need to do more testing) that it works well. That said, I haven't really finished the chain yet, as I haven't been able to decide on how to deal with bad PSH and URG flags yet (I could easily do some blacklisting, but the whole point of my endeavor is to do whitelisting only).

Here's what I've got so far:As you can see, pretty much the only thing that's changed since my last post is the addition of a match in the CHECK_TCP_FLAGS chain for packets with the SYN bit set (I've put the rule in bold). With that rule commented, I get several SYN packets being sent to DROP. This is interesting, as these are packets which the kernel sees as being in the ESTABLISHED state (otherwise they wouldn't be traversing that chain). Here's a sample from my log file to show you what I mean:I used QUOTE tags instead of CODE tags for that as otherwise the page rendering gets all weird and stuff, sorry. Can anyone shed some light as to what conditions would make Linux/Netfilter treat certain SYN packets as being in the ESTABLISHED state?