>Server security is as important as network security because servers
often hold a great deal of an organization’s vital information. If a
server is compromised, all of its contents may become available for the
cracker to steal or manipulate at will. The following sections detail
some of the main issues.
>
CLASS=”SECT2″
>
NAME=”S2-RISK-SERV-PORTS”
>2.3.1. Unused Services and Open Ports
> A full installation of Red Hat Enterprise Linux contains up to 1200 application and
library packages. However, most server administrators do not opt to
install every single package in the distribution, preferring instead
to install a base installation of packages, including several server
applications.
> A common occurrence among system administrators is to install the
operating system without paying attention to what programs are
actually being installed. This can be problematic because unneeded
services may be installed, configured with the default settings, and
possibly turned on. This can cause unwanted services, such as Telnet,
DHCP, or DNS, to run on a server or workstation without the
administrator realizing it, which in turn can cause unwanted traffic
to the server, or even, a potential pathway into the system for
crackers. Refer To
HREF=”http://wiredgorilla.com/main/article-topic-7.html”
>Linux Server Security for information on
closing ports , installing Firewalls and disabling unused services.
>
CLASS=”SECT2″
>
NAME=”S2-RISK-SERV-PATCH”
>2.3.2. Unpatched Services
> Most server applications that are included in a default installation
are solid, thoroughly tested pieces of software. Having been in use in
production environments for many years, their code has been thoroughly
refined and many of the bugs have been found and fixed.
> However, there is no such thing as perfect software and there is
always room for further refinement. Moreover, newer software is often
not as rigorously tested as one might expect, because of its recent
arrival to production environments or because it may not be as popular
as other server software.
> Developers and system administrators often find exploitable bugs in
server applications and publish the information on bug tracking and
security-related websites such as the Bugtraq mailing list (
HREF=”http://www.securityfocus.com”
TARGET=”_top”
>http://www.securityfocus.com)
or the Computer Emergency Response Team (CERT) website (
HREF=”http://www.cert.org”
TARGET=”_top”
>http://www.cert.org). Although these
mechanisms are an effective way of alerting the community to security
vulnerabilities, it is up to system administrators to patch their
systems promptly. This is particularly true because crackers have
access to these same vulnerability tracking services and will use the
information to crack unpatched systems whenever they can. Good system
administration requires vigilance, constant bug tracking, and proper
system maintenance to ensure a more secure computing environment.
>
CLASS=”SECT2″
>
NAME=”S2-RISK-SERV-LAZYADMIN”
>2.3.3. Inattentive Administration
> Administrators who fail to patch their systems are one of the greatest
threats to server security. According to the
CLASS=”FIRSTTERM”
>System
Administration Network and Security Institute
(
CLASS=”FIRSTTERM”
>SANS), the primary cause of computer security
vulnerability is to “assign untrained people to maintain security and
provide neither the training nor the time to make it possible to do
the job.” This applies as much to inexperienced administrators as it
does to overconfident or amotivated administrators.
> Some administrators fail to patch their servers and workstations,
while others fail to watch log messages from the system kernel or
network traffic. Another common error is to leave unchanged default
passwords or keys to services. For example, some databases have
default administration passwords because the database developers
assume that the system administrator changes these passwords
immediately after installation. If a database administrator fails to
change this password, even an inexperienced cracker can use a
widely-known default password to gain administrative privileges to the
database. These are only a few examples of how inattentive
administration can lead to compromised servers.
>
CLASS=”SECT2″
>
NAME=”S2-RISK-SERV-INSECURE”
>2.3.4. Inherently Insecure Services
>Even the most vigilant organization can fall victim to
vulnerabilities if the network services they choose are inherently
insecure. For instance, there are many services developed under the
assumption that they are used over trusted networks; however, this
assumption fails as soon as the service becomes available over the
Internet ? which is itself inherently untrusted.
>One category of insecure network services are those that require
unencrypted usernames and passwords for authentication. Telnet and FTP
are two such services. If packet sniffing software is monitoring
traffic between the remote user and such a service usernames and
passwords can be easily intercepted.
> Inherently, such services can also more easily fall prey to what the
security industry terms the
CLASS=”FIRSTTERM”
>man-in-the-middle
attack. In this type of attack, a cracker redirects network traffic by
tricking a cracked name server on the network to point to his machine
instead of the intended server. Once someone opens a remote session to
the server, the attacker’s machine acts as an invisible conduit,
sitting quietly between the remote service and the unsuspecting user
capturing information. In this way a cracker can gather administrative
passwords and raw data without the server or the user realizing it.
> Another category of insecure services include network file systems and
information services such as NFS or NIS, which are developed
explicitly for LAN usage but are, unfortunately, extended to include
WANs (for remote users). NFS does not, by default, have any
authentication or security mechanisms configured to prevent a cracker
from mounting the NFS share and accessing anything contained
therein. NIS, as well, has vital information that must be known by
every computer on a network, including passwords and file permissions,
within a plain text ACSII or DBM (ASCII-derived) database. A cracker
who gains access to this database can then access every user account
on a network, including the administrator’s account.
