Linux can be secured and hardened by applying security at various levels.
Workstation Security
Securing a Linux environment begins with the workstation. Whether locking down a personal machine or securing an enterprise system, sound security policy begins with the individual computer. After all, a computer network is only as secure as the weakest node.
When evaluating the security of a Red Hat Enterprise Linux workstation, consider the following:
- BIOS and Boot Loader Security — Can an unauthorized user physically access the machine and boot into single user or rescue mode without a password?
- Password Security — How secure are the user account passwords on the machine?
- Administrative Controls — Who has an account on the system and how much administrative control do they have?
- Available Network Services — What services are listening for requests from the network and should they be running at all?
- Personal Firewalls — What type of firewall, if any, is necessary?
- Security Enhanced Communication Tools — Which tools should be used to communicate between workstations and which should be avoided?
Server Security
When a system is used as a server on a public network, it becomes a target for attacks. For this reason, hardening the system and locking down services is of paramount importance for the system administrator. The following general tips for enhancing server security
- Keep all services up to date to protect against the latest threats.
- Use secure protocols whenever possible.
- Serve only one type of network service per machine whenever possible.
- Monitor all servers carefully for suspicious activity.
Securing Services With TCP Wrappers and xinetd – TCP wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, which stands guard between an incoming request and the requested service.
The benefits offered by TCP wrappers are enhanced when used in conjunction with xinetd, a super service that provides additional access, logging, binding, redirection, and resource utilization control.
It is a good idea to use IPTables firewall rules in conjunction with TCP wrappers and xinetd to create redundancy within service access controls.
Enhancing Security With TCP Wrappers – TCP wrappers are capable of much more than denying access to services. For a thorough list of TCP wrapper functionality and control language, refer to the hosts_options man page.
TCP Wrappers and Connection Banners – Sending clients connecting to a service an intimidating banner is a good way to disguise what system the server is running while letting a potential attacker know that system administrator is vigilant. To implement a TCP wrappers banner for a service, use the banner option.
This example implements a banner for vsftpd. To begin, create a banner file. It can be anywhere on the system, but it must bear same name as the daemon. For this example, the file is called /etc/banners/vsftpd.
The contents of the file look like this:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.
The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating. For this banner to be presented to incoming connections, add the following line to the /etc/hosts.allow file:
vsftpd : ALL : banners /etc/banners/
TCP Wrappers and Attack Warnings – If a particular host or network has been caught attacking the server, TCP wrappers can be used to warn the administrator of subsequent attacks from that host or network via the spawn directive.
In this example, assume that a cracker from the 206.182.68.0/24 network has been caught attempting to attack the server. By placing the following line in the /etc/hosts.deny file, the connection attempt is denied and logged into a special file:
ALL : 206.182.68.0 : spawn /bin/ ‘date’ %c %d >> /var/log/intruder_alert
The %d token supplies the name of the service that the attacker was trying to access. To allow the connection and log it, place the spawn directive in the /etc/hosts.allow file. Since the spawn directive executes any shell command, create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server.
TCP Wrappers and Enhanced Logging – If certain types of connections are of more concern than others, the log level can be elevated for that service via the severity option.
In this example, assume anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place a emerg flag in the log files instead of the default flag, info, and deny the connection. To do this, place the following line in /etc/hosts.deny:
in.telnetd : ALL : severity emerg
This uses the default authpriv logging facility, but elevate the priority from the default value of info to emerg, which posts log messages directly to the console.
Enhancing Security With xinetd – The xinetd super server is another useful tool for controlling access to its subordinate services. For a more thorough list of the options available, refer to the man pages for xinetd and xinetd.conf.
Setting a Trap – One important feature of xinetd is its ability to add hosts to a global no_access list. Hosts on this list are denied subsequent connections to services managed by xinetd for a specified length of time or until xinetd is restarted. This is accomplished using the SENSOR attribute. This technique is an easy way to block hosts attempting to port scan the server.
The first step in setting up a SENSOR is to choose a service you do not plan on using. For this example, Telnet is used. Edit the file /etc/xinetd.d/telnet and change the line flags line to read:
flags = SENSOR
Add the following line within the braces:
deny_time = 30
This denies the host that attempted to connect to the port for 30 minutes. Other acceptable values for the deny_time attribute are FOREVER, which keeps the ban in effect until xinetd is restarted, and NEVER, which allows the connection and logs it. Finally, the last line should read:
disable = no
While using SENSOR is a good way to detect and stop connections from nefarious hosts, it has two drawbacks:
- It does not work against stealth scans.
- An attacker who knows a SENSOR is running can mount a denial of service attack against particular hosts by forging their IP addresses and connecting to the forbidden port.
Controlling Server Resources – Another important feature of xinetd is its ability to control the amount of resources services under its control can utilize. It does this by way of the following directives
- cps = <number_of_connections> <wait_period> — Dictates the connections allowed to the service per second. This directive accepts only integer values.
- instances = <number_of_connections> — Dictates the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.
- per_source = <number_of_connections> — Dictates the connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.
- rlimit_as = <number[K|M]> — Dictates the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.
- rlimit_cpu = <number_of_seconds> — Dictates the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.
Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.
Netfilter and IPTables – The Linux kernel features a powerful networking subsystem called netfilter. The netfilter subsystem provides stateful or stateless packet filtering as well as NAT and IP masquerading services. Netfilter also has the ability to mangle IP header information for advanced routing and connection state management. Netfilter is controlled through the IPTables utility.
The power and flexibility of netfilter is implemented through the IPTables interface. This command-line tool is similar in syntax to its predecessor, IPChains; however, IPTables uses the netfilter subsystem to enhance network connection, inspection, and processing; whereas IPChains used intricate rule sets for filtering source and destination paths, as well as connection ports for both. IPTables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding all in one command-line interface.
