Can ipfw be used to limit concurrent requests from an IP?

Ian Smith smithi at nimnet.asn.au
Wed Jun 1 16:20:53 UTC 2016


On Tue, 31 May 2016 19:28:59 +0100, Will Squire wrote:
 > > On 28 May 2016, at 15:27, Ian Smith <smithi at nimnet.asn.au> wrote:
[..]
 > >> Can ipfw limit the number requests in a given amount of time from a 
 > >> specific IP?
 > >> 
 > >> To contextualise, if an IP sends requests in high concurrency (let's 
 > >> say 50 a second) can ipfw either block requests the exceed a 
 > >> threshold for that second (lets say the threshold is 20, 30 would be 
 > >> blocked), or ban/deny the given IP for exceeding a threshold?

 > > you can use stateful rules with 'limit' instead of 'keep-state' to limit 

 > Thanks for the reply Ian. I donÿÿt think limit would work due to HTTPÿÿs
 > ÿÿkeep-aliveÿÿ feature. I believe this means a connection would be kept open 
 > (counting as one connection) and still open to heavy polling by the client.

That's probably right, and your desire to define connection rate limits 
rates should have steered me away from suggesting 'limit'.  inetd.conf 
is careful not to mention http, so that was a dumb sugdestion too :(

 > >> The aim is to lessen strain under DoS attacks, specifically for HTTP. 
 > >> The system is using Apache and mod_evasive has been added and tested, 
 > >> but it is not functioning correctly.

>From what I've just dug up on a quick hunt, I think that's what you 
should get working.  It looks very useful if it works as advertised.

Running a command, more likely script, that invokes ipfw to add notified 
addresses (with a timestamp, possibly set to some future time ($now + 
$interval)?) to an ipfw table is easy; I have several scripts that deal 
with this.  A cron script to periodically find and delete the expired 
entries is also straightforward.

However ipfw must be run as root, so you'll need some signalling so a 
script run by www-user (ono) can inform a root shell process to run ipfw 
commands and return status to your script.  Good fun .. with some care.

 > > I haven't used (nor heard of) mod_evasive so can't comment on that, but 
 > > limiting the total number of connections open to a given service can 
 > > certainly mitigate the effect of such DoS attacks.
 > 
 > Again, I think keep-alive might cause issues here (but please do correct me if 
 > wrong). Limiting connection to the HTTP service might also worsen the DoS to 
 > users.

Yes, I believe you're right.  Even with the webserver returning 403s, 
it's still an access.log DoS .. so the firewall is the tool to block 
those deemed baddies, and mod_evasive looks like a good tool for the 
deeming job .. just some hits searching 'mod_evasive apache freebsd':

https://project.altservice.com/issues/562
https://www.unixmen.com/protecting-apache-server-denial-service-dos-attack/
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7
and of course
https://www.freshports.org/www/mod_evasive/

[.. chomping tcpwrappers stuff ..]

 > Iÿÿm not familiar with using TCPwrappers, Have seen another recommend 
 > SSHGuard though (which I am using already). Can I do something similar 
 > with that, or does/should it do this (add to ban table) automatically? Unsure 
 > if SSHGuard needs any additional rules written for Apache.

I haven't used SSHGuard.

Perhaps if you share your mod_evasive config and a problem description, 
someone here may be able to help?  If so, I can offer ipfw script ideas.

cheers, Ian


More information about the freebsd-questions mailing list