Any workstation connected to a network needs to be hardened against attack. Following are some general principles that should be applied when hardening a system:
- Assume that default installations of any distribution will be inherently unsafe until hardened.
- Limit software, processes, and access to the minimum needed to perform the mission of the workstation.
- Use more secure alternatives to insecure services (such as using ssh instead of telnet).
- Keep current with security patches and upgrades for software packages.
- Use iptables to back up the hardening of the workstation.
Hardening an operating system usually consists of many small steps. Here are some that apply to UNIX workstations:
- Run high-visability services accessed from the network as chroot, if possible. Recall the earlier discussion on chroot. Good candidate services are Domain Name Server (DNS) and Web servers.
- Disable unneeded services.
- Remove unneeded software packages.
- Run iptables to filter traffic coming in from the network.
- Set nosuid, noexec, nodev in /etc/fstab on ext2 partions, such as /tmp, that are accessable by everyone. This reduces the risk of a Trojan horse attack.
- Use strong passwords. In a nutshell, a strong password is not based on common words and cannot be cracked with a brute force attack (in a reasonable amount of time).
- Enable password shadowing.
- Configure /etc/login.defs. Among other things, the following can be set:
- PASS_MAX_DAYS-Maximum number of days a password may be used.
- PASS_MIN_DAYS-Minimum number of days allowed between password changes.
- PASS_MIN_LEN-Minimum acceptable password length.
- PASS_WARN_AGE-Number of days warning given before a password expires.
- Add a wheel group to designate which users are allowed to su to root.
- Disable root logins and have administrators use su to get root access.
- Limit TTY and root access in /etc/security/access.conf.
- Set limits in /etc/security/limits.conf. Limits can be assigned to individual users or by groups. Items that can be limited include the following:
- core-Limits the core file size (KB)
- data-Maximum data size (KB)
- fsize-Maximum filesize (KB)
- memlock-Maximum locked-in-memory address space (KB)
- nofile-Maximum number of open files
- rss-Maximum resident set size (KB)
- stack-Maximum stack size (KB)
- cpu-Maximum CPU time (MIN)
- nproc-Maximum number of processes
- as-Address space limit
- maxlogins-Maximum number of logins for this user
- priority-The priority to run user process with
- locks-Maximum number of file locks the user can hold
- Disable root and anonymous FTP access in /etc/ftpusers.
- Protect log files by limiting access to root. Log files are an important means to detect and counter an attack. The early stages of an attack often deal with deleting and disabling logging. Consider setting up a loghost and have critical systems send their logs to a central log server for greater protection and monitoring.
- Consider burning operating system and services on a CD and boot from that CD. This is only practical for stable non-changing servers.
- Disable remote X by adding --nolisten tcp to the X command line (usually startx).
- Train system administrators and users on security issues and attack prevention.
TCP wrapper can be a powerful tool for the system administrator to minimize the risk of an attack. Here is how www.cert.org describes this tool.
Servers on UNIX systems usually either provide their services via the TCP/IP protocol stack to everyone or no one. In addition to this conceptual weakness, logging of connections is minimal and does not include, for example, source or timestamp. Connection attempts can be an early warning signal that a site is under attack so you want to capture as much information as possible.
Tcpd, the program implementing the tcp wrapper, was developed as a result of an actual attack. It provides (1) some level of access control based on the source and destination of the connection request and (2) logging for successful and unsuccessful connections. tcp wrapper starts a filter program before the requested server process is started, assuming the connection request is permitted by the access control lists. All messages about connections and connection attempts are logged via syslogd.
In this tutorial:
- UNIX and Linux Security
- Network and development tools
- UNIX/Linux as a poor target
- Open source issues
- Detecting hardware changes
- Disk partitioning
- Prepare for the eventual attack
- Controlling the Configuration
- Kernel configurations
- Kernel modules
- proc file system
- Operating UNIX Safely
- Uncommon services
- Processes controlling processes
- The chkconfig command
- Controlling users
- Encryption and certificates
- Hardening UNIX
- Packet filtering with iptables