asterisk users - Jul 2010 - iptables/ blocking brute-force attacks, and so on...

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

Hi,

one question again from an asterisk newbie.
Where can i get the header files Asterisk 1.6.1.20 for Debian Lenny?
I need them to install chan_capi for my Diva E1 Server Card.

Thanks in advance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100702/80d41bc4/attachment.htm

On Fri, Jul 2, 2010 at 1:22 PM,  <unserossi at aol.com>
wrote:
> Where can i get the header files Asterisk 1.6.1.20 for Debian Lenny?
>
$ apt-get install asterisk-dev

-- 
Paul Belanger | dCAP
Polybeacon | Consultant
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
blog.polybeacon.com

-----Original Message-----
From: Paul Belanger <paul.belanger at polybeacon.com>
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Sent: Fri, Jul 2, 2010 7:35 pm
Subject: Re: [asterisk-users] Asterisk header files for Debian Lenny 1.6.1.20


On Fri, Jul 2, 2010 at 1:22 PM,  <unserossi at aol.com> wrote:
> Where can i get the header files Asterisk 1.6.1.20 for Debian Lenny?
>


$ apt-get install asterisk-dev



-- 

This are the header files for 1.4, not for 1.6.
--

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100702/7c7aa0b9/attachment.htm

On Fri, Jul 2, 2010 at 1:38 PM,  <unserossi at aol.com>
wrote:
> This are the header files for 1.4, not for 1.6.
>
Then how did you install asterisk 1.6?

-- 
Paul Belanger | dCAP
Polybeacon | Consultant
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
blog.polybeacon.com

On Fri, 2 Jul 2010, Gordon Henderson wrote:
> I'll call this activity "slamming".
At least in the US, slamming already has a specific telephony meaning.

    http://en.wikipedia.org/wiki/Telephone_slamming

-- 
Thanks in advance,
-------------------------------------------------------------------------
Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                              Fax: +1-760-731-3000

On Fri, 2 Jul 2010, Gordon Henderson wrote:
> The file is at http://unicorn.drogon.net/firewall2
Lots of cool stuff in here. It's going to take a bit to understand it
all :)

-- 
Thanks in advance,
-------------------------------------------------------------------------
Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                              Fax: +1-760-731-3000

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
>