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