| |
|
Home
|
| Red Hat Linux 9: Red Hat Linux Security Guide |
|---|
| Prev | Chapter 4. Workstation Security | Next |
4.5. Available Network Services While user access to administrative controls is an important issue for
system administrators within an organization, keeping tabs on which
network services is of paramount importance to anyone who installs and
operates a Linux system.
Many services under Linux behave as network servers. If a network
service is running on a machine, then a server application called a
daemon is listening for connections on one or
more network ports. Each of these servers should be treated as potential
avenue of attack.
4.5.1. Risks To Services Network services can pose many risks for Linux systems. Below is a list of some
of the primary issues:
Buffer Overflow Attacks — Services
which connect to ports numbered 0 through 1023 must run as an
administrative user. If the application has an exploitable buffer
overflow, an attacker could gain access to the system as the user
running the daemon. Because exploitable buffer overflows exist,
crackers will use automated tools to identify systems with
vulnerabilities, and once they have gained access, they will use
automated rootkits to maintain their access to the system. Denial of Service Attacks (DoS) — By
flooding a service with requests, a denial of service attack can
bring a system to a screeching halt as it tries to log and answer
each request.
Script Vulnerability Attacks — If a
server is using scripts to execute server-side actions, as Web
servers commonly do, a cracker can mount an attack improperly
written scripts. These script vulnerability attacks could lead to
a buffer overflow condition or allow the attacker to alter files
on the system.
To limit exposure to attacks over the network all services that are
unused should be turned off.
4.5.2. Identifying and Configuring Services To enhance security, most network services installed with Red Hat Linux are
turned off by default. There are, however some notable exceptions:
cupsd — The default print server for Red Hat Linux.
lpd — An alternate print server.
portmap — A necessary component for
the NFS, NIS, and other RPC protocols.
xinetd — A super server that controls
connections to a host of subordinate servers, such as
wu-ftpd, telnet, and
sgi-fam (which is necessary for the Nautilus
file manager).
sendmail — The Sendmail mail
transport agent is enabled by default, but only listens for
connections from the localhost.
sshd — The OpenSSH server, which is a
secure replacement for Telnet.
When determining whether or not to leave these services running, it is
best to use common sense and err on the side of caution. For example,
if you do not own a printer, do not leave cupsd
running with the assumption that one day you might buy one. The same
is true for portmap. If you do not mount NFS
volumes or use NIS (the ypbind service), then
portmap should be disabled.
Red Hat Linux ships with three programs designed to switch services on or
off. They are the Services Configuration Tool
(redhat-config-services),
ntsysv, and chkconfig.
For information on using these tools, see the chapter titled
Controlling Access to Services in the
Red Hat Linux Customization Guide.
If you are not sure what purpose a service has, the
Services Configuration Tool has a description field,
illustrated in Figure 4-3,
that may be of some use.
But checking to see which network services are available to start at
boot time is not enough. Good system administrators should also check
which ports are open and listening. See Section 5.8 Verifying Which Ports Are Listening for more on this subject.
4.5.3. Insecure Services Potentially, any network service is insecure. This is why turning
unused services off is so important. Exploits for services are
revealed and patched routinely. So it is important to keep packages
associated with any network service updated. See Chapter 3 Security Updates for more information about this issue.
Some network protocols are inherently more insecure than others. These
include any services which do the following things:
Pass Usernames and Passwords Over a Network
Unencrypted — Many older protocols, such as
Telnet and FTP, do not encrypt the authentication session and
should be avoided whenever possible.
Pass Sensitive Data Over a Network
Unencrypted — Many protocols pass data over the
network unencrypted. These protocols include Telnet, FTP, HTTP ,
and SMTP.
Many network file systems, such as NFS and SMB, also
pass information over the network unencrypted. It is the user's
responsibility when using these protocols to limit what type of data
is transmitted.
Also, remote memory dump services, like
netdump, pass the contents of memory over the
network unencrypted. Memory dumps can contain passwords or, even
worse, database entries and other sensitive information.
Other services like finger and
rwhod reveal information about users of the
system.
Examples of inherently insecure services includes the following:
rlogin rsh telnet vsftpd wu-ftpd
All remote login and shell programs (rlogin,
rsh, and telnet) should be
avoided in favor of SSH.
(see Section 4.7 Security Enhanced Communication Tools for more information about
sshd).
FTP is not as inherently dangerous to the security of the system as
remote shells, but FTP servers must be carefully configured and
monitored to avoid problems. See Section 5.6 Securing FTP for
more information on securing FTP servers.
Services which should be carefully implemented and behind a
firewall include:
finger identd netdump netdump-server nfs portmap rwhod sendmail smb (Samba) yppasswdd ypserv ypxfrd
More information on securing network services is available in Chapter 5 Server Security.
The next section discusses tools available to set up a simple
firewall.
|
|
|
|
|
|
|
|
Disclaimer: For authoritative source or latest update to this
documentation, please refer to http://www.redhat.com/docs/manuals/linux/ |
|
 |
|
|
|
Quotes: The lapse of ages changes all things - time, language, the earth, the bounds of the sea, the stars of the sky, and every thing 'about, around, and underneath' man, except man himself.
|
|
|
|
|
|
|