48.2. Server Security
When a system is used as a server on a public network, it becomes a target for attacks. Hardening the system and locking down services is therefore of paramount importance for the system administrator.
Before delving into specific issues, review the following general tips for enhancing server security:
- Keep all services current, 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.
48.2.1. 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 stand 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 server 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
xinetdto create redundancy within service access controls. Refer to Section 48.8, “Firewalls” for more information about implementing firewalls with iptables commands.
Refer to Section 18.2, “TCP Wrappers” for more information on configuring TCP Wrappers and
The following subsections assume a basic knowledge of each topic and focus on specific security options.
188.8.131.52. Enhancing Security With TCP Wrappers
TCP Wrappers are capable of much more than denying access to services. This section illustrates how they can be used to send connection banners, warn of attacks from particular hosts, and enhance logging functionality. Refer to the
hosts_optionsman page for information about the TCP Wrapper functionality and control language.
184.108.40.206.1. TCP Wrappers and Connection Banners
Displaying a suitable banner when users connect to a service is a good way to let potential attackers know that the system administrator is being vigilant. You can also control what information about the system is presented to users. To implement a TCP Wrappers banner for a service, use the
This example implements a banner for
vsftpd. To begin, create a banner file. It can be anywhere on the system, but it must have same name as the daemon. For this example, the file is called
/etc/banners/vsftpdand contains the following line:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
%ctoken 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 displayed to incoming connections, add the following line to the
vsftpd : ALL : banners /etc/banners/
220.127.116.11.2. TCP Wrappers and Attack Warnings
If a particular host or network has been detected attacking the server, TCP Wrappers can be used to warn the administrator of subsequent attacks from that host or network using the
In this example, assume that a cracker from the 18.104.22.168/24 network has been detected attempting to attack the server. Place the following line in the
/etc/hosts.denyfile to deny any connection attempts from that network, and to log the attempts to a special file:
ALL : 22.214.171.124 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert
%dtoken supplies the name of the service that the attacker was trying to access.
To allow the connection and log it, place the
spawndirective in the
spawndirective 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.
126.96.36.199.3. 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 using the
For this example, assume that anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place an
emergflag in the log files instead of the default flag,
info, and deny the connection.
To do this, place the following line in
in.telnetd : ALL : severity emerg
This uses the default
authprivlogging facility, but elevates the priority from the default value of
emerg, which posts log messages directly to the console.
188.8.131.52. Enhancing Security With xinetd
This section focuses on using
xinetdto set a trap service and using it to control resource levels available to any given
xinetdservice. Setting resource limits for services can help thwart Denial of Service (DoS) attacks. Refer to the man pages for
xinetd.conffor a list of available options.
184.108.40.206.1. Setting a Trap
One important feature of
xinetdis its ability to add hosts to a global
no_accesslist. Hosts on this list are denied subsequent connections to services managed by
xinetdfor a specified period or until
xinetdis restarted. You can do this using the
SENSORattribute. This is an easy way to block hosts attempting to scan the ports on the server.
The first step in setting up a
SENSORis to choose a service you do not plan on using. For this example, Telnet is used.
Edit the file
/etc/xinetd.d/telnetand change the
flagsline to read:
flags = SENSOR
Add the following line:
deny_time = 30
This denies any further connection attempts to that port by that host for 30 minutes. Other acceptable values for the
deny_timeattribute are FOREVER, which keeps the ban in effect until
xinetdis restarted, and NEVER, which allows the connection and logs it.
Finally, the last line should read:
disable = no
This enables the trap itself.
SENSORis a good way to detect and stop connections from undesirable hosts, it has two drawbacks:
- It does not work against stealth scans.
- An attacker who knows that a
SENSORis running can mount a Denial of Service attack against particular hosts by forging their IP addresses and connecting to the forbidden port.
220.127.116.11.2. Controlling Server Resources
Another important feature of
xinetdis its ability to set resource limits for services under its control.
It does this using the following directives:
cps = <number_of_connections> <wait_period>— Limits the rate of incoming connections. This directive takes two arguments:
<number_of_connections>— The number of connections per second to handle. If the rate of incoming connections is higher than this, the service is temporarily disabled. The default value is fifty (50).
<wait_period>— The number of seconds to wait before re-enabling the service after it has been disabled. The default interval is ten (10) seconds.
instances = <number_of_connections>— Specifies the total number of connections allowed to a service. This directive accepts either an integer value or
per_source = <number_of_connections>— Specifies the number of connections allowed to a service by each host. This directive accepts either an integer value or
rlimit_as = <number[K|M]>— Specifies the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or
rlimit_cpu = <number_of_seconds>— Specifies the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or
Using these directives can help prevent any single
xinetdservice from overwhelming the system, resulting in a denial of service.