Title: RE: Netfilter State table questions

Hi Fionn,
>
>I'm having a torrid time with our security guys at the moment. They are
>extremely suspicious of the Linux firewall (running on RedHat 7.2) and I
>need some information/proof to throw at them (along with a couple of
>handgrenades!! :-)))) .
>
:-)

>Here are my list of questions. If anybody could help, or point me  towards
>some documentation, I'd be eternally grateful.
>
>1) How does netfilter maintain it's state table? I understand that one can
>view it in the /proc/ip_conntrack file, but does this give me a full picture
>of the state table?
>

As far as information you can see is concerned, I guess this is
more or less the only way to see the state table from userspace.

If you want more stringent control of the state table (ie. the
state tracking is a lot more than just the ESTABLISHED, RELATED,
NEW, INVALID states), try the conntrack patch from patch-o-matic.
It allows a lot more control over the way packets are dealt with
in iptables state tracking, and will help you understand things a
little better. It's written by one of the netfilter coreteam members
and should be added to the mainstream kernel fairly soon.

>2) Does the state stable keep things like IP sequence numbers so that
>session hijacking can be avoided, and an interface label (e.g eth0) that the
>state is for?

AFAIK, currently sequence numbers are only tracked when iptables
sees SYN,SYN/ACK,ACK handshakes (don't take my word on it though),
not for "normal" traffic.

I don't see how sequence number tracking could really prevent against
session hijacking (seriously, if someone would care to explain...).

However, there is a tcp window/sequence tracking patch in patch-o-matic
that is also eventually scheduled for kernel inclusion. It does full
sequence number tracking with window scaling, etc. So if you want it
now, it can be done.

>3) How would one go about confirming that netfilter does FULL stateful
>checking?

If you mean: does netfilter check for protocols attacks at the application
layer, like http or smtp buffer overflows, then the answer is: no.
Netfilter/iptables by itself doesn't offer the functionality of, say,
the "security server" extensions in Checkpoint Firewall-1.

However, if you want to do this type of checking for higher security,
you should take your packets up to userspace and let a proxy handle
them, possibly in a transparent way. The good thing is that
netfilter/iptables fully supports this. The Squid HTTP proxy has been
known to integrate very well with netfilter/iptables for transparent
proxying purposes. I know SuSE has an open source transparent ftp
proxy (I think it's called frox - not sure though) that should also
work. I've been known to redirect SMTP traffic to machines running qmail
via netfilter/iptables to handle all incoming and outgoing mail.

So the architecture and modular framework is there, but you'll have
to fill in the application proxy parts yourself.

Also note that netfilter/iptables does allow protocol tracking of
ftp, irc, GREP/PPTP, talk, eggdrop, H.323, tftp and some other protocols
I forgot. It basically means that netfilter/iptables will look into the
packets and check for any related connections that are about to be set up.
These checks are in kernel space and don't take the packet up to a userspace
program.

>4) Is there any way to alter the default session timeout periods without
>having to recompile the kernel?

Yes, if you apply the aforementioned tcp window tracking patch, you
will be able to control all the timeout settings via the /proc filesystem.

Regards & good luck,
Filip

Reply via email to