s HARDENING THE BASICS in Font

Make Data Matrix 2d barcode in Font s HARDENING THE BASICS

The order in which you start and stop services on your system is also important. This is mainly for controlling when your firewall and logging services start and stop. Ensure you start your firewall, (iptables, for example) and your syslog daemon before you bring up your network. This ensures your system will not be connected to any external systems or networks without the protection of your firewall or without any logging of your system occurring. Then during the shutdown of your system, ensure you stop your networking services before you stop your firewall and syslog services. On most systems init scripts are started and stopped according to the sequence number given to them; sequence 20 will start before 30, and so on. I briefly covered sequence numbers in the previous Working with Debian init Scripts and Working with Red Hat init Scripts sections. You should ensure the start sequence numbers for your firewall and your syslog daemons are lower than the sequence number for your system s networking service, in other words, the daemons start before your network. Your networking services are usually started by an init script called network on a Red Hat system and a script called networking on a Debian system. Then confirm that your system s networking service stops before your firewall and logging.

s I will talk further about booting and some additional security features related to securing file systems Tip

The next area I will cover is the security of your console, your terminals, and the login screens presented to your users when they log into the system. The console of your system is usually physically attached to your system. (It is usually from the console you will have installed your distribution.) In the Linux world, logging onto the console often allows you to perform activities, commands, or functions that you would not be able to do from other locations, such as via a secure shell (SSH) login. You need to understand what the capabilities of a user logged into the console are and how to secure them further. Additionally, your console also has a number of virtual terminals defined that you can access. I talked about defining these virtual terminals in the earlier The inittab File section. These also need to be secured, and I will cover in the Securing Virtual Terminals section a method of locking these virtual terminals from unauthorized use. Lastly, when users connect to your systems, they are presented with a login screen. The information presented on most default login screens can offer attackers information about your system you do not want to share. Additionally, these login screens are a good method of communicating warnings and notices to the user logging into your system.

s In addition to securing your console and terminals, do not neglect your physical security. Ensure your Tip systems are stored somewhere that makes access to the console difficult to all those bar authorized people. Ensure the access is logged of any authorized people who can enter the area in which the console and system are stored. Additionally, if you have a case lock or similar physical security devices on your system, then use it to secure access to the interior of your system.

I will first talk about where root can log on. In 3 I will talk about restricting root logons over SSH to your system. You can further limit where root can log on by restricting it to a specific set of terminals. To do this, edit the contents of the /etc/securetty file. The login program refers to this file to determine whether the root user can log into a particular device. Listing 1-12 shows a sample of a typical securetty file. Listing 1-12. A Sample securetty File tty1 #tty2 #tty3 #tty4 All devices you want to allow root to log in from should be listed in the file (without the /dev/ prefix). I recommend allowing root login only on one terminal and forcing all other logins to be a non-root user and if required use su to gain root privileges. In Listing 1-12 you can see that only device tty1 allows a root login. All other devices have been commented out of the file, disabling root login on those devices. You also need to secure the securetty file to ensure it is modifiable only by root. Enter the following: puppy# chown root:root /etc/securetty puppy# chmod 0600 /etc/securetty

s You can also achieve similar results using the PAM module, pam_access.so. See its configuration Tip