DDOS attacks against ITSPs
All, I am relatively certain most of you have heard about the issue CallCentric had experienced recently where they came under a significant DDOS attack. My question to the community at large is, who here has been down this road and been attacked; and what was the signature of that attack. I am sure your are not alone and we could probably all do fairly well to compare notes on the topic. This year alone we have seen at least 7 different flavors of DDOS attacks aimed at our resources some impactful some not, and I would be extremely interested in comparing notes with anyone else (especially callcentric engineers) who are interested in hoping to share information and perhaps prevent the next major incident. Feel free to respond on or off list as you see fit. -Ryan
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? On Fri, Oct 12, 2012 at 8:23 PM, Ryan Delgrosso <ryandelgrosso at gmail.com>wrote:
All, I am relatively certain most of you have heard about the issue CallCentric had experienced recently where they came under a significant DDOS attack. My question to the community at large is, who here has been down this road and been attacked; and what was the signature of that attack. I am sure your are not alone and we could probably all do fairly well to compare notes on the topic.
This year alone we have seen at least 7 different flavors of DDOS attacks aimed at our resources some impactful some not, and I would be extremely interested in comparing notes with anyone else (especially callcentric engineers) who are interested in hoping to share information and perhaps prevent the next major incident.
Feel free to respond on or off list as you see fit.
-Ryan ______________________________**_________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/**mailman/listinfo/voiceops<https://puck.nether.net/mailman/listinfo/voiceops>
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
Hi folks,
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?
We (Simwood) have been operating a honeypot for some-time. The results are in the public domain at http://mirror.simwood.com/honeypot cheers Simon -- ***** Email confidentiality notice ***** This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Simwood eSMS Limited is a limited company registered in England and Wales. Registered number: 03379831. Registered office: c/o HW Chartered Accountants, Keepers Lane, The Wergs, Wolverhampton, WV6 8UA. Trading address: Falcon Drive, Cardiff Bay, Cardiff, CF10 4RU.
Thanks Simon and J. Both are very useful lists. On Mon, Oct 15, 2012 at 9:06 AM, Simon Woodhead <simon.woodhead at simwood.com>wrote:
Hi folks,
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?
We (Simwood) have been operating a honeypot for some-time. The results are in the public domain at http://mirror.simwood.com/honeypot
cheers Simon -- ***** Email confidentiality notice *****
This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Simwood eSMS Limited is a limited company registered in England and Wales. Registered number: 03379831. Registered office: c/o HW Chartered Accountants, Keepers Lane, The Wergs, Wolverhampton, WV6 8UA. Trading address: Falcon Drive, Cardiff Bay, Cardiff, CF10 4RU.
participants (4)
-
joquendo＠e-fensive.net -
peeip989＠gmail.com -
ryandelgrosso＠gmail.com -
simon.woodhead＠simwood.com