Top Five Linux Security Tools

First, there are no magic programs you can run that will make your network or server secure forever. Security is an ongoing process of improving, evaluating, and then improving again. Fortunately, many good tools are available for Linux that will help you in this process. In this article, I present five of my favorites, which will help you prevent, detect and respond to intrusions. Although it is often much easier to prevent problems whenever possible, at some stage you'll have a problem you'll need to detect and respond to. This means it's a good idea to familiarize yourself with these programs before you need them in a crisis situation.

To evaluate how vulnerable a machine is, you need to know how many services are exposed to attackers. One excellent tool for this is Fyodor's Network MAPper Nmap. Debian users can fetch it via apt-get install nmap. Make sure you run it to check what services are available from a server—even if you think you already know. Obviously, you won't be affected by SSH password guessing if the SSH port is closed.

One of the simplest uses of Nmap is host discovery on your local network; in this instance, we ask Nmap to send ICMP echo request packets (pings) to each host in the IP address range:

$ nmap -sP 10.0.0.1-254
Starting nmap 3.81 ( http://www.insecure.org/nmap/ )
       at 2006-11-01 14:46
NZDT
Host 10.0.0.25 appears to be up.
MAC Address: 00:0C:F1:AE:E6:08 (Intel)
Host 10.0.0.51 appears to be up.
MAC Address: 08:00:09:9A:1A:AA (Hewlett Packard)
Host 10.0.0.70 appears to be up.
MAC Address: 00:0F:EA:64:4E:1E (Giga-Byte Tech Co.)
...

More often though, Nmap is used to discover which services are running. Because of the way that TCP establishes a connection using a three-way handshake, we can detect open ports without actually connecting to them. This is known as a SYN or half-open scan and is the default mode when used as root. If executed as a normal user, Nmap attempts to do a full connect to test if each port is open. (Technical aside: in the half-open mode, we send the initial SYN packet and listen for a reply. An RST indicates the port is closed; an SYN+ACK means it is open. If no reply is received, Nmap marks the port as filtered. Some firewalls will drop unwanted packets, leading to a status of filtered, and others will send RSTs, which make the port appear as closed.) Typically, if a server is listening on ports you don't expect it to, you should investigate:

#nmap -sS 10.0.0.89
Starting nmap 3.81 ( http://www.insecure.org/nmap/ )
          at 2006-11-01 14:52
NZDT
Interesting ports on 10.0.0.89:
(The 1637 ports scanned but not shown
below are in state: closed)
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
42/tcp    open  nameserver
80/tcp    open  http
110/tcp   open  pop3
...

Fyodor also has added a number of service fingerprints, and you can ask Nmap to identify particular services running by using the -sV option:

# nmap -sV 10.0.0.89
Starting nmap 3.81 ( http://www.insecure.org/nmap/ )
        at 2006-11-01 14:47
NZDT
Interesting ports on 10.0.0.89:
(The 1637 ports scanned but not shown
below are in state: closed)
PORT      STATE SERVICE           VERSION
21/tcp    open  ftp?
22/tcp    open  ssh               OpenSSH 3.8.1p1
Debian-8.sarge.4 (protocol 2.0)
42/tcp    open  nameserver?
80/tcp    open  http              Apache httpd 1.3.33
((Debian GNU/Linux) mod_gzip/1.3.26.1a PHP/4.3.10-16)
110/tcp   open  pop3?
...

The other incredibly useful option is OS detection, which can be invoked with -O. If the machine has at least one port open and at least one closed, you can get a fairly accurate idea as to what the operating system is:

# nmap -O -sS 10.0.0.89
Starting nmap 3.81 ( http://www.insecure.org/nmap/ )
         at 2006-11-02 09:02
NZDT
Interesting ports on 10.0.0.89:
(The 1637 ports scanned but not shown
below are in state: closed)
PORT      STATE SERVICE
21/tcp    open  ftp
...
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.5.25 - 2.6.3 or
Gentoo 1.2 Linux 2.4.19 rc1-rc7), Linux 2.6.3 - 2.6.8
Uptime 30.906 days (since Mon Oct  2 11:18:59 2006)

So, please use Nmap to check that you don't have any machines or services on your network that have been “temporarily” installed and forgotten. You also should use it from outside your network perimeter to verify that your firewall configuration is as it should be.

While you are looking after your network, you need a secure way to administer your machines. This means not using Telnet or rcp, or any other protocols that transmit passwords and data without any protection. OpenSSH is most people's favourite replacement for Telnet/rcp, which encrypts all data as it travels and makes some effort to verify that no one is spoofing the identity of the remote end of the connection. Debian users can fetch it via apt-get install openssh-server.

First, I recommend switching to an alternate port, using passphrases only, not passwords, or auditing your passwords on a regular basis. Remember that SSH secures the transmission of data—this means if your access control is poor, an attacker can control your computer in a secure manner, which is probably not what you want. I've seen too many Linux machines compromised through “temporary” accounts, such as upload/upload. To change the port, edit /etc/ssh/sshd_config, alter the line #Port 22 to Port 12345, and restart the service.

In the following example, we show how to use passphrases instead of passwords. Let's call the computer you want to execute the scp/ssh command on the client and the remote computer to ssh to, or copy from, the server. What you're doing here is allowing your user account on the client computer to read and write to any of your files on the remote computer. Doing this as root makes the server just as insecure as the client—you have been warned.

You can omit the passphrase and not use ssh-agent (the ssh-add command), but it's better not to. Log in to the client and enter the commands:

client% ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key
 (/usr/local/sss/jriden/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
 MY PASSPHRASE
Enter same passphrase again: MY PASSPHRASE
Your identification has been saved in
 /usr/local/sss/jriden/.ssh/id_rsa.
Your public key has been saved in
 /usr/local/sss/jriden/.ssh/id_rsa.pub.
The key fingerprint is:
75:65:36:2b:ed:38:9f:4a:6d:c4:d8:ec:25:ed:ff:31
 jriden@its-dev2
client% ssh-add
Enter passphrase for /usr/local/sss/jriden/.ssh/id_rsa:
 MY PASSPHRASE
Identity added: /usr/local/sss/jriden/.ssh/id_rsa
(/usr/local/sss/jriden/.ssh/id_rsa)
client%

Now, get ~/.ssh/id_rsa.pub, and add the contents as one entry in ~/.ssh/authorized_keys or ~/.ssh/authorized_keys2 on the server. Make sure to remove extraneous newlines that may creep in during the copy and paste:

client% scp server:~/testfile .
The authenticity of host 'server (130.123.128.86)'
 can't be established.
RSA key fingerprint is
 97:7b:e0:12:c2:f8:8e:05:cc:2b:74:50:9b:00:28:0e.
Are you sure you want to continue connecting
 (yes/no)? yes
Warning: Permanently added 'server,130.123.128.86'
 (RSA) to the list
of known hosts.
testfile
|***************************************************|
81940       00:00

The prompt here is because the server is not a known host, and this is the way SSH attempts to combat host spoofing. The next time you do it, there should be no prompt.