[asterisk-dev] Asterisk Network Security Idea (using tcp_wrappers)

[John Todd]

On Mar 28, 2009, at 7:01 PM, Joseph Benden wrote:

> Hello all,
>
> There has been recent discussion regarding a needed network security  
> infrastructure for Asterisk. After some thought, I have come up with  
> a proposal for such an infrastructure. I would like the input of the  
> community on this idea and, if acceptable, I would be willing to  
> start the implementation.
>
> I propose an idea based around an old concept that many existing  
> network daemons use, tcp_wrappers[1]. First things first, after  
> private discussion, it has been found that the license[2] of  
> tcp_wrappers is compatible with the dual-license nature of Asterisk.
>
> Contrary to its name, TCP wrappers may be used for either TCP or UDP  
> connections and are mostly centered around filtering at the host or  
> subnet network address level. This concept mirrors the existing ACL  
> infrastructure in place within the SIP module[3] of Asterisk  
> (permit,deny). The benefit in using TCP Wrappers is centralized  
> management of ACLs across network daemons and the use of existing  
> tools that can utilize them, such as DenyHosts[4]. DenyHosts has the  
> capability of monitoring the syslog, using regular expressions, and  
> acting by the modification of /etc/hosts.deny, to stop attacks on a  
> system. DenyHosts supports many operating systems and would be of  
> benefit in our community, as attacks against SSH and other services  
> would instantly block access to Asterisk.
>
> To implement TCP Wrappers, two functional changes to Asterisk would  
> need to be implemented. The first is a centralized syslog function  
> that logs invalid usage of Asterisk, such as from the SIP and IAX  
> channels, the Manager API, the HTTP server, the Skinny channel, etc.  
> The second is a function that these internal Asterisk services use  
> to determine if an incoming connection is authorized to communicate  
> with Asterisk. These two functional changes permit tools to monitor  
> Asterisk via syslog and allow the usage of /etc/hosts.allow and /etc/ 
> hosts.deny via the TCP Wrappers library.
>
> For the first function, a possible method signature could be:
>
> void ast_log_invalid(const char *module, const char *reason, const  
> char *ipaddr, const char *for)
>
> For the second function, a possible method signature could be:
>
> int ast_permitted(const char *name, const char *addr, const char *for)
> int ast_permitted_sin(const struct sockaddr_in *sin, const char *for)
>
> The above function would use the passed information to call the  
> function hosts_ctl() of TCP Wrappers.
>
> [1] tcp_wrappers: ftp://ftp.porcupine.org/pub/security/index.html
> [2] tcp_wrappers license: ftp://ftp.porcupine.org/pub/security/tcp_wrappers_license
> [3] Asterisk SIP permit-deny-mask: http://www.voip-info.org/wiki/index.php?page=Asterisk+sip+permit-deny-mask
> [4] DenyHosts: http://denyhosts.sourceforge.net/
>
> Comments, suggestions, or ideas are welcomed!
>
> Best Regards,
> Joseph Benden



Joe -
   I think this is a fairly scale-able way to manage security within  
Asterisk.  The tcp_wrappers system is well-known, comes as a default  
on most modern UNIX-like systems, and is license-compatible.  This  
seems like the best method I've yet heard of creating an  
"infrastructure" that is achievable quickly from a code perspective.   
Also, unlike almost every other suggestion, you've made a proposal to  
write code!  This is the most important part.  :-)

   Notably missing from this design is the external heuristic to parse  
logfiles and populate hosts.[allow,deny].  I believe that there are a  
wide variety of external programs that exist which will serve this  
function, including many that will report to and collect from remote  
central databases of "attacker" IP addresses.  I don't doubt that they  
are effective and pre-existing, and that many more sophisticated users  
will opt for "rolling their own" method of parsing the log output and  
updating whatever filter mechanisms they have in place.  But I believe  
that there should be included with Asterisk some basic, self-contained  
method of turning those reports into actionable lines in hosts. 
[allow,deny] to protect a single machine in its simplest configuration.

   I'm on the fence when thinking about if this logic and action  
should be contained within Asterisk or simply be an included script in  
the third-party apps directory.  There are good arguments for both.   
Being able to type something like "filter show blocked" or "filter  
unblock 10.3.2.1" at the CLI (or equivalent AMI command) would  
integrate well with the other models of interaction that programs have  
with Asterisk, without writing a separate security management tool  
that would then have to interact with the various web interfaces, etc.  
that are built on top of Asterisk.  This is significantly complex,  
though CLI or self-contained filtering logic would not interact  
extensively with the rest of Asterisk once the basics of using /etc/ 
hosts.[allow,deny] was enabled, if we used those data structures as  
the "API".  This self-contained nature reduces the risk of unexpected  
behaviors with the rest of Asterisk, but there are still a lot of  
lines of code to be written to make this possible.

   At a minimum, a script that lives in the third-party-apps directory  
is almost mandatory, I think.  Without including _some_ way to parse  
events and turn them into protective statements, I suspect that the  
only people who would use the method would be people who already know  
how to protect their systems.  If it's not easily accessible by the  
minimally competent Asterisk admin, it does far less good than it  
could against the enemy.

  I'm also on the fence if there should be some "default" protective  
behavior, but let's wait on that discussion until it's possible to  
have it.


Notes:
   - I would suggest that the /etc/hosts.[allow,deny] files be  
specified in a config file somewhere and not be hard-coded
   - each service within Asterisk should have separate filter  
capabilities, since Asterisk operates on so many ports
   - Adding lines to these files is great.  How are they removed after  
time?  Is there an astdb table with timer data? (very important!)

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/