nitzanPremium,VIP
join:2008-02-27
kudos:2 | reply to nonymous
Re: DDOS Attacks - Is Any VoIPP More Immune ? said by nonymous:said by borntochill:There are effective mitigation systems against sophisticated DDoS attacks. For instance, Prolexic and Verisign among others offer cloud-based clean pipes services, however these systems/services do not come cheap. We're talking annual operating service costs in the five figures or even six figures. All that traffic still has to be dumped somewhere. So yes upstream filtering but your ISP may charge a ton if it saturates too much of even their stream. You guys are thinking regular DDOS attacks - at least in this case it wasn't a regular attack. CallCentric's "pipes" haven't been clogged - it's the registration servers that became overloaded. This has nothing to do with bandwidth or lack thereof.
The only ways to mitigate this attack are to deploy more secure code and/or deploy more/bigger registration servers. To put it to an example, lets say you have a registration server big enough to handle 1000 registrations a second - if a few servers send 10000 requests a second at it it'll choke - but it's relatively easy to fix by just blocking them. But if 600,000 servers (botnet) send one request a minute the effect is the same, yet incredibly hard to block. There are other ways to make this even harder to block, but I don't want to give the bad guys more ideas.
So bottom line: bigger servers + better code = less susceptible to registrar DDOS. |
|
Reviews:
 ·voip.ms
| said by nitzan:You guys are thinking regular DDOS attacks - at least in this case it wasn't a regular attack. CallCentric's "pipes" haven't been clogged - it's the registration servers that became overloaded. This has nothing to do with bandwidth or lack thereof. Thanks for the heads up. I hadn't more than quickly perused the CC outage thread so was unaware of this info.
All the same, it's helpful to know which VSPs are investing resources and being proactive in protecting their systems. Since there are DDoS vulnerabilities unique to VoIP, is there a working group sharing information to help providers stay up-to-date on the latest threats, and, if so, who is actively participating?
This sort of information needn't be cloak-and-dagger. |
|
 VexorgTR
join:2012-08-27
Sheffield Lake, OH
·Callcentric
·callwithus
 ·CenturyLink
 ·Clear Wireless
 ·Time Warner Cable
| reply to Davesnothere
Re: DDoS Attacks, Is Any VoIPP Less Susceptable ? I think just about anyone could get "skunked" by a DDoS, provided that there's a big enough attack base.
The Plus side is that CC wasn't totally smashed... the calls could be re-routed to mobile for the 2 days. Despite that it "Beat Up" CallCentric... it technically didn't take it out. The website, and the call routing worked the whole time. |
|
| said by VexorgTR:The Plus side is that CC wasn't totally smashed... the calls could be re-routed to mobile for the 2 days. Despite that it "Beat Up" CallCentric... it technically didn't take it out. The website, and the call routing worked the whole time.
I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that. All attempts at outgoing calls failed too.
This was a massive attack and to pretend it was anything other than successful does not help anybody.
--
DPC3825 - WRT610N - Panasonic KX-TGP500 - Asterisk 1.8.11.0 with Asterisk GUI on Virtual Server
Anveo - Voxbeam - Localphone - Numbergroup - Callcentric - VoIP.MS - UKDDI |
|
Reviews:
·Callcentric
| said by grand total:I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that.
Without meaning to sound argumentative, you may wish to double check your initial findings.
Our effort to reroute calls for thirteen different DIDs under six different Callcentric accounts was ultimately 100% successful. However, it didn't work at first try.
Without successful SIP registrations, SIP traffic from Callcentric was initially being blocked by our firewall, as it had been programmed to do. Until we opened ports 5060 and 5080 to UDP traffic from Callcentric's IP addresses, initial testing of SIP URI forwarding failed. The calls were being forwarded by Callcentric but being rejected by our equipment. |
|
 TrimlinePremium
join:2004-10-24
Windermere, FL
·Callcentric
| said by engineerdan:said by grand total:I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that.
Without meaning to sound argumentative, you may wish to double check your initial findings. Our effort to reroute calls for thirteen different DIDs under six different Callcentric accounts was ultimately 100% successful. However, it didn't work at first try. Without successful SIP registrations, SIP traffic from Callcentric was initially being blocked by our firewall, as it had been programmed to do. Until we opened ports 5060 and 5080 to UDP traffic from Callcentric's IP addresses, initial testing of SIP URI forwarding failed. The calls were being forwarded by Callcentric but being rejected by our equipment. SIP URI forwarding worked yesterday, but is not today for me. The one call that did make it through had no audio, otherwise, dead air is heard on SIP forwarded calls. Sigh. |
|
| reply to engineerdan
said by engineerdan:said by grand total:I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that.
Without meaning to sound argumentative, you may wish to double check your initial findings. No problem. I forwarded to another SIP server with an open port 5010 (Anveo). Calls were not being forwarded.
--
DPC3825 - WRT610N - Panasonic KX-TGP500 - Asterisk 1.8.11.0 with Asterisk GUI on Virtual Server
Anveo - Voxbeam - Localphone - Numbergroup - Callcentric - VoIP.MS - UKDDI |
|
garys_2kPremium
join:2004-05-07
Farmington, MI Reviews:
·callwithus
·Callcentric
| said by grand total:said by engineerdan:said by grand total:I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that.
Without meaning to sound argumentative, you may wish to double check your initial findings. No problem. I forwarded to another SIP server with an open port 5010 (Anveo). Calls were not being forwarded. That was exactly what I was hoping to try last night (sip forward to Anveo) but went to bed, instead. I guess it wouldn't have been successful, then. |
|
TrimlinePremium
join:2004-10-24
Windermere, FL Reviews:
·Callcentric
| reply to grand total
said by grand total:said by engineerdan:said by grand total:I tried to reroute calls to another SIP URI, but testing showed that the calls were not being forwarded. I don't think I was alone in that.
Without meaning to sound argumentative, you may wish to double check your initial findings. No problem. I forwarded to another SIP server with an open port 5010 (Anveo). Calls were not being forwarded. Try forwarding to a DID directly. I just tried, and it seemed to work. Let us know your results. |
|
garys_2kPremium
join:2004-05-07
Farmington, MI | As of last night that didn't work for me. My next step would have been to try SIP forwarding, but per grand total's experience, there was no guarantee that would work, either. |
|
|
|
Reviews:
·Callcentric
| reply to grand total
said by grand total:No problem. I forwarded to another SIP server with an open port 5010 (Anveo). Calls were not being forwarded.
Callcentric's FAQ (here and pasted below for your reference) indicates that the recipient of the SIP URI forward needs to permit traffic on ports 5060-5080, not just 5010. Might that have something to do with it?
NOTE: In general ports 5060-5080 should be allowed in order to properly communicate with the Callcentric servers. Users experiencing audio issues may want to check that RTP audio is not blocked by their firewall configuration. |
|
| said by engineerdan:Callcentric's FAQ (here and pasted below for your reference) indicates that the recipient of the SIP URI forward needs to permit traffic on ports 5060-5080, not just 5010. Might that have something to do with it?
NOTE: In general ports 5060-5080 should be allowed in order to properly communicate with the Callcentric servers. Users experiencing audio issues may want to check that RTP audio is not blocked by their firewall configuration. Callcentric does not care what port I forward to, but that port should be expecting SIP traffic. In Anveo's case port 5010 definitely is open and expecting SIP traffic.
You seem unable to accept that SIP URI forwarding did not work, but I can assure you it did not. (I have not tried today, and won't until all this mess is fixed).
--
DPC3825 - WRT610N - Panasonic KX-TGP500 - Asterisk 1.8.11.0 with Asterisk GUI on Virtual Server
Anveo - Voxbeam - Localphone - Numbergroup - Callcentric - VoIP.MS - UKDDI |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to Davesnothere
I guess (and it's just a guess here) - direct media mode (when RTP stream goes directly between customers and not through VSP servers) may mitigate the problem. Especially for SIP-SIP communications (which will eventually replace the old POTS lines). AFAIK, VoIP.ms doesn't provide it so far. Not sure about CallCentric though...
--
Keep it simple, it'll become complex by itself... |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to Davesnothere
One more thing to add here:
I think susceptibility to DDoS attacks depends on the software used and overall design structure deployed.
From small personal experience of running FreeSWITCH under DDoS I may assure you that FS is not prepared for reacting on DDoS at all. When I pointed that out to FS developers, I was faced back with arrogance - "it's your problem, not ours. Use system provided protection mechanisms if you need to do the job". But I think they're dead wrong. FS can easily recognize the beginning of the attack by a simple analysis of the SIP incoming traffic... Example? Common SIP clients don't try to send REGISTER requests with 50 different names changed alphabetically within 1 sec. There are obvious patterns of attacks, that SIP server could recognize almost immediately and stop responding to them, ... if they are designed with that problem in mind. In my case, FS tried to reply to all requests and eventually put the whole server down after depleting its system memory during several hours of hard (and completely unnecessary) work.
Which SIP server is used by CallCentric? I hope it's not FreeSWITCH.
How are they prepared to that event and what do they particularly do to mitigate that?
--
Keep it simple, it'll become complex by itself... |
|
| said by OZO:When I pointed that out to FS developers, I was faced back with arrogance - "it's your problem, not ours. Use system provided protection mechanisms if you need to do the job". But I think they're dead wrong. FS can easily recognize the beginning of the attack by a simple analysis of the SIP incoming traffic...
Your suggestion sounds like the approach that 3cx takes:
quote:
»www.3cx.com/blog/voip-articles/3···-attack/
3CX Premium Partner, Charles Ambrosecchia of Sigma Networks, reports that their Network Operations Center was the subject of an intense attack from an IP Address inside Germany for 17 continuous hours, with data rates peaking at over 5Mbps to a single 3CX Phone System installation.
Charles stated that 3CX Phone System performed admirably by rejecting the initial attempts at registration with incorrect forged credentials (essentially a brute force attack). Shortly thereafter, 3CX Phone System automatically classified the source of the attack as a potentially malignant entity and added it to its dynamic blacklist.
3cx is a commercial company. So they have a direct monetary incentive to solve their users' practical problems, rather than to be arrogant about it and treat it as an abstract problem. |
|
VexorgTR
join:2012-08-27
Sheffield Lake, OH | reply to Davesnothere
Having CC forward calls to a DID of some sort, Mobile or Other VOIP carrier worked just fine.
Again, I did all my forwarding to DID's. |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to tanzam75
Thanks for sharing that example. It just shows that some development teams want to improve their product, while others have obvious attitude problems, that makes them blind to any suggestions... The latter I saw a lot with FreeSWITCH development. They keep old bugs opened indefinitely without any attempt to fix... not to mention implementing new functions, that will benefit everyone.
Security of the SIP switch (always opened to public access) is very serious issue to ignore...
So, I'd suggest, look at SIP messages sent by your VSP and particularly at its "User-Agent" line and if it says "FreeSWITCH" don't be surprised if at some point of time it will go down and you'll not have any service at all due to some DDoS attack... (which could happen at any time, BTW).
--
Keep it simple, it'll become complex by itself... |
|
| reply to Davesnothere
This callcentric attack has caused severe down time for many of my close competitors/friends. I just today have joined some new forums to find out what others are doing and how susceptible my provider is to a DDos attack. I use Flowroute due to the influx of LNPs I originally needed to import. If you have not checked out their service do so before jumping into a new provider. |
|
nitzanPremium,VIP
join:2008-02-27
kudos:2 | reply to OZO
said by OZO:I guess (and it's just a guess here) - direct media mode (when RTP stream goes directly between customers and not through VSP servers) may mitigate the problem. Especially for SIP-SIP communications (which will eventually replace the old POTS lines). AFAIK, VoIP.ms doesn't provide it so far. Not sure about CallCentric though... AFAIK CallCentric, as well as almost all large retail providers, proxy all audio. There are excellent business and technical reasons to do so, but I won't get into them here. |
|
gweidenh
join:2002-05-18
Houston, TX
kudos:1 | said by nitzan:AFAIK CallCentric, as well as almost all large retail providers, proxy all audio. There are excellent business and technical reasons to do so, but I won't get into them here.
Please start a new thread and list off some of the key reasons. I for one avoid providers that proxy the audio. |
|
