Protecting a Ubuntu server from brute force attacks?

It’s running Ubuntu 9.04 which is obsolete and unsupported, but I’m stuck with it for now. It’s not my server and not my decision.

Recently I’ve noticed what are obviously automated brute force log in attempts on the server.

They come from various IP addresses. They’re mostly foreign and almost certainly proxies. They run for quite a while making attempts every few seconds and trying various user ids, mostly “root” but various random names, “jsmith” or “rich”, for example, or things like “postgres” or “webadmin”. They also try random ports.

This has been going on for several days at least. I’ve been manually adding the offending IP addresses to iptables in order to drop everything coming from them.

What I really want to do is automate it to block any IP address that fails x login attempts within y minutes and keep them blocked for a period like 30 minutes or an hour.

I’ve tried adding UFW but apt-get doesn’t work, presumably due to the out of date OS.

Supposedly it’s possible to do something like what I want using iptables. I can’t figure it out from the less than useful help page. I’ve tried some examples from the web but they all produce cryptic error messages presumably because they’re not for our version of iptables.

Any thoughts or suggestions would be greatly appreciated.

Isn’t 9.04 only two years old? Don’t Ubuntu servers get maintained by Canonical for five years? Apt-get ought to work. But I didn’t even know that Ubuntu Server came without ufw.

edit: Huh, apparently there isn’t even a server version of Jaunty. So your server is just using a desktop version of Ubuntu? OTher than that I can’t help with your problem, but Slackware tells you how many failed login attempts have been made as a user when that user logs in, so it’s keeping track of it somewhere, you just need to find out where.

It’s been awhile since I’ve administered any flavor of Linux and not at all on Ubuntu, but the way I remember was using PAM (which I think has been depreciated).

I found some answers on the LinuxQuestions.org website.

That may get you started in the right direction.

The server is with Rackspace and it was set up before I came along. I have no idea if Rackspace supplied it with Jaunty or if it was someone on our end. Wiki says that it’s no longer supported.

I wasn’t even aware that it was a desktop version. I’m supporting it remotely via Putty and WinSCP. It did seem odd that a lot of online docs described GUI interfaces.

You just need to use --hitcount with iptables. There should be examples all over the place, like here or here (also talks about some alternative programs)

What does the server do and why are they allowing the firewall to expose so many ports to attack? What services are you allowing external attackers to continually try to authenticate against? Can you only permit those services to be accessible via SSL tunnels? Can you require certificate authentication?

It’s a web server. I didn’t set it up and I’m not really a guru on this stuff. I don’t know what ports are exposed or why. How do I unexpose them (without compromising function)? I don’t know what services are allowing the attacks.

How do I implement SSL tunnels? I don’t know if I can require certificate authentication.

This is a good illustration of what I’m running into. Your first link suggests the following commands, which seem like they should work:

When I enter the first command I get the following response:

iptables -L gives the following (It includes the IPs I’ve added manually):


Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  61.185.242.98        anywhere
DROP       all  --  c91593dc.virtua.com.br  anywhere
DROP       all  --  178.18.17.188        anywhere
DROP       all  --  vb-052.interviewstudio.com  anywhere
DROP       all  --  web04.topspeed.com   anywhere
DROP       all  --  219.235.240.19       anywhere
DROP       all  --  218.0.4.186          anywhere
DROP       all  --  218.108.85.251       anywhere
DROP       all  --  210.37.41.163        anywhere
DROP       all  --  temp11.he.net        anywhere
DROP       all  --  217.149.255.166      anywhere
DROP       all  --  static.customer-201-116-17-163.uninet-ide.com.mx  anywhere  
DROP       all  --  c91593dc.virtua.com.br  anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

What name is it failing to match? There is an “INPUT” chain. What other name is it failing to match?

I’m the farthest thing from a linux expert, but this is what I used when my ubuntu server was getting lots of attempted authentications.

fail2ban

It doesn’t look like there’s a release for my OS.

I would still recommend installing fail2ban. It doesn’t require touching iptables (which can be frustrating for new users) and does its job well. You could try grabbing a deb from an Ubuntu repository, try installing it with dpkg and crossing your fingers. If that’s not your speed you could try to get a backport.

If you’re running a desktop version of the distribution it’s possible no one bothered building the package. It should be very simple, but Ubuntu has a strict release schedule that causes some packages to fall through the cracks.

Port 22 is the standard port for SSH. Assuming that’s where you’re seeing the login failures, there are two things you can do that might help without needing iptables:

  1. Change the SSH port number. This means you’ll have to specify the correct port when logging in. Just uncomment the Port line in your sshd_config and change it to a random number less than 65536.

  2. Disable password logins, and require a public key. Instructions for Ubuntu here.

(1) will reduce the noise in your logs. (2) will stop brute-force password attacks from succeeding.

In both cases be careful you don’t lock yourself out.

Locking myself (and my boss) out is, of course, my big concern.

If I change the port, is a reboot required?

No, just restarting sshd (which you need to do for both changes). I always make a point of rebooting once I’ve made changes like this though, to make sure everything sticks and avoid surprises at the next reboot.

Locking yourself out is a concern with iptables too, so take care however you do it.

Oh, you’re using putty on Windows? See here for instructions on generating your keys. You need to make sure you can log in this way before disabling password logins. That’s step 1 and 2 in the other Ubuntu guide.

I didn’t realize ssh was a concern. You should disable root login while you’re at it. And don’t forget that once the port is changed, you’ll need to supply the new port number when you try to log in.