Do you know off hand what criteria Kamailio commonly uses to dump excessive SIP flows? Is it based on IP (black/whitelists)? Throttling back INVITES from the same source? A common method that was in the news was someone posting a malicious link on twitter (for example) that caused cell phones to dial 911. If the twitter feed is read by folks who live in Massachusetts for example the 911 call center could be flooded for a period of time. Just an example. Is this another case, like DDOS, where we are just screwed for the most part as providers? Matt ________________________________ From: sasha at evaristesys.com <sasha at evaristesys.com> on behalf of Alex Balashov <abalashov at evaristesys.com> Sent: Monday, May 15, 2017 10:49:29 AM To: Matthew Yaklin Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Mitigating or stopping TDOS attacks - any advice? In the open-source world, this is an application to which Kamailio is exceptionally well-suited, provided you can devise some means of putting the customer "behind" it. The lightweight architecture and enormous message throughput makes it an exceptionally good fit for lightly stateful tasks like dumping excessive SIP flows. On Mon, May 15, 2017 at 02:44:30PM +0000, Matthew Yaklin wrote:

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

-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

On Mon, May 15, 2017 at 11:21:36AM -0400, Ivan Kovacevic wrote:

It seems to be more of an art, making it inherently difficult to programmatically pre-empt it.

This is definitely true. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Switches with TDM interfaces, even with calls that ingress and egress as TDM, still often have the ability to query some sort of policy / admission control server, e.g. via SIP redirect. Where technically possible, this can be used to "inject" intelligence where little to none exists (as is so commonly the case with the Big Brands), or to devise intelligence that is specific to your environment and problem space. Where not technically possible - well ... -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

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/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1q...> | SIP Based Services for Contact Centers | LinkedIn <http://t.sidekickopen61.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1q...> *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/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4L...]

Is this idea corny? Perhaps a solution could be like they do for web pages to prove you are human. Direct all the customer's incoming calls to an asterisk box. The asterisk box plays a recording asking for them to type in a digit string that is random for each call. If the person types in the right string.. allow the call. If the wrong string is entered.. drop the call. A beefy asterisk box can handle many calls. Probably more the the switch's incoming trunks if the hardware is up to it. Just use this when needed and after the TDOS fades away.. disable it. Just an idea... probably has several holes in it. --- I also saw this while googling. Not enough info on the web page for me to even guess if the solution really works. https://securelogix.com/threats/telephony-denial-of-service-tdos-attacks/ . I think it uses Splunk on the back end. Matt ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Alex Balashov <abalashov at evaristesys.com> Sent: Monday, May 15, 2017 1:15:38 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Mitigating or stopping TDOS attacks - any advice? On Mon, May 15, 2017 at 01:09:01PM -0400, Ivan Kovacevic wrote:

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 suppose it depends on how many concurrent channels/call paths the customer has. Given a very small number, almost any amount of calls can tie them up. But, in general, it's not a DoS attack if it doesn't ... DoS. :-) If the attackers slow down the call setup rate enough that it doesn't meet frequency-based DoS detection, chances are it's not a very impactful attack. Of course, there is a grey area; everything is vague to a degree we do not realise until we try to make it precise (with apologies to Bertrand Russell). -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

I noticed how you mentioned asterisk and if it could handle that many calls and you seemed skeptical. Probably based on experience. After all these years I thought a single asterisk server could handle more calls in a stable fashion but it appears not. Once past 500 concurrent calls, depending on hardware and config, things start to get sketchy. It has been a while since I last used asterisk for a VM server or pbx. Those days seem long ago. Over the years we have had customers experience TDOS. While we have no current customer experiencing the issue today we wanted to research our options just in case. It seems metaswitch has a cloud based robocall blocking feature we just read about. I have to wonder if that hook in the switch could be used for something. As others have said though... gathering all this cdr info, analyzing it, and then blocking certain calls while keeping good ones is quite the task to program. And to do it really fast. One can stop trivial attacks that have a pattern but a determined attacker can be quite crafty. Thank you everyone, Matt ________________________________ From: sasha at evaristesys.com <sasha at evaristesys.com> on behalf of Alex Balashov <abalashov at evaristesys.com> Sent: Tuesday, May 16, 2017 5:01:04 PM To: Matthew Yaklin Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Mitigating or stopping TDOS attacks - any advice? A "voice CAPTCHA" is a viable solution. But it does require infrastructure commitments on your part, even if, as you say, an Asterisk box can handle many concurrent calls. If you want to recycle that across multiple customers, that kind of moat can get mildly complicated. The only concern I would have is from a user experience point of view; your customer might not want their callers to have to go through a confusing menu, and it would doubtless be psychologically off-putting. I don't know what kind of business the customer is, but imagine if you called your dentist's office and were prompted to enter some sort of PIN. As a layperson, you might think something is wrong with the phone system. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

The key here is not holding the call past the authentication transaction. This is a relatively trivial javascript/lua application in freeswitch and the FS instances in this case are an excellent candidate for being containerized. Take the call, auth it with a voice captcha, then get rid of it. Perhaps do the auth during early media then 302 it. Your CPU cycles spent goes down by orders of magnitude this way. I know if at least one large provider doing exactly this on behalf of their customers. Imminently do-able. If you are interested in doing this, but timid, feel free to reach out off-list. Im happy to point you in the right direction. On 5/16/2017 2:01 PM, Alex Balashov wrote:

A "voice CAPTCHA" is a viable solution. But it does require infrastructure commitments on your part, even if, as you say, an Asterisk box can handle many concurrent calls. If you want to recycle that across multiple customers, that kind of moat can get mildly complicated.

The only concern I would have is from a user experience point of view; your customer might not want their callers to have to go through a confusing menu, and it would doubtless be psychologically off-putting. I don't know what kind of business the customer is, but imagine if you called your dentist's office and were prompted to enter some sort of PIN. As a layperson, you might think something is wrong with the phone system.