[VoiceOps] Asterisk Security

[Peter Beckman]

On Wed, 5 Aug 2009, J. Oquendo wrote:

> The fact that if you used fail2ban, I can insert whatever network I like
> via packetcrafting and give you headaches for days. Imagine that for a
> moment - blocking I don't know say... 0.0.0.0 or better yet, if someone
> has an axe to grind with you and is capable (not difficult) of tracking
> down your address ranges. They could do some really cruddy stuff like
> have your own servers/netblocks block themselves out, have your servers
> block out your default route and the list goes on and on.

  Absolutely.  Use of such a tool has to be with the realization that the
  tool can be used against you, and that you need to really know your
  network, and how your firewall works.

> Multiple that by all of your netblocks, clients' static netblocks, etc.
> It would be a horrible thing to maintain.

  I disagree.  A single file with a mix of netblocks, static and dynamic
  DNS, and customer IP addresses that allows for inline comments can be used
  in multiple applications.

  For the most part, most of your production IP services are already
  firewalled with an explicit whitelist.  When you need production IP
  services available to the world (HTTP, SIP if you are handling NAT'ed
  customer devices), a tool that supports whitelisting and dynamically
  blocks for Z seconds non-whitelisted IPs and hosts that fail to
  authenticate (or do something) X times in Y seconds is valuable.

  The shell script examples you posted are bad for production, because they
  block on the first failed attempt, and have no method for unblocking.

  The tools being discussed (sshguard, fail2ban, others) block hosts for Z
  seconds only after X failures in Y seconds.  This is useful to proactively
  protect the availability of your services in the following instances:

     * This means a tinkerer who screws up their Asterisk config and blasts
       you with 150 registration requests a minute would get blocked for 15
       minutes before being able to try again, forcing the customer to maybe
       realize something isn't right, and for you to optionally be notified
       of the block, and maybe call the person proactively to help, AND
       proactively protecting your SIP registration server from being DOS'ed
       by a newbie.
     * Drive-by brute force.  150 failed auths in 1 minute indicate an
       attempted brute force attack.
     * Packetcrafting usefulness is diminished by your whitelist.  While
       packetcrafting could be used to temporarily disconnect one of your
       non-whitelisted customers, at least you'd know about the block and
       could make an informed decision to either whitelist the client
       temporarily or permanently.

  Sometimes it will have a previously unthought of bad result on your
  services, which you then consider and fix.  It may not be perfect, but
  neither is getting brute forced and having thousands of dollars of calls
  made on your dime, or having your customers offline because of one bad
  tinkerer DOSing your services at 2am while you sleep.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------