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:[email protected]] On Behalf Of Ryan
Delgrosso
Sent: Monday, August 18, 2014 1:53 PM
To: ECG - Mark Lindsey
Cc: [email protected]
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."
[email protected] +1-229-316-0013 http://ecg.co/lindsey
On Aug 18, 2014, at 13:52 , Ryan Delgrosso <[email protected]> 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
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
