Confessions of a Guru

Ubuntu and Lightning – not working, application seems buggy?

I’ve switched over to running Ubuntu 8.10 full time at work now. The only things I miss are TortoiseSVN and the application integration with the desktop (Thunderbird/W32 for example lets you drag attachments onto the desktop). Oh, and I miss TimeSnapper (classic – free download) too, but will get off my chuff and work out an alternative using Xwd.

Anyway, at work we use the Lightning calendar plugin for Thunderbird, with the Google Calendar provider in order to collaborate on a calendar. For the most part this works well as when not in the office you can fall back to Google Calendar.

I went down the path of installing Lightning into Thunderbird (download the XPI, browse to it etc…) but after the installation Lightning seemed broken. The UI was mostly there but it looked buggy and nothing worked. After hunting around for a reason, I came across this thread that suggested that the problem was that the libstdc++5 package had to be installed.

I was skeptical, but after reading half a dozen “me too” posts where the problem had been fixed I got stuck in.

Uninstall the Lightning plugin from Thunderbird
Open a terminal, and run this command: sudo aptitude install libstdc++5
Reinstall Lightning from the XPI you downloaded

Then things came to life nicely. I was disappointed that the state of Lightning without libstdc++5 appeared to be a buggy application rather than a specific error.

lightning, linux, thundebird, ubuntu | GuruBob | January 23, 2009 11:09 pm | Comments (1)

Goodbye Telecom

Next week I’ll be porting my Telecom phone number to a VoIP provider (2talk) and then getting naked DSL provisioned on my line. This setup should leave me with full speed broadband, the benefits of a VoIP line (I’ll blog about that later) and all the features that 2talk provide for my voice line for only $85 per month.

Considering my broadband/phone bill currently sits at about $120 per month this will be a nice saving, plus an excuse to play with some technology I’ll be using Snap for the naked DSL, only because Orcon (my current provider) haven’t unbundled in Dunedin yet and it looks like it’ll be quite a while.

If you don’t mind a bit of downtime on your phone line or broadband service, the steps are:

Port your phone number to 2talk.
Get naked DSL provisioned on your home line.
Configure your system so that your phone rings at home by connecting to 2talk’s servers

You’ll need some hardware, and some charges (termination charges with your current broadband provider for example) may apply.

orcon, phone, voip | GuruBob | January 17, 2009 9:39 am | Comments (0)

More on fail2ban

A while ago I blogged about a SSH attack – this had been going on unnoticed for some time. Taking my typical fire-and-forget (gently forced by a busy family life) I simply installed fail2ban and did nothing else. Finally I was in a position where I had to research fail2ban a little more to figure out how to make it work.

What is fail2ban?

It’s a python script (that runs as a daemon) which monitors log files in your /var/log file. It monitors them for specific entries, for example “Failed password”, and then updates iptables rules to deny network access for the offending IP for a configured amount of time.

A good example of this is that if you try to ssh into my system three times unsuccessfully, you won’t be able to try again for 10 minutes. This is sufficient to make automated brute force attacks useless.

Do you need it?

If you have a public-facing server with the ability to log into it (including web applications even) then you need this. If you’re curious to see if you’ve been targeted for attacks, try running these commands as root on your server:

cat /var/log/auth.log | grep 'Failed password' | grep sshd | awk '{print $1,$2}' | sort | uniq -c
zcat /var/log/auth.log* | grep 'Failed password' | grep sshd | awk '{print $1,$2}' | sort | uniq -c

The first command examines your current auth.log file and the second examines your historical auth.log.[0-9] files. In my recent history (prior to configuring fail2ban properly) I had over 6,000 failed SSH login attempts on a single day just after Christmas.

What next?
The steps are:

bob@server:~$ sudo apt-get install iptables fail2ban
bob@server:~$ sudo /etc/init.d/fail2ban start

Now, you can check to see if it’s working by “pinging” the service:

bob@server:~$ sudo fail2ban-client ping
Server replied: pong

And you can get information on what’s currently been banned by examining the ssh “jail” – the jail is term used to describe the configuration and current black list for access from remote hosts:

bob@server:~$ sudo fail2ban-client status
Status
|- Number of jail:	1
`- Jail list:		ssh
bob@server:~$ sudo fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:	/var/log/auth.log
|  |- Currently failed:	0
|  `- Total failed:	52
`- action
   |- Currently banned:	0
   |  `- IP list:
   `- Total banned:	7

To test everything is working, simply try to log into your system incorrectly three times. When you’ve done this and you look at the results of “fail2ban-client status ssh” you will see your remote IP in the list. To unblock your IP, simply restart the fail2ban daemon (i.e. sudo /etc/init.d/fail2ban restart)

These pages were very useful when reading about fail2ban: