[VoiceOps] Hackers Crash Clay Co. Phones ...
Ryan Delgrosso
ryandelgrosso at gmail.com
Tue Aug 19 00:37:02 EDT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20140818/7d5149b3/attachment-0001.html>
More information about the VoiceOps
mailing list