On Apr 13, 2010, at 1:18 PM, Jon Lewis wrote:

> On Tue, 13 Apr 2010, Fred Posner wrote:
> 
>> http://www.voiptechchat.com/voip/457/amazon-ec2-sip-brute-force-attacks-on-rise/
>> 
>> There's been a bunch of different discussions on ways to combat the attacks, including redirecting the attacks to a different port (and responding with a fake message), iptables, fail2ban, etc.
>> 
>> The redirect had mixed results... and I didn't want the fail2ban, so I put up a little perl script for automatically blocking the traffic via a dedicated iptables chain. The script is posted on Team Forrest:
> 
> There's a recent NANOG mailing list thread about this.  It sounded like Amazon was going to do something about it...but if you're saying it's still going on, I guess they haven't done enough.
> 
> Out of curiosity, why did you object to fail2ban?  It would actually be more efficient than what you've done.  In your example, you're rereading and reprocessing /var/log/asterisk/messages every 2 minutes.  If you insist on rolling your own, I'd suggest you look at perl's File::Tail and recode your perl script to run as a daemon that processes log lines once in real time as they're written.
> 
> Also, you could save yoursefl some coding by replacing push(@failhost,$1); with $failhost{$1}++;  That way, you're building an array of IPs and the number of times you've seen them, both at the same time.
> 
> Another issue is, you don't expire the iptables rules.  Iptables chains are processed linearly.  As the chain length increases, the system has to spend longer and longer looking at each rule in the asterisk chain to see if the packet will be dropped or allowed.  Fail2ban solves that by expiring rules after a predetermined time.
> 

All good points...

I didn't want fail2ban as I'm already using blockhosts, which I just love. Since it's a UDP connection without the ability to spawn, I figured if I had to cron something I'd just do it myself. The reason I didn't do the tail was just out of a quickness in writing the script. My log rotate is weekly... so the tail method I didn't think would handle a single probe daily... whereas the quick log read would, taking less than a second on large logs. So it was a "pure laziness" approach of not having to write a counting log or similar.

The expiration idea is something I should have absolutely done.

Thanks for the feedback.

---fred
http://qxork.com