Re: ipfw: Too many dynamic rules
On Tue 2010-09-14 (13:54), Gareth de Vaux wrote: On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote: Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any improvement at all? That's a bit strange. There's probably something If there was an improvement it was subtle (I was doing sporadic measurements), just that in the end my firewall was getting overloaded either way. Yeah looks like a bit of an improvement but I also wasn't controlling for end user usage so can't say for sure without rerunning. Setting net.inet.tcp.fast_finwait2_recycle=1 though seems to have done the trick, thanx. This is now typical: $ netstat -n | grep -c FIN_WAIT_2 5 and my server still seems to be serving. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Fri 2010-09-10 (13:49), Gareth de Vaux wrote: Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (6). Ok that seems to be doing something. Will report back later. Nope it's not helping. That and/or dropping net.inet.ip.fw.dyn_ack_lifetime. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Tue, Sep 14, 2010 at 12:36:57PM +0200, Gareth de Vaux wrote: On Fri 2010-09-10 (13:49), Gareth de Vaux wrote: Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (6). Ok that seems to be doing something. Will report back later. Nope it's not helping. That and/or dropping net.inet.ip.fw.dyn_ack_lifetime. You're absolutely certain these are all in FIN_WAIT_2 state and not TIME_WAIT? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote: You're absolutely certain these are all in FIN_WAIT_2 state and not TIME_WAIT? Yup, $ netstat -an | grep FIN_WAIT_1 | wc -l 57 $ netstat -an | grep FIN_WAIT_2 | wc -l 431 $ netstat -an | grep TIME_WAIT | wc -l 17 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote: Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any improvement at all? That's a bit strange. There's probably something If there was an improvement it was subtle (I was doing sporadic measurements), just that in the end my firewall was getting overloaded either way. FWIW, I'd recommend keeping an appended log of output from something like this script: will do ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Tue, Sep 14, 2010 at 01:12:00PM +0200, Gareth de Vaux wrote: On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote: You're absolutely certain these are all in FIN_WAIT_2 state and not TIME_WAIT? Yup, $ netstat -an | grep FIN_WAIT_1 | wc -l 57 $ netstat -an | grep FIN_WAIT_2 | wc -l 431 $ netstat -an | grep TIME_WAIT | wc -l 17 Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any improvement at all? That's a bit strange. There's probably something about ipfw I'm not getting. Adding luigi@ to the CC list, since I think he's familiar with ipfw internals. FWIW, I'd recommend keeping an appended log of output from something like this script: while true do echo `date` -- `netstat -n | grep -c FIN_WAIT_2` /some/log sleep 5 done Just make sure the sleep interval is lower than the FIN timeout. Another thing to try: setting net.inet.tcp.fast_finwait2_recycle=1 and see if this makes a difference. I'm not familiar with this setting myself, but some Google results indicate some people do use it. The sysctl description is a bit vague too. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Fri, 10 Sep 2010, Marat N.Afanasyev wrote: Ian Smith wrote: On Thu, 9 Sep 2010, Vlad Galu wrote: 2010/9/9 Marat N.Afanasyevama...@ksu.ru: I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. Agreed. stateful firewall does not limits numbers of states/connections. it just add a new layer which can be overfulled easily. if you experience a DDoS attack it's better to block attackers addresses, e.g, adding them to some ipfw table using external methods. Sure, that's another tool in the box. There's no single solution to such things, however connection limits applied to a stateful firewall are specifically intended to prevent state tables being overwhelmed, and the default table sizes are generally more useful for smaller systems. did you try to use lighweight and FAST frontend web-server as proxy? e.g. www/nginx or www/zerowait-httpd? Wasn't me having the problem :) ADSL1 here, not nearly enough bandwidth to worry about DDoS choking server processes. I use stateless for most inbound connections anyway, sendmail's connection limits for mail, and inetd connection limits per time for POP, FTP and some other services. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. I can say that 4 connection limit is extremely low limit, because if you use a somewhat distributed web site (css, images, etc. in different files) client software may open DOZENS of connections simultaneously, and you will deny absolutely rightful connections. btw, real DDoS is often uses thousands, tens of thousands and even hundreds of thousands botware hosts. I've rarely seen millions, may be 2 or three times at all, while 50-80 thousands hosts is average. It's all a matter of scale. I didn't get the impression that Gareth was running anything big enough to see that scale of attack, but that's just my impression. And of course 4 was just that example from the manual, a limit perhaps suitable for a small mailserver? By all means make it 4 dozen if you really think clients each need that many open connections. Given he was already enquiring about ipfw used statefully, one could instead use 'limit dst-port N' to limit _total_ active connections to the webserver to something reasonable for the particular environment, and other tuning as others have suggested. I still tend to agree with Vlad; better to limit connections/states than then having to deal with the consequences of overwhelmed servers; YMMV. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) yes, this is one of the best looking solutions. Just one more tool .. there are various firewall log tailing utilities available; one size is never going to fit all, and I'd been wanting to try writing something myself for ages. But it's all small beer here :) cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
Ian Smith wrote: On Thu, 9 Sep 2010, Vlad Galu wrote: 2010/9/9 Marat N.Afanasyevama...@ksu.ru: I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. Agreed. stateful firewall does not limits numbers of states/connections. it just add a new layer which can be overfulled easily. if you experience a DDoS attack it's better to block attackers addresses, e.g, adding them to some ipfw table using external methods. did you try to use lighweight and FAST frontend web-server as proxy? e.g. www/nginx or www/zerowait-httpd? PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. I can say that 4 connection limit is extremely low limit, because if you use a somewhat distributed web site (css, images, etc. in different files) client software may open DOZENS of connections simultaneously, and you will deny absolutely rightful connections. btw, real DDoS is often uses thousands, tens of thousands and even hundreds of thousands botware hosts. I've rarely seen millions, may be 2 or three times at all, while 50-80 thousands hosts is average. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) yes, this is one of the best looking solutions. -- SY, Marat
Re: ipfw: Too many dynamic rules
On Thu 2010-09-09 (09:20), Jeremy Chadwick wrote: Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are unrelated to TCP keepalives[1]. I mention this because you're focusing on netstat, which will give you indication of TCP session state, not HTTP protocol statefulness. Gotcha Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (6). Ok that seems to be doing something. Will report back later. Finally, why are you using dynamic firewall rules at all? So that I can identify legitimate(ish) traffic and drop the rest. For what purpose do you need these that, say, pf and its state tracking would not suffice? I haven't used pf. I started with ipfw and its done the trick so far. What's the difference between pf and ipfw's state tracking in this respect? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On 09/09/10 17:39, Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. For what it's worth, here's what I've been running: net.inet.ip.fw.dyn_buckets=1024 net.inet.ip.fw.dyn_max=8192 net.inet.ip.fw.dyn_ack_lifetime=60 If in a tight spot, I might reduce dyn_ack_lifetime to 10. There is no way this machine would service 8192 legitimate simultaneous connections so this works for me. If you have the memory I think you can increase dyn_max practically arbitrarily. If under a DDoS attack, you might run out of some other resource, like ephemeral TCP ports for the server side of connections, before running out of ipfw entries. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Fri 2010-09-10 (03:18), Ian Smith wrote: Try using 'limit' rather than the unlimited 'keep-state' for inbound dynamic connections to your server/s. eg, derived from ipfw(8): These are mostly legitimate connections though, they just aren't being closed properly. So if limit were to have an affect in my scenario, it would just prevent legitimate users from reconnecting. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Thu, Sep 09, 2010 at 05:39:02PM +0200, Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). Firstly, I'm not familiar with dynamic firewall rules in ipfw. I tend to use pf these days, with ALTQ for rate-limiting. pf offers a lot of improvements over ipfw. Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are unrelated to TCP keepalives[1]. I mention this because you're focusing on netstat, which will give you indication of TCP session state, not HTTP protocol statefulness. Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you should consider adjusting the following sysctl: net.inet.tcp.finwait2_timeout Try something like 15000 (15 seconds) instead of the default (6). Finally, why are you using dynamic firewall rules at all? For what purpose do you need these that, say, pf and its state tracking would not suffice? [1]: http://en.wikipedia.org/wiki/Keepalive -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Thu, 9 Sep 2010, Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. Try using 'limit' rather than the unlimited 'keep-state' for inbound dynamic connections to your server/s. eg, derived from ipfw(8): ipfw add allow tcp from any to me 80 setup limit src-addr 4 .. can be placed on a server to make sure that a single client does not use more than 4 simultaneous connections. You could add 'in recv $ext_if' to avoid limiting internal clients. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? Limiting the number of source connections per source address to what apache is happy to deal with, you mightn't need to fuss with that? cheers, Ian I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) may be using ipfw add XXX allow tcp from me 80 to any would be enough? I usually use keep-state rules only for outgoing connections and try to keep number of such rules as few as possible. if you're afraid of somebody trying to attack your servers using unopened connections you may filter out connections that aren't established. you can try to change, of course, net.inet.ip.fw.dyn_*_lifetime variables, but I think that using dynamic rules to filter out web-server answers is not as good practice as it seems. -- SY, Marat
Re: ipfw: Too many dynamic rules
Date: Thu, 09 Sep 2010 22:03:10 +0400 From: Marat N.Afanasyev ama...@ksu.ru Sender: owner-freebsd-sta...@freebsd.org Gareth de Vaux wrote: Hi again, I use some keep-state rules in ipfw, but get the following kernel message: kernel: ipfw: install_state: Too many dynamic rules when presumably my state table reaches its limit (and I effectively get DoS'd). netstat shows tons of connections in FIN_WAIT_2 state, mostly to my webserver. Consequently net.inet.ip.fw.dyn_count is large too. I can increase my net.inet.ip.fw.dyn_max but the new limit will simply be reached later on. I currently get around this with a cronjob that sets net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes every night. If I leave it at 0 for longer or indefinitely then idle ssh sessions and the like are dropped. This works fine for me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1? Or with Apache? I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I have a KeepAliveTimeout of 4 in Apache (2.2.16). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) I'll be more blunt...stateful firewalls should NEVER be placed in front of externally accessible services. Access filters are fine, but stateful firewalls are nothing but a denial of service waiting to happen. Security pros have always know this, but too many folks insist that there be a firewall in front of everything and that is simply an invitation to problems. Marat is right! Just don't even try. An attacker can ALWAYS overwhelm the state tables in a stateful firewall. It's just way too easy. There was a long discussion of this a while back on a network ops list I participate in and noobs kept claiming that you have to have a stateful firewall in front of everything while the real operational security folks (like those at Y! and Google) kept explaining that it just does not work. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
2010/9/9 Marat N.Afanasyev ama...@ksu.ru: I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. -- Good, fast cheap. Pick any two. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipfw: Too many dynamic rules
On Thu, 9 Sep 2010, Vlad Galu wrote: 2010/9/9 Marat N.Afanasyev ama...@ksu.ru: I wonder, are these dynamic rules really necessary? let's see, a client connects to your web-server and you immediately should create a new dynamic rule, therefore you participate in this DoS attack as well as attacker. ;) With a stateless firewall, you help the attacker even more. Because he's able to connect to your httpd/whatever daemon is listening directly and he can easily fill up the descriptor table of that process. Limiting the number of states/connections from the same host prevents that. Sure, those states eat up RAM, but so do the established connections. Having a slightly more aggressive state expiry policy always helps. Sure, there are accf_http(9), accf_data(9) and various forking workarounds, but they don't work unless your TCP server is specifically designed to use them. Agreed. PF also allows you to tarpit malicious hosts based on how often they try to reconnect - you can dynamically add them to a table which you can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) BTW, Gareth: ... while talking to mail.lordcow.org.: DATA 550 5.1.1 b...@lordcow.org... User unknown 550 5.1.1 b...@lordcow.org... User unknown 503 5.0.0 Need RCPT (recipient) cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
