Netfilter questoin

(E-Mail Removed) wrote:
> Does netfilter look at all packets or just packets that are not part of
> an established connection?

All. How else would you be able to filter based on whether it is NEW,
RELATED, ESTABLISHED, or INVALID?

If it only looks at packets that are not
> part of an established connection how can it tell. Does it look to see
> if the SYN flag is set or does it look for the absence of an ACK bit?

I'm sure you should be able to find this with google. Or look at
netfilter's code. In other words, how the hell should I know, it just does.

Does netfilter look at all packets or just packets that are not part of
an established connection? If it only looks at packets that are not
part of an established connection how can it tell. Does it look to see
if the SYN flag is set or does it look for the absence of an ACK bit?

rexwe...@gmail.com wrote:
> Does netfilter look at all packets or just packets that are not part
of
> an established connection? ...

It inspects every packet.

> If it only looks at packets that are not
> part of an established connection how can it tell.

Precisely why it inspects every packet -- so it _can_ tell ;-)

> Does it look to see
> if the SYN flag is set or does it look for the absence of an ACK bit?

Depends on your filter rules. Every packet is inspected to look for a
match against the list of rules (in the order you enter/insert them),
then netfilter does as you instructed it.

If no rule matches the packet then the default rule applies. This is
why the default for incoming packets is recommended to be DROP. Ie.,
if you don't allow it in with a specific rule it is DROPed.

Because every packet is inspected, on a desktop system especially, the
first rule should be re: ESTABLISHED as most packets will be packets
you requested (and presumably safe). The faster the packets can be
matched against the _appropriate_ rule, the quicker they can be
processed.

At least this is the general idea of ordering. There are a few
exceptions.

hth,
prg
email above disabled

> Does netfilter look at all packets or just packets that are not part of
> an established connection?

As the others have stated, "all".

> If it only looks at packets that are not
> part of an established connection how can it tell.

It keeps track of established connections itself. It does this by watching
the syn/ack handshake go back and forth between two IPs, then it knows it's
an established connection. It can also tell "related" connections with the
extra modules like the ones that actually watch ftp connections and can tell
when a data ftp port has been opened and the new data connection is now
marked as "related".

> Does it look to see
> if the SYN flag is set or does it look for the absence of an ACK bit?

It watches the flags when the connection is being established and when it is
torn down. That's how it knows in the middle of a transmission that this
particular packet is part of (or not part of) an already established
connection.

When it sees a new handshake initiate it makes a new connection tracking
entry and waits to see if the handshake will complete. It will keep track
of `cat /proc/sys/net/ipv4/ip_conntrack_max` connections, and you can change
this number by `echo "32768" > /proc/sys/net/ipv4/ip_conntrack_max`, or
sticking in some other number to suit you fancy. I'm sure it has a hard
upper limit, but I've never reached it and I've always used 32768.

This keeping track of connections can actually turn into a DoS opportunity.
Since I use 32,000 connections someone could theoretically open 40,000
connections (and not close them) by initiating the connections and thus
overflow my connection tracking buffer. Then my netfilter wouldn't know if
real packets are existing or not.

You can turn connection tracking off. And there is a new netfilter -j
designator, the tar baby. Tar baby sends back a ack/syn pair for whatever
connection you are doing the tar baby on. So if you have someone that just
rips along looking for open ports, tar baby makes all the ports (that you
specify) look like they are open when they really aren't. The result is two
fold on the scanner/attacker: (1) if the scanner is using resources for each
one of the connections of the scan, his scan is causing him to eat up
resources, and (2) the scanner thinks every port is open and can't tell
which ones are tar-baby and which ones are real without further
investigation, by then your firewall should be alerted as to the scan and
have the remote IP blocked out permanently. If you do tar baby, make sure
you turn connection tracking off, or else all those ack/syn packets tar baby
sends back will make netfilter think that it is a real connection.

Wow! Thanks for the great info! It is exactly what I was looking for.