|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Chapter 5. 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.
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:
vsftpd : ALL : banners /etc/banners/
|
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.
 |
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:
Add the following line within the braces:
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:
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.
|
|
|
