Securing an Individual Server

Hell Really Exists

Hell Really Exists

Get Instant Access

CRITICAL SKILLS

9.1 Keep Your System up2date

9.2 Understand TCP/IP and Network Security

9.3 Use Tracking Services

9.4 Monitor Your System

9.5 Employ a Checklist

9.6 Find Helpful Resources Online

9.7 Be Aware of Security Miscellany

You don't have to look hard to find that someone has discovered yet another new and exciting way to break into your systems. Sites such as http://www.securityfocus.com and mailing lists such as BugTraq regularly announce such new exploits. And making the situation even more troublesome for system administrators is the proliferation of "script kiddies." These individuals do not themselves possess the technical knowledge to break into other sites; they use prebuilt scripts instead, motivated by the adolescent thrill of impressing friends and being a nuisance. The positive result of this behavior is that the Linux community has become very responsive to security issues that come up. In several cases, security patches have been made available within 24 hours of the announcement of a vulnerability.

In this module, you'll learn about basic techniques for securing your server. If you follow these tips, you'll be more likely to keep out the script kiddies. But be advised: No system is perfect. New holes are discovered daily, and new tools to launch attacks come out more often than we'd like to imagine. Securing your systems is much like fighting off disease—as long as you maintain basic hygiene, you're likely to be okay, but you'll never be invulnerable.

Nearly all system administration texts today have to cover these topics, explaining which of the neat, network-friendly features you have to turn off so that crackers can't abuse them. No matter what operating system you manage, if you have users, you may encounter misuse. In this module, I'll help you make it more difficult for the abusers to make headway on your systems.

CRITICAL SKILL

Keeping Your System up2date

It's swell that programmers are slaving away like busy worker bees to close security holes as they surface. That's also useless to you if you never update your system to reflect the changes they're making. Red Hat is kind enough to package up security fixes for the software it distributes, and it makes those packages available to you in a couple of ways.

Making use of these updates is an excellent way of ensuring that known exploits for the software you need to use can't be made into open doors for those who attack your systems. Whether you pay for support via the Red Hat Network and configure your systems to install the security fixes automatically, or you simply download security updates as they become available, installing these upgrades is mandatory for ensuring that your systems are as secure as they can be.

Using the Red Hat Network

The easiest way to manage Red Hat package updates, for security fixes or anything else, is to use the Red Hat Network (RHN). You can sign up for this service at http://rhn.redhat.com; there is an annual fee required to entitle more than one system to updates (boxed software releases come with varying periods of additional free RHN access). When you installed Red

Hat Linux 8.0, it automatically installed the Red Hat Network Registration Client, which you can start by going to the panel's main menu button and running the following command from a terminal window:

[[email protected] ~]$ up2date

Even if you're not interested in joining Red Hat Network yet, you can try it out. You can receive a free demonstration entitlement by creating an account and registering a system.

Upgrading Using up2date

The first time you execute the up2date command, you'll see a configuration screen to enable you to begin the process of registering your server with the Red Hat Network, as shown in the following illustration. If you run the command as a non-root user, you'll first have to enter the root password.

to a

Click the Forward button to continue with the configuration process. You'll get another graphical screen (see Figure 9-1) with some lengthy text describing Red Hat's privacy statement. Read it yourself, typos and all, but the bottom line is that you have some control over the information that Red Hat collects, but they'll collect your hardware and package inventory and your IP address.

If you click the Forward button again, you'll finally arrive at the registration screen (shown in Figure 9-2), at which you can enter existing Red Hat Network user or organization account information, or create a user account. You may have to try multiple usernames if your choices turn out to be popular. Click Forward to continue.

Step 1: Review the Red Hat Privacy Statement

Privacy Statement

When it comes to your privacy, our promise Is simple. Your personal information Is yours, not ours. In fact, we feel so strongly atout it that we encourage you to read our complete privacy policy below, so that you are comfortable with how any information you provide may be used.

We think our customers understand better than anyone else how Red Hat can most effectively serve their needs. Because of this, Red Hat makes every effort to allow our customers to define the relationship they will have with us. We ask our customers how they would like Red Hat to communicate with them, if at all. We disclose how we will be using our customers' information through documents like this one, or by answering individual questions customers may ask. Also, we never sell our customers' information or provide It to others without making it clear that we intend to do so at the time the information Is collected.

If you have any questions about any of these practices, please feel free to contact us at feedback®redhat.com.

Information Collected During Web Registration

Our website's registration system requires you to give us some contact information (like a user name and email address) and

Figure 9-1 Read and decipher Red Hat's privacy statement.

Figure 9-1 Read and decipher Red Hat's privacy statement.

Figure 9-2 Register a user name and password with the Red Hat Network.

On the next screen, you'll find a list of the hardware on your system, plus an editable field in which you can enter the name of the system, or give it an identification number, or both. You can uncheck the box to avoid sending your hardware configuration information to Red Hat if you so choose. Click Forward to move on.

Step 3: Register a System Profile - Hardware

A Profile Name is a descriptive name that you choose to identify this System Profile on Red Hat Network web pages. Optionally, include a computer serial or identification number.

Profile name:

tedford

Hardware information is important to determine what updated software and drivers are relevant to this system. The minimum set of information you can Include will contain your system's architecture and Red Hat Linux version.

0 Include information about hardware and network

Included information

Red Hat Linux version: 8.0 CPU model: Pentium III (Katmai) Hostname: tedford CPU speed: 500 MHz IP address: 10.0.2.52 Memory: 512 megabytes

Additional hardware information including PCI devices, disk sizes and mount points will be Included in the profile.

The following screen, shows a list of the packages found on the system. If you want this information sent to Red Hat, leave the boxes checked. You can unselect individual packages or the whole lot of them as you see fit. Click Forward when you're ready.

Step 3: Register a System Profile - Packages

RPM information is ¡important to determine what updated software packages are relevant to this system.

0 include RPM packages installed on this system in my System Profile Below is a list of packages present on your system that RPM knotvs about:

RPM information is ¡important to determine what updated software packages are relevant to this system.

0 include RPM packages installed on this system in my System Profile Below is a list of packages present on your system that RPM knotvs about:

Package Name

Version

Release

*

0

4Suite

0.11.1

10

0

GConf

1.0.9

0

GConf2

1.2.1

0

Glide?

2001052

0

LPRng

3.8.9

0

MAKEDEV

3.3.1

0

ORB it

0.5.13

0

ORB it:

2.4.1

0

Omni

0.7.0

0

Omni-foomatic

0.7.0

0

PyXML

0.7.1

H

When the next screen comes up (shown in the following illustration), you'll get one last chance to avoid sending the collected data to Red Hat. If you've changed your mind, click the Back button to change things or the Cancel button to exit up2date. Otherwise, click Forward.

Send Profile Information to Red Hat Network

We are finished collecting information for the System Profile.

Click "Forward" to send this System Profile to Red Hat Network. Click "Cancel" and no information will be sent. You can run the registration program later by typing rhn_register at the command line.

If you continued, and I hope you did, you will get a list of Red Hat update channels that apply to your system, shown next. The up2date command shows the list of update channels to which the system is subscribed. The Red Hat Linux 8.0 channel suited to your system will be listed and enabled. Click Forward to continue.

Channels

Channels

The next screen (in Figure 9-3) gives you a list of available update packages that have been flagged to be skipped. By default, this includes all kernel packages. If you want to install some or all of the packages listed here, click the appropriate boxes for the packages you want. Click Forward when you're ready.

According to your preferences you have chosen not to automatically update the above packages. If you would like to override your settings and include one of the above packages in the list of packages to retrieve, select its checkbox.

Figure 9-3 The up2date command lists update packages scheduled to be skipped.

The following screen shows the available package updates that apply to your system. As with previous screens, you can opt to include all the packages or select them one by one. After selecting the packages you want, click Forward.

Available Package Updates

0 Select all packages

Package Name

Version

Release

Arch

Size

A

LH fetch mail

5.9.0

21

¡336

423 kB

u

ggv

1.99.9

5

¡336

323 kB

□ hwdata

0.4 S

1

noarch

1S4 kB

_

U

mozilla

1.0.1

26

¡336

10402 kB

u

mazilla-mail

1.0.1

26

¡336

206S kB

u

mozilla-nspr

1.0.1

26

¡336

111 kB

View Advisory

Package Information

View Advisory

The up2date program will now retrieve the packages you selected. This may take a while if there are lots of updates or if you have limited bandwidth. Grab a Mountain Dew, trim your fingernails, or go over a few mastery checks while you're waiting. When the packages have downloaded, the Forward button will be enabled. Click it to continue on to install the packages.

The installation process is straightforward; as with the package download, up2date will keep you apprised of the progress so far. When the installation process is done, you'll be able to click the Forward button again to bring up a screen listing the updates that have been installed.

All Finished

The Red Hat Update Agent has finished installing the following packages successfully:

From this screen, click the Finish button to exit up2date back to the desktop of your up-to-date Linux server!

Configuring up2date

If your network uses an HTTP proxy system, or if you want to make other changes to the up2date utility's default configuration, you can use the up2date-config program to set up things the way you want them. Invoke the program using the following command:

[[email protected] ~]$ up2date-config

This command brings up the configuration screen shown in the following illustration. The contents of the General tab allow you to point to a proxy server and enter your authentication information.

You can also set the package retrieval options from the Retrieval/Installation tab (shown in Figure 9-4). If you want to check the authenticity of the upgrade packages, prevent installation

General iRetrieval / Installation) Package Exceptions

Package Retrieval Options

□ Do not Install packages after retrieval

0 Do not upgrade packages when local configuration file has been modified

□ Retrieve source RPM along with binary package

Package Verification Options

[3 Use GPG to verify package Integrity

Package Installation Options 0 After installation, keep binary packages on disk

0 Enable RPM rollbacks (allows "undo" but requires additional storage space)

Override version stored In System Profile:

Package storage directory: /var/spool/up2date

Figure 9-4 Configure package retrieval and installation options in up2date-config.

of the packages (just download them), or enable "undo" operations for upgrades about which you have second thoughts, you can do those things here.

If you want the up2date program to download kernel upgrade packages by default, you can make that configuration change from the Package Exceptions tab, shown in Figure 9-5.

Figure 9-5 Add or remove upgrade packages to skip in up2date-config.

By default, the kernel-related packages are not automatically downloaded, so there should already be an entry in the skip list. You can add additional exceptions if you wish, but don't do this unless you have a good reason. The whole point of this tool is to keep your system up to date.

NOTE n

You can also initiate system upgrades via the RHN web interface at http://rhn.redhat.com. The systems will need to be entitled and running the rhnsd daemon for this to work properly, but it can be more convenient than having to touch each of many systems to perform updates. Of course, running rhnsd itself may have security implications, but if you've got to choose, rhnsd is the lesser of two evils.

Manually Performing Security Updates

You don't have to be a Red Hat Network subscriber or use the up2date command to keep your system up to date. Instead, you can track Red Hat Linux 8.0 security updates from Red Hat's web site at https://rhn.redhat.com/errata/rh8-errata.html. Follow these steps to update your system the manual way:

1. Find the packages you need on the web site.

2. Download them from the web site to your system.

3. Verify their authenticity by checking their GNU Privacy Guard keys using the rpm -K *.rpm command in the download directory.

4. Run the package upgrades as described in Module 4.

Getting Your System up2date

Project 9-1

You've seen the screens in this module; now see them on your very own Linux server's screen. In the course of this project, you will create a Red Hat Network account, register your computer, and update its packages. Even if you have already burned your one demonstration run of up2date, you can make this project a reality by registering another account name.

Step by Step

1. Run the up2date program to set up your account and register your Red Hat Linux 8.0 system (if you haven't already).

2. Select at least one, but not all, of the available packages for download.

3. Once the packages have been downloaded, install them.

4. Now that you've used the "manual" version of the up2date process, check to see if the RHN daemon process is activated. If it isn't, start it up.

5. Log onto your account at http://rhn.redhat.com and find your registered system. Set it up to perform the remainder of the upgrade installations.

6. The RHN daemon process checks for updates every two hours by default. Track the progress of the update you scheduled using the Red Hat Network web site.

7. Once the packages are listed as having been updated, check a list of the locally installed packages and look for the updated versions.

8. If the kernel has been upgraded during this process, reboot and ensure that the system still comes up properly.

Project Summary

Now that was an easy project. Maintaining packages on a Red Hat Linux server is not difficult, because of the automation that the Red Hat Network provides. If you do lots of customization of startup scripts or make other significant changes, you may run into problems because certain packages won't be upgraded (otherwise they would clobber your changes). This can cascade into a larger problem if the nonupgrading packages are required for other upgrades to be installed. Fortunately, this problem can be avoided by using tools to change the startup scripts, rather than moving them around willy-nilly.

CRITICAL SKILL

Understanding TCP/IP and Network Security

This module assumes you have experience configuring a system for use on a TCP/IP network. Because the focus here is on network security and not an introduction to networking, this section discusses only those parts of TCP/IP affecting your system's security.

The Importance of Port Numbers

Every host on an IP-based network has at least one IP address. In addition, every Linux-based host has many individual processes running. Each process has the potential to be a network client, a network server, or both. Obviously, if a packet's destination were identified with the IP address alone, the operating system would have no way of knowing to which process the packet's contents should be delivered.

To solve this problem, TCP/IP adds a component identifying a TCP (or UDP) port. Every connection from one host to another has a source port and a destination port. Each port is labeled with an integer between 0 and 65535.

In order to identify every unique connection possible between two hosts, the operating system keeps track of four pieces of information: the source IP address, the destination IP address, the source port number, and the destination port number. The combination of these four values is guaranteed to be unique for all host-to-host connections. (Actually, the operating system tracks a myriad pieces of connection information, but only these four elements are needed to uniquely identify a connection.)

The host initiating a connection specifies the destination IP address and port number. Obviously, the source IP address is already known. But the source port number, the value that will make the connection unique, is assigned by the source operating system. It searches through its list of already open connections and assigns the next available port number. By convention, this number is always greater than 1024 (port numbers from 0 to 1023 are reserved for system uses). Technically, the source host can also select its source port number. In order to do this, however, another process cannot have already taken that port. Generally, most applications let the operating system pick the source port number for them.

Knowing this arrangement, you can see how source Host A can open multiple connections to a single service on destination Host B. Host B's IP address and port number will always be constant, but Host A's port number will be different for every connection. The combination of source and destination IPs and port numbers (a 4-tuple) is therefore unique, and both systems can have multiple independent data streams (connections) between each other.

Port Dangers

For a server to offer services, it must run programs that listen to specific port numbers. Many of these port numbers are called well-known services because the port number associated with a service is an approved standard. For example, port 80 is the well-known service port for the HTTP protocol.

All these ports allowing incoming connects are not just an opportunity for productive, predictable use of your system, they're also an opportunity for the unscrupulous or clueless to gain unintended access on your system. Legitimate users' systems know the default port numbers for the services you'll offer, but so will crackers' tools. So by default, you'll want to restrict access as much as possible, allowing only your real users to access your system.

In "Using the netstat Command," later in this module, you'll look at the netstat command as an important tool for network security. When you have a firm understanding of what port numbers represent, you'll be able to easily identify and interpret the network security statistics provided by the netstat command.

For More Information on TCP/IP

There are many great books that discuss TCP/IP in greater detail. The Network Administrator's Reference by Tere' Parnell and Christopher Null (/McGraw-Hill/Osborne, 1999) is a good place to start. This book discusses network administration from a high-level point of view and is a solid text all by itself (despite being very Windows NT-centric). It discusses TCP/IP but doesn't get too far into the nuts and bolts.

The ultimate TCP/IP "bible" (referenced by network developers and administrators around the world) is W. Richard Stevens' TCP/IP Illustrated series (Addison-Wesley, 1994-96). These books step you through TCP/IP and related services in painstaking detail. As a systems administrator, you'll be interested mostly in Volume 1: The Protocols, which addresses the suite of protocols and gives a strong explanation of IP stacks. If there's a kernel-hacker inside of you who's curious about TCP/IP implementation, check out Stevens' line-by-line analysis of the BSD network code in Volume 2: The Implementation. (Although there's little resemblance between Linux's networking code and the code documented in Volume 2, the general guidance and philosophy offered are still invaluable.)

Another excellent book, TCP/IP Network Administration by Craig Hunt (O'Reilly & Associates, 2002), is a solid network administration reference. It has a much greater breadth of topics (but less technical depth) than Stevens' Volume 1.

Finally, if you're responsible for implementing a firewall (and I recommend you do implement one), the O'Reilly & Associates text on firewall design, Building Internet Firewalls (O'Reilly & Associates, 2000), edited by D. Brent Chapman, et al., is a good one.

CRITICAL SKILL

Using Tracking Services

The services provided by a server are what make it a server. These services are provided by processes that bind to network ports and listen to incoming requests. For example, a web server might start a process that binds to port 80 and listens for requests to download the pages of a site. Unless a process exists to listen to a specific port, Linux will simply ignore packets sent to that port.

NOTE n

Remember that when a process makes a request to another server, it opens a connection on a port, as well. The process is, in effect, listening to data coming in from that port. However, on the client the process knows to whom it's talking because it initiated the request. The client process will automatically ignore any packets sent to it that do not originate from the server to which it's connected.

This section discusses the usage of the netstat command, a tool for tracking network connections (among other things) in your system. It is, without a doubt, one of the most useful debugging tools in your arsenal for troubleshooting security and day-to-day network problems.

Using the netstat Command

To track what ports are open and what ports have processes listening to them, you use the netstat command. For example:

[[email protected] /root]# netstat -natu

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp

1

0

209

179

251.53 : 1297

199

184

.252.

5:80

CLOSE_WAIT

tcp

1

0

209

179

251.53 : 1296

199

184

.252.

5:80

CLOSE_WAIT

tcp

57

0

209

179

158.93 1167

199

97.226.1

:21

CLOSE_WAIT

tcp

0

0

192

168

1.1:6000

192

168

1.1:

1052

ESTABLISHED

tcp

0

0

192

168

1.1:1052

192

168

1.1:

6000

ESTABLISHED

tcp

0

0

0

0

0

0

4242

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1036

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1035

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1034

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1033

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1032

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1031

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

1024

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

6000

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

80

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

515

0

0

0

0

:*

LISTEN

tcp

0

0

192

168

1.1:53

0

0

0

0

:*

LISTEN

tcp

0

0

127

0

0

1:53

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

98

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

113

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

23

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

21

0

0

0

0

:*

LISTEN

tcp

0

0

0

0

0

0

111

0

0

0

0

:*

LISTEN

udp

0

0

0

0

0

0

1024

0

0

0

0

:*

[[email protected] /root]#

By default (with no parameters), netstat will provide all established connections for both network and domain sockets. That means you'll see not only the connections that are actually working over the network, but also the interprocess communications (which, from a security monitoring standpoint, are not useful). So in the command illustrated, you have asked netstat to show you all ports (-a), whether they are listening or actually connected, for TCP (-t) and UDP (-u). You have told netstat not to spend any time resolving hostnames from IP addresses (-n).

In the netstat output, each line represents either a TCP or UDP network port, as indicated by the first column of the output. The Recv-Q (receive queue) column lists the number of bytes received by the kernel but not read by the process. Next, the Send-Q column tells you the number of bytes sent to the other side of the connection but not acknowledged.

The fourth, fifth, and sixth columns are the most interesting in terms of system security. The Local Address column tells you your own server's IP address and port number. Remember that your server recognizes itself as 127.0.0.1 and 0.0.0.0 as well as its normal IP address. In the case of multiple interfaces, each port being listened to will show up on both interfaces and thus as two separate IP addresses. The port number is separated from the IP address by a colon. In the output from the preceding netstat example, one Ethernet device has the IP address 192.168.1.1, and the PPP connection has the address 209.179.251.53. (Your IP addresses will vary depending on your setup.)

The fifth column, Foreign Address, identifies the other side of the connection. In the case of a port that is being listened to for new connections, the default value will be 0.0.0.0:*. This IP address means nothing, since you're still waiting for a remote host to connect to you!

The sixth column tells you the State of the connection. The man page for netstat lists all of the states, but the two you'll see most often are LISTEN and ESTABLISHED. The LISTEN state means there is a process on your server listening to the port and ready to accept new connections. The ESTABLISHED state means just that—a connection is established between a client and server.

Security Implications of netstat's Output

By listing all of the available connections, you can get a snapshot of what the system is doing. You should be able to explain and justify all ports listed. If your system is listening to a port that you cannot explain, this should raise suspicions.

If you've been using your memory cells for other purposes and haven't memorized the services and their associated port numbers, you can look up the matching info you need in the

/etc/services file. However, some services (most notably those that use the portmapper) don't have set port numbers but are valid services. To see which process is associated with a port, use the -p option with netstat. Be on the lookout for odd or unusual processes using the network. For example, if the BASH shell is listening to a network port, you can be fairly certain that something odd is going on.

Finally, remember that you are interested only in the destination port of a connection; this tells you which service is being connected to and whether it is legitimate. Unfortunately, netstat doesn't explicitly tell you who originated a connection, but you can usually figure it out if you give it a little thought. Of course, becoming familiar with the applications that you do run and their use of network ports is the best way to determine who originated a connection to where. In general, you'll find that the rule of thumb is that the side whose port number is greater than 1024 is the side that originated the connection. Obviously, this general rule doesn't apply to services typically running on ports higher than 1024, such as X (port 6000).

One purpose for the netstat command is to determine what services are enabled on your servers. Making Linux easier to install and manage right out of the box has led to more and more default settings that are unsafe, so keeping track of services is especially important.

When you're evaluating which services should stay and which should go, answer the following questions:

1. Do I need the service? The answer to this question is very important. In most situations, you should be able to disable a great number of services that start up by default. A standalone Web server, for example, should not need to run NFS.

2. If I do need the service, is the default setting secure? This question can also help you eliminate some services—if they aren't secure and they can't be made secure, then chances are they should be removed. The Telnet service, for instance, is often a candidate for early removal because it requires that passwords be sent over the network without encryption.

3. Does the service software need updates? All software needs updates from time to time, such as that on web and FTP servers. This is because as features get added, new security problems creep in. So be sure to remember to track the server software's development and get upgrades installed as soon as security bulletins are posted.

To shut down a service that is started via the xinetd program, simply edit the service's configuration file in /etc/xinetd and set disable equal to Yes. See Module 8 for more information on xinetd. Send a SIGUSR2 signal to reload xinetd. Red Hat Linux makes this simple using the following command:

[[email protected] /root]# service xinetd reload

NOTE

If you have a system using the older inetd, edit the /etc/inetd.conf file and comment out the service you no longer want. To designate the service as a comment, start the line with a number sign (#). Remember to send the HUP signal to inetd once you've made any changes to the /etc/inetd.conf file.

Shutting Down Non-xinetd Services

If a service is not run by xinetd, then a process that is probably started at boot time is running it. The easiest way to stop that from happening is to edit the startup service list using the redhat-config-services GUI tool or the ntsysv command from the command line as described in Module 8. You can also manually change the symlink. Go to the /etc/rc.d/ directory and in one of the rc*.d directories, find the symlinks that point to the startup script. (See Module 8 for information on startup scripts.) Rename the symlink to start with an X instead of S. Should you decide to restart a service, it's easy to rename it again starting with an S. If you have renamed the startup script but want to stop the currently running process, use the service command to tell the process to stop. For example, here is the command to kill a portmap process:

[[email protected] /root]# service portmap stop

NOTE W

As always, be sure of what you're killing before you kill it, especially on a production server.

A Note about the syslogd Service

One non-inetd service that will pop up on netstat output but can be safely ignored is syslogd. This service has historically defaulted to binding to a network port and listening for network messages to log. Because of the danger of logging arbitrary messages from a network, Linux developers have added a mechanism whereby syslogd logs requests sent from other hosts only if it has been started with the -r option. By default, syslogd does not start with -r, so you can safely let it remain on your system.

CRITICALSKILL

Monitoring Your System

The process of tying down your server's security isn't just for the sake of securing your server; it gives you the opportunity to see clearly what normal server behavior should look like. After all, once you know what normal behavior is, unusual behavior will stick out like a sore thumb. (For example, if you turned off your Telnet service when setting up the server, seeing a log entry for Telnet means something is very wrong!)

Commercial packages that perform monitoring do exist and may be worth checking out for your site as a whole, but I'll leave the discussions of their capabilities to Network World or InfoWorld. Here, you'll take a look at a variety of other excellent tools that help you accomplish the monitoring of your system. Some of these tools come with all Linux distributions; some don't. All are free and easily acquired.

Making the Best Use of syslog

In Module 8, you explored syslog, the system logger that saves messages from various programs into a set of text files for record-keeping purposes. By now, you've probably seen the type of log messages you get with syslog. These include security-related messages such as who has logged in to the system, when they logged in, and so forth.

As you can imagine, it's possible to analyze these logs to build a time-lapse image of the utilization of your system services. This data can also point out questionable activity. For example, why was the host crackerboy.nothing-better-to-do.net sending so many web requests in such a short period of time? What was he looking for? Has he found a hole in the system?

Log Parsing

Doing periodic checks on the system's log files is an important part of maintaining security. Unfortunately, scrolling through an entire day's worth of logs is a time-consuming and unerringly boring task that reveals few meaningful events. To ease the drudgery, pick up a text on a scripting language (such as Perl) and write small scripts to parse out the logs. A well-designed script works by throwing away what it recognizes as normal behavior and showing everything else. This can reduce thousands of log entries for a day's worth of activities down to a manageable few dozen. This is an effective way to detect attempted break-ins and possible security gaps. Hopefully, it'll become entertaining to watch the script kiddies trying and failing to break down your walls.

You may also want to look into the logwatch program that comes with Red Hat 8. This simple program can be configured to create reports based on your log activity and mail them to the administrator. It's certainly not the perfect solution, but it may be a good starting point. Read the man page for more details.

Storing Log Entries

Unfortunately, log parsing may not be enough. If someone breaks into your system, it's likely that your log files will be promptly erased—which means all those wonderful scripts won't be able to tell you a thing. To get around this, consider dedicating a single host on your network to storing log entries. Configure your /etc/syslog.conf file to send all of its messages to this single host, and configure the host so that it's listening only to the syslog port (514). In most instances, this should be enough to gather, in a centralized place, the evidence of any bad things happening.

If you're really feeling paranoid, consider attaching a DOS-based PC to the serial port of the loghost and, using a terminal emulation package such as Telix, recording all of the messages sent to the loghost. (You can also use another Linux box running minicom in log mode—just be sure not to network this second Linux box!) Have /etc/syslog.conf configured to send all messages to a /dev/ttyS0 if you're using COM1 or /dev/ttyS1 if you're using COM2. And, of course, do not connect the DOS system to the network. This way, in the event the loghost also gets attacked, the log files won't be destroyed. The log files will be safe residing on the DOS system, which is impossible to log in to without physical access.

For the highest degree of monitoring capability, connect a parallel-port printer to the DOS system and have the terminal emulation package echo everything it receives on the serial port to the printer. Thus, if the DOS system fails or is damaged in some way by an attack, you'll have a hard copy of the logs. (Note that a serious drawback to using the printer for logging is that you cannot easily search through the logs. Ifyou choose to set up this arrangement, consider also keeping an electronic copy for easier searching.)

Consider using a package like swatch to page you when it sees a log entry that indicates trouble. You can find out more about it at http://www.oit.ucsb.edu/~eta/swatch/.

Monitoring Bandwidth with MRTG

Monitoring the amount of bandwidth being used on your servers produces some very useful information. The most practical use for it is justifying the need for upgrades. By showing system utilization levels to your managers, you'll be providing hard numbers to back up your claims. Your data can be easily turned into a graph, too—and managers like graphs! Another useful aspect of monitoring bandwidth is to identify bottlenecks in the system, thus helping you to better balance the system load. But the most useful aspect of graphing your bandwidth is to identify when things go wrong.

Once you've installed a package such as MRTG (Multi-Router Traffic Grapher, available in Red Hat Linux 8.0) to monitor bandwidth, you will quickly get a criterion for what "normal" looks like on your site. A substantial drop or increase in utilization is something to investigate Check your logs, and look for configuration files with odd or unusual entries.

The COPS tool (Computer Oracle and Password System) provides a simple and automated way of checking for unusual settings in the system. Such checks include looking for SetUID programs in home directories, unusual permission settings on home directories, configuration files that expose your system to outside access without authorization, and so on.

One of the most significant features of COPS is that it is designed to be automatically run from a cron entry (see Module 8 for more about cron) every night. The report, if there is anything to report, is e-mailed to you.

You can research and download the latest and greatest version of COPS at ftp://ftp.cert.org/ pub/tools.

Tripwire, distributed as a standard Red Hat Linux 8.0 package, takes a very paranoid approach to security: If something changes, Tripwire tells you. This comprehensive protection removes the opportunity for someone to place a "backdoor" or "time bomb" in your system.

Tripwire generates MD5 checksums of every file on your system and saves them in an encrypted format. When you want to check on differences, you can recall the saved checksums and compare all of the files on the system to their known good MD5 checksum. Differences are reported.

The idea here is for you to perform an install and then ready a system for network deployment. But before actually putting the system onto the network, you run the Tripwire tool to generate and store all of the checksums. You can be confident that your list of MD5 checksums is safe in its encrypted domicile.

The process of setting up a Tripwire arrangement is time consuming. And if you use it on a system you're fiddling with, you'll get lots and lots of change notifications. However, short of cutting off network connectivity, it's hard to tighten up a system any more than this.

Nessus is a very flexible security scanner with a modular architecture that helps it keep up with the latest threatening developments. While it's not the final word in threat assessment (there isn't one), it's very capable and full-featured, with a variety of scanning and reporting options. See http://www.nessus.org for more information. You can also install Nessus via a

COPS

Nessus package from http://freshrpms.net, but be mindful that third-party packages could introduce vulnerabilities of their own. Sort of makes you want to disconnect your computers from the rest of the world, if you focus too much on this security stuff, doesn't it? :

Nessus is a client/server tool for which you'll have to set up a server process, add users ;

who are allowed to run scans, and then launch a GUI to configure an "attack" to identify vulnerabilities. By default, Nessus doesn't try to crash the host you're testing, but you might want to be careful about which potential vulnerabilities you test. Running a denial of service attack as a test of a production server during business hours might be a career-limiting move.

SATAN

SATAN, the System Administrator Tool for Analyzing Networks, was released in the mid-1990s to a flurry of press suggestions that it was a hacker's toolkit. And SATAN's author, Dan Farmer, more or less declared that it was a hacker's toolkit—but for system administrators rather than evildoers.

SATAN works by probing your network for potential security holes. This program is especially interesting because it can be run from both inside (for you) and outside of your network (against you). It's an effective way of exposing firewall gaps when you run it from the outside, and an excellent investigation of internal weaknesses when run from an inside host.

Although SATAN is a bit older and doesn't identify many of the newer attacks that are employed today, it does do many of the "twist the door handle and see if it's open" checks that are no less important. You should assume that others will run SATAN against you, so be sure you know where your own weaknesses are and get them fixed as quickly as possible.

Like COPS, SATAN is available from ftp://ftp.cert.org/pub/tools.

Ask the Expert Q:

I'm interested in learning more about system security in general. What can I read on the subject?

A: There's tons of information available, so the biggest problem is sorting out what you really want to find out about. Red Hat has a Security Guide document that discusses a variety of security issues. Look at the HTML version at https://www.redhat.com/docs/ manuals/linux/RHL-8.0-Manual/security-guide/. I'm fond of the policy documents available at http://www.sans.org/newlook/resources/policies/policies.htm, from the SysAdmin, Audit, Network, Security (SANS) Institute, and the Auditing Linux document at http://www.sans.org/SCORE/checklists/AuditingLinux.doc.

"O

(continued)

Q: You mention several security-related tools; are there more I should know about?

A: The Linux Intrusion Detection System, which is software for bolstering the security of a Linux system's operation, is worth looking into at http://www.lids.org. There are also "hardened" Linux distributions, including Bastille Linux

(http://www.bastille-linux.org), which is an add-on for other distributions (including Red Hat Linux 8.0) designed to tighten security for you. Furthermore, if you follow the link sections of the web sites listed in "Find Helpful Resources Online," later in this module, you'll find a wide range of additional materials to peruse.

Q: I've heard that Linux is much more secure than Windows. Is it that secure?

A: There have been lots of arguments on this subject, with people going so far as to count the number of vulnerability reports on each operating system. Unfortunately, this is rarely an apples-to-apples comparison, and debating the issue won't make your servers, whether from Microsoft, Red Hat, or somebody else, any more secure. Instead, spend your efforts on becoming knowledgeable about what the real risks are. Spend some time browsing the sites mentioned in this module; they'll give you some solid information on what to do with the systems you have.

Q: But I need to know which operating system is most secure so that I can use it and not have to worry.

A: But unfortunately, you'll always have to worry. The only way to secure a computer system is to turn it off and lock it up. Even then, it could be compromised by someone with a lock pick set and a UPS. So unless you plan to dump your computers in a smelting furnace (alongside any rogue T-1000 terminators you run across), you're going to need to exert some effort keeping on top of their security.

Project 9-2

Running a Nessus Scan

There are lots of interesting tools available for scanning systems for vulnerabilities. It's quite instructive to see the output from such a tool, to see what somebody else might find out about your system.

While there may be other pressing issues to consider first (I'll explain a few of them in "Be Aware of Security Miscellany" later in this module), scanning a system doesn't take long, and just reading the explanation of the results can be an excellent learning experience.

Step by Step

2. Once Nessus is installed, create a certification for the server using the /sbin/nessus-mkcert

3. Add a Nessus user with the nessus-adduser command.

4. Start the nessusd service.

5. Start the client program, nessus, and point it to the host system running nessusd.

6. Log in as the Nessus user you added.

7. Configure the scan to use whichever plug-ins sound interesting. The default settings work pretty well, but remember not to bombard an important server.

8. Select a target system and scan away.

9. Look at the resulting report, double-clicking on the network and host information that appears to get to the target system's results.

10. Decide whether you'll need to disable any services, apply any updates, or perform other security-related housecleaning based on your results.

Project Summary

Running Nessus is not at all hard, so installing and configuring it may be the most difficult part. By now you should be an old pro at setting up software on your Linux system! Avail yourself of help online if you get stuck, and refer to the man pages, or even type nessus at a prompt and press TAB to see which auto-completion options are available. Also, remember that you're performing a vulnerability scan in this project. That may not be allowed by your Internet service provider or hosting site, so be careful, Linux administrator, whose drapes you're peeking through. Even owners of other servers on an internal network can become fairly agitated and unruly if they catch you scanning their systems. As well they might!

1. Obtain and install Nessus. Using the http://freshrpms.net site's prebuilt packages is the : ;>

easiest way, but you can practice your software building and installation skills (from ; Jo

Module 4) by downloading the source code from http://www.nessus.org. Install all the packages or build both server and client software.

CRITICAL SKILL

Employing a Checklist

If you don't keep track of the systems you administer, you never know what's going on with them. Using a simple checklist can help keep you aware of security issues that need to be bolted down on every system, not just the one you practiced on while reading this module! Table 9-1 shows a sample checklist that you can modify to meet your own needs.

Rule

Security Measure

1.

Use software to enhance safety

1.1

Set password protection on your boot loader

1.2

When installing, keep the Red Hat default of using shadow passwords with MD5 encryption

1.3

Enable PAM

1.4

Use OpenSSH rather than rlogin and rsh (see Module 15 for more on OpenSSH)

1.5

Install and configure Tripwire, and monitor its output

1.6

Use up2date or a manual process to ensure that update packages are installed from a secure site

1.7

Periodically use a vulnerability scanner to keep yourself and your systems honest

2.

Configure the system to enhance safety

2.1

Do not open file and directory permissions any wider than necessary, especially executable and configuration files

2.2

Do not use SetUID root permissions

2.3

Disable reboots using the CTRL-ALT-DEL key combination (in the /etc/inittab file)

2.4

Use restrictive settings on Apache, DNS, FTP, SMTP, POP/IMAP, printing, and NFS configurations (and only enable these servers as needed)

2.5

Configure iptables firewalling as appropriate

3.

Restrict or eliminate vulnerable software

3.1

Do not use xinetd services unless necessary

3.2

Disable the rlogin and rsh commands; use OpenSSH instead

3.3

Disable unnecessary processes listening on ports

4.

Use your brain

4.1

Limit access to the physical server

Table 9-1 Sample Security Consciousness Checklist

Table 9-1 Sample Security Consciousness Checklist

Rule

Security Measure

Maintain backups, emergency boot disks, and configuration information

Avoid having too many people know root passwords

4.4 Use secure passwords for all your accounts

Table 9-1 Sample Security Consciousness Checklist (continued)

CRITICAL SKILL

Was this article helpful?

0 0

Post a comment