[asterisk-biz] PBX got Hacked

[SIP]

Gregory Boehnlein wrote:
>> I guess there should be some configurable options in Asterisk to cover
>> for that. Like 10 consecutive failed login attempts should invoke
>> asterisk to reply a login denied to that IP address and another option
>> that would allow for let's say 5 attempts in 5 minutes and then block
>> the extension for login.
>>
>> Make the login attempts number and blocking time configurable,
>> settable system wide with an option to override per extension would
>> close the hole.
>>     
>
> This is one of the things that we discussed at Astridevcon in 2008, and
> several questions came up;
>
> 1. Should this even be Asterisk's responsibility, when it can already be
> implemented w/ external tools that are much better suited to the task, are
> already well supported and work really well:
>
> http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
>   

Responsibility? That's a difficult word. Is it irresponsible to build a
program without additional security if building in that security is
possible?

Whose responsibility is the security of the Asterisk system as a whole?
ONLY the administrator? Or both the dev team AND the administrator? If
it's ONLY the administrator, then that could speed things up in
development (who needs to worry about clean threads or buffer
checking?).  I'm of the opinion it should be both. Yes, there are other
cobbled together hacks out there that can help protect things here and
there, but how many hacks does it take before the whole system itself is
nothing more than a hack?

> 2. What are the implementations of having a blocking scheme like this when
> you have 100 phones behind NAT? (The simple answer to this is to allow
> whitelisting of known address blocks)
>   

Most banning logic in ANY firewall scenario simply assumes every and all
machines are suspect unless you specifically say they're not.
Whitelisting blocks and IPs, or having 'lesser' stringent checks on
blocks and IPs is a good way to handle this.

> 3. It would be very difficult to develop a security model that works for ALL
> channel drivers. It is easier to think about using a method that works for
> chan_sip, but a more detailed framework is necessary for all other channel
> drivers.
>   

If the big problem is chan_sip, then you start there and build the
others as you decide how. It's a far better idea to secure what can be
secured when you can secure it, instead of waiting around for a grand
unified theory of security models for an indeterminately long period of
time while the holes still exist. Like any sort of warfare, you fortify
the things that need fortification, and you can skimp on the areas that
are unlikely or drastically more difficult targets, as the likelihood of
an enemy going after those first is slim.



N.