[asterisk-dev] GSoC: Implementing Networking Security Framework for DOS attacks

[John Todd]

On Mar 24, 2009, at 9:25 AM, Smita wrote:

> Hello,
>
> I wanted to know if this idea is viable. Any help in refining the idea
> in the current context is highly appreciated!
>
> Store DoS related information within specfic nodes. This could include
> IPs or networks that are blacklisted, etc. When processing an incoming
> packet, the origin IP is compared to the data stored. If a match is
> found for the IP or the source network, the packet is discarded.
>
> Alternatively, these information nodes could contain Packets Per
> Second information for that IP/network. Any packet from this source
> that exceeds this count is dropped.
>
> Another variation could be the above concept being applied to session
> layer (SIP packets) rather than IP layer.
>
> What I refer to as nodes here, could be a data structure (e.g. like  
> Judy Nodes).
>
> References: http://astridevcon.pbwiki.com/Network-Security-Framework
>
> Please comment.
>
> Thanks,
> Smita



This has been suggested at least twice as a GSoC proposal, so I'll  
count this as a third (if anyone is counting other than me. :-)  Some  
have suggested that first, Asterisk needs to have a document that  
describes better how such a framework would be put in place.  As the  
author of the document you point to above, I'm in agreement - as it  
stands, it is far from complete and contains more concept than  
comprehensive design.  I'd be happy to see someone else pick it up and  
flesh it out a bit with the development process in mind.

In relevant news, there was a discussion yesterday via phone with JR  
Richardson, Eric Langheinrich, and myself (*) on the viability of  
using the Project Honeypot (http://www.projecthoneypot.org/) system as  
a centralized database for reporting "bad" events such that systems  
participating in the reporting system would be optionally able to  
extract data to create filters.  Honeypot.org doesn't have this focus  
at the moment (they're more for anti-spam) but Eric indicated that he  
would be very interested in helping make it contain the data that we  
might need to perform such a central role in attack reporting.

There are some potential very easy methods to implement as a first  
step, but they are fairly crude and probably don't easily translate to  
a widely-scalable system.  Imagine just an HTTPS wrapper around string- 
matched syslog events for outbound reporting, and rsync-based  
importation of partial iptables access lists, or perhaps sip.conf  
"permit=,deny=" lists.   I worry that these completely external  
methods may lose traction because of the moderate complexity of  
configuration, and the "non-default" nature of the protection.  I've  
learned from painful experience that 99% of the defaults in Asterisk  
are left in place, and almost nobody implements even basic security  
features unless (after a breach/at the point of a gun.)  The upside on  
the primitive syslog parsing method is that its fast to get in place,  
and requires no changes to Asterisk.

I do believe that a better security model needs to be developed for  
Asterisk on any network connection interfaces.  I also believe  
Asterisk should have robust attack reporting capabilities, and  
moderate attack-defense capabilities in each network element.  Having  
this built-in to standard versions of Asterisk would improve  
protection across the entire user base.

It could be argued that Asterisk has no place at all in defending  
against these attempts, and that is the job of a firewall or other  
external software and not the application.  Personally, I reject that  
particular delineation even though it may make sense from a "purist"  
perspective.  I think that applications should be secure entirely  
within themselves, and firewalls are the primary defense for weak  
applications with short-sighted developers.  Sorry if this raises  
hackles, but I see firewalls and VPN software as symptoms of  
underlying poor design at the app level.  While I advocate network- 
based protection, it should be a supplementary protection and warning  
layer and not the primary structure of defense.

Asterisk is installed on a huge number of platforms with varying  
capabilities of both the underlying system and of those that manage  
the platform.  Creating a filtering module that is embedded in  
Asterisk has the best chance of creating the most benefit for all  
users, and such a model does not meaningfully reduce the well-being of  
a system which chooses not to use it in favor of external protection  
systems.


So in summary: does anyone else think that at more integrated security  
framework would be worth the time of a GSoC coder? Does anyone else  
want to participate in the discussions with the Project Honeypot  
developers?  Send me or JR (jmr.richardson at gmail.com) mail.

(*: a few others were invited, but only we three ended up in the call)


JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/