asterisk users - Aug 2010 - Fail2ban integration issues with Asterisk 1.4.21 under Debian Lenny

Hi,

I've recently had a fairly prolonged SIP registration attack, 18 hours in 
this case and often with 200 attempts per second, and suspect I've had a 
number of these in the past.  The main symptom I noticed previously was, 
because Asterisk was responding to each registration request it received, 
it was very quickly using up my 448 kbps upload limit for my home ADSL 
connection: any further traffic (i.e. anything I did) was then 
experiencing significant packet loss.

Anyway, I've now implemented the "7 steps to better Asterisk
security"
that I found on the Digium website (deny/permit, alwaysauthreject etc.), 
and have been looking at fail2ban.  However, when I attempted to install 
it (following the instructions I found on a page about fail2ban with 
Asterisk), I ran into a couple of issues.

FWIW, I'm using Asterisk 1.4.21.2~dfsg-3+lenny1 on Debian.

First, I tried uncommenting the line in /etc/asterisk/logger.conf, i.e.
dateformat=%F %T
and verified that the date format in /var/log/asterisk/full had, indeed, 
changed (after I did an asterisk -rx 'logger reload', of course).  It
had
changed: it now started with the year, instead of Aug; however, the 
parentheses were still there, whereas the instructions seemed to indicate 
that they'd disappear when this line was used in logger.conf.

At that point, I presumed I'd have to use syslog, after all, as that was 
given as the only alternative if the date format couldn't be fixed 
properly.  That wasn't my preference, but it was still workable.

The second snag I found was that, after I fixed sip.conf to include 
appropriate deny= and permit= lines and alwaysauthreject=yes, the failed 
registration attempts were no longer being logged in 
/var/log/asterisk/full at all, despite my having the line
full => notice,warning,error,debug,verbose
in the logfiles section of logger.conf.

It seems that the attack was coming from a region that was denied in 
sip.conf.  This is obviously no problem from the security point of view, 
as the attempt would inevitably fail; however, my issue isn't that the 
attack might succeed, but rather, that by responding to the attack at all, 
Asterisk is grinding my internet connection to a halt.  And Asterisk is, 
indeed, still responding, rather than just ignoring the attempts.

Is there a way to get Asterisk to log failed SIP registration attempts 
that come from a denied IP address?  Or a way to get it to simply ignore 
such attempts?

I have a feeling that a major Debian release has come out recently, and 
passed me by.  I'm wondering if that contains Asterisk 1.6, and, if so, 
whether all these issues (date format as well as logging sip registration 
attempts from denied IP addresses) might be present in that release.  That 
would certainly present a neat solution - just upgrade my machine!

Any input very welcome.

Oh, if it's of any interest: I worked out what was going on by using 
tshark (terminal version of wireshark).  In 20 seconds, it captured well 
over 7000 packets, rather than the 30 or so I was expecting - and these 
included about 4000 packets arriving from one host with SIP registration 
attempts, fully 200 per second...

Best,

Nikhil.

On Mon, 30 Aug 2010, Nikhil Nair wrote:
> Hi,
>
> I've recently had a fairly prolonged SIP registration attack, 18 hours
in
> this case and often with 200 attempts per second, and suspect I've had
a
> number of these in the past.
Almost everyone has - read the fine archives, then google for sipvicious 
because that's what they're using.

18-hours eh? This recent one broke my record - just under 3 days. See 
this:

   http://unicorn.drogon.net/hack1.png

green is inbound - all from one site belonging to a Romanian telephone/ISP 
- sustained from Thursday evening until Sunday lunchtime.

The real issue here is that most of the hackers I've had attack me and my 
clients are using an older version of sipvicious - and the problem with 
that is that it will not go away when you firewall it, so using fail2ban, 
etc. is a waste of time against it - it might protect your asterisk box, 
but it won't protect your network. In the above case I had, I added 
firewalling into the router where the blue-line output line went to zero 
on Thursday evening (I was playing with it on Friday morning which is why 
there's output from it then)

However because the ISP in this case counts all traffic coming in, it 
counted against their monthly allowance - that for me and my clients is 
going to be the killer more than anything else - we can firewall against 
these things, but sipvicious doesn't care - it just keeps on pumping the 
data towards you and your ISP keeps on incrementing the counters and 
billing you for it (and I've yet to find a UK ISP who will put in a block 
at their border against this sort of thing - actually, I know one, but 
they're too expensive for most).

At least the older versions of sipvicious behave this way, but when do 
criminals bother to upgrade their software? They don't seem to care - 
they've already stolen resources, so it's no big issue to them.

This problems is not going to go away - if anything, I reckon it will get 
worse in the near future. Fail2ban, etc. is not going to protect you from 
broken versions of sipvicious. Anyone who can not firewall their inbound 
SIP port to a known set of IP addresses is inviting attack, and they will 
be attacked. The sipvicious tools make scanning very easy indeed, so you 
will have to take additional measures if you want to save your bandwidth 
and sanity.

So.. Get a copy of the sipvicious code from http://blog.sipvicious.org/ 
(or directly from http://code.google.com/p/sipvicious/ ) and learn how to 
use svcrash.py as that's the only thing that's going to ultimately stop
a
long-term attack on your site. For now, anyway.

Gordon