[VoiceOps] DDOS attacks against ITSPs

[J. Oquendo]

On Mon, 15 Oct 2012, PE wrote:

> This is an important topic. And whether you know it or not, your network
> has, at some time I'm sure, been under fire, whether a DDoS, Registration
> flood, or other. A true DDoS is obviously the hardest to deal with, though
> the others can also cause harm. In my experience, a Registration flood is
> the most common, and the signatures are generally:
> 
> 1. Scan of your IP's
> 2. Attempt to register to any that reply to SIP
> 3. Registrations are usally to 4-digit extensions. I guess the attacker is
> hoping to hit a PBX, not necesarily an ITSP
> 4. User-agent is usually "friendly-scanner"  (i.. SipVicious)
> 5. Many come from international locations
> 
> Acme has some good documentation on the topic as well as best common
> practices for configuration. Their ACLs are supposed to offload the
> processing from the CPU (where the heavy lifting of SIP B2BUA is done) to
> the interface. Of course, no interface can truly stop a flood that fills
> the pipe.
> 
> So, what to do?
> 
> First, check your configs and do the most you can there. Next, if you have
> the tools, keep an eye on registrations and overall bandwidth in and out of
> your network and to specific interfaces. When you see an odd spike, dig
> into it and block the sender, where appropriate. Geographic diversity may
> help, but IP diversity might be equally effective, though some gear does
> not support this.
> 
> I'm curious if anyone has set up a honey-pot to find the bad guys before
> they find you and if so, what has the success been. Would the list be
> willing to share their blacklists?
> 

Google VoIP Abuse Project. (It's Moday and I'm too lazy to
type/dig it out)

As for honeypots, I have created one primarily for Asterisk
but it can be modified for most systems with a little expect
scripting. I also built an alerting VoIP based notifier for
nCite/Netrake/Audiocodes/_Whatever_they_call_themselves_now.


1) Can be blocked using common sense firewalling (block all
allow in trusted)
2) Can be mitigated with strong(sensible) usernames and
passwords
3) See #2 ... Also we don't do username/password auth on the
SBC level
4) 1.1.1.1 no brainer. Can also be filtered/SIEM'd/etc
5) Many MORE come from cloud providers right in North
America


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM

"It takes 20 years to build a reputation and five minutes to
ruin it. If you think about that, you'll do things
differently." - Warren Buffett

42B0 5A53 6505 6638 44BB  3943 2BF7 D83F 210A 95AF
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF