Security audits are a necessity.
Unfortunately, due to the constantly changing array of exploits and threats coming at your Internet-facing server from all over the world, there's no best practices manual for a security audit. This is because no one knows exactly what level of openness is appropriate/optimal on a given application server.
But you gotta start somewhere. Because if you're just blithely running an un-hardened *nix server with stock configurations for service apps like Apache and ssh, you're pretty much giving away the store.
What follows is a short how-to dealing with how to get started, security-auditing-wise. It is by no means comprehensive and is only intended to provide a "leg up" for those who feel like they ought to be auditing their servers but aren't sure where to start. I'll be using Debian systems running the current stable release (i.e. Lenny) to demonstrate the techniques, but I'll try to keep things as OS agnostic as possible: most of the packaged software I describe below can be found in your generic, mainstream fedora repo.
The methodology will be to start from the outside and work inward. I recently saw a Linux Journal article that described doing things the opposite way (or at least that's the impression with which I was left), and that doesn't make much sense to me. From where I'm standing, it seems that if you're conducting a security audit, you ought to start out by looking at your server the same way everyone else does.
Accordingly, we'll begin from the outside and from as basic a perspective as possible: scanning ports and checking for known vulnerabilities and obvious mis-configurations. Once we've got a little perspective on how our server looks to the script kiddies and botnets of the world, we'll do some web-server specific scanning to attempt to detect vulnerable plugins, apache mis-configurations and application-level security holes. After that, we'll finish by checking for rootkits and doing some internal auditing.
OpenVAS: Port Probe and All-purpose scan
The first thing to do is to scan your ports.
The odds are good that if you've got a server out there on the Internet (in the DMZ of your intranet or in a hosting company's rack, for example) that it's got a bunch of open ports. You've probably got one or two listening for HTTP requests, one or two listening for SSH requests and so on. What you probably haven't got is a good idea of how those ports look to the world.
So the first part of any security audit is the portscan. In olden times, you'd use a combination of telnet and nmap for this: nmap would handle the port scanning and tell you which ports were listening/open and then you'd use your expert knowledge of various network protocols to use a telnet-like program to check out those ports and see what sort of access and information they were offering to the world.
There are, fortunately, labor-saving apps that will do the scanning and auditing for you. A few months back, you would have been using nessus, as it was the big name in F/OSS auditing. nessus, however, has gone commercial (proprietary and closed) and a new, open project (GPL) called OpenVAS has taken its place.
For anything other than security auditing, using commercial software is probably OK. At the very least it's not always counter-productive to use non-F/OSS for non-security-related tasks. In the case of security-related apps, however, it just doesn't make any sense to take a chance on using software that isn't available for public scrutiny.
At any rate, if you're familiar with the way that nessus works, you'll be happy to know that the big ideas and the general methodology/procedure behind using OpenVAS are essentially the same. If you're unfamilar with programs like nessus and OpenVAS, here's how they work, from an administrator/auditor's perspective:
- Set up a server
- Use a client to tell the server to probe the target site
- View the audit report on the client
At present, if you're using the stock stable/unstable Debian repositories, you haven't got access to the packaged version of the OpenVAS server. That being the case, we're going to go ahead and get a little bit heroic here and do this the Cowboy Way (i.e. from source).
- Dependencies and Source Files
Make sure that you've got the following packages (some of which the openvas developers list as dependencies, some of which you'll need to compile anything from source) before proceeding:
molluska:/opt/# aptitude install libgnutls-dev libpcap-dev libgpgme11 libgpgme11-dev libglib2.0 libglib2.0-dev build-essential bison
Now that that's handled, there are four "modules" that are required to run an OpenVAS server. The openvas developers say that you've got to install the modules in the following order:
- openvas-libraries
- openvas-libnasl
- openvas-server
- openvas-plugins
So that's what wer're going to do. I like to do this sort of thing in/opt, but it really doesn't matter where this happens.
Get the files:
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/572/openvas-libraries-2.0.2.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/561/openvas-libnasl-2.0.1.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/562/openvas-server-2.0.1.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/576/openvas-plugins-1.0.6.tar.gz
NB: these URL's are for the version that was current when this was written--no guarantees that they'll be there two hours from now.
- ./configure && make && make install
Now, we start the compilation process which, thanks to our having resolved the dependencies enumerated above, should go off without a hitch:
molluska:/opt/openvas# tar -zxvf openvas-libraries-2.0.2.tar.gz
[...]
molluska:/opt/openvas# cd openvas-libraries-2.0.2
molluska:/opt/openvas/openvas-libraries-2.0.2# ./configure
[...]
molluska:/opt/openvas/openvas-libraries-2.0.2# make
[...]
molluska:/opt/openvas/openvas-libraries-2.0.2# make install
Once you've successfully installed the openvas libraries, you'll be prompted to modify /etc/ld.so.conf by adding the line "/usr/local/lib" to it and running ldconfig to update your linker. Do that, and then repeat the steps described above (untar, configure, make, make install) in the other three folders to finish installing the OpenVAS modules.
- Add a User and Generate an SSL Cert
Once you've got everything installed, you'll need to create two things: an OpenVAS user and an SSL certificate. Fortunately, both of these tasks have been nearly fully automated and all you'll have do to get the job done is execute a couple of binaries (which should be on your path, now that you've installed everything according to the above instructions) and follow some on-screen prompts:
molluska:/opt/openvas# openvas-adduser
[...]
molluska:/opt/openvas# openvas-mkcert
[...]
And that's it. Make a note of the paths that the openvas-mkcert program gives you at the end of the certificate creation (as you might need to specify them at some later time; you won't need them again to follow these instructions).
- Fire it up
Once you've got all your modules installed, your certificate created and your user added, it's time to fire up the server/daemon. The smartest way to do this is to pseudo-daemonize it and tail its output while it loads plugins:molluska:/# nohup openvasd &
[1] 4508
molluska:/# nohup: ignoring input and appending output to `nohup.out'
molluska:/# tail -f nohup.out
Should get you something like this:tail -f nohup.out
Loading the plugins... 714 (out of 10558)
...and so on. Once the plugins are all the way loaded, fire off a quick ps to make sure that the server is running and maybe a quick netstat to make sure you know what port it's listening at, and that's it: you're done with the server side of things and ready to move on to the client and auditing part.
molluska:/opt/openvas# ps aux |grep openvas
root 26129 1.1 0.2 16296 76 ? S 06:29 1:46 openvasd: waiting for incoming connections
molluska:/opt/openvas# netstat -anp |grep openvas
tcp 0 0 0.0.0.0:9390 0.0.0.0:* LISTEN 26129/openvasd: wai
Installing the OpenVas client is much easier.
While there is a packaged version of the OpenVAS client app, we're going to install one from source (mostly so our version of the server matches with our version of the client; this is mostly me being OCD, however, and you can probably get away with using the packaged version). To install the client, we'll follow the same steps as above, but on a different machine:
gonzo:/opt/openvas-client# wget http://wald.intevation.org/frs/download.php/575/openvas-client-2.0.3.tar.gz
[...]
gonzo:/opt/openvas-client# tar -zxvf openvas-client-2.0.3.tar.gz
[...]
gonzo:/opt/openvas-client# cd openvas-client-2.0.3
gonzo:/opt/openvas-client/openvas-client-2.0.3# ./configure
[...]
gonzo:/opt/openvas-client/openvas-client-2.0.3# make
[...]
gonzo:/opt/openvas-client/openvas-client-2.0.3# make install
NB: you may, depending on your client system, have to resolve some GTK dependencies and other build/compiler dependencies like the ones listed above: libgtk2.0-dev should solve most of your gtk problems, if you're running Debian Lenny.
Once the GUI client is installed, start it up:
toconnell@gonzo:~$ sudo aptitude install openvas-client
[...]
toconnell@gonzo:/opt/openvas-client/openvas-client-2.0.3/bin$ ./OpenVAS-Client &
Connection Screen, OpenVAS GUI Client
Once the GUI client is up and running, click the connect icon at the top of the interface (looks like two gray tubes colliding) to open the window that allows you to specify your newly install server's location and settings. Fill in the blanks and connect:
Once your client is connected with your server, you're ready to fill in the blanks and start your first round of tests. This is fairly self-explanatory and, honestly, you wouldn't be reading this if you couldn't figure out simple GUI interfaces: specify your target (i.e. the server you're auditing), make sure that all the plugins are enabled and then click the life preserver to start the "Scan Assistant" and execute the scan. Follow the on-screen prompts: easy as apple pie.
The best thing to do, once your scan starts, is probably to go do something else and come back in a little bit: in my experience these scans can take anywhere from 15 to 45 minutes, depending on your server and your pipe: my server is an old Linksys NSLU2 and my pipe is a consumer-grade Speakeasy residential connection, so I'm used to waiting close to an hour for the scan to finish. Using corporate resources will result in less idle time.
OpenVAS scan results report
Once the scan is done, you're treated to a report view. This is what we've been after all long. In it, you'll see a full run-down of what ports on your server are open and what open ports are listening for what. Additionally, you'll be treated to helpful recommendations about how to close security holes. And while closing those holes is beyond the scope of this article, I will say that almost every recommendation I've gotten from an OpenVAS report has been sane, been sensible and lead to a harder server.
nikto: Web-server Specific Auditing
The second thing to do, in order to perform a robust audit of your system, is to hit it with nikto (http://www.cirt.net/nikto2).
nikto, unlike OpenVAS doesn't require a server/client hook-up: just install the client with apt and fire off some tests, writing the output from those tests to plaintext files:
molluska:/# aptitude install nikto
molluska:/# nikto -h newathens.org -p 80 -output nikto_na80 && nikto -h newathens.org -p 443 -output nikto_na443
You'll get helpful output that points you towards an obvious solution like this:
+ mod_ssl/2.2.9 appears to be outdated (current is at least 2.8.30) (may depend on server version)
And you'll also get put on notice if you've got paths/folders/files with names that automatic exploiters and scripts tend to look for:
+ OSVDB-3092: GET /login/ : This might be interesting...
...to script kiddies and Chinese botnets.
You'll also get put on notice if you've got too much of your software's installation defaults hanging out in the open:
+ OSVDB-3233: GET /icons/README : Apache default file found.
Server-side Checks
chkrootkit
There are a few utilities that allow you to perform quick server-side audits of your security situation. Some of them, like rkhunter will run daily (like logwatch or apticron) and tell you if they've identified any new chinks in your armor. The first one to install and run is chkrootkit.
molly:/# aptitude install chkrootkit
[...]
molly:/# chkrootkit
This is a great place to start your internal audit because it'll tell you if you've picked up any known bugs and whether anything weird, filesystem-wise, appears to be going on with your computer.
The best use for this app is to give you a very quick idea of what sort of shape you're in. If you've got a system littered with suspicious files, odd-looking binaries, etc., you know exactly where to start plugging holes.
rkhunter
While we're on the subject of checking for root kits, let's do rkhunter:
molly:/# aptitude install rkhunter
[...]
molly:/# rkhunter --update
molly:/# rkhunter --check
This gets you a quick check of all your important binaries (to make sure they look like they're supposed to look, i.e. that they haven't been replaced by scripted exploits or an intruder with something that opens a back door) and a quick scan for known exploits of the rootkit variety. You'll also be told whether you're running inetd/xinetd (which tends to open ports in a manner whose security can be less than "ironclad") and other fun facts about potential vulnerabilities.
The best thing to do with this report is think long and hard about what ports/resources/pathways you actually want to make available to the Internet and then start disabling services. Once you've spent some time with that, you're pretty well on your way to having an idea of exactly how hard your server is and how much work you've got to do to keep it safe.
If anyone has any ideas about other utilities or techniques for security auditing, please feel encouraged to share them in the comments.
