[asterisk-dev] auto blacklisting "script kiddies"

[John Todd]

At 3:08 PM +0100 2007/4/26, Steve Kennedy wrote:
>
>Would it not be a good idea if Asterisk would auto-blacklist single IP
>addresses that attempted multiple SIP or other registrations.
>
>The attacks I've seen seem to be scripted and aren't particularly
>clever, so an auto back-off system or just lock from that IP address
>after a particular number of registration attempts. This could be
>specified as a config variable (as in number of attempts before lock).
>
>Locked IP's could then be manually unlocked, or unlocked after a time
>period (or in combination, locked wait some time, unlock and if more
>attempts continue, lock for a longer time period etc).
>
>This isn't going to defeat any kind of serious attack, but would deter
>the script kiddies out there. It also potentially wont work for ITSPs
>etc, but for smaller installs it could be just the solution?
>
>
>Steve
>
>--
>NetTek Ltd  UK mob +44-(0)7775 755503
>UK +44-(0)20 79932612 / US +1-(310)8577715 / Fax +44-(0)20 7483 2455
>Skype/GoogleTalk/AIM/Gizmo/Mac stevekennedyuk / MSN steve at gbnet.net
>Euro Tech News Blog http://eurotechnews.blogspot.com


This topic was discussed some months ago.  Here is a reply 
(unfinished and enclosed at the end of this comment section) that I 
never actually hit the "Send" button on from last year's thread. 
There does seem to be some value in allowing Asterisk to limit 
packets, session requests, or dialogs based on some type of high/low 
water mark for attempts by a certain IP address or CIDR-notated 
network.

It seems that there needs to be a quick description of what we're trying to do:

   - define what is "bad"
   - define the scope of who is making "bad" requests
   - define the action (filter) that occurs when something "bad" is identified
   - define how long (time) or what circumstances (action) removes the filter
   - define how we log any of these criteria or actions

Anyway, I'd comment more on it, but that would mean that the email 
would sit on my screen for another few months and probably never get 
sent, so I'll send this half-baked comment stream out and let others 
continue...

JT


>Date: Tue, 26 Sep 2006 21:55:09 -0700
>To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>From: John Todd <jtodd at loligo.com>
>Subject: Re: [asterisk-dev] Rate limiting traffic to address 
>potential DoS	issues?
>
>>A community member has communicated to me a couple of issues where 
>>if he sends large volumes of correctly-formatted (but otherwise 
>>invalid) packets at Asterisk channel drivers, Asterisk behaves 
>>quite poorly. In general it does not crash, but it will lose calls, 
>>respond very slowly, etc.
>>
>>I have been loath to start trying to build remediation for this 
>>into Asterisk itself, since that's a very slippery slope and we 
>>could end up spending the next six months trying to come up with 
>>new attack vectors and then coding to deal with them. In addition, 
>>at least in my opinion, there are good, free tools already to do 
>>this sort of thing (rate limiting of incoming traffic), as well as 
>>solid commercial products.
>>
>>However, I'd like to get the opinions of our developer community... 
>>do you think this is something we should attempt to address within 
>>Asterisk itself, or we are better off to post some 'best practices' 
>>documents that demonstrate ways that existing tools can be used to 
>>combat these attacks?
>>
>>--
>>Kevin P. Fleming
>>Senior Software Engineer
>>Digium, Inc.
>>
>
>This is a topic near and dear to my heart.  The lack of even 
>moderate DoS and attack mitigation tools in most SIP packages is 
>what keeps the Session Border Controller companies smiling and 
>rolling in money for the forseeable future.  It is my belief that 
>the abilities of SBC systems should be rolled into the SIP proxies 
>or media application servers (Asterisk is both) where the attacks 
>are actually focused.
>
>As with some of the other posters, I think there is a middle ground. 
>While I don't think it's possible to manage all types of "bad" 
>packets sent to Asterisk, I do think that there needs to be some 
>mitigation of certain types of attacks.  It is fairly easy to 
>describe large classes of "bad" things, and gracefully handle many 
>of those bad things without re-writing the entire channel stack.
>
>I am not certain if a totally generic framework can be built for 
>managing attack vectors - I think whatever work happens will have to 
>be in channel-specific ways.  However, this doesn't mean that each 
>channel type can't share the syntax and methods.
>
>Here is a rough guide to what I see as the threats, in my perceived 
>order of priority;
>
>  - Bogus SIP packets
>  - Bogus RTP packets
>  - Bogus IAX2 packets
>  - Bogus H.323 packets
>  - Bogus Skinny packets
>  - Bogus Asterisk Manager Interface requests (*1)
>
>where "bogus" means:
>
>   - too many valid packets
>   - incorrect protocol formatting
>   - INVITE, connect, or initial setup overloads
>   - too many invalid packets (DoS of garbage)
>
>I know there are many sub-variations of these types of bogosity, if 
>I may use that word.  I think if we cover the large topic areas, the 
>smaller sub-issues will sort themselves out.
>
>For most of these,
>
>RTP seems to me to be the easiest to manage - we will always be 
>expecting RTP from certain destinations, so if the packets don't 
>come from one of those valid destinations then the system should 
>drop the packet silently.  This seems to be something that a generic 
>firewall should be able to handle at the kernel level, but Asterisk 
>would need to inform the firewall ruleset as to what is the 
>"expected" open firewall list, and then null-route packets within 
>the RTP ranges that aren't expected per the protocol negotiation via 
>SIP or H.323 or whatever.  This may already be the case for some 
>firewall programs: netfilter? iptables? pf?  Sorry, I don't have 
>enough in-depth experience on these to know if this is already the 
>way they do things.  There would need to exist the ability for 
>Asterisk to publish it's current RTP [source IP, destination port] 
>list to the firewall program so that the dynamic filter could be 
>built.  Doesn't sound too hard, but I always think these jobs are 
>easy.  :-)
>
>
>
>(*1) A large portion of the cure of this problem is SSL-ifying the 
>AMI interface, which has been more-or-less done and languishing in 
>the bugtracker for some months.