Month: September 2010

We’re Now Available Over IPv6!

You probably won’t have noticed but this site is now available over IPv6:

$ host www.barryodonovan.com
www.barryodonovan.com has address 87.232.16.35
www.barryodonovan.com has IPv6 address 2a01:268:3002::35

I spend a lot of my working hours doing a lot with IPv6 and, as any sys admin knows, it’s quite often the case that you get around to doing these things for yourself last. In our case, there was a bit of work involved as we had to first get our ISP’s core network dual stacked with IPv6 – luckily they’re a customer of ours 😉

Stay tuned here and over on the company blog for upcoming IPv6 posts and announcements.

In the meantime, if your ISP isn’t offering IPv6 to end users yet, head on over to SixXS where you can get an IPv6 tunnel for free. If you’re based in Ireland be sure to chose HEAnet or Airwire as your PoP as they’re both based in Ireland and members of INEX so your latency will be as low as possible.

UPDATE: Much more on this an why over on the company blog: We’re IPv6 Ready – Finally!

PostgreSQL 9.0 Released with Mission Critical Features

At work, we’ve always used and advocated MySQL for high availability mission critical applications thanks to it’s built in binary replication features.

This was a feature PostgreSQL sorely lacked but it is some thing that has also been rectified in the 9.0 release which, among many other features, includes:

  • Hot standby;
  • Streaming replication; and
  • In-place upgrades.

We’ll be studying and testing this new release carefully as, despite the previous lack of the above features, PostgreSQL had a lot of other features over MySQL and was also ahead of MySQL with such taken for granted features as views, triggers and stored procedures.

Asterisk SIP Brute Force Attacks on the Rise

See my article on the company blog for a discussion on this, and a how to on using Fail2ban to help stop these attacks.

SIP Brute Force Attacks on the Increase

On our own Asterisk PBX server for our office and on some customer boxes with open SIP ports, we have seen a dramatic rise in brute force SIP attacks.

They all follow a very common pattern – just over 41,000 login attempts on common extensions such as 200, 201, 202, etc. We were even asked to provide some consultancy about two weeks ago for a company using an Asterisk PBX who saw strange (irregular) calls to African countries.

They were one example of such a brute force attack succeeding because of a common mistake:

  1. an open SIP port with:
  2. common extensions with:
  3. a bad password.

(1) is often unavoidable. (2) can be mitigated by not using the predictable three of four digit extension as the username. (3) is inexcusable. We’ve even seen entries such as extension 201, username 201, password 201. The password should always be a random string mixing alphanumeric characters. A good recipe for generating these passwords is to use openssl as follows:

openssl rand -base64 12

Users should never be allowed to choose their own and dictionary words should not be chosen. The brute force attack tried >41k common passwords.

Preventing or Mitigating These Attacks

You can mitigate against these attacks by putting external SIP users into dedicated contexts which limit the kinds of calls they can make (internal only, local and national, etc); ask for a PIN for international calls; limit time and cost; etc.

However, the above might be a lot of work when simply blocking users after a number of failed attempts can be much easier and more effective. Fail2ban is a tool which can scan log files like /var/log/asterisk/full and firewall IP addresses that makes too many failed authentication attempts.

See VoIP-Info.org for generic instructions or below for a quick recipe to get it running on Debian Lenny.

Quick Install for Fail2ban with Asterisk SIP on Debian Lenny

  1. apt-get install fail2ban
  2. Create a file called /etc/fail2ban/filter.d/asterisk.conf with the following (thanks to this page):
  3. Put the following in /etc/fail2ban/jail.local:
  4. Edit /etc/asterisk/logger.conf such that the date format under [general]reads: 
    dateformat=%F %T
  5. Also in /etc/asterisk/logger.conf, ensure full logging is enable with a line such as the following under [logfiles]: 
    full => notice,warning,error,debug,verbose
  6. Resart / reload Asterisk
  7. Start Fail2ban: /etc/init.d/fail2ban startand check:
    • Fail2ban’s log at /etc/log/fail2ban.logfor: 
      INFO   Jail 'asterisk-iptables' started
    • The output of iptables --list -vfor something like: 
      Chain fail2ban-ASTERISK (1 references)
 pkts bytes target     prot opt in     out     source               destination
  227 28683 RETURN     all  --  any    any     anywhere             anywhere

You should now receive emails (assuming you replaced the example addresses above with your own and your MTA is correctly configured) when Fail2ban starts or stops and when a host is blocked.

Go That Way, Really Fast

In the vein of Release Early, Release Often, Jeff Atwood, CTO of StackOverflow.com, has posted an interesting article on the topic and on the huge amount of work they have gotten done in five months and their fears that they’re still not moving fast enough.

We’re going to go that way, really fast. And if something gets in our way, we’ll turn.


Link: MySQL Best Practices

I came across this site today which has some good advice for MySQL. I’m particularly happy to see that Doctrine, a relatively new ORM for PHP which we’re big fans of, is gaining some traction.

I came across this site today which has some good advice for MySQL. I’m particularly happy to see that Doctrine, a relatively new ORM for PHP which we’re big fans of, is gaining some traction.

I also noticed that Piwik, an open source analytics package, are using some interesting quality assurance tools which may be of interest to PHP developers (along with a continuous integration tool I came across recently: phpUnderControl).