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

[Roderick A. Anderson]

On 07/02/2010 10:10 AM, Gordon Henderson wrote:
>
> 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.

Thanks Gordon.

This will be useful ... and not only for Asterisk/SIP/IAX.

I use a similar technique for handling the script kiddies hammering for 
a ssh connection.  Three failed tries in less than a minute gets them 
dropped.  My syslog went from several tens of thousands of connection 
attempts per day, per host to less than 10 (on a really bad day).

I wish the TARPIT module was available for CentOS.  :-)


\\||/
Rod
-- 
> ===
>
>
> 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
>