/etc insider

since 1999 (and still editing)

Linux netfilter aka iptables sucks at logging

| Comments

Actually I really like Netfilter. But when it comes to logging I have to admit – it sucks rather boundless. Why is that? Let me explain. The only way to get Netfilter logging is using a logging “target” and it has several “targets” suitable for that. For simplicity we can stick to target LOG – others logging purpose targets aren’t any different at the issue we’re talking about. So, the issue comes from the fact that by design you can have only one target per Netfilter’s rule. Basic targets are ACCEPT and DROP. So are you starting to get it? – Right, if you want to log some packet you’re discarding you have to postpone with the discard: LOG it first, then decide the fate of the packet. Thus if you want to LOG and DROP you need to repeat the same rule with different “targets”, say:

1
2
iptables -A INPUT -s 1.2.3.4 -j LOG -m comment --comment "We log you ..."
iptables -A INPUT -s 1.2.3.4 -j DROP -m comment --comment "... and drop finally"

– this effectively duplicates number of rules for one task and thus clutters the firewall. What if you want to change criteria – your abuser’s host IP changed from 1.2.3.4 to 1.2.3.5, – right, – now you need to change source IP twice on the both lines. This is, BTW, something related to so-called “database normalization”, you’d better take a look at what is it until it’s too late and your DB sucks even more that Netfilter’s logging.

Netfilter’s FAQ rather naively considers this is not a big deal. They suggest using combined, user-created targets. Yeah, BTW, this is the thing I like in Netfilter too. How can we (naively) try to overcome this shortcoming? – We create own target, say, logdrop and use it this way:

1
2
3
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Now we can log the abuser attempt and drop his malicious intents with one line:

1
iptables -A INPUT -s 1.2.3.4 -j logdrop

Cool? Well, not that really. The thing is you often want to have different parameters for logging. Say, sometimes, for one cases, you want to use limit thus limitting logging to 3 times per second (but drop every packet, of course). Sometimes you really need to have different log prefix so then later you can distinguish between different kind of accidents when you’re analyzing the log files. So it means now, if we’re following Netfilter guys’ advice, we have to create lots of different logdrop target. Say, Log3persecDrop, LogPrefixALERT-portscanDrop, LogReject (yeah, you can not only silently DROP packets, but REJECT them too). – Cluttering and mess again. How do others firewalls cope with it? For e. g., FreeBSD’s ipfw allows every rule has log option – it’s an option – “to log”, not a replacement for allowing packet to pass or denying it to do so.

Comments