Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Feb 2007 11:17:00 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        admin <admin@azuni.net>, freebsd-net@freebsd.org, freebsd-questions@freebsd.org
Subject:   Re: ipfw limit src-addr woes
Message-ID:  <45DC9AAC.8090301@elischer.org>
In-Reply-To: <Pine.BSF.3.96.1070221180206.7164B-100000@gaia.nimnet.asn.au>
References:  <Pine.BSF.3.96.1070221180206.7164B-100000@gaia.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

if the keep-state rule is a skipto then the check-state will skip to..
I use that in some rules.

here's a snippet that I have when acting as a filtering transparent bridge,
with DNS replies (from the outside) being diverted to a snooper.
The bridge is between em2 (inside) and em3 (outside).

01200  17588453  1257728932 skipto 1210 udp from any to any dst-port 53 recv em2
01201  16192860  2721432229 skipto 1220 udp from any 53 to any recv em3
01202  43658738 21537916245 skipto 1250 ip from any to any
01210  34023270  3994649771 skipto 1240 ip from any to any keep-state
01220         0           0 check-state
01229      2364      441701 deny ip from any to any
01240  16190496  2720990528 divert 5001 udp from any 53 to any recv em3
01242  17832774  1273659243 deny ip from any to any

(note this requires patches  to allow divert from a bridge.)
It's convoluted I know but it only (well, mostly) diverts packets from 
the outside that are part of a conversation that was started already 
(probably by a dns request from inside) DNS packets from the outside 
that are not a response to something we already asked for are discarded 
(a DOS protection)

note that all the packets that went to the check-state, (1220) ended up going back to 1210
where they did the skipto 1240 and were filtered again.


> 
> 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.
> 
> [shrug]  Over to the ipfw gurus.
> 
> Cheers, Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45DC9AAC.8090301>