Hackers Crash Clay Co. Phones ...
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count y-271463051.html?ref=051 Painful issue for Big River Telephone! Frank
It seems like almost every telephone company can be hit like that except the ?largest?... A denial of service attack by simply calling so many times it fills up their main trunks. And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke. matt On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both. Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest. I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level. -Ryan On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3). It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas: -- Has telephone number A called to telephone number B before? Or B->A ? -- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A? The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate. And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way. And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That sounds like call-blocking, which is not allowed... Frank -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mark R Lindsey Sent: Monday, August 18, 2014 2:49 PM To: ryandelgrosso at gmail.com Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3). It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas: -- Has telephone number A called to telephone number B before? Or B->A ? -- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A? The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate. And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way. And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count y-271463051.html?ref=051
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting. Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers. This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly. 2 of the examples we discussed previously were: 1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar. 2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing. Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc. Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing. I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control). On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Hi, Team - Mathematically, an interesting algorithm to apply here would be a Bloom Filter, http://en.wikipedia.org/wiki/Bloom_filter. The concept is that each call is hashed 3 ways. Let's just assume there are 32,000,000 bits that start out as 0. Concatenate the FROM and TO E.164 addresses. Then hash that string 3 ways (yielding 3 numbers, X(c1), Y(c1), Z(c1)). To record the fact that call c1 has happened, we light bits X(c1), Y(c1), and Z(c1). If, later on, an incoming call, c(n), hashes and receives false from (X(cn) AND Y(cn) AND Z(cn)), then call cn is definitely a call that has not been seen before. (If it had been a repeat, all three of those bits would be lit!) There is a chance that a TRUE will result from bad luck . . . but we can compute the chance of a false positive and accept that "risk". (If 10% of the bits in the Bloom Filter have been lit, there is a 0.1 * 0.1 * 0.1 = 0.001 chance of mistakenly thinking .) The algorithm requires only 32,000,000 bits of RAM. Over time, the Bloom Filter will begin to fill up. When the Bloom Filter becomes close to full (let's say 3,000,000 bits lit or after some arbitrary amount of time), simply zero out all of the bits and start all over. So . . . keep statistics on the ratio of recognized calls versus unrecognized calls over a given time period. If there are wildly too many recognized calls, you might have a small set of numbers flooding (TDoS) a small set of numbers. If there are wildly too few recognized calls, you might have a spoofer pretending to be a large number of different (fake) FROM numbers. I just wanted to throw out a new algorithm because I know you guys will like to read about it in wikipedia, / Jim -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 3:53 PM To: Mark R Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting. Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers. This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly. 2 of the examples we discussed previously were: 1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar. 2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing. Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc. Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing. I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control). On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD: http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-Monito... Cheers, Simon. -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting. Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers. This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly. 2 of the examples we discussed previously were: 1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar. 2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing. Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc. Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing. I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control). On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution. Is CPM driven off of CDR's or off of the SAS datastream or some other source? If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's) It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources. -Ryan On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-Monito...
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action. Cheers, Simon. -----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution. Is CPM driven off of CDR's or off of the SAS datastream or some other source? If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's) It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources. -Ryan On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- Monitor.pdf
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- Clay-County-271463051.html?ref=051
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I think Ryan's point here is getting data on in-progress calls into it instead of completed calls.. AFAIK CPM basically watches the real time call logs from the CFS, and only knows about calls once they complete. On Aug 18, 2014 6:04 PM, "Simon Dredge" <Simon.Dredge at metaswitch.com> wrote:
Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action.
Cheers,
Simon.
-----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution.
Is CPM driven off of CDR's or off of the SAS datastream or some other source?
If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's)
It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources.
-Ryan
On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- Monitor.pdf
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- Clay-County-271463051.html?ref=051
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
All I might have a solution that I'd like to talk to the group about. It can not only detect but could use your switch API to take action. Who's interested in discussing it! Sent from my iPhone
On Aug 18, 2014, at 9:59 PM, Tim Jackson <jackson.tim at gmail.com> wrote:
I think Ryan's point here is getting data on in-progress calls into it instead of completed calls..
AFAIK CPM basically watches the real time call logs from the CFS, and only knows about calls once they complete.
On Aug 18, 2014 6:04 PM, "Simon Dredge" <Simon.Dredge at metaswitch.com> wrote: Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action.
Cheers,
Simon.
-----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution.
Is CPM driven off of CDR's or off of the SAS datastream or some other source?
If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's)
It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources.
-Ryan
On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- Monitor.pdf
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
> http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- > Clay-County-271463051.html?ref=051 > > Painful issue for Big River Telephone! > > Frank > > > _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Discuss away, were all riveted with antici...... :) On 8/18/2014 7:52 PM, Anthony Orlando via VoiceOps wrote:
All I might have a solution that I'd like to talk to the group about. It can not only detect but could use your switch API to take action. Who's interested in discussing it!
Sent from my iPhone
On Aug 18, 2014, at 9:59 PM, Tim Jackson <jackson.tim at gmail.com <mailto:jackson.tim at gmail.com>> wrote:
I think Ryan's point here is getting data on in-progress calls into it instead of completed calls..
AFAIK CPM basically watches the real time call logs from the CFS, and only knows about calls once they complete.
On Aug 18, 2014 6:04 PM, "Simon Dredge" <Simon.Dredge at metaswitch.com <mailto:Simon.Dredge at metaswitch.com>> wrote:
Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action.
Cheers,
Simon.
-----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com <mailto:ryandelgrosso at gmail.com>] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution.
Is CPM driven off of CDR's or off of the SAS datastream or some other source?
If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's)
It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources.
-Ryan
On 8/18/2014 3:36 PM, Simon Dredge wrote: > I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD: > > http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- > Monitor.pdf > > Cheers, > > > Simon. > > > -----Original Message----- > From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] On Behalf Of > Ryan Delgrosso > Sent: Monday, August 18, 2014 1:53 PM > To: ECG - Mark Lindsey > Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> > Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... > > I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting. > > Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers. > > This sounds like good territory for an acme SPL plugin, possibly in > conjunction with this enum extension > http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly. > > 2 of the examples we discussed previously were: > > 1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar. > > 2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing. > > Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc. > > Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing. > > > I think this has commercial viability for access providers protecting > their customers business interests and for implementers designing > solutions but perhaps not so much in a carrier to carrier capacity > (beyond appropriate support of signaling congestion control). > > > On 8/18/2014 12:48 PM, Mark R Lindsey wrote: >> Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3). >> >> It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas: >> >> -- Has telephone number A called to telephone number B before? Or B->A ? >> >> -- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A? >> >> The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate. >> >> And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way. >> >> And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network." >> >> >> >>>>> mark at ecg.co <mailto:mark at ecg.co> +1-229-316-0013 <tel:%2B1-229-316-0013> http://ecg.co/lindsey >> On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com <mailto:ryandelgrosso at gmail.com>> wrote: >> >>> IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both. >>> >>> Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest. >>> >>> I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level. >>> >>> -Ryan >>> >>> On 8/18/2014 6:30 AM, Matt Yaklin wrote: >>>> It seems like almost every telephone company can be hit like that >>>> except the ?largest?... >>>> >>>> A denial of service attack by simply calling so many times it fills >>>> up their main trunks. >>>> >>>> And we saw how the large IP colo providers handle this for >>>> customers who get dos'd. The amount of bandwidth they have is >>>> staggering and they still cannot guarantee you will stay up if a >>>> ?skilled? attacker wants you down. So you keep throwing money at it >>>> until you are so well established online that you look at your >>>> monthly bill and want to puke. >>>> >>>> matt >>>> >>>> On Mon, 18 Aug 2014, Frank Bulk wrote: >>>> >>>>> http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- >>>>> Clay-County-271463051.html?ref=051 >>>>> >>>>> Painful issue for Big River Telephone! >>>>> >>>>> Frank >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> VoiceOps mailing list >>>> VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> >>>> https://puck.nether.net/mailman/listinfo/voiceops >>> _______________________________________________ >>> VoiceOps mailing list >>> VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> >>> https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> > https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
i was thinking a conf call. ?Maybe 4-5 participants. ?Let me know who's interested. On Tuesday, August 19, 2014 12:39 AM, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote: Discuss away, were all riveted with antici...... :) On 8/18/2014 7:52 PM, Anthony Orlando via VoiceOps wrote: All? ? I might have a solution that I'd like to talk to the group about. It can not only detect but could use your switch API to take action. Who's interested in discussing it! Sent from my iPhone On Aug 18, 2014, at 9:59 PM, Tim Jackson <jackson.tim at gmail.com> wrote: I think Ryan's point here is getting data on in-progress calls into it instead of completed calls..
AFAIK CPM basically watches the real time call logs from the CFS, and only knows about calls once they complete. On Aug 18, 2014 6:04 PM, "Simon Dredge" <Simon.Dredge at metaswitch.com> wrote:
Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action.
Cheers,
Simon.
-----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
Simon, I think the gotcha with CPM in this scenario is its a
great tool for determining "this has happened" but not so great for building a mitigation solution.
Is CPM driven off of CDR's or off of the SAS datastream or
some other source?
If its CDR driven you will be blind to this problem
because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut).
If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's)
It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources.
-Ryan
On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- Monitor.pdf
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account? (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies?? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
? ? ? -- Has telephone number A called to telephone number B before? Or B->A ?
? ? ? -- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
> http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- > Clay-County-271463051.html?ref=051 > > Painful issue for Big River Telephone! > > Frank > > >
_______________________________________________
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
<delurks> Would those interested in this matter like to hijack the VoIP Users Conference call this week? We don't have a guest arranged for this week. Randy is on vacation so I have the helm. We have the ZipDX monster bridge at our disposal. </delurks> Michael Graves mgraves at mstvp.com http://www.mgraves.org o(713) 861-4005 c(713) 201-1262 sip:mgraves at mjg.onsip.com skype mjgraves --------- Original Message --------- Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... From: "Anthony Orlando via VoiceOps" <voiceops at voiceops.org> Date: 8/19/14 8:23 am To: "Ryan Delgrosso" <ryandelgrosso at gmail.com>, "voiceops at voiceops.org" <voiceops at voiceops.org> i was thinking a conf call. Maybe 4-5 participants. Let me know who's interested. On Tuesday, August 19, 2014 12:39 AM, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote: Discuss away, were all riveted with antici...... :) On 8/18/2014 7:52 PM, Anthony Orlando via VoiceOps wrote: All I might have a solution that I'd like to talk to the group about. It can not only detect but could use your switch API to take action. Who's interested in discussing it! Sent from my iPhone On Aug 18, 2014, at 9:59 PM, Tim Jackson <jackson.tim at gmail.com> wrote: I think Ryan's point here is getting data on in-progress calls into it instead of completed calls.. AFAIK CPM basically watches the real time call logs from the CFS, and only knows about calls once they complete. On Aug 18, 2014 6:04 PM, "Simon Dredge" <Simon.Dredge at metaswitch.com> wrote: Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive analytics. It'll trigger immediately (in real-time) on an anomaly, informing the operator that action is required so they can take necessary action. Cheers, Simon. -----Original Message----- From: Ryan Delgrosso [mailto:ryandelgrosso at gmail.com] Sent: Monday, August 18, 2014 4:32 PM To: Simon Dredge Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ... Simon, I think the gotcha with CPM in this scenario is its a great tool for determining "this has happened" but not so great for building a mitigation solution. Is CPM driven off of CDR's or off of the SAS datastream or some other source? If its CDR driven you will be blind to this problem because you wont be measuring calls that are rejected due to lack of capacity(no cdr cut). If its driven off of SAS data you will get the missed/incomplete call stats but at the cost of speed (multiple orders of magnitude more data than CDR's) It would be interesting to hear if this perhaps uses a different datasource. Perhaps there is a facility in perimeta that informs this better than CFS data sources. -Ryan On 8/18/2014 3:36 PM, Simon Dredge wrote:
I know many meta-users like the new-ish call pattern monitor. It uses weighted profiling benchmarking algos similar to NBAD:
http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern- Monitor.pdf
Cheers,
Simon.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso Sent: Monday, August 18, 2014 1:53 PM To: ECG - Mark Lindsey Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
I dunno that's a slippery slope. Im not a proponent of putting management of your network services into someone elses hands, especially things like this where the service provider should have visibility into what they are or are not admitting.
Agreed on your synopsis of call admission control, the border should be able to make these decisions rapidly, freeing up softswitch resources to actually serve customers.
This sounds like good territory for an acme SPL plugin, possibly in conjunction with this enum extension http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i dont see a clear path for this in the TDM world but my exposure there is limited. It would seem like a good solution might be using ENUM (with source URI) to build statistics centrally based on calling/called numbers and then forcing the ENUM response once thresholds are hit to illicit an appropriate decline message for flagged invites with a retry-after interval allowing you to effectively throttle specific call scenarios assuming your origination carriers will behave correctly.
2 of the examples we discussed previously were:
1: Social media death star. Justin biebers (or anyone else with millions of rabid followers) twitter account (53.7M followers) gets hacked and attacker tweets "Call this number for free tickets" or similar.
2: T-DOS using stolen sip accounts effectively turning other service providers into a death star. More damage per source number (higher CPS than social media per attacker but less distributed source). This one seems much easier to create given the ease with which stolen sip accounts can be acquired, and harder to mitigate if the stolen accounts support callerID spoofing.
Both of these situations are exacerbated by LCR resellers creating at times 10-20 invites from 1 due to route advancing when the destination is truly congested, which gets worse when the LCR resellers in turn have resellers in route etc etc.
Of course any solution needs to have provisions for conveying congestion control to the originating network so they stop route advancing.
I think this has commercial viability for access providers protecting their customers business interests and for implementers designing solutions but perhaps not so much in a carrier to carrier capacity (beyond appropriate support of signaling congestion control).
On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies? i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
-- Has telephone number A called to telephone number B before? Or B->A ?
-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
-Ryan
On 8/18/2014 6:30 AM, Matt Yaklin wrote:
It seems like almost every telephone company can be hit like that except the ?largest?...
A denial of service attack by simply calling so many times it fills up their main trunks.
And we saw how the large IP colo providers handle this for customers who get dos'd. The amount of bandwidth they have is staggering and they still cannot guarantee you will stay up if a ?skilled? attacker wants you down. So you keep throwing money at it until you are so well established online that you look at your monthly bill and want to puke.
matt
On Mon, 18 Aug 2014, Frank Bulk wrote:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In- Clay-County-271463051.html?ref=051
Painful issue for Big River Telephone!
Frank
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Fixed link:
http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-Count...
-- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
participants (10)
-
avorlando＠yahoo.com -
frnkblk＠iname.com -
jackson.tim＠gmail.com -
jim.gast＠tdstelecom.com -
jra＠baylink.com -
lindsey＠e-c-group.com -
mgraves＠mstvp.com -
myaklin＠g4.net -
ryandelgrosso＠gmail.com -
Simon.Dredge＠metaswitch.com