Query: linux tcp/ip stack logging capability used by external devices like a iptables
 

Dear Network Experts,

I am reasonably new to the Linux networking principles.

I am just wondering if the Linux networking stack records various attacks to the TCP/IP stack by itself. For example does it log errors of misaligned TCP flags (the setting of both syn and rst etc). And where would such error, failed attempt log files be stored? (Ubuntu user)

I am trying to figure out if various errors that arise within the TCP/IP stack could some how be used as guidance when designing for example firewall rules.

Consider if an offending IP address is launching a DoS attack for example a FIN-WAIT-2 flood attack can the server have its TCP/IP stack log this?
if this is the case then I can use various constraint reasoners and other nuts and bolts to automatically infer a set of dynamic firewall rules to mitigate/reduce attacks.

I understand that iptables can protect the network by implementing various best practices but I am keen to know more about the logging facilities that the server TCP/IP stack can perform on its own. After all, its doing deep packet inspection (using this term loosely) as it decouples the packet, so I presume it has the mechanics to record failed attempts and so forth.

Looking forward to your comments. I have just started on my quest today, so I am still just getting my teeth into the issue.

regards,
Bill.

the linux kernel does not do deep packet inspection (examination of the payload), but it does necessarily check packet headers for illegal formations, and generally just silently discards such packets (logging them creates its own security problems, such as logging floods). I'm unaware of any log settings within the network stack. There may be a way to turn some logging on for these events but you might have to edit the source and rebuild the kernel to do this.

As far as I know there's nothing out of the box that will do specifically what you want, especially as "attacks" are not categorized as such by the kernel or even by iptables. In general network packets are either well-formed and allowed or malformed and quietly discarded.

iptables has some logging features that will allow you to record some types of activity. you could implement it along the lines of:

iptables --state ESTABLISHED -j ALLOW # this allows pkts from established sessions
iptables -j LOG # this logs anything that wasn't deemed 'established' like NEW tcp sessions or stray FIN pkts

(don't use these verbatim - I've left out a lot of details that will be specific to your situation.) :)

Thanks for the response.

Presumably iptables is also open to log floods as it acts as a proxy logger for its inner systems!

Things are starting to make sense now, in particular as you mention packets getting silently discarded (and not logged). One solution that I already had in mind and you also mention is to have the firewall log packets that have non-compliant headers. Or snort logs.

I could then automatically reason over these logs and auto-configure a new set of firewall rules to mitigate threats to systems it protects.

I'll need to think more about this. I guess I was just hoping that end systems themselves could offer various network facts incurred on their own and then build protective rule sets and so forth to counter them.

Of course if the server was running external TCP stack mechanims for example TCP-Wrapper or snort, I could just interpret its failed log attempts and push the dropping of such packets up stream. Thus bringing about security-in-depth. (I am aware of snort-inline also)

But that was not what I was thinking about as I wanted to know if *vanilla* tcp/ip stacks on servers or even end-client systems could be used in the guidance process. While they themselves would not have the semantic capability to understand the attacks, constructing a reasoner would and thus automatically configure the firewall.

Once again, thanks for your input.
Back the drawing board for me :-)
regards,
Bill.