Linux security page

Introduction

    This is going to be a page about how to keep your Linux machine from being compromised.
    NOTE: this is an old page, so your mileage may vary.

Overview

    First, you should keep your computer up to date.  Most Linux distributions have a method to this, such as updaters.  With Slackware, which I use, there are patches on most mirrors, located in Slackware-10.1/patches/packages or as applicable.
    Second, you should uninstall all network services that you do not need.  If you don't run a web server, don't keep Apache installed.  If you don't run a mail server, uninstall sendmail, etc.
    However, some are not actual programs but are instead system services.  These can be hardened using inetd by commenting out unneeded services in /etc/inetd.conf and by using the /etc/hosts.allow and /etc/hosts.deny files.  A sample hosts.allow for someone not allowing any servers would be:

ALL: 127.
ALL: 192.168.1.

And an example of the /etc/hosts.deny would be:

ALL: ALL

This would mean only local machine (i.e. your computer) can use all services, and that all other hosts are denied.
    Third, if you must run servers, read the documentation and configure them in the recommended secure ways, i.e. if an option is suggested or recommended for more security, use those options.  Also, X11 / XFree86 tend to "listen" on port 6000, you can shut off that default behavior by editing the startx script and/or any scripts that call for the server to use the -nolisten tcp option.
    Fourth, use a firewall.  A firewall is not by any means the most effective method to keep people out, but it can be used to filter out bad traffic, and is highly recommended. You may look at a copy of the one I use here
    Fifth, use file permissions.  If you don't want normal users viewing the firewall script, the LILO configuration, etc, set the permissions so that they cannot.  This is usually something like "chmod o-rwx /etc/lilo.conf" etc.  If you don't want people running lsmod or ifconfig to gather system information on your computer, take that ability away with "chmod o-x /usr/sbin/iptables" etc.  This also applies if you offer logins or services.  If you don't want someone who has legitimate access using nmap and ping from your computer, set those to not allow users to run them (if they're not the file owner, they're "other", so you can chmod o-rwx the programs you don't want them running, etc).
    Sixth, monitor your logs.  They're mostly found in /var/log and shouldn't be readable by normal users.
    Seventh, you can run an intrusion detection system.  However, as my experience is with systems used at the home, I don't recommend running an intrusion detection system on a home system.
    Eighth, use encryption.  If you don't want someone to read something, encrypt it.  Encryption can be a very powerful tool.  The same goes for communications: if you don't want someone overhearing what you're saying, encrypt it.
    Ninth, security is about trust.  If you don't trust someone, don't give them a way to access your files or your computer.  It's as simple as that.

Secure Shell

    This is an encrypted remote shell server.  It is an excellent tool for sharing files and doing other various things.  However, there are some issues.
    First, protocol 1 is insecure.  You should configure (in /etc/ssh/sshd_config) the server to not use it. This is done by giving the option "Protocol 2" in /etc/ssh/sshd_config.
    Second, you may use a different port.  However, my personal opinion is that this is meaningless because port numbers are arbitrary.  However, with recent ssh worms and such, it might be a good idea. This is easily accomplished using the "Port 234" option, for example, if you want to use port 234.   Make sure (if you're using inetd) that you edit /etc/hosts.allow to allow use of the port.  The service format follows the name in /etc/services (the line "ssh: ALL" allows everyone access to ssh port, which is 22 in /etc/services).
    Third, try changing the login grace time to one minute, as opposed to two minutes.  It shouldn't take long for someone to enter their password.
    Fourth, try changing the maximum authentication tries to less than the default of six, such as three.
    Fifth, since I keep hearing that one should watch for .rhosts files in users' home directories, you could set ignore rhosts to "yes".
    Sixth, you might not want people to use empty passwords, so you can set permit empty passwords to "no".
    Seventh, you might not want people using X11 forwarding on your computer, so you can set X11 forwarding to "no".

Identd

    I'm one of those people that doesn't mind allowing certain sites or services that need the authentication service, such as certain IRC servers.  However, I don't want just anyone using it.  For this, there are two layers: 1) put very specific host-based rules in iptables for using port 113, 2) configure inetd to allow it based on the IP address of the host.
    However, here are some further tips.  As for the port, those services that want to use this ident feature use the default port, 113.  Not much to be done there.  You can shrink the "socket backlog limit" to the number of hosts that you are allowing to use this.  You can change the maximum number of concurrent requests to only one.  You can set the timeout since connection or last query to one second (since most hosts do queries faster than this).  You can change the maximum number of threads doing kernel lookups to one to keep it from possibly overloading your system.  You can change the maximum number of retry attempts for kernel lookups to zero (basically disabling retries).  Also, if you want no one to know what operating system you're using, change the result:opsys to "GUESS" or something unrelated.
    These items are basically a way to prevent overloading and/or causing a denial of service and using common sense.  I highly recommend that you use similar tactics with other services and such.  Always look at your options and try to make them seem fair or more "real world".

Locking down /bin/su

    I'm one of those people that prefers only the "wheel" user group to have the ability to change users, especially to root.  To do this, you must log in as root (making sure the user(s) that you want to have this ability are logged out), and then change the permissions on /bin/su:

chgrp wheel /bin/su
chmod 4710 /bin/su

    Then you should create /etc/suauth and set that up as well to prevent anyone but "wheel" group:

echo "root:ALL EXCEPT GROUP wheel:DENY" > /etc/suauth
chmod 0400 /etc/suauth

    This should make it so that only those belonging to the wheel group (other than obviously root itself) can use the su program.  This will also prevent, say, an upgrade or update to /bin/su from losing permissions that were set, from removing this restriction.  I would like to thank mancha and alienBOB from FreeNode IRC channel ##Slackware, for this tip.

Preventing Fork Bombs

    I wrote this after finally figuring out how to prevent fork bombs in Slackware.  Remember, I'm primarily a musician, I just happen to use Linux.  Anyways, add this line to /etc/profile:

ulimit -u 100

    This basically sets the maximum number of processes a user can run at one time to 100.  Since my normal amount (ps -U username -u username | wc -l) is about 50 or so, I'd think that I'm good to go now.
    I tested this myself, and while on my computer it tends to lag quite a bit while being fork bombed, the system can still be logged into locally by root and the fork bomb killed.  (By the way, don't think fork bombs are unique to Linux: any operating system can be fork bombed in almost any language by anyone with the determination to do so.  Windows can be fork bombed, and fork bombs can be inserted into Flash and Java.)

Preventing Ctrl+Alt+Backspace

    You've secured your Linux only to find that now anyone can bring your laptop out of suspend and by executing ctrl+alt+backspace log your user out of the graphical system (and in Slackware, if your machine starts up in level 3 init, use your login).  The solution is putting this in your /etc/X11/xorg.conf:

Section "Serverflags"
   Option "DontZap" "yes"
EndSection

    This should prevent anyone from logging you out of X.  Be warned, though, that this is global, meaning that you will lose the ability to execute ctrl+alt+backspace.

Preventing Firewire Hack

    I am being told that since Firewire has direct access to the RAM on a computer, it would be easy for an attacker who has the proper tool to insert a firewire device and copy the entire contents of a machine's RAM.  This means that even if you were to use encrypted disk with LUKS and LVM, an attacker could gain access to it using this tool.  I recommend that one blacklist (not load) the modules to firewire (assuming their machine has firewire ports and that they own no firewire devices).  While I no longer have a computer with Firewire, here's how to blacklist the modules (add this to /etc/modprobe.d/blacklist.conf):

# For the old Firewire modules:
blacklist ieee1394
blacklist ohci1394
# For the new Firewire modules:
blacklist firewire-core
blacklist firewire-net
blacklist firewire-ohci
blacklist firewire-sbp2

NEW: Locking Down X Server Access

    Recently, while reading a good book on UNIX security, I ran across instructions to lock down access to the local X server using xauth.  I set about trying to find out how to do this automatically using a ".conf" file, and as a result of my research, noticed in the xauth manual a reference to /etc/X0.hosts, which refers you to the Xserver manual.  It gave examples, one of which I found interesting.  To lock down X server authentication to only local users using xhost, put this line in /etc/X0.hosts:
LOCAL:

Conclusion

    This is most of the information I know about securing your box.  For information on other servers, be sure to search the internet and use the documentation provided.