[asterisk-dev] Adding netfilter NATting/ALG support to chan_rtp

[John Todd]

On Nov 7, 2008, at 5:36 AM, Jared Smith wrote:
> On Thu, 2008-11-06 at 20:47 -0800, Philip Prindeville wrote:
>> I read it...  it was fairly generic.
>>
>> If there was as special takeaway from it, it was lost on me...
>
> I don't mean to speak for John's proposal, but I think the two key
> things that I got from his proposal are:
>
> 1) Use scripts external to Asterisk to respond to various stimuli.  I
> know in your case that you'd like to embed the netfilter libraries so
> that Asterisk can control netfilter directly, but please remember that
> Asterisk runs on a *lot* of different platforms, many of which don't  
> use
> netfilter.  By using external scripts, this can be a generic solution
> for all platforms, and is not limited to those using netfilter.
> (External scripts obviously help alleviate the licensing concerns as
> well.)
>
> 2) Let the Asterisk administrator be able to script the various
> responses based on his own needs.  As you can well imagine, Asterisk  
> is
> deployed in many different scenarios, and what's good for one
> installation isn't necessarily good for another.  In other words,  
> let's
> say Asterisk detects that there have been twenty registration attempts
> for a particular SIP peer in the past minute, all using different
> passwords.  One Asterisk administrator's response may be totally
> different, depending on how he's deployed Asterisk.  Having a generic
> framework that he/she can adapt to their particular deployment is key.
>
> Anyway, that's my two cents (before taxes) on the matter.
>
> -- 
> Jared Smith
> Training Manager
> Digium, Inc.


The concept I briefly and incompletely outline (http://astridevcon.pbwiki.com/Network-Security-Framework 
) has a few components:

First: Create a method by which channels can identify "bad" packets.   
Those could be DoS attacks, password brute force attacks, invalid  
protocol packets, etc.  This would feed two possible defenses  
(below.)  Identification would include dynamic filters which could be  
self-creating and self-removing over time without participation of the  
administrator.  Channels would then bubble this information out to two  
possible filter mechanisms.

Second: create a method that is embedded with Asterisk (via hopefully  
a suitably-licensed set of libraries) which would allow for a set of  
default named access lists and dynamic access lists that would, at the  
app level (not the kernel level), permit Asterisk to ignore packets.

Third: create a method that would allow Asterisk based on the "bad"  
packet profiles each channel would create to call external processes,  
either on-host or on remote hosts (i.e.: ipfilter, Cisco ACLs, etc.)  
to provide protection.  This would be completely external to Asterisk,  
and would simply be a system call with parameters that would call some  
external script.  This would allow integration with pretty much any  
tool or method.


The proposal is incomplete - others are welcome to comment on it and  
expand upon it.  Maybe it needs to be simpler.  Maybe it's not  
powerful enough.  Certainly, people who are interested in creating a  
real architecture and coding for it are highly encouraged - I'm just  
whistling in the wind until someone finds it important enough to start  
typing code.  But nobody cares about security, right?  ;-)

JT


---
John Todd
jtodd at digium.com        +1-256-428-6083
Asterisk Open Source Community Director