views:

47

answers:

2

I'm receiving many failed login requests from spammers/bots that are trying to brute-force the credentials, also I'm receiving many requests to pages like /forum/index.php.

I wrote a script to parse the IP's of those attackers from production.log:

#!/bin/bash

# Failed Logins
grep "Failed " ~/app/log/production.log | egrep -o -e "[0-9]{2,3}\.[0-9]{2,3}\.[0-9]{2,3}\.[0-9]{2,3}" | sort | uniq > ~/spammers.txt

# Try to GET .php Files
cat ~/app/log/production.log | awk '$0!~/^$/ {print $0}' | sed -n -e "N; /\.php/p" | grep "ApplicationController#index" | egrep -o -e "[0-9]{2,3}\.[0-9]{2,3}\.[0-9]{2,3}\.[0-9]{2,3}" | sort | uniq >> ~/spammers.txt

But I can't block (.httaccess) those IP's until I manually check their origin by Geolocation.

Is out there a Rail-ish solution for this problem?

A: 

There are a number of things you could do. None is particularly Rails-y, but should help anyways.

First of all, I recommend that you use JanRain Engage (formerly rpxnow.com) for authentication. This product enables people to log into your site using authentication credentials from Google, Yahoo, Microsoft, Facebook and a bunch of other OpenID providers. Let them worry about DOS attacks.

Secondly, if they have specific URLs that they are trying to hit, have your web serve it up as a static web page, and set the HTTP headers so that the rogue page is cached in their browser. Then, at least your server won't get hammered as hard.

Thirdly, log the IP addresses of spammers & bots that try to log into your pages more than, say, 10 times in a minute, and if they try to log in again, throttle their response by putting a 4 second sleep before you render their page.

Jay Godse
Somehow, I bet the script the hackers wrote doesn't respect cache headers. Also, I would bet money that the hackers are just hitting common URLs and would keep doing so even if it was an open ID site.
Scott S.
Using sleep before you render their page is only going to tie up your rails processes. Don't do it.
Scott S.
@Scott S - Good point. The sleep should happen in the web page javascript that renders the login form, or the login response form. But you're right on the first one...spam bots are usually not programs in web browsers.
Jay Godse
+1  A: 

I don't think there is a Rails answer to this.

If you're running on a linux server, you can look into using LFD (Login Failure Daemon). http://www.configserver.com/cp/csf.html

Once you set it up to watch your rails app, it would block them at the firewall level after enough failed logins, intrusion attempts, etc.

Scott S.