Basic Server Security

August 06, 2010

I stumbled across a presentation on HN today which detailed a vulnerability on several sites which allowed the contents of memcaches to be viewed.

It's a pretty interesting scenario. Sites use caches to speed up all kinds of things from profile information, tweets, and evidently even login credentials. These caches are often based on memcached because it works all in memory and never blocks for I/O.

Memcached has a very simple interface. It is simple ASCII over a TCP/IP connection. There is no authentication required to access or modify the cache. This means that if the cache is is open to outside network traffic, all data that gets cached is publicly accessible. There isn't generally a reason for the cache to be publicly available, but it is important to run some basic security checks when configuring a server so that problems like this one don't occur.

When I get done configuring a server or adding new packages, I like to check a few things.

Open Ports

In general, I want as few processes listening for connections to the outside world as possible. All software has bugs, and the more software that you have accessible to the outside world, the more likely it is that your server can be compromised by exploiting one of these bugs.

Port scanning

As I set things up, I try not to open more ports or even run more processes than I need, but it's important to make sure that I didn't miss anything. The way I like to do this is by port scanning my box.

Port scanning involves attempting to connect to my server on each port via some remote machine. If the connection is established, then the port is open to the outside world. If not, it either means that your server isn't listening on that port or a firewall is blocking it somewhere along the way. I suppose this could be done one port at a time using netcat or telnet, but nmap automates this task.

:~# nmap joncraton.org

Starting Nmap 4.62 ( http://nmap.org ) at 2010-08-06 23:41 UTC
Not shown: 1713 closed ports
Interesting ports on joncraton.org (127.0.0.1):
PORT      STATE SERVICE

80/tcp    open  http
443/tcp   open  https

Nmap done: 1 IP address (1 host up) scanned in 0.152 seconds

You can also get similar information by running netstat from the host machine:

:~# netstat -lnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9001          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9002          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN

This show that there are several processes listening on the loopback interfaces. These are my Django instances and memcached. It also shows that ports 80 and 443 are open to the public as they should be. So, the external ports look good.

SSH

For a single server, you can't easily get away from having SSH open on a port. In order to prevent random bots from continuously attempting to login to my server, I like to run SSH on a different port. This is easy to do in the SSH configuration. It is also highly recommended to disable root login from SSH and perhaps even disable password based logins altogether and instead use SSH keys for authentication.

Web Servers

Web servers generally have default configurations that are fairly secure, but it is always good to read up on what you can do to tighten things up a bit.

Conclusion

Poor operation procedures can lead to very large problems. Running through some basic checks when setting up a server can protect data and save a lot headache later on.

Check out my other pages tagged "blog".