[asterisk-users] iptables/ blocking brute-force attacks, and so on...

[Gordon Henderson]

I've just posted this to another list where we were talking about the same 
old issues we've been plagues with recently - I'd already posted some 
iptables rules, but added more to it for this...

This script probably isn't compatable with anything else, but I don't run 
anything else. It's also designed to act on the incoming interface, not to 
run in a router, but it's not hard to make it run in a router - but easier 
to port-forward in the router and run it on the host.
===


So I've decided to put together some additional rules to help prevent bulk
attacks/ddos type of things...

Fail2ban is OK - if you've got the time to configure it to parse log-files
and if you run python. In my world, I don't run python and parsing
log-files to create config files is tedious, although this has probably
already been done...

I also feel it solves the wrong problem as there are tools already
built-in to the Linux kernel to do some of this anyway, and I loathe
bloat. In my view, fail2ban and it's ilk should never have been written,
but I can't deny that they don't work - I just think it's better to use
what's already available.

However, I accept that iptables/netfilter and the other bits that can go
with it are horribly complex if you're not a syadmin type (and sometimes,
even if you are!!!)

So what I'll do (as it's what I do myself) is build on the script I use
myself and then you can use it yourself, or adapt it as needed... (or just
laugh and hit the delete key)

===

Here's the issue: We need to stop bulk SIP register attempts which try to
find open SIP account, or perform password guessing, while leaving the
server open to the world in-general (which is essential if, as I do, you
offer SIP trunking services to people with dynamic IP addresses, and
generally want yourself or staff to connect remotely to your own SIP
server when out and about)

I'll call this activity "slamming".

Ideally we want the solution to be as general purpose as possible without
continually having to "tune" it to re-parse log-files or add/remove IP
addresses manually and so on. Essentially a "fire and forget" type
approach. (However, we should never really forget it and regular checking
would be sensible)

Linux has built-in "deep packet inspection" code, and it also has a bunch
of code that will "mark" packets for further inspection. This code is
capable of efficiently timing matches too - so you can count "up to" so
many per second, minute, etc. and you can combine matches with protocol,
IP address and just about anything else in the IP stack you can think of.

So the plan - we time or mark incoming SIP connections of certain types
from all IP addresses that connect, and if they start to exceed a set
limit of connections per time unit, we block them, and we will keep on
blocking them while they're slamming the server.

(And AIUI, this is more or less what Fail2Ban is doing - only it's looking
in log-files for activity - we're doing it as it happens right inside the
kernel)

What this won't do is act as a substitute for good username/password
combinations, and the use of alwaysauthreject=yes in sip.conf, but it will
slow them down and stop the "slamming" types of attacks, so in this
respect, it's no different to controlling access to other services - such
as ssh, pop/imap/smtp-auth and so on. However it should keep your
bandwidth down to a minimum and (probably more importantly), CPU usage if
it's a low-power processor. And hopefully when the crackers stop seeing
replys, they'll give up and go elsewhere.

It's downfalls:

Providing virtual PBX services for SMEs:

We have to be careful if we're providing virtual PBX type services for a
SME company behind a NAT firewall, (think 100 SIP phones all registering
at the same time from the same IP address) but in-general they'll have a
fixed IP address so we can simply bypass them earlier in the chain so they
won't go through the slamming detection rules. (use the allowSites file)

Logging:

Logging via syslog can be a huge resource hog and you can find your server
crippled by excessive syslogging if you're not careful! Solutions? Well,
don't log for one. Another is to make sure your syslog is written in
buffered mode and not line at a time mode. See the man page for your
syslog system, but in traditional syslog systems, it's usually done by
placing a hyphen in-front of the log-file name. E.g.

    kern.*                          -/var/log/kern.log

There are many other ways to syslog though - some to databases, remote
servers etc. but if you know how to do that, you probably know how to do
this...


Another pit-fall I've discovered is phones with many BLF lamps and
subscriptions, but that can be bypassed - I think SUBSCRIBE requests are
mostly harmless...

And then there's other protocols - e.g. IAX - I'll have a look at the
data format for IAX and see if I can do the same for that too - although I
haven't heard of any slamming type attacks on IAX - yet...

The file is at http://unicorn.drogon.net/firewall2

Please don't just run it without having a look through it though - you
might find yourself locked out of your own system! The FTP port ranges are
set to match those I use in proftpd, so you might have to change those if
using FTP and/or other FTP servers...

The timing stuff can be expanded to other services too - you just need to
know what the packet formats are like so you can apply the DPIs to them -
however, do make use of facilities offered by the services before jumping
in with your own - e.g. ssh has a crude version of this built in (see
MaxStartups in the config file) and other processes generally make it hard
to perform these types of attacks anyway by deliberately taking their time
over authentication for example.

One more thing to watch out for is broken phones - I've seen Snom phones
fire registers at an Asterisk server at the rate of 2 a second when the
phone had the wrong password set...


Feedback welcome!

Enjoy!

Gordon