Author: Mike Peters
SSH
If you are accessing machines remotely across a network, you should not be using Telnet. Telnet transmits information, including passwords, in plain text, which can easily be intercepted and read. SSH performs much the same task as Telnet, but it does so through an encrypted tunnel and is therefore much more secure.
There are a number of configuration options you should consider when using SSH. These are set in the /etc/ssh/sshd_config and /etc/ssh/ssh_config files.
First, set the LoginGraceTime, the time users have to enter their login information, to a low but sensible value — 30 seconds maybe.
Make sure root is not allowed to login by setting PermitRootLogin to no. If you need root privileges you should log in as a normal user and su to root.
Set StrictMode to yes to ensure that users cannot access home directories owned by other users.
You can restrict the users who are allowed to login using SSH by setting the AllowUsers directive. Multiple users can be listed by separating them with a space:
AllowUsers user1 user2
If you need to restrict access to certain machines you can use the AllowHosts directive:
AllowHosts 192.168.1.2
SSH also provides Secure Copy (SCP) and Secure File Transfer Protocol (SFTP), which are secure ways to transfer files between two machines over an SSH tunnel. To copy a file called my file to /home/foo on 192.168.1.2, you would use the command # scp myfile 192.168.1.2:/home/foo. Whenever possible you should use SCP or SFTP in place of FTP to transfer files between hosts.
Limiting resource usage with PAM
PAM, the Pluggable Authentication Mechanism, allows you to configure how applications authenticate users. You can set limits to a user’s system usage by editing the files under /etc/security.
A good place to start is with the /etc/security/limits.conf file. This file allows you to restrict resource usage by users or groups of users. For example, you can control CPU usage by time, or restrict maximum file or data size or the number of times a user can concurrently login. Each line takes the form:
<domain> <type> <item> <value>
To prevent users hogging system resources you should limit the number of processes they are allowed:
* soft nproc 100 * hard nproc 150
You may also want to restrict the number of concurrent logins and the maximum file size users are allowed:
* hard maxlogins 4 @users hard fsize 50000
The asterisk above indicates all users, while @users affects only users belonging to the users group. The available options for <item> are listed in the limits.conf file. You can specify limits be hard or soft by using the hard and soft keywords in the <type> column. If you set a hard limit it cannot be exceeded; processes will be killed so that the system stays within the limit. Soft limits result in users being warned when the limits are exceeded, but no processes are killed.
There are certain accounts that should never be allowed to login, and these can be
configured in the /etc/security/access.conf file by adding a line like:
-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL
The dash at the beginning of the line removes privileges from the listed accounts. The
keyword ALL indicates which privileges to remove. You should add any special accounts that do not require login privileges to this list.
You can put many other restrictions in place using PAM, such as chroot environments and time-based logins, but these are beyond the scope of this article.
Finally, you can restrict which users can su to root by adding to /etc/pam.d/su the lines:
auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/Pam_wheel.so group=wheel
These settings require that a user be a member of the wheel group in order to su to root.
Set up a firewall
Every machine connected to the Internet needs to be protected by a firewall. While I won’t go into the details of setting up a firewall in this article (but see below for a link to many firewall resources), I’ll mention a couple of things you need to bear in mind when configuring your firewall.
First, make sure you set the default policy of the firewall to drop any packets (this should be standard in any firewall script you download anyway). Refuse any access to your external interface initiated from 127.0.0.1 or your internal network; a common way used to fool firewalls is to spoof an internal network address to gain access by pretending to be a local machine. Finally, never allow access to services from external addresses unless you are certain you know what you are doing.
Once you have your firewall up and running you should run a scan with a utility such as Nmap to make sure that you really have closed off access to all the services:
nmap -sT -PT your.external.ip.address
Run the scan from both within your network and from a remote machine not directly connected to your network and compare the results. If you don’t have access to a remote machine running Nmap, there are many online scanners such as Shields Up that allow you to check your firewall.
Commonly run services
It is beyond the scope of this article to explain in detail how to secure all of the services you may want to run on your network, but I’ll go over a few commonly run services and offer some points you should bear in mind. Generally speaking, if you are running a service on your network you should be as restrictive as possible in your policy. Deny everything by default and then give access to what you need, as opposed to allowing everything and blocking what you don’t want.
Apache
Apache is the most commonly run Web server on the Internet. You may want to run Apache on your home machine to test sites you develop or maybe you run a small intranet. You can restrict Apache to allow access only from certain hosts. For example, if you want to allow access only to local users, add the following line to httpd.conf:
Listen 127.0.0.1:80
The following can be used to restrict access to all but certain hosts:
<Directory /var/www/htdocs> # Deny all accesses by default Order deny,allow # Allow access to local machine Allow from 127.0.0.1 # Allow access to local network Allow from 192.168.1. # Allow access to a certain machine Allow from 192.168.3.6 # Set the default policy to deny Deny from all </Directory>
Using Apache’s access controls is no substitute for a firewall; they should be used alongside a firewall as an extra level of security. Securing Apache to run a publicly available site on the Internet is beyond the scope of this guide.
FTP
If possible, you should avoid the use of FTP entirely as, like Telnet, it transmits passwords in the clear. Use SCP and SFTP as secure alternatives.
NFS
NFS is a commonly used utility to share files on Linux and Unix networks. NFS is far from a secure protocol and should be used only with extreme caution. Only export the directories needed to the hosts that need them.
NFS implicitly trusts the client machine, meaning that if a user has root access to the client he can access any files exported to that machine, including those belonging to another user. This is true even with the root_squash option, which prevents the local root user having root privileges on remote filesystems. While root_squash is set by default, users merely need to su to another user to access their files. If you require a secure way to share files on your network you should look into NFS4 in newer kernels or a secure alternative such as OpenAFS.
Essential tools
There are many tool available to make securing your Linux box easier. In addition to the ones I’ve already mentioned, some other tools you should have in your arsenal include:
chkrootkit — Scans for many common rootkits on the local machine.
tcpdump — Dumps the headers of network traffic for analysis. Should be available by default on most distros.
ethereal — A powerful network analyzer.
Tripwire — Monitors the integrity of files on your system and tracks any changes.
Portsentry — Detects portscans.
Logcheck — Monitors log files and warns you of any suspicious activity.
Snort — A network intrusion detection system that can monitor your network in real-time for suspicious activity.
Iptables — Not strictly a tool, this page contains a whole host of links to ready made firewall scripts and HOWTOs.
Conclusions
Remember that security is an ongoing process. Check regularly exactly what services are running on your machine. Check your logs for suspicious activity — after all, it’s no good keeping logs if you don’t check them.
Computer security is not an exact science. New vulnerabilities are found all the time and every time you install new software, new possibilities for crackers open up. After securing your initial installation, be sure you make an ongoing effort to maintain security.
Always stay up-to-date with the latest vulnerabilities in the software you run. Patch your servers whenever updates are made available. Sign up to a vulnerability mailing list such as BugTraq. If your distro has a security or updates list, make sure you join it. Most importantly, make sure you know what software is running on your hosts, and only run the services that you really need. Don’t run anything until you know what it does and what the possible consequences are.
Mike Peters is a freelance consultant and programmer and long-time Linux user.
