Please Stop Doing That
June 12, 2008 8:12 AM
Apache Filter: blocking logins after failed attempts.
A coworker asked me this one first, but I'm stumped, so I turn to the hive mind.
He's running a pretty vanilla Apache on FreeBSD to serve a website that has a /members section protected by htaccess. He administers passwords and such fine, and he's happy with the security and reliability and such, but he's starting to have a problem with scripts/robots hammering his login pages with web-based brute force attacks, trying user names (aaron, adam, arthur, axel...) and common passwords.
This isn't a huge security problem but it's proving to be a heck of a drag on his web server, and it's poisoning his traffic data. Apparently "something like 90 percent" of his traffic last weekend was just that kind of noise. I first suggested just blocking the offending IPs within the .htaccess itself, but the source IPs change every couple of hours, and some are from identifiably dynamic IPs like ADSL users, so temporary blocks are definitely the right way, here.
Obviously, he'd rather not reengineer a whole new authentication scheme, and that's probably beyond his ken anyway. So is there an Apache module or middleware script he could use as an add-on or (pre?)login, to provide temporary lockouts for given user names or IP numbers? The goal is something like the typical bank login response: "Too many failed logins, please try again in (1 hour)." where that (hour) is configurable.
Captchas on login might work, but that strikes me as too strange and cruel, I think, to impose on every login.
It's a straight HTML website right now, nothing fancy at all (he uploads members documents by FTP and uses some web-front end CGI from his ISP for adding/removing htaccess users) and he's not comfortable with Perl or PHP beyond install-and-forget. That said, I could probably lend a couple hours of my own help to implement something one-time, as long as it "just works" after that.
Suggestions, geek-hive?
A coworker asked me this one first, but I'm stumped, so I turn to the hive mind.
He's running a pretty vanilla Apache on FreeBSD to serve a website that has a /members section protected by htaccess. He administers passwords and such fine, and he's happy with the security and reliability and such, but he's starting to have a problem with scripts/robots hammering his login pages with web-based brute force attacks, trying user names (aaron, adam, arthur, axel...) and common passwords.
This isn't a huge security problem but it's proving to be a heck of a drag on his web server, and it's poisoning his traffic data. Apparently "something like 90 percent" of his traffic last weekend was just that kind of noise. I first suggested just blocking the offending IPs within the .htaccess itself, but the source IPs change every couple of hours, and some are from identifiably dynamic IPs like ADSL users, so temporary blocks are definitely the right way, here.
Obviously, he'd rather not reengineer a whole new authentication scheme, and that's probably beyond his ken anyway. So is there an Apache module or middleware script he could use as an add-on or (pre?)login, to provide temporary lockouts for given user names or IP numbers? The goal is something like the typical bank login response: "Too many failed logins, please try again in (1 hour)." where that (hour) is configurable.
Captchas on login might work, but that strikes me as too strange and cruel, I think, to impose on every login.
It's a straight HTML website right now, nothing fancy at all (he uploads members documents by FTP and uses some web-front end CGI from his ISP for adding/removing htaccess users) and he's not comfortable with Perl or PHP beyond install-and-forget. That said, I could probably lend a couple hours of my own help to implement something one-time, as long as it "just works" after that.
Suggestions, geek-hive?
I don't necessarily see why displaying a message would at all discourage the bots. I doubt they're really reading the page, just sending the POST requests. What you need is something that pays attention to the failed logins and adds an firewall rule to block the traffic for a certain time. Not sure if there's a generic solution for this or not.
posted by sbutler at 9:07 AM on June 12, 2008
posted by sbutler at 9:07 AM on June 12, 2008
Clarification for sbutler: I don't mean ONLY display the message, I mean also block them by userID or IP number temporarily, yes. I just described it from the user perspective. HTaccess/Apache can already block permanently if IPs/userIDs are added and removed manually, but that'll only be noticed after a lot of abuse, so I'm fishing for an automatic temporary-disable somehow.
I have a sense that it "must" exist, but I can't think of a way.
posted by rokusan at 9:12 AM on June 12, 2008
I have a sense that it "must" exist, but I can't think of a way.
posted by rokusan at 9:12 AM on June 12, 2008
OSSEC is has a way to do this with SSH by monitoring the syslogs and then temporarily adding a host to /etc/hosts.deny.
I don't know if it has a rule like this for apache failed passwords in its default set of rules but maybe these can help:
http://ubuntuforums.org/showthread.php?t=213445
http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1222865,00.html
posted by bdc34 at 9:14 AM on June 12, 2008
I don't know if it has a rule like this for apache failed passwords in its default set of rules but maybe these can help:
http://ubuntuforums.org/showthread.php?t=213445
http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1222865,00.html
posted by bdc34 at 9:14 AM on June 12, 2008
apache's mod_security module is your friend here. It has a drop action that will do exactly what your friend wants.
For example this directive closes the connection if more than 20 Basic Authentication attempts occur within a 2 minute period
SecAction initcol:ip=%{REMOTE_ADDR},nolog
SecRule ARGS:login "!^$" nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/120
SecRule IP:AUTH_ATTEMPT "@gt 20" log,drop,phase:1,msg:'Possible Brute Force Attack"
posted by handybitesize at 9:51 AM on June 12, 2008
For example this directive closes the connection if more than 20 Basic Authentication attempts occur within a 2 minute period
SecAction initcol:ip=%{REMOTE_ADDR},nolog
SecRule ARGS:login "!^$" nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/120
SecRule IP:AUTH_ATTEMPT "@gt 20" log,drop,phase:1,msg:'Possible Brute Force Attack"
posted by handybitesize at 9:51 AM on June 12, 2008
that msg is the mod_security documentation guy's own, and doesn't include the expletives that you'd obviously want to send to the bot's logs
posted by handybitesize at 9:56 AM on June 12, 2008
posted by handybitesize at 9:56 AM on June 12, 2008
I just installed DenyHosts on my server to handle blocking bad login attempts. Since doing so the number of attempted logins (HTTP or SSH) has dropped to a tiny fraction of what it once was.
DenyHosts, if configured correctly, will also download lists of known bad hosts from other servers, and upload lists of bad hosts that you collect. Preemptively blocking login attempts seems better to me than retroactively adding them to a list. Also can be set to auto-flush blocked addresses after X amount of days, so anyone accidentally added is eventually removed.
Setting it up on Ubuntu was a snap. FreeBSD port info can be found here.
posted by caution live frogs at 1:48 PM on June 12, 2008
DenyHosts, if configured correctly, will also download lists of known bad hosts from other servers, and upload lists of bad hosts that you collect. Preemptively blocking login attempts seems better to me than retroactively adding them to a list. Also can be set to auto-flush blocked addresses after X amount of days, so anyone accidentally added is eventually removed.
Setting it up on Ubuntu was a snap. FreeBSD port info can be found here.
posted by caution live frogs at 1:48 PM on June 12, 2008
OSSEC, mod_security and DenyHosts all look like options (he'd need to get his ISP to install but I think that would be all right).
My only concern is that all three block HTTP completely, so there wouldn't even be an error page ("Try again later.") or such for the occasional real user who just mistypes their password five times (or whatever). Or am I missing something?
posted by rokusan at 2:05 PM on June 12, 2008
My only concern is that all three block HTTP completely, so there wouldn't even be an error page ("Try again later.") or such for the occasional real user who just mistypes their password five times (or whatever). Or am I missing something?
posted by rokusan at 2:05 PM on June 12, 2008
If you don't drop the connection, you could tell mod_security to redirect for example, you will still have the request and, therefore the tainted traffic handled by the webserver. Something I thought you wanted to avoid.
posted by handybitesize at 4:07 PM on June 12, 2008
posted by handybitesize at 4:07 PM on June 12, 2008
I am under the impression fail2ban can block ip addresses after a certain number of failed apache logins.
posted by DJWeezy at 6:31 PM on June 12, 2008
posted by DJWeezy at 6:31 PM on June 12, 2008
Looks like Mod_Security is the ticket, since it can stay within Apache and therefore do the redirect to alerts. From reading the docs it looks like he could configure it to give a warning after five failed logins, AND flat out ban the IP after 10. That's near-perfect.
Thanks, all.
posted by rokusan at 6:46 PM on June 12, 2008
Thanks, all.
posted by rokusan at 6:46 PM on June 12, 2008
If you want to get fancy, you can even hook up mod_security to talk to your firewall (or iptables) to really block those bad guys. To them, it looks like you fell off the Internet.
I say this, because I had a problem with bots continuing to hammer the site, even though all they were getting were Access Denied errors. For days.
posted by meta_eli at 7:43 PM on June 12, 2008
I say this, because I had a problem with bots continuing to hammer the site, even though all they were getting were Access Denied errors. For days.
posted by meta_eli at 7:43 PM on June 12, 2008
This thread is closed to new comments.
If you use mod_auth_pam to make Apache interface with the system PAM libraries for authentication, you can configure the login_limit PAM module to automatically lock out brute force attempts.
This does require not only admin level access to the Apache installation, but also access to change the system PAM configuration, and a sufficient understanding of how that works that you can assess the security complexities this might introduce (for example, you probably don't want all those Apache users to be able to log in as shell users on the machine) and understand how to prevent undesired outcomes.
posted by standbythree at 8:38 AM on June 12, 2008