Home | @unixist | unixist@freenode

>: Linux Security Best Practices


This post is intended as a whirlwind tour of linux security best practices. The idea is to understand basic linux security principles so you can go off and learn more about the specifics of those that apply to your environment. This post is a work in progress :)

Initial System Configuration

Users

Depending on the nature of the linux installation, you may require regular, unprivileged users to have access to the server. Regardless of the use case ensure the following are true:

Tools to nail down: OpenSSH, PAM

Services

Very simple: leave no services running that you are not using. This means apache, tinydns, sendmail/postfix/qmail (some applications write logs by sending e-mail, like cron jobs, so keep your MTA running if necessary).

Determine what you’re running by default

To see which services start upon system boot, use whichever of the following commands is appropriate for your system. If neither chkconfig nor sysv-rc-conf exist on your system, you can probably run the third command below.

$chkconfig --list | grep -e '3:on' -e '5:on'
$sysv-rc-conf --list | grep -e '3:on' -e '5:on'
$find /etc/init.d /etc/rc.d -executable -type f 2>/dev/null

Determine what’s listening on your network

Ensure that only processes which need to be accessible via the network are listening on an external interface. All other processes should function fine listening only on the loopback interface, 127.0.0.1. To see which processes are listening on your network interfaces (the -p option requires root privileges to display process names that aren’t owned by you):

$ netstat -uplant

Determine your system’s posture from the outside

From outside the host’s network, perform a scan with a network scanning tool such as nmap:

$ nmap -sS -sU -sV --version-all -p 1-65535 -P0 <host>

Don’t reveal more than you ought

Fortunately and unfortunately, the internet isn’t what it used to be so not all internet citizens are friendly. So why give people viewing your website or scanning your system more information than they need and that they can use against you? Disable your service banners.

For Apache, look for lines starting with “ServerTokens” and “ServerSignature” in the config file. The location of the file varies, so if you don’t know where it is, you can probably find it with this command:

$ find /etc -name httpd.conf -o -name apache.conf -o -name apache2.conf

Lines to change:

ServerTokens Prod
ServerSignature Off

You’ll have to dig around for similar information divulged by other services you run. I don’t believe it is possible to disable OpenSSH’s version banner as it is used by clients to determine compatibility and feature negotiation.

Tools to nail down: ps, netstat, lsof, nmap

Host-based security

Firewall

Firewalls can be complex, iptables takes time to learn, nuances abound. The rule of thumb, however, is straight-forward: practice the rule of least privilege. That applies to firewalls by setting your INPUT and OUTPUT (and FORWARD if applicable) chains to default DROP. The default disposition of your host’s firewall should be to drop all traffic that is not explicitly allowed.

Define what type of traffic should be generated and received for this machine or class of machines. Then with granularity only allow ingress/egress traffic for specific ports and protocols. For example, if your web server is the only host that should be connecting to your database, ensure your database server allows inbound connections on it’s db port only from the web server. The sources from which you allow inbound access to manage your system (probably ssh, TCP/22) should be limited as well if possible. If you find it difficult to know what IP you’ll be managing your systems from at any given time (anyone login from phones, cafes, home?), consider port knocking and/or fail2ban.

CentOS has a decent section of it’s iptables article describing a good minimal iptables ruleset to get you started.

Security measures like port knocking and fail2ban are may be inappropriate for some environments. You don’t want to accidentally block a valid user whose NATed with an idiot that’s brute forcing your sshd. fail2ban at least allows for a configurable “ban” period so the damage to valid users isn’t permanent or egregious. Your risk assessment and thread model should help dictate the extent to which your edge hosts (or any login host, I suppose) should be protected.

File integrity monitoring

Section under construction

Ongoing Security

Remote Logging

Log files are useful for many things: discovery of service errors; performance monitoring; and maybe most importantly, postmortem analysis of system compromise. Use a remote logging facility such as rsyslog or a remote mount like NFS or Samba to have logs (read: at least everything in /var/log) generated by the system and your services shipped off to a remote host. Whichever remote logging tool you choose, you’ll probably want to use encrypted transit with it. Remote logging makes the compromise of multiple hosts necessary for an attacker to manipulate or delete log files.

Enable the remote logging facility on the syslog server:

If you’re using rsyslog, edit /etc/rsyslog.conf:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

If you’re using regular syslog, edit its config file, which is usually /etc/syslog.conf. There may be other options present, but “-r” is the option that matters here. It tells syslogd to listen on a network interface.

SYSLOGD_OPTIONS="-r"

Enable remote logging on all of your hosts. Add a line like below in your /etc/syslog.conf or /etc/rsyslog.d/50-default.conf if you’re using syslog or rsyslog respectively.

*.* @syslog1.example.com
*.* @syslog2.example.com

I log *.* remotely because I’m paranoid. If your log throughput is too high or you’ve got meaningless or errant messages from your systems, consider limiting the logging to at least auth and authpriv:

auth,authpriv.* @syslog1.example.com
auth,authpriv.* @syslog2.example.com

That will reduce the logs to only those related to authentication and authorization related events. If you do this limited logging remotely, ensure that you are still logging the rest of the message levels–kern, daemon, debug–to a local file on each host (e.g. /var/log/auth, /var/log/syslog).

Optionally, syslogd or rsyslogd can handle remote logging over TCP and over TLS. rsyslog.com has a concise article on enabling encrypted log traffic.

If you’re old school, you can always print your logs on paper to ensure they aren’t tampered with :)

Know your SUID/SGID applications

SUID (Set User ID)/SGID (Set Group ID) applications are files with the filesystem’s SUID or SGID bits set. When either of these bits set, any user who executes this file does so within the context of the owner or group owner, respectively. For example:

$ls -l /bin/su
-rwsr-xr-x 1 root root 36832 2011-06-24 09:29 /bin/su

The “s” in the owner portion of /bin/su’s permission set denotes that this file is SUID. Any user executing it will do so with the owner’s privilege. In this case, any user can execute /bin/su in order to authenticate against some criteria, almost always /etc/shadow, a file to which they would ordinarily have no access.

Monitor the SUID files on your system regularly. etutorials.org has an article on SUID/SGID files and script you can throw in a cron job to be notified when a new SUID/SGID file is dropped onto your system.

Host Intrusion Detection System (HIDS)

There are many host-based IDS for linux. Each has its own tradeoffs with respect to difficulty of configuration, maintenance, feature set, location in the network, active development. Search around the net or check out popular systems like snort, samhain, and prelude.

I am most familiar with OSSEC and so will highlight some features it provides that are essential to any IDS deployment.

OSSEC book and kindle edition co-authored by the author of OSSEC itself.

Section under construction

Takeaways

  1. Minimize your host and network attack surface
  2. Know what processes you’re running
  3. Be familiar with the types of traffic that generally flows on your network
  4. Make use of your logs. You get them for free so you might as well take advantage of them.