[on-asterisk] Brute force and controlled anarchy.

[Reza - Voipernetics]

Contrary to advise and suggestions from many professionals in the
industry per Brute Force attacks, firewalls, log monitoring for brute
registrations, increased CPU usage due to brute force, my experience
shows that a "controlled form of anarchy, keeping things simple, appears
to be the best strategy.

Unlike rejecting and banning IPs, which still invokes bandwidth usage
and cpu usage, this is what I have done:

a) Have a separate context exclusively for unauthorized calls.
b) Allow all fake registrations to think they have registered (they no
longer pound with brute force if they think they got in)
c) Send ALL the calls for fake registrations (who think they logged
in) into a "SCREAMING MONKEYS" context.

My observation invoking these simple techniques has resulted into zero
dead locks on clients machines and production machines that get hammered
on a regular basis, running different versions of Asterisk.

Yes, ideally you would want to have an SBC but for those of you who do
not have the knowledge or resources for SBC, the above steps per our
experience has been rock solid stable. Our technical support requests
for all our installations across the globe, as gone done from few calls
per day, to zero calls in the last 30 days.

Technical:

a) Have a separate context exclusively for unauthorized calls.
I call this context "MONKEYS", you could choose "BUFFOONS" if you wanted.

b) Allow all fake registrations to think they have registered (they no
longer pound with brute force if they think they got in). That is do
the following:
For sip.conf file, edit "default" context which looks like "[default]"
to "[MONKEYS]" or "[BUFFOONS]".
context=MONKEYS
allowguest=yes
;authfailureevents=no (make sure this is commented)
alwaysauthreject = yes


c) Send ALL the calls for fake registrations (who think they logged
in) into a "SCREAMING MONKEYS" context.
That is modify the extensions file "extensions.conf" and insert the
following:
[MONKEYS]
exten => _X.,1,NoOp(Thugs, Monkeys and Buffons are attempting to
dial in)
exten => _X.,n,NoOp(======================================)
exten => _X.,n,NoOp(BUFFOONS IP ADDRESS: ${CHANNEL(recvip)}. This
actually shows you the IP address of the caller)
exten => _X.,n,NoOp(Buffoon tried to call: ${EXTEN}. This is for
your records what number he actually dialed)
exten => _X.,n,NoOp(======================================)
exten => _X.,n,Answer
exten => _X.,n,Playback(tt-monkeys)
exten => _X.,n,Wait(100)
exten => _X.,n,Hangup

FYI, all default asterisk distribution comes with a sound file which is
the sound of screaming monkeys... and that file is " tt-monkeys "

For those of you who do not have an SBC (as with close to 100% of our
clients), the above simple techniques has been superb. In a brute
force attack, using stress testing software such as SIPviscious or other
scripts, the objective of the idiot is to try to hack into your server
for the purpose of toll fraud. So in the above scenario - rather than
your server having to manage and block thousands and thousands of
registration attempts in seconds, or responding to a "Failed
authorization", which further provokes software like SIPViscious to do
more brute attempts, it "thinks" it has registered successfully, and
starts attempting calls to expensive destinations, eliminating another
attempt for 10K retries. In their attempt, all they hear is screaming
monkeys.

Leaving SBC's aside, would like to hear from others, what simple steps
you may have taken to rid these attacks.
No... FAIL2BAN does not help in a massive DDOS attack, even if you
have everything perfect.

Cheers!
Reza.

--
FOUNDER & SR. TELECOM ANALYST
VOIPERNETICS COMMUNICATIONS
TEL: 647-847-2287 x2016


---------------------------------------------------------------------
To unsubscribe, e-mail: asterisk-u...@uc.org
For additional commands, e-mail: asteri...@uc.org

[Bruce N]

Thanks for sharing Reza; It's very interesting to know how your solution
changed the amount of support required.

Now, let's see if someone can add speech recognition to sipvicious to
detect tt-monkeys tone => therefore the presence of asterisk and to dig
deeper :)

VPN might send curious observers away more than anything else but it is NOT
cheap.

-Bruce


On Wed, Jul 29, 2015 at 4:42 PM, Reza - Voipernetics <re...@voipernetics.com>
wrote:

[David Donovan]

Hi Reza,

Thanks for sharing your solution. It reminds me of an SMTP tar pit.

While there's no arguing with your first-hand observations of reduced
deadlocks and system load, I wonder if this reduces the impact of
scripted/brute force attacks but creates another risk. If a buffoon can
connect and cause your system to play screaming monkeys, could they not
make hundreds or thousands of calls and cause a serious load problem on the
system? The calls won't reach a proper remote termination of course, but
if mere denial of service was the goal, could this be an issue?

I'm not administering public-facing Asterisk boxes so maybe I'm overlooking
something obvious. The issue could be possibly mitigated by sip call-limit
or something.

If it ever became a problem, I'm sure there's a way to reduce the amount of
resources used in the buffoon context, like giving Ringing() (which doesn't
send audio if I'm right) for a loooong time then a HangUp(). As you say,
the malicious scripts criteria for success is logging in, not necessarily
completing a call.

I was also reminded of this quote:
“The green reed which bends in the wind is stronger than the mighty oak
which breaks in a storm.”
― Confucius

Thanks again for contributing,

Dave

[John Lange]

I also found that approach very interesting. It's the opposite of what you
would intuitively do, ie let everyone in, vs. block everyone who's unknown.

As others have mentioned, the one concern I have is the load caused by
playback of tt-monkeys (though I'm amused). Wouldn't it work equally well
to simply do an Answer(), then Wait(100) without playback?

And doesn't it also make sense to combine the above with a Fail2Ban keyed
on the log of "BUFFOONS IP ADDRESS"?

Regards,

John

[Bruce N]

John,

I think Reza's main concern is really true DDoS directed at telephony
servers for the purposes of gaining access to routes (i.e. call North Korea
and the operator will share profits with you).

By blocking IPs as they come in, you are still indicating you are a SIP
server and you are worried and want to block access so there comes more
tries from different IP sources which is what DDoS is at core. What Reza is
suggesting, let them think they got access and let them dial so they think
they are making money while they are not. This will stop DDoS *probably*
because they will think they got access so their DDoS will be directed
somewhere else. I think this work because those who run scripts run them
without secondary checks and there are easier targets to move onto than to
come back to Reza's servers and figure out why they failed. They will
recognize it as a sip server with no international routes maybe...hence
banning IPs is the opposite of what he suggests to do.

-Bruce

[Liviu Toma]

Hi,

There's another interesting approach to filtering SIP scanners that I
found on the DSLReports VoIP forum:
http://www.dslreports.com/forum/r29375858-SIP-Scanners
Basically allow known IP addresses in your iptables rules, and for the
rest of the world, allow only clients that use a specific host name to
reach you (obviously, make sure your reverse DNS doesn't reveal that
host name).
For everyone else, your PBX will be completely opaque.

Liviu

[John Lange]

Interesting. But DDos (Distributed Denial of Service) is an attack intended
to make a service completely unavailable. That is not what is being
described above, and in any case, the above tactics would not stop a true
DDoS. In fact, it would make you more vulnerable since all I have to do is
attempt to dial thousands of times in parallel and you machine would die
trying to play thousands of instances of tt-monkeys at the same time.

That being said, the attack above is brute force exploitation. In my
experience, once they are blocked and realize they are detected, they move
on to other targets. They don't switch IPs and try again since there is
little chance of success.

--
John Lange
www.johnlange.ca

[Bruce N]

That is a great workaround. However, I see this as an inherent SIP RFC
issue and an improvement similar to this on the RFC will probably stop
having to find these sort of workarounds all together.

For example, you can set your SIP server to respond to first SIP packet
only if the first request comes with a valid username. Current RFC asks to
respond to it with tokens and handshake for further negotiation which is
weak. The SIP server should drop the first packet the moment it sees the
invalid username in the packet. Dropping it, some argue will lead to
remuneration of extension numbers or usernames. However, you can easily
mitigate that by having a random long alphanumeric username and your second
line of defense will be the password which will be exchanged while
encrypted. So, this creates a two level authentication (what is becoming
popular these days).

This still doesn't answer true DDoS attacks as others mentioned but all
these minor things help along the way in cost savings which is the goal.

- Bruce