As a Linux Security Freelancer, I’m often asked where best to start when securing a single linux host. Whereas most would suggest configuring iptables or similar, the most effective first step in my opinion is to remove unnecessary services.
There are a number of methods that you can use to show open sockets at least:
lsof -U will list open sockets
nmap -sT -sU localhost will scan your local machine for open TCP or UDP ports
netstat -a | grep LISTEN will show all listening sockets.
Forgive me for stating the obvious, but the first thing to do is disable any open sockets or services that aren’t required. On a default install, this could include the likes of the portmapper service, identd and an smtpd.
Next, you want to suitably lock down user accounts, check passwords, and perhaps consider enforcing a secure password policy, at minimum I generally prefer at least 8 characters, at least one uppercase, one lowercase and one integer. Obviously this shouldn’t be easily guessible, nor should it just end in a ‘1’.
Once done, the next thing that you want to do is to suitably firewall the services that you do require open, and perhaps also restrict the rate of ICMPs, etc, with iptables.
Next you likely want to remove any unnecessary software. Debian and it’s default net install has been my preferred distro for over about 7 years now largely because it is so non-bloat, and the default installation rarely requires packages removing.
If you’re allowing local access to the machine, you might want to remove all ‘SUID’ tools. You can find these with: ls -alF `find / -perm -4000`
SUID is a shortened form of SetUID which is a shortened form of Set User ID, which I suppose is technically a shortened form of Set User IDentification :). What it means in practise, is that the binary has the ability to call the setuid() and/or setgid() functions to run under the UID/GID of it’s owner (often ‘root’) as opposed to the user calling it. In short, a regular user account does not and should not have permission to craft and send out custom ICMP packets to pick one example. In order to allow him to ‘ping’, the ping utility needs to be setuid root, and we will trust that the ping utility is sufficiently secure that it will not allow anything to be done with it that shouldn’t. We trust that over the years, ping, traceroute and other setuid tools have been sufficiently tested to be free from bugs, however it is in setuid utilities such as this that buffer overflows can be located, allowing a malicious local user to crash the program whilst it’s running (with ‘root’ priviledges) and hopefully drop the user to a rootshell. Although slightly offtopic, this should hopefully provide sufficient information regarding setuid binaries and their caveats.
There’s network and local security, how about physical security? If this is a concern, consider passworded BIOS (easily disabled), and also take adequate steps to prevent users with physical access from resetting your root password
For more information on security related issues, do check out my security consultant page.