[VoiceOps] Mitigating or stopping TDOS attacks - any advice?

Mon May 15 13:09:01 EDT 2017

I think putting this à “block the offending traffic pattern” into practice
is the crux of the issue. Maybe I am short-sighted or don’t give AI
sufficient credit, but I think identifying the offending traffic pattern is
not going to be easy (or maybe possible at all).

Anyone initiating a TDOS attack can manipulate the call pattern and caller
ID easy enough to make it look like ‘normal’ traffic.

I do hope I am wrong, but…

Best Regards,

Ivan Kovacevic

Vice President, Client Services

Star Telecom | www.startelecom.ca
<http://t.sidekickopen61.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1qMvVnW3LjyBM63K6FlW63JXmj56dLPjf6TyZWx02?t=http%3A%2F%2Fwww.startelecom.ca%2F&si=6470560385859584&pi=c347a136-9122-44d9-b157-dd8bfc614cc9>
| SIP Based Services for Contact Centers | LinkedIn
<http://t.sidekickopen61.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1qMvVnW3LjyBM63K6FlW63JXmj56dLPjf6TyZWx02?t=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fstar-telecom-www-startelecom-ca-%3Ftrk%3Dbiz-companies-cym&si=6470560385859584&pi=c347a136-9122-44d9-b157-dd8bfc614cc9>

*From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Carlos
Perez
*Sent:* May 15, 2017 12:57 PM
*To:* Victor Chukalovskiy <victor.chukalovskiy at gmail.com>
*Cc:* voiceops at voiceops.org
*Subject:* Re: [VoiceOps] Mitigating or stopping TDOS attacks - any advice?

(with the context being unwanted calls) An alternative that should be
considered since it will add the intelligence to identify abnormal patterns
and not complicating your signaling path (introducing an additional
possible point of failure and or post dial delay) is using a machine data
analyzer solution such as Splunk or ELK.

This approach is based on near-realtime processing of CDRs therefore it can
manage one or many brands. It is highly scalable (since the data processing
is done off-board) and highly customizable to tailor any needs. The idea is
that upon detecting an abnormal pattern the data analyzer interacts with
the switch in the form of a hook/API instruction to have the logic on the
switch to block the offending traffic pattern (instead of throttling or
blocking an entire source IP or trunk which may not be wanted in this case
as it will block wanted traffic).

Carlos Perez

Sansay, Inc.

On Mon, May 15, 2017 at 8:05 AM, Victor Chukalovskiy <
victor.chukalovskiy at gmail.com> wrote:

Hi,

You are talking PSTN --> customer call flow scenario in CLEC setting.
Usually  a class 4/5 switch is set to "transparently" pass all incoming
calls from PSTN side to whatever customers trunk or line the DID or range
is pointed to. And then either that resource gets full due to call volume
or your switch starts failing or lagging due to CPS.

You have two options however:

If you were to pass all your traffic through a SIP proxy, like Kamallio or
OpenSIPS like Alex suggested, that  proxy can be programmed to do any kind
of fancy call admissions control, dynamic filtering, number pattern etc.‎
This however means you put an extra box in the call path between your PSTN
switch and a customer.

Alternatively, you may try to see if all your PSTN switches can do some
kind of external dip or routing query on incoming calls (radius, SIP refer
etc). If they can, you can set a server or a cluster that would answer all
those dips and decide on per-call basis wether the call should be admitted
or not. So think external "brain" for your switches. This way call
admission controll decision is made externally, but enforced right at your
PSTN switch, and you don't have extra box in the call path. Making it
somewhat more elegant.

This is pretty high-level, but if I understood your topology right, these
are basically your two options.

-Victor

Sent from my BlackBerry 10 smartphone.

*From: *Matthew Yaklin

*Sent: *Monday, May 15, 2017 10:44

*To: *voiceops at voiceops.org

*Subject: *[VoiceOps] Mitigating or stopping TDOS attacks - any advice?

Hello all,

I am curious what others have in place or actions they take when a customer
is the target of a TDOS attack?

TDOS being Telephony Denial of Service. An attack where the perp uses
whatever means to flood a customer's telephone service with unwanted calls.

Say you are a multi state CLEC. You have multiple brands of switches (Meta,
Taqua, DMS, Genband, etc...) as well as ACME and Perimeta SBCs in use. You
have legacy TDM as well as SIP trunks. Your customers are served via legacy
and modern methods. You have hosted PBX as well (Broadsoft). Many customers
are on your LAN but many are on the internet. So that is our situation. Or
you can be bigger or smaller. No matter the size I would welcome how you
handle it.

We have asked our manufacturers for advice but they have only provided the
basic number blocking available by default on the switch. Meta and Genband
have provided little other than pointing to existing features. If you have
any thoughts on whether there is something we can provide based upon SIP
messaging or other creative solutions that would be awesome!

So I welcome a discussion on this and any advice other operators can give.

Thank you very much,

Matt

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[image:
http://t.sidekickopen61.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4LCS0Vf6xNj7dSCJWW64Jplz1pctGFW55kbNc1k1H6H0?si=6470560385859584&pi=c347a136-9122-44d9-b157-dd8bfc614cc9]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20170515/ff69e0a6/attachment-0001.html>