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.
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.
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 service that
provides additional access, logging, binding, redirection, and resource
utilization control.
Tip
It is a good idea to use IPTables firewall rules in
conjunction with TCP wrappers and xinetd to create
redundancy within service access controls. Refer to Chapter 7 Firewalls for more information about implementing firewalls
with IPTables commands.
More information on configuring TCP wrappers and
xinetd can be found in the chapter titled
TCP Wrappers and xinetd in the
Red Hat Enterprise Linux Reference Guide.
The following subsections assume a basic knowledge of each topic and
focus on specific security options.
TCP wrappers are capable of much more than denying access to
services. This section illustrates how it can be used to send
connection banners, warn of attacks from particular hosts, and enhance
logging functionality. For a thorough list of TCP wrapper
functionality and control language, refer to the
hosts_options man page.
Sending a client an intimidating banner when they connect to a
service 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. The Red Hat Enterprise Linux Reference Guide has a list of other
tokens available for TCP wrappers.
For this banner to be presented to incoming connections, add the
following line to the /etc/hosts.allow file:
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:
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.
Note
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.
If certain types of connections are of more concern than others,
the log level can be elevated for that service via the
severity option.
For 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 elevates the priority from the default value of
info to emerg, which posts log
messages directly to the console.
The xinetd super server is another useful tool for
controlling access to its subordinate services. This section focuses
on how xinetd can be used to set a trap service and
control the amount of resources any given xinetd
service can use to thwart denial of service attacks. For a more
thorough list of the options available, refer to the man pages for
xinetd and xinetd.conf.
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
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 that 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.
Another important feature of xinetd is its
ability to control the amount of resources which 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.
