[asterisk-dev] Adding netfilter NATting/ALG support to chan_rtp
philipp_subx at redfish-solutions.com
Mon Nov 10 15:19:58 CST 2008
John Todd wrote:
> 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
>> 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
>> 2) Let the Asterisk administrator be able to script the various
>> responses based on his own needs. As you can well imagine, Asterisk
>> deployed in many different scenarios, and what's good for one
>> installation isn't necessarily good for another. In other words,
>> 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? ;-)
Ok, those parts I got.
It's quite a large scope project, and I see a lot of good in it...
unfortunately, I don't have the time or the expertise to implement most
of that, so I'm going to go for the low-hanging fruit and just implement
hooks to call netfilter (probably via the API, rather than command
line... I don't want the latency of starting up a process).
What is the usual workaround to writing new Asterisk functionality that
leverages code with different licensing restrictions (i.e. GPL and not
LGPL or GPLv2)?
Also, where in the code would be the appropriate places to do the NAT
munging on the INVITE? And where else should I do munging? Are there
other message types?
More information about the asterisk-dev