Hardening the operating system involves many things are are not only operating system-specific, but may often vary from one “flavor” of an operating system to another.
Typical steps include:
- Disabling all default accounts and groups that are not needed. When an operating system is installed it sets up quite a few user accounts and groups by default. (Try logging into your Debian system using the username news and see how far you can navigate around your system’s file system and what files you can cat to the screen.) There’s a line in the /etc/passwd file for each user. Each line contains different pieces of info separated by colons (:) with the last item being the user’s default shell (typically the Bash shell). To disable user accounts, just change the default shell to /bin/false so they can’t log in.
- Change your startup configuration so that only necessary services are running. Many services open TCP/IP “ports” which hackers find when running port scans against systems. (Many applications are responsible for starting services also.) Closing all unnecessary ports is a common practice. You can run a port scanner from another system against your server to see which ports are open.
- Configure file system security (using the chmod and chown commands) so that only the bare minimum of access to files and directories is allowed.
- Utilize strong (mixed case, alpha-numberic, long) passwords on accounts that are necessary.
- Don’t use common names for groups that are given high levels access (ex: “admins”).
- Use TCP wrappers (tcpd) to run Internet-related daemons and properly configure the hosts.allow and hosts.deny files to restrict access.
- Don’t run a GUI if you don’t need one and never leave a GUI running while the server isn’t being used for an interactive console session.
- Log off of server consoles when they’re not being used. This is especially important for Internet-connected systems.
The installation routines for many Linux distributions set things wide open by default to reduce the number of technical support calls and e-mails they get. (The more wide open a system is the less likely it is that someone – or an application – will run into problems trying to perform a specific task or function.) As a result, most Linux systems are inherently insecure. Once you do make security-related changes, check to make sure that all functions of your applications still run the way they should.
Application Configuration
Some applications are insecure due to the defaults used during their installations and some are just inherently insecure. Telnet and ftp are two inherently insecure applications because passwords are transmitted over the wire as clear text.
The biggest threat to many applications is their vulnerability to “buffer overflow” attacks which usually results in the hacker having access to the system with the rights of whatever user account the application was running under.
The following are some general guidelines related to applications:
- Use more secure equivalents for insecure applications (ex: ssh instead of telnet, sudo in place of su, etc).
- Keep your applications up-to-date with the latest versions. Many releases are specifically developed to address security issues.
- Determine which ports an application opens up and see if they are absolutely necessary. If they aren’t, shut them down.
- Check the application vendor’s Web site for information on how to make the application more secure and for any news items and or patches that address newly-discovered security vulnerabilities.
- If you have a Web server, learn proper programming techniques to ensure that CGI scripts are secure and make sure the scripts you use utilize these techniques. Also acquaint yourself with the security issues related to Server Side Includes and any Web site interpreters you may be running (such as PHP or ASP).
- In the case of a Web server, if Web page updates are fairly infrequent, you could just edit the pages on the server using a text editor or use a floppy disk to “sneaker-net” the updated HTML files by mounting the floppy disk, copying the files into the DocumentRoot directory, and then unmounting the floppy. Either of these would eliminate the need to run an ftp server service and enabling an account for the person who maintains the pages.
- If you have an Apache Web server (or have a Web site that is hosted on a shared Apache Web server) and the US government’s Titan Rain investigation has you considering blocking visitors from China (which we are now doing), you can configure Apache to deny access to your site from Chinese IP addresses
- Searching Google for the name of the application along with the word ‘harden’ will usually yield some helpful configuration information. For instance, Googling ‘harden apache’ will list some Web pages which tell you what modules you can rem out (in the /etc/apache/modules.conf file) to make your Apache installation more secure.
If all you want to do is set up a simple Web server (running Apache) then there are quite a few “applications” (OS utilities actually) that run by default that are not needed. They open ports and since each open port is a possible entry point into your server by a hacker, you don’t want them open. I disable them by renaming their ‘S’ (startup) symlinks in the appropriate runlevel directory. Since Debian boots into runlevel 2 by default, we want to go into the runlevel 2 startup directory with the command:
cd /etc/rc2.d
There we’ll find the symlink S20ssh which opens the port for secure remote console sessions. If you’ll be physically at the console (keyboard and monitor), there is no need for remote access. To stop the SSH server service from needlessly opening a port we disable it by just renaming its symlink with the command:
mv S20ssh _S20ssh
You can do the same for S20exim4, S20lpd, and S21nfs-common. Now if you reboot your system and run the netstat -a command you’ll see fewer open ports. One port that does remain open though is ‘sunrpc’. That’s the RPC portmap service and it is notorious for being the target of exploits. If you run the netstat -ap command you’ll see that ‘/sbin/portmap’ is the application that has the sunrpc port (port 111) open. NFS and some other applications need the RPC service. Apache does not. So for our simple Web server we can disable portmap. However, this service is called from two places so we need to rename both symlinks with the commands:
mv /etc/rc2.d/S18portmap /etc/rc2.d/_S18portmap
mv /etc/rcS.d/S43portmap /etc/rcS.d/_S43portmap
Note that disabling RPC will cause the ‘nfs-common’ service to fail at boot-up but that’s OK. You shouldn’t be mounting any network drives on a Web server anyway.
Now if you again reboot your system and run the netstat -a command you’ll see only port 80 open (and possibly port 25 listening on 127.0.0.1 which is internal only).
Other daemons and services don’t open ports but they’re not needed either and they just use up memory. Two examples in the default installation that you can also rename are S89atd and, if your system isn’t connected directly to a cable or DSL modem that uses PPPoE, S14ppp.
Because applications interact with the operating system, start processes, and accept input they can affect operating system security. Likewise, operating system security can affect an application’s ability to function properly. Achieving maximum OS security while still retaining full application functionality is a balancing act.
This balancing act is evident when using “jails” or chroot jails. You can put any program or daemon in it’s own jail. A chroot jail is a way of configuring the operating system so that the directory the application is running from appears to be the root of the entire file system. As such, the only directories the application can “see” or has access to are the ones it needs to run. That way, if an application does have a security flaw, the hacker exploiting that flaw won’t have access to the entire file system.
For example, if you want to set up a DNS server be advised that BIND runs as root. As such, if a hacker exploited a security flaw in BIND they would have root access to the entire file system. By running BIND in a jail, the hacker would only have access to the BIND application directory.
The problem with jails is that they can be a pain to set up. ALL files that an application needs (library files, config files, etc.) or generates (data files, log files) have to reside within the jail. So if you were going to set up a jail for BIND in /var/lib/named you’d have to create /var/lib/named/etc (for config files) and /var/lib/named/var (for log files) directories under that directory. You also then need to create a user for the application and change ownership of the directories to that user. It may be a pain but it does isolate your file system considerably.