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 > -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
