Nikhil Nair
2010-Aug-30 11:16 UTC
[asterisk-users] 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.
Gordon Henderson
2010-Aug-30 12:19 UTC
[asterisk-users] Fail2ban integration issues with Asterisk 1.4.21 under Debian Lenny
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