Re: ipfw limit src-addr woes
On Wed, 21 Feb 2007, Julian Elischer wrote: > 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. Thanks Julian, great illustration! After much chewing I've got most of the marrow, but have buried this bone where I can dig it up again (woof) Re admin's issue, I notice that the em3 packets failing check-state still require denying at 1229, such that p(kts)1201 - p1229 = p1240. Do you have any earlier rules jumping into here too, as the 1210 packet counts don't quite add up; ie p1210 > (p1200 + p1240) by ~244k packets? Re 1242, are these (mostly) diverted packets reentering the firewall? After snooping, how do the clients get their DNS replies if they're denied here, or does your divert code reinsert those elsewhere? And where do the then ~1.2M extra denied packets denied here come from? Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
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. [shrug] Over to the ipfw gurus. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
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). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
Ian Smith wrote: On Mon, 19 Feb 2007, admin wrote: > Ian Smith wrote: > > On Mon, 19 Feb 2007, admin wrote: > > > Andre Santos wrote: > > > > On 2/18/07, admin <[EMAIL PROTECTED]> wrote: > > > > > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > > > >> connections a single IP can have at the same time in a transparent > > > >> web-proxy environment: > > > >> > > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > > > >> 80 in via if0 setup limit src-addr 10 > > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > > >> ... the rest fwd... > > > >> > > > >> as I understand the manpage, when the current number of connectiions is > > > >> below 10, the action "skipto" is performed, else, the packet is dropped > > > >> and the search terminates. But... > > > > No, a packet is not dropped on a condition that fails a skipto test. > > > The manpage doesn't make this point clear. You pretty much have to read it all .. several times .. a year. One of the things you note is that each rule is tested until a packet is either allowed or denied by a rule, even until '65535 deny ip from any to any'. > limit {src-addr | src-port | dst-addr | dst-port} N > The firewall will only allow N connections with the same > set of parameters as specified in the rule. Yes, for this rule. It still needs to be applied to an allow or deny (or forward, divert etc, anything that terminates the search). > To limit the number of connections a user can open you can use the > following type of rules: > ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 > ipfw add allow tcp from any to me setup limit src-addr 4 Yes. Notice that these are allow rules, so the search terminates when successfully matched. It is assumed you'll later have rule/s denying what you've not allowed. True, this is not stated with every example. > I'm assuming the packet gets silently dropped when the limit is > overloaded but gets acted upon otherwise due to the stateful "limit" > behaviour (keep-state in disguise). Just do a "skipto" when there's a > state entry and that's it. And that's why the counter grows for > established connections too, even though there's a "setup" modifier. Can't tell without seeing your whole ruleset, but now that you know that the skipto rule has NOT dropped the setup packets that don't match that rule (including those exceeding the src-addr limit), I suspect you'll find another rule has allowed them, on some other condition, later on. 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 :-) > As for the problem, it seems to me that all this noise is because of > different timeouts in ipfw and TCP layer/whatever. The dynamic state > entry for a connection expires while netstat -na still show the > connection as ESTABLISHED, or, worse, the state entry is still there but > the corresponding connection is in some half-closed state (FIN_WAIT_2, > CLOSE_WAIT, LAST_ACK). The first case allows many more connections than > "limit", while the second case won't let many good clients connect due > to their buggy browsers not closing connections and letting the count > build up. Could this be it? I don't believe so. They can only have been established in the first place if the setup packet has been, somewhere in your ruleset, allowed. Yup. Then, after setting up the connections, the state times out earlier than the actual connection shown by netstat! Gotta play a bit more with the *_lifetime sysctls... And yes (answering to someone else on the list), net.inet.ip.fw.dyn_keepalive is on: I don't tend to mess with the default values of things I don't understand or care about... only what's absolutely necessary. Here it seems they're allowed (at least the ones from x.x.x.x/x) by the fwd at 401 which has no 'setup' constraint, and will fwd both setup AND established packets from x.x.x.x/x .. other rules, y and z, presumably. Replaying .. trying not to do quite so much in one rule, but given you can't just 'allow' here, since you want to run your fwd rules later: > 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port \ > 80 in via if0 setup limit src-addr 10 0
Re: ipfw limit src-addr woes
On Mon, 19 Feb 2007, admin wrote: > Ian Smith wrote: > > On Mon, 19 Feb 2007, admin wrote: > > > Andre Santos wrote: > > > > On 2/18/07, admin <[EMAIL PROTECTED]> wrote: > > > > > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > > > >> connections a single IP can have at the same time in a transparent > > > >> web-proxy environment: > > > >> > > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any > > dst-port > > > >> 80 in via if0 setup limit src-addr 10 > > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > > >> ... the rest fwd... > > > >> > > > >> as I understand the manpage, when the current number of connectiions > > is > > > >> below 10, the action "skipto" is performed, else, the packet is > > dropped > > > >> and the search terminates. But... > > > > No, a packet is not dropped on a condition that fails a skipto test. > > > The manpage doesn't make this point clear. You pretty much have to read it all .. several times .. a year. One of the things you note is that each rule is tested until a packet is either allowed or denied by a rule, even until '65535 deny ip from any to any'. > limit {src-addr | src-port | dst-addr | dst-port} N > The firewall will only allow N connections with the same > set of parameters as specified in the rule. Yes, for this rule. It still needs to be applied to an allow or deny (or forward, divert etc, anything that terminates the search). > To limit the number of connections a user can open you can use the > following type of rules: > ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 > ipfw add allow tcp from any to me setup limit src-addr 4 Yes. Notice that these are allow rules, so the search terminates when successfully matched. It is assumed you'll later have rule/s denying what you've not allowed. True, this is not stated with every example. > I'm assuming the packet gets silently dropped when the limit is > overloaded but gets acted upon otherwise due to the stateful "limit" > behaviour (keep-state in disguise). Just do a "skipto" when there's a > state entry and that's it. And that's why the counter grows for > established connections too, even though there's a "setup" modifier. Can't tell without seeing your whole ruleset, but now that you know that the skipto rule has NOT dropped the setup packets that don't match that rule (including those exceeding the src-addr limit), I suspect you'll find another rule has allowed them, on some other condition, later on. > skipto is a nice thing as it allows you to AND rules ;-) or to OR, NAND or NOR :) Reminds one that a ruleset is procedural. > Besides, that's what my humble testing came up with - connections over > the limit DO get dropped... if done nicely. > > As for the problem, it seems to me that all this noise is because of > different timeouts in ipfw and TCP layer/whatever. The dynamic state > entry for a connection expires while netstat -na still show the > connection as ESTABLISHED, or, worse, the state entry is still there but > the corresponding connection is in some half-closed state (FIN_WAIT_2, > CLOSE_WAIT, LAST_ACK). The first case allows many more connections than > "limit", while the second case won't let many good clients connect due > to their buggy browsers not closing connections and letting the count > build up. Could this be it? I don't believe so. They can only have been established in the first place if the setup packet has been, somewhere in your ruleset, allowed. Here it seems they're allowed (at least the ones from x.x.x.x/x) by the fwd at 401 which has no 'setup' constraint, and will fwd both setup AND established packets from x.x.x.x/x .. other rules, y and z, presumably. Replaying .. trying not to do quite so much in one rule, but given you can't just 'allow' here, since you want to run your fwd rules later: > 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port \ > 80 in via if0 setup limit src-addr 10 00350 skipto 370 tcp from ${thatmob} to any dst-port 80 in via if0 00360 skipto 401 ip from any to any # bit clunky, but !(all that) 00370 skipto 401 tcp from any to any setup limit src-addr 10 # goodies 00380 deny tcp from any to any # else baddies > 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > ... the rest fwd... FWIW: not only have I never used limit src-addr, but neither forward with keep-state rules, so I could be talking ${hit} .. caveat bloggor. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
Ian Smith wrote: On Mon, 19 Feb 2007, admin wrote: > Andre Santos wrote: > > On 2/18/07, admin <[EMAIL PROTECTED]> wrote: > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > >> connections a single IP can have at the same time in a transparent > >> web-proxy environment: > >> > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > >> 80 in via if0 setup limit src-addr 10 > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > >> ... the rest fwd... > >> > >> as I understand the manpage, when the current number of connectiions is > >> below 10, the action "skipto" is performed, else, the packet is dropped > >> and the search terminates. But... No, a packet is not dropped on a condition that fails a skipto test. The manpage doesn't make this point clear. limit {src-addr | src-port | dst-addr | dst-port} N The firewall will only allow N connections with the same set of parameters as specified in the rule. To limit the number of connections a user can open you can use the following type of rules: ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 ipfw add allow tcp from any to me setup limit src-addr 4 I'm assuming the packet gets silently dropped when the limit is overloaded but gets acted upon otherwise due to the stateful "limit" behaviour (keep-state in disguise). Just do a "skipto" when there's a state entry and that's it. And that's why the counter grows for established connections too, even though there's a "setup" modifier. skipto is a nice thing as it allows you to AND rules ;-) Besides, that's what my humble testing came up with - connections over the limit DO get dropped... if done nicely. As for the problem, it seems to me that all this noise is because of different timeouts in ipfw and TCP layer/whatever. The dynamic state entry for a connection expires while netstat -na still show the connection as ESTABLISHED, or, worse, the state entry is still there but the corresponding connection is in some half-closed state (FIN_WAIT_2, CLOSE_WAIT, LAST_ACK). The first case allows many more connections than "limit", while the second case won't let many good clients connect due to their buggy browsers not closing connections and letting the count build up. Could this be it? skipto number Skip all subsequent rules numbered less than number. The search continues with the first rule numbered number or higher. You'll need a specific allow or deny rule; skipto does neither, it just branches to 401 if the condition is matched, otherwise proceeds to the next rule, which is also 401. This runs rule 401 and on, either way. > >> the problem is that the src-addr limit is not enforced as some clients > >> somehow open a huge number (3-5 times the prescribed value) of > >> www-connections to some single address Out There, forcing you to bump up > >> certain sysctl variables (such as kern.ipc.nmbclusters, > >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be > >> going on? Is ipfw broken, or am I misusing it? You've misread skipto, is all. As it stands, the counts will show how many packets passed the test, but all packets proceed to the next rule. I'd rephrase rules to use skipto only for branching on condition, or !condition, past specific allow and/or deny rules to deal with this. > >> OS: FreeBSD 6.2 > > > > > > The following command worked here (6.2-RC1). Only one connection was > > allowed to 1.2.3.4. > > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 > > > > Use the command "ipfw -d show" to see what connections are matching > > your dynamic rules. > > > > # ipfw -d show | fgrep x.x.x.x | wc -l > 20 > $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l > 113 > > Why is it that only 20 connections have been accounted for by ipfw's > dynamic rules but there are actually 113 active connections from that IP > at the moment? The limit src-addr is 75. See above. Sorry I didn't notice this when you first posted it. I've not yet used limit src-addr myself, but use skipto a lot :) Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
On Mon, 19 Feb 2007, admin wrote: > Andre Santos wrote: > > On 2/18/07, admin <[EMAIL PROTECTED]> wrote: > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > >> connections a single IP can have at the same time in a transparent > >> web-proxy environment: > >> > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > >> 80 in via if0 setup limit src-addr 10 > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > >> ... the rest fwd... > >> > >> as I understand the manpage, when the current number of connectiions is > >> below 10, the action "skipto" is performed, else, the packet is dropped > >> and the search terminates. But... No, a packet is not dropped on a condition that fails a skipto test. skipto number Skip all subsequent rules numbered less than number. The search continues with the first rule numbered number or higher. You'll need a specific allow or deny rule; skipto does neither, it just branches to 401 if the condition is matched, otherwise proceeds to the next rule, which is also 401. This runs rule 401 and on, either way. > >> the problem is that the src-addr limit is not enforced as some clients > >> somehow open a huge number (3-5 times the prescribed value) of > >> www-connections to some single address Out There, forcing you to bump up > >> certain sysctl variables (such as kern.ipc.nmbclusters, > >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be > >> going on? Is ipfw broken, or am I misusing it? You've misread skipto, is all. As it stands, the counts will show how many packets passed the test, but all packets proceed to the next rule. I'd rephrase rules to use skipto only for branching on condition, or !condition, past specific allow and/or deny rules to deal with this. > >> OS: FreeBSD 6.2 > > > > > > The following command worked here (6.2-RC1). Only one connection was > > allowed to 1.2.3.4. > > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 > > > > Use the command "ipfw -d show" to see what connections are matching > > your dynamic rules. > > > > # ipfw -d show | fgrep x.x.x.x | wc -l > 20 > $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l > 113 > > Why is it that only 20 connections have been accounted for by ipfw's > dynamic rules but there are actually 113 active connections from that IP > at the moment? The limit src-addr is 75. See above. Sorry I didn't notice this when you first posted it. I've not yet used limit src-addr myself, but use skipto a lot :) Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
Andre Santos wrote: On 2/18/07, admin <[EMAIL PROTECTED]> wrote: Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... as I understand the manpage, when the current number of connectiions is below 10, the action "skipto" is performed, else, the packet is dropped and the search terminates. But... the problem is that the src-addr limit is not enforced as some clients somehow open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 The following command worked here (6.2-RC1). Only one connection was allowed to 1.2.3.4. # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 Use the command "ipfw -d show" to see what connections are matching your dynamic rules. # ipfw -d show | fgrep x.x.x.x | wc -l 20 $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l 113 Why is it that only 20 connections have been accounted for by ipfw's dynamic rules but there are actually 113 active connections from that IP at the moment? The limit src-addr is 75. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
admin wrote in msgid: <[EMAIL PROTECTED]> Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... as I understand the manpage, when the current number of connectiions is below 10, the action "skipto" is performed, else, the packet is dropped and the search terminates. But... the problem is that the src-addr limit is not enforced as some clients somehow open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 I tested ipfw with the "limit" option and it works just fine. I can open only one http connection from "194.109.21.3" and hangs on opening a second one with an error in the logfile. rule: # add 03000 allow log logamount 50 tcp from any to any dst-port 80 in limit dst-addr 1 My logfile: Feb 18 16:16:57 jeremino kernel: ipfw: 3000 Accept TCP 194.109.21.3:3626 10.0.0.6:80 in via dc1 Feb 18 16:16:58 jeremino kernel: drop session, too many entries You get the point. I know, indeed it works just great for many clients, including myself, but *some* clients manage to ignore the firewall rule and open many more connections in the ESTABLISHED state than allowed and eat up lots of memory with their send/recv queues... Instead of knocking my head on the wall I opted for posting here for help ;-) I've decided to prove that I'm not crazy. This little code utilizes the BSD sockets API trying to open many connections to some outside web-site but just halts after crossing the limit (assuming the connections get transparently proxied by the problem firewalled-FreeBSD-proxy box on its path). The question remains: why could some clients be immune to the limit? #include #include #include #include #include #include #include #define NUM_CONNS_TO_TRY_TO_OPEN 150 int main(void) { struct sockaddr_in sock_addr; struct in_addr in_addr; int i; if (inet_aton("66.94.234.13", &in_addr) == 0) { perror("inet_aton"); return EXIT_FAILURE; } sock_addr.sin_family = AF_INET; sock_addr.sin_addr = in_addr; sock_addr.sin_port = htons(80); for (i = 0; i < NUM_CONNS_TO_TRY_TO_OPEN; i++) { int s; if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) { perror("socket"); return EXIT_FAILURE; } if (connect(s, (struct sockaddr *) &sock_addr, sizeof sock_addr) != -1) { fprintf(stderr, "%d ", i); } else { perror("connect"); return EXIT_FAILURE; } } getchar(); return 0; } ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
admin wrote in msgid: <[EMAIL PROTECTED]> > Hi, I'm trying to use ipfw's limit clause to limit the number of > connections a single IP can have at the same time in a transparent > web-proxy environment: > > 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > 80 in via if0 setup limit src-addr 10 > 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > ... the rest fwd... > > as I understand the manpage, when the current number of connectiions is > below 10, the action "skipto" is performed, else, the packet is dropped > and the search terminates. But... > > the problem is that the src-addr limit is not enforced as some clients > somehow open a huge number (3-5 times the prescribed value) of > www-connections to some single address Out There, forcing you to bump up > certain sysctl variables (such as kern.ipc.nmbclusters, > kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be > going on? Is ipfw broken, or am I misusing it? > > OS: FreeBSD 6.2 I tested ipfw with the "limit" option and it works just fine. I can open only one http connection from "194.109.21.3" and hangs on opening a second one with an error in the logfile. rule: # add 03000 allow log logamount 50 tcp from any to any dst-port 80 in limit dst-addr 1 My logfile: Feb 18 16:16:57 jeremino kernel: ipfw: 3000 Accept TCP 194.109.21.3:3626 10.0.0.6:80 in via dc1 Feb 18 16:16:58 jeremino kernel: drop session, too many entries ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw limit src-addr woes
Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... as I understand the manpage, when the current number of connectiions is below 10, the action "skipto" is performed, else, the packet is dropped and the search terminates. But... the problem is that the src-addr limit is not enforced as some clients somehow open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw limit src-addr woes
On 2/17/07, admin <[EMAIL PROTECTED]> wrote: Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... the problem is that the src-addr limit is not enforced for some nasty clients that open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 I would go for pf instead of ipfw for that job ;) -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw limit src-addr woes
Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... the problem is that the src-addr limit is not enforced for some nasty clients that open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"