[asterisk-users] Under heavy attack

[Joel Maslak]

On Sun, Oct 31, 2010 at 2:40 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>wrote:

> On Sat, Oct 30, 2010 at 07:33:23PM -0600, Joel Maslak wrote:
>
> > The CPU usage is trivial to deny them.  As is the bandwidth usage, if
> > you are not sitting on a slowish broadband connection.
>
> s/slow/assymetric/
>


A 1mb/s uplink is slow nowadays.  I suspect a symetrical 1mb/s SDSL line
would also be having trouble with lots of registrations.

But regardless, that's why I don't use ADSL for call paths, unless the ADSL
is 100% within a corporate network (terminates on an ATM line in some
corporate office, not in a public provider) - to easy for bad guys to send
enough traffic at you to disrupt your calls.

If you did have fast enough downlink to not be a victim of this, then you
just need QoS - VoIP signalling (registration/registration-fail messages)
should always be a lower priority than the VoIP media stream - and it's
possible even on ADSL internet connections to control what you send to your
provider and in what order you send it.  Media packets should always be sent
before signaling on that uplink.  Even fair queuing (so long as your router
recognizes the UDP traffic flows as flows) would help (and would let your
legitimate users register quickly even during an attack).



> > It also seems that the only way to make blocking effective is to
> > block everything by default except known endpoints.  Blocking the
> > door knickers doesn't protect against a bad guy finding (not through
> > brute force) valid credentials.
>
> Unless you have people on the road.
>

Agreed.  But I would host that in a datacenter with adequate bandwidth, not
on the end of an ADSL or other connection that is easy to DOS.

If these are mobile users, I hope they never use any public networks
(hotels, starbucks) where other subscribers can do things like ARP attacks
to do MITM (and steal your calls; it might not be happening today, but it
will be happening soon - as the social networking attacks demonstrate).  If
you do have truly roaming users, I hope you use HTTPS (with validation of
certs turned on) or a VPN (likely not an option of connecting to an ADSL
site, due to bandwidth concerns).



> Or unless you have people who want to actually use the peer-to-peer
> nature of SIP and call your SIP address.
>

Once again, I'd use a border gateway at a datacenter or other location with
significant bandwidth (not an ADSL line).  Even for a small shop.



> I suspect even munin would provide you such options. Not to mention any
> more capable monitor.
>

I already have a monitor (tied into nagios, which pages me if my fraud
thresholds are exceeded), but I feel that is probably beyond the abilities
of most of the people experiencing call fraud.  The people who know what
they are doing with Unix and Asterisk are generally not the victims of
this.  It would be nice if there was something built into Asterisk to alert
on fraud - something that an end user with little Asterisk (or Unix)
experience could utilize to be alerted to call fraud, which is easily
detectable almost 100% of the time (too many calls for the organization ==
call fraud).  And that is really what this is about - keeping someone from
getting a $30,000 phone bill.  It certainly should be the part of any
commercial offering.

I stand by my statements.  Blocking people who were already denied access
will not stop call fraud on systems with secure authentication.  You need to
worry about the guy that has the trojan on the computer with the soft phone
- the hacker who now has legit credentials (and will never be flagged by
fail2ban when he uses them).  It's the bad guy you don't know about, not the
bad guy you stopped, that is a danger.  As for bandwidth issues, I would
never use an ADSL-based internet connection for VoIP - too easy for the bad
guy to make a mess of things (or even just a misconfigured endpoint).  But
if I did, I'd agree that some sort of fail2ban-like system would be helpful
if you couldn't implement QoS.

People can take or leave my advice, but it is sound.  Practice security
theater or actual security.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20101031/516d77eb/attachment.htm