Ian Smith wrote:
On Tue, 20 Feb 2007, Julian Elischer wrote:
> admin wrote:
>
> > Wrong: the implied "check-state" done by the "limit" lets the connection
> > through (i.e. performs the action) iff there's state recorded for it
> > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet
> > incoming and the number of current states is trying to cross the limit,
> > the SYN packet is implicitly dropped and the search terminates.
> >
> > This is not to say that I completely understand the things going on when
> > the connections start building up (different timeouts?) but the above
> > conclusion is based on what simulation has shown. The whole ruleset fits
> > on one screen, there's an "allow ip from any to any" in the end, so I'm
> > pretty sure I'm not crazy :-)
>
> One thing to keep in mind is that a 'check-state' rule works by effectively
> jumping to the rule that did the 'keep-state' and re-executing it..
> (and incrementing its stats).
What if the action of the rule that does the 'keep-state' (here a limit
src-addr) is a skipto, rather than an allow / fwd / divert etc rule that
would terminate the search? Does 're-executing' here imply anything
about whether the skipto's conditional branch is or is not taken?
I bought into this because admin said that more connections were being
allowed than the limit src-addr clause should allow, and I assumed that
the skipto branch was not being taken on over-limit packets, and that
the following fwd rule (allowing any type of packets including SYN) was
being executed, which would account for what he'd said was happening.
admin above asserts that my assumption was wrong, and that in a match
beyond the limit number of connections for that src/dest address, the
setup packet is 'implicitly dropped and the search terminates', and
while I can't find that stated as such in ipfw(8), he may be right.
Which still doesn't explain why connections from a particular IP beyond
his specified limit are allowed to be established, as originally stated.
I've changed "limit src-addr N" to "limit src-addr dst-addr N" - to key
the limit on client parties trying to pose some single external IP
address under attack (and, admittedly, the transparent proxy down with
it :))
Some bit of scripting below allows me to monitor ipfw's dynamic rules
usage keyed by src-addr+dst-addr, sorted by rule count (top 10 users):
ipfw -d show | sed -n '/^## Dynamic rules /,$p' | tail -n+2 | awk '$5 ==
"LIMIT" { k=sprintf("%s %s", $7, $10); a[k]++ } END { for (i in a)
{printf "%3d %s\n", a[i], i }}' | sort -nr -k1,1 | head
Typical output:
32 client1.ip.ad.dr x.x.x.x
30 client1.ip.ad.dr y.y.y.y
20 client1.ip.ad.dr z.z.z.z
14 client2.ip.ad.dr e.f.g.h
...
it shows that client1.ip.ad.dr has 32 connections to x.x.x.x, 30
connections to y.y.y.y, etc.
And here's the thing: when under "attack", netstat -na | fgrep
client1.ip.ad.dr shows a huge number of connections to some single
x.x.x.x, port 80 in the ESTABLISHED state - 2, 3 times the value of
limit - with full send queue usage (as determined by
net.inet.tcp.sendspace) - all opening at a very fast pace!! The ipfw -d
script, though, shows that the limit is not yet even crossed! Only when
the netstat's connection count gets to 4-5 times the limit does ipfw
start to realize something's wrong and drop packets - the usage count
shown by the script above is then strictly that of "limit src-addr N"!
It _must_ some different timeouts, I don't know _which_ timeouts though.
True, some buggy web-browsers of many "good" clients leave the
connection in the FIN_WAIT_2 state until timed out - and this still
counts as open (eats up a socket etc.) - that's why I was forced to
change "limit src-addr N" to "limit src-addr dst-addr N" to better get
the idea.
[shrug] Over to the ipfw gurus.
Ditto.
Cheers, Ian
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
