Sie sind auf Seite 1von 40

Red Hat Enterprise Linux Network Services

Key Concepts

The IP protocol, and it's associated IP addresses, serves to route data from one
computer to another.
The TCP and UDP protocols, with their associated port numbers, serve to route
data received via the IP protocol to a particular process on a machine.
Networking applications are processes like any other process on the machine,
and can be monitored with the ps command.
The netstat -tuna command can be used to view a list of open ports on a given
machine.
Most Linux networking servers use a "forking" model.

Discussion

Linux developers look to the Unix operating system as inspiration for much of Linux's
design. As a result, most Linux network server applications are implemented as
daemons. This lesson focuses on the traditional Unix techniques used to manage
network daemons. While these techniques are not often used in day to day management
of Red Hat Enterprise Linux, they provide a useful model which promotes
understanding and is invaluable for troubleshooting.

The lesson begins with a quick review of TCP/IP networking, and then follows along as
an administrator installs, starts, reconfigures, and stops the vsftpd network application.

Course Introduction

Originally, computers were used to crunch numbers. Typical computer users in the
1970's probably wrote their own programs, submitted their work when there was an
opening, and came back for the results. Today, computers are more often used to
produce, edit, organize, and otherwise manipulate words, images, and sounds. Typical
computer users today open a web browser on a home computer, enter a URL or click on
a few links, and have a wealth of information at their fingertips. Time of day is seldom
considered; The following story could take place at 2:00 in the morning just as easily as
at 2:00 in the afternoon.

Susan is planning a trip to New York. She sits down at her computer, opens a browser,
and searches for hotels in Manhattan. She looks up a a map of the neighborhood she
will be visiting, and prints it out. She searches for guidebooks about New York
restaurants, and purchases one online. Finally, she types up her itinerary, and emails it
to a friend. She then exits the browser, shuts down the computer, and leaves the room.

This course isn't about Susan's computer - or at least not the computer you're thinking
of. This course is about the dozen other computers she used - the ones not directly
mentioned in the story. This course is about the computers that Susan's computer talked
to. There are the obvious ones, such as the server which performed her web searches (a
Web server). There are also the more subtle ones - the one that assigned her computer
an IP address as it booted (a DHCP server), the one which translated all of her domain
names into IP addresses (a DNS server), and the one which relayed her email out to its
destination (a SMTP server).

These unseen computers probably don't have a mouse, a keyboard, or a monitor - at


least not exactly. They probably live in various closets spread around the world. They
definitely don't get shut off when someone leaves the room. And in the example given
above, chances are as good as not that the various web, DHCP, DNS, and SMTP servers
are running Linux. We don't know what type of machine Susan was sitting at, but if she
performed her search on Google.com, or bought her book from Amazon.com, she was
using Linux.

This course is about the installation, basic configuration, and management of network
applications - the ones mentioned above, and more. Upon completion, the student
should be able to maintain these network services, whether they exist on a desktop or on
an unseen server in a closet.

Review of TCP/IP Networking Basics

The IP protocol

As its name implies, the Internet Protocol (IP) has been adopted as the standard protocol
for communication between machines. Two machines using the IP protocol must each
have an identity known as an IP address, which is usually represented as a series of four
integers between 0 and 255, such as "192.168.0.4". This familiar representation of an IP
address is often informally referred to as a dotted quad.

IP addresses can be compared to telephone numbers. Packets of data labeled with a


computer's IP address can be routed to that computer, just as a telephone call can be
routed to the right telephone. How this routing occurs is a wonderful topic, but beyond
the scope of this course. For our purposes, just know that the IP protocol, with its
associated IP addresses, is responsible for routing data from one computer to another
over the Internet.

Because people can remember names more easily than numbers, IP addresses can be
assigned a name, such as <hostname>www.redhat.com</hostname> or
<hostname>www.kernel.org</hostname>. Hostnames can be converted into an
associated IP address using techniques that will be covered later in detail. For now, just
assume that knowing a computer's hostname is essentially the same as knowing its IP
address.

The TCP and UDP Protocols

IP addresses and the IP protocol are used to route packets of information from one
computer to another, but that's not the end of the story. Usually, that information needs
to be routed to and from particular applications on the various computers. One of two
similar yet distinct protocols are often used, either the TCP or UDP protocol. Both of
these protocols are based on the concepts of ports and sockets.

In order to communicate using the network, applications must ask the Linux kernel to
open a socket. The application can then send information across the network by writing
to the socket, and receive information by reading from the socket. Because a machine
may have many different applications carrying on simultaneous conversations, each
socket is assigned a port number, which can range from 1 to 65535 (which
mathematicians or computer geeks might recognize as 2^16, almost).

In the following diagram, applications running on running on two machines,


<hostname>server.isp.net</hostname> with an IP address of 123.45.67.89, and
<hostname>client.example.com</hostname> with an IP address of 192.168.0.1, are
having conversations. The diagram illustrates processes running on each of the
machines, and the port numbers which they were assigned. For example, the httpd
process on <hostname>server.isp.net</hostname> has been assigned port number 80,
while the firefox process on <hostname>client.example.com</hostname> has been
assigned the port number 44985.

Figure 1. TCP/IP Ports and Sockets

The TCP and UDP protocols are not alternatives to the IP protocol, but are used in
addition to the IP protocol. While the IP protocol uses IP addresses to route data to a
particular machine, the TCP and UDP protocols in turn use ports to route data to a
particular process on that machine.

The combination of the IP address and port number of the processes on each of the two
machines is referred to as a socket pair, and is enough information to uniquely identify
the various network conversations.

Most services we will encounter use the TCP/IP protocol, though a few use the UDP/IP
protocol. For now, just know that each protocol has a distinct set of ports, so that TCP
port 80 is not the same thing as UDP port 80. As we continue, we will often speak as if
all IP applications use the TCP/IP protocol, because the majority do.

Clients and Servers

Most networking protocols are designed around a "Client/Server" architecture. To some


extent, the features of networking clients and servers can be compared to human clients
buying a candy bar from human servers at the local store.
Servers have well known addresses. Just as a customer knows where to find a
candy bar server (at the store around the corner, behind the counter), networking
clients know where to find networking servers (at the host
<hostname>www.yahoo.com</hostname>, listening to port 80). When
requesting a new networking socket, servers generally ask for a specific port
(such as 80). In contrast, clients are usually randomly assigned a port number.
Servers are highly available. Because servers don't know exactly when clients
will come along, they need to be always ready. Just as the candy bar server
needs to always stand behind the counter to be ready for new customers, a
network server needs to be always running and listening for new connections.
Often, network servers run as daemons, which are processes which disassociate
themselves from the terminal which started them. Therefore, unlike most
commands, daemons continue to run even after the session from which they
were started has been closed.
Clients initiate transactions. A client initiates the buying of a candy bar by
walking up to the counter. Generally, networking clients initiate transactions by
requesting new connections with a networking server.

More about Ports

As was mentioned above, servers and clients generally handle ports differently; servers
request a specific port on startup, while clients are randomly assigned one. Which port
does a server request?

Well Known Ports and the /etc/services File

Specific services have been assigned port numbers, so that clients know where to find
them. These ports are cataloged in the file /etc/services, which lists hundreds of well
known ports. The following table lists a few of the well known ports that we will be
encountering in this course.

Table 1. Well Known Ports

Service Protocol Port


ftp TCP 21
ssh TCP 22
smtp TCP 25
domain (DNS) UDP 53
http TCP 80
pop3 TCP 110
imap TCP 143
https TCP 443
microsoft-ds TCP 445

Because ports for specific services are well known, when requesting new connections,
ftp clients know to request a connection to port 21, while web browsers know to request
port 80.
Privileged Ports (1-1023)

The ports numbered 1 - 1023 are termed privileged ports, and only processes running as
root can bind to these ports. On machines which might have many users, this feature
helps ensure that the right service is bound to the right port. For example, the user
<username>elvis</username> could not start his own version of a webserver, only the
user <username>root</username> could.

When clients are assigned a port number, the assigned port number comes from well
above the privileged port range.

The netstat Command

The netstat command can be used to observe which ports are open on a machine.
Unfortunately, without arguments, the netstat command displays probably its least
helpful information (something called Unix domain sockets, which aren't involved with
networking and thus not relevant to this course). In order to make netstat useful for our
purposes, obscure command line switches need to be added. One combination which
has the combined advantages of providing reasonable output and being easy (for
English speakers) to remember is netstat -tuna.

[student@station ~]$ netstat -tuna


Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
udp 0 0 0.0.0.0:631 0.0.0.0:*

The output shows all open ports on the system, including their protocol, local address,
and "Foreign" address. Additionally, for TCP ports, the TCP state of the socket is
shown.

When being run by the root user, an additional -p command line switch will request that
the name and process ID ("pid") of the process owning the port be displayed as well.
Unfortunately, this is considered privileged information, and is not available to standard
users.

[student@station ~]$ su
Password:
[root@station ~]# netstat -tunap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
3681/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
3793/sendmail: acce
tcp 0 0 :::22 :::* LISTEN
3763/sshd
udp 0 0 0.0.0.0:631 0.0.0.0:*
3681/cupsd

The Local Address


The "Local Address" is the combination of IP address and port number to which the
processes are bound. Many machines can support more than one IP address, possibly
because they have more than one Ethernet card. In fact, most machines support at least
two: one "real" address, which is assigned to their Ethernet card, and a "loopback"
address (usually 127.0.0.1), which is a virtual address that just loops back to the same
machine.

When binding to a particular port, networking servers generally choose one of three
strategies when specifying which particular IP address they want to bind to.

Bind to the loopback address only. In the output above, the cupsd (TCP) and
sendmail daemons have taken this approach. While using the TCP/IP protocol,
these daemons will only receive connections from processes running on the
same machine as they are.
Bind to explicitly stated addresses. If a machine has more than one IP address,
a daemon could explicitly state which IP addresses to which it should bind.
None of the processes above have taken this approach. [1]
Binding to any address. When binding to a port, a process can specify that it
should bind to all addresses. This is generally represented by an IP address of
0.0.0.0 or just "::". [2] In the above output, sshd and the UDP cupsd port have
taken this approach.

The Foreign Address

When a client has connected to a service, the IP address and port number of the client is
displayed. In the output above, no clients have yet connected, so the Foreign Address is
not very interesting. That is about to change.

State

For the TCP protocol, TCP connections are said to be in certain states. Although there
are officially 11 states, for us only two of them are important: LISTEN and
ESTABLISHED. A socket in the LISTENing state is a server which is willing to accept
new clients. A socket in the ESTABLISHED state is actively bound to a particular
client. All of the TCP sockets above are in the LISTENing state.

Observing a typical Network Service: sshd

The Secure Shell Service

In order to illustrate many of the concepts mentioned above, we turn to examine the
Secure Shell (ssh) service which should be running on your machine. By default, most
Red Hat Enterprise Linux installations run the "Secure Shell" service, which allows
clients (using the ssh command) to open shells on ("log in to") remote machines running
the sshd server.

Network servers are processes, just like any other process on the machine, so simply
using the ps command is usually enough to confirm that the sshd daemon is running.

[student@station ~]$ ps aux | grep sshd


root 3763 0.0 0.3 3984 1548 ? Ss 06:38 0:00
/usr/sbin/sshd
student 5238 0.0 0.1 4512 656 pts/4 R+ 06:44 0:00 grep
sshd

Sure enough, /usr/sbin/sshd is running.

In order to confirm that sshd has opened a network socket, we first determine the well
known port for the ssh protocol by grepping it out of the /etc/services file.

[student@station ~]$ grep ssh /etc/services


ssh 22/tcp # SSH Remote Login
Protocol
ssh 22/udp # SSH Remote Login
Protocol
x11-ssh-offset 6010/tcp # SSH X11 forwarding
offset

Ignoring the x11-ssh-offset, we find that "plain ole ssh" has a well known port of 22.
Using the netstat -tuna command, we confirm that port 22 is open.

[student@station ~]$ netstat -tuna | grep :22


tcp 0 0 :::22 :::* LISTEN

If fortunate enough to be the root user, we can include -p to confirm that sshd is the
process which has opened it.

[root@localhost ~]# netstat -tunap | grep :22


tcp 0 0 :::22 :::* LISTEN
3763/sshd

Handling Clients: Forking Servers

So far, we have only witnessed servers in the LISTENing state. Clients have yet to enter
the picture. Focusing on just the sshd service, the following diagram shows the sshd
process, with a pid of 3763, bound to port 22, patiently LISTENing for clients.

Figure 1. A Listening sshd Server


What happens when a client comes along? Let's assume that the user elvis on the host
<hostname>station10.example.com</hostname> successfully uses ssh to connect to the
machine <hostname>station.example.com</hostname>. How does the sshd daemon
handle the connection?

[elvis@staiton10 ~]$ ssh student@station.example.com


student@station.example.com's password:
[student@station ~]$

Most Unix networking daemons implement a "forking server" model. When a client
establishes a connection, the sshd daemon "forks", or creates a new process which is a
(nearly) exact duplicate of itself. The new child process is dedicated to that one
particular client, while the parent process drops the client and returns to just listening to
new clients, as illustrated below.

Figure 2. A Forked sshd Child Handling a Client


The details of this figure can be confirmed by running the netstat command (as root).
Notice the client address now reflects the IP address and port number of the remote ssh
client (192.168.0.10, and 48515). (Complicating matters, netstat is displaying the IPV4
address in IPV6 format. For our purposes, the leading ::ffff: can be ignored.)

[root@localhost ~]# netstat -tunap | grep :22


tcp 0 0 :::22 :::* LISTEN
3763/sshd
tcp 0 0 ::ffff:192.168.0.1:22 ::ffff:192.168.0.10:48515
ESTABLISHED 6879/sshd: student

The fact that the the sshd daemon forked a new child can be confirmed with the ps
command.

[student@station ~]$ ps aux | grep sshd


root 3763 0.0 0.3 3984 1552 ? Ss 06:38 0:00
/usr/sbin/sshd
root 6879 0.0 0.4 6816 2144 ? Ss 08:07 0:00 sshd:
student [priv]
student 6883 0.0 0.4 6816 2208 ? S 08:07 0:00 sshd:
student@pts/5
student 6984 0.0 0.1 3800 648 pts/3 R+ 08:11 0:00 grep
sshd

In fact, the sshd daemon takes the non-standard approach of forking two two child
processes, one which drops root privileges, but we're only going to focus on the one
which manages the client connection (pid 6879).

What would the situation look like if a ssh client now connected from the local machine
using the 127.0.0.1 loopback address?

Figure 3. Connections From the Same Machine

Now the netstat command reflects four connections related to port 22.

[root@localhost ~]# netstat -tunap | grep :22


tcp 0 0 127.0.0.1:48820 127.0.0.1:22
ESTABLISHED 7831/ssh
tcp 0 0 :::22 :::*
LISTEN 3763/sshd
tcp 0 0 ::ffff:192.168.0.1:22
::ffff:192.168.0.1:48515 ESTABLISHED 6879/sshd: student
tcp 0 0 ::ffff:127.0.0.1:22
::ffff:127.0.0.1:48820 ESTABLISHED 7832/sshd: student
The ssh client itself (pid 7831). Notice what's considered the "Local Address" and
"Foreign Address" is inverted for the client.
The original listening daemon (pid 3763).
The first forked child, handling the remote ssh client (pid 6879).
A newly forked child, handling the local ssh client (pid 7832)

Again, the ps command should display a sshd daemon for each client (pid 6879 and
7832), and a listening sshd daemon (pid 3763). (And, as mentioned above, a sshd
daemon for each connection which is not directly related to networking). As a bonus,
we get the local ssh client as well.

[root@localhost ~]# ps aux | grep ssh


root 3763 0.0 0.3 3984 1552 ? Ss 05:16 0:00
/usr/sbin/sshd
root 6879 0.0 0.4 6816 2144 ? Ss 06:11 0:00 sshd:
student [priv]
student 6883 0.0 0.4 6816 2208 ? S 06:11 0:00 sshd:
student@pts/6
student 7831 0.0 0.3 4752 1828 pts/4 S+ 06:11 0:00 ssh
student@127.0.0.1
root 7832 0.0 0.4 6816 2144 ? Ss 06:11 0:00 sshd:
student [priv]
student 7836 0.0 0.4 6816 2208 ? S 06:11 0:00 sshd:
student@pts/7
root 6005 0.0 0.1 5320 656 pts/7 R+ 06:19 0:00 grep
ssh

When the ssh clients close their respective connections, the forked sshd daemons which
are handling their connections die, and we would be left once again with our original
sshd listening daemon, patiently waiting from new clients to come along.

Summary

This lesson was meant to serve as a refresher for basic TCP/IP concepts, and their
implementation on the Linux operating system. We covered a lot of ground, so here's a
quick summary of the main points.

1. The IP protocol, with it's associated IP addresses, serves to route data from one
computer to another.
2. The TCP and UDP protocols, with their associated port numbers, serve to route
data received via the IP protocol to a particular process on a machine.
3. Networking applications are processes like any other process on the machine,
and can be monitored with the ps command.
4. The netstat -tuna command can be used to view a list of open ports on a given
machine.
5. Most Linux networking servers use a "forking" model, where the original server
process merely LISTENs for new connections, while a new child is forked off to
manage each client's ESTABLISHED connection.

Online Exercises

Lab Exercise
Objective: Use the netstat command analyze networking services on your
machine.

Estimated Time: 20 mins.

Specification

1. Use the ssh command to shell into your local machine


(<hostname>localhost</hostname>). Leave the connection open until your lab
has been graded.
2. Use the netstat command to answer the following questions about your
machine. Record the answer as a single integer in the specified file in your
academy user's home directory.

Table 1. Network Related Questions

File Question
listening_sockets
How many ports are open in the LISTENing state? (Count
multiple references to the same port as one port.)
loopback_sockets
How many sockets in the LISTENing state have bound
explicitly to the loopback address?
sshd_port To which port is the sshd server bound?
ssh_port To which port is the ssh client bound?

Deliverables

1. 1. In the home directory of your academy user's account, the files mentioned
above, each of which contains the single word answer to the questions above.
Managing Red Hat Services

Red Hat Enterprise Linux usually manages network applications as services. This
chapter introduces service management, using the vsftpd FTP server as an example.

Key Concepts

Red Hat Enterprise Linux daemons are managed with service scripts found in
/etc/rc.d/init.d/. Daemons managed with these scripts are often referred to
as services.
The simplest way to manage a Red Hat Enterprise Linux service is using the
service command: service service_name status|start|stop|reload|...
Services are most easily configured to start at bootup using chkconfig service
on|off.

Table 1. The <service>vsftpd</service> Service

Package vsftpd
Service <service>vsftpd</service>
Daemon /usr/sbin/vsftpd
Config Files /etc/vsftpd/*, particularly /etc/vsftdp/vsftpd.conf
Logging /var/log/xferlog
Ports 21/tcp (ftp), 20/tcp (ftp-data)

The vsftpd daemon accepts the user <username>anonymous</username>


without authentication, but chroots the user to the /var/ftp directory.
The vsftpd accepts authenticated Linux users, and may chroot them to their
home directories.

Discussion

Managing Red Hat Enterprise Linux Services

Our First Red Hat Service: vsftpd

For it's FTP service, Red Hat Enterprise Linux uses vsftpd (whose name is derived from
"Very Secure File Transfer Protocol Daemon"). As the name implies, the FTP protocol
allows users to copy files from one machine to another.

The vsftpd daemon is a good starting point, because it tends to be one of the simpler
services to configure, allowing us to focus on Red Hat Enterprise Linux's general
techniques for managing daemons, without being distracted by too many details. This
lesson will first focus on the standard technique for installing, starting, and stopping the
<service>vsftpd</service> service. Once these basics are covered, we'll look at some
configuration unique to vsftpd.

In Red Hat Enterprise Linux, when starting network applications for the first time, there
is a general recipe to follow.
1. Install the software if the relevant RPM packages are not already installed.
(Think "rpm or yum".)
2. Start the service using its appropriate service script. (Think "service")
3. Configure the service to start automatically upon reboots. (Think "chkconfig").

We now look at these steps in more detail.

Installing relevant software: rpm and yum

In order to start a network application, we start with an obvious starting point: the
software must be installed. Red Hat Enterprise Linux uses the Red Hat Package
manager, better known as RPM, to manage software. Another Red Hat Academy course
provides the details of using rpm and yum. Here, we merely review a couple of
commands which will server our purposes.

Table 1. Some commonly used RPM commands

Command Effect
rpm -qa List all installed packages by name.
rpm -ql package_name List all of the files owned by the package package_name.
rpm -qi package_name List information about the package package_name.
rpm -ihv Install a package from the package_file_name package
package_file_name file.
yum install Install a package, and any needed dependencies, from a
package_file_name bound YUM repository.

When starting from square one, often the hardest part of configuring a service is
knowing which RPM package provides it. Within this course, we will always make
explicit the relevant package names. Here we go.

The FTP service is provided by the vsftpd package.

You can verify that the vsftpd package is (or is not) installed by querying the package.
If not, assuming your machine has been bound to a yum repository, the package is most
easily installed (by root) using yum.

[root@station ~]# rpm -qi vsftpd


package vsftpd is not installed
[root@station ~]# yum install vsftpd
...
Dependencies Resolved

======================================================================
=======
Package Arch Version Repository
Size
======================================================================
=======
Installing:
vsftpd i386 2.0.5-10.el5 rha-rhel
137 k
Transaction Summary
======================================================================
=======
Install 1 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 137 k


Is this ok [y/N]: y
...

Once installed, another rpm query can be used to list all of the files which are owned by
the package.

[student@station ~]$ rpm -ql vsftpd


/etc/logrotate.d/vsftpd.log
/etc/pam.d/vsftpd
/etc/rc.d/init.d/vsftpd
/etc/vsftpd
/etc/vsftpd/ftpusers
...

Hopefully, these are familiar skills. In future lessons, we will merely mention "the
relevant RPM package is such-and-such. You will want to make sure it's installed".

Starting the Service: service

Most Red Hat Enterprise Linux applications come with reasonable working default
configurations, and the vsftpd daemon is no exception. However, as a security
precaution, most Red Hat Enterprise Linux network services are not started by default.
Instead, an administrator must explicitly start them, or enable the service to be started
by default at bootup.

While an administrator could start the daemon manually just by running the executable
(such as /usr/sbin/vsftpd, more on this later), Red Hat Enterprise Linux wraps most
daemons with convenient to use service scripts. These service scripts are all located in
the /etc/rc.d/init.d directory.

[student@station ~]$ ls /etc/rc.d/init.d/


acpid diskdump lm_sensors pand smb
anacron dund mdmonitor pcmcia snmpd
apmd firstboot mdmpd portmap
snmptrapd
...
cups iptables network rpcidmapd
vsftpd
...

As the file command demonstrates, each of these files is a shell script.

[student@station ~]$ file /etc/rc.d/init.d/*


/etc/rc.d/init.d/acpid: Bourne-Again shell script text
executable
/etc/rc.d/init.d/anacron: Bourne shell script text
executable
/etc/rc.d/init.d/apmd: Bourne shell script text
executable
/etc/rc.d/init.d/atd: Bourne-Again shell script text
executable
/etc/rc.d/init.d/autofs: Bourne-Again shell script text
executable
...

Each of these scripts (which generally should be run as root) expects to be called with a
single argument, one of start, stop, restart, condrestart, or status.

[student@station ~]$ su -
Password:
[root@station ~]# /etc/rc.d/init.d/vsftpd
Usage: /etc/rc.d/init.d/vsftpd {start|stop|restart|condrestart|status}

The use of these service scripts is fairly straightforward. Want to know if the
<service>vsftpd</service> service is running? Check it's status.

[root@station ~]# /etc/rc.d/init.d/vsftpd status


vsftpd is stopped

If you don't yet trust the service scripts, check to see if the vsftpd daemon is running
with the ps command directly.

[root@station ~]# ps aux | grep vsftpd


root 5895 0.0 0.1 3752 704 pts/5 S+ 07:29 0:00 grep
vsftpd

Nothing (except grep).

Want to start the <service>vsftpd</service> service? Call the service script with the
start argument.

[root@station ~]# /etc/rc.d/init.d/vsftpd start


Starting vsftpd for vsftpd: [ OK ]

Want to confirm that the service is running? Check it's status again with the service
script, or search for the vsftpd process directly in the output of ps.

[root@station ~]# /etc/rc.d/init.d/vsftpd status


vsftpd (pid 5949) is running...
[root@station ~]# ps aux |grep vsftpd
root 5949 0.0 0.2 4064 1076 pts/5 S 07:33 0:00
/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
root 5959 0.0 0.1 3756 740 pts/5 S+ 07:33 0:00 grep
vsftpd

In fact, these scripts are so commonly used, that a shortcut command has been
introduced: service. Rather than needing to spell out the /etc/rc.d/init.d/ directory
each time, an administrator can simply use the service command, which interprets it's
first argument as a script to execute out of this directory. Compare the following two
examples.

[root@station ~]# /etc/rc.d/init.d/vsftpd


Usage: /etc/rc.d/init.d/vsftpd {start|stop|restart|condrestart|status}
[root@station ~]# service vsftpd
Usage: /etc/init.d/vsftpd {start|stop|restart|condrestart|status}
[root@station ~]# /etc/rc.d/init.d/vsftpd status
vsftpd (pid 5949) is running...
[root@station ~]# service vsftpd status
vsftpd (pid 5949) is running...

To wrap up, managing services in Red Hat Enterprise Linux is as simple as using the
service command. The following table summarizes what you need to know from this
section.

Table 1. Directly managing services with service

Command Effect
service service_name start Start the service_name service.
service service_name stop Stop the service_name service.
service service_name status Determine if the service_name service is active.
service service_name restart Restart the service_name service.

In fact, the hardest part of starting or stopping a service is generally knowing the name
of the service, or if it's installed or not. That's why it's important to know about the
/etc/rc.d/init.d directory. A quick ls in this directory will usually refresh one's
memory.

Starting Services Automatically at Bootup: chkconfig

The service command will start a service directly, but if the machine is rebooted, the
service will not be restarted by default. In order to start a service by default at bootup,
the service must be "chkconfig-ed" on.

The chkconfig command, if called without arguments, will dump a usage message.

[root@station ~]# chkconfig


chkconfig version 1.3.20 - Copyright (C) 1997-2000 Red Hat, Inc.
This may be freely redistributed under the terms of the GNU Public
License.

usage: chkconfig --list [name]


chkconfig --add <name>
chkconfig --del <name>
chkconfig [--level <levels>] <name> <on|off|reset>

Usually, administrators only need to know the following three uses.

[root@station ~]# chkconfig --list vsftpd


vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@station ~]# chkconfig vsftpd on
[root@station ~]# chkconfig vsftpd off

To fully understand the chkconfig command would require a full discussion of the Unix
concept of runlevels, which is beyond the scope of the current course. (The topic is fully
covered in RHA130). For now, just know that which services are started automatically
and which are not are determined by what runlevel a machine is in, and that the default
runlevel of a "fully booted" machine in Red Hat Enterprise Linux is either runlevel 3 or
runlevel 5.

The chkconfig --list service_name command displays if a particular service will be


started in a particular runlevel. By default, the <service>vsftpd</service> service, like
most Red Hat Enterprise Linux network services, is disabled by default. Notice the "all
off" status for <service>vsftpd</service> reported by the chkconfig command.

[root@station ~]# chkconfig --list vsftpd


vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

By "chkconfiging" a service on, starting the service will become part of the normal
bootup process.

[root@station ~]# chkconfig vsftpd on

To confirm, use chkconfig --list service_name again.

[root@station ~]# chkconfig --list vsftpd


vsftpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Notice that for the "standard" runlevels, including runlevels 3 and 5, the
<service>vsftpd</service> service is now "on", and therefore will be started by default
at bootup. To disable the service, just chkconfig it back off.

[root@station ~]# chkconfig vsftpd off

Again, the commands you need to know from this section are summarized in the
following table.

Table 1. Starting Services by Default with chkconfig

Command Effect
chkconfig service_name on Configure a service to be started by default at bootup.
chkconfig service_name Configure a service to not be started by default at
off bootup.
chkconfig --list List the current bootup configuration of a service (is it
service_name "on" or "off").

Configuring vsftpd

Using the skills learned in the previous sections, the steps to install and start the
<service>vsftpd</service> service are easy. For a machine that does not even have the
vsftpd package installed, the following three commands are all that are needed.

[root@station ~]# yum install -y vsftpd


...
======================================================================
=======
Package Arch Version Repository
Size
======================================================================
=======
Installing:
vsftpd i386 2.0.5-10.el5 rha-rhel
137 k
...
[root@station ~]# service vsftpd start
Starting vsftpd for vsftpd: [ OK ]
[root@station ~]# chkconfig vsftpd on

With the server up and running, we first introduce some FTP clients, and then turn to
the job of configuring the server.

FTP Clients: ftp, lftp, Nautilus, and Almost Any Web Browser

Several different applications in Red Hat Enterprise Linux act as FTP clients, including
the following.

ftp: This no-frills command line client allows users to connect to FTP servers
either anonymously or as a "real" user, and get (download) and put (upload)
files.
lftp: The lftp command line client includes many features for both interactive
and scripted use, including tab completion, mirroring, and much more. lftp is the
favorite command line FTP client of many Linux users.
Nautilus: By selecting Connect to Server... from any Nautilus browser's File
menu, the standard GNOME file browser can browse FTP servers as easily as
the local filesystem. Transferring files from an FTP server is as easy as dragging
icons from one window to another.
firefox: Simply by entering URL's that begin ftp:// (as opposed to http://), the
firefox web browser, like most any modern web browser, can also act as an
anonymous FTP client.

By default in Red Hat Enterprise Linux, the FTP server receives connections for
anonymous users. Most modern FTP clients will assume an anonymous connection, if
no username is provided. With the older ftp client, however, the user anonymous must
be specified. Although prompted for a password, the password is ignored.

[elvis@elsewhere ~]# ftp station


Connected to station.example.com.
220 (vsFTPd 2.0.1)
...
Name (station:elvis): anonymous
331 Please specify the password.
Password: type anything
230 Login successful.
...
ftp>

Configuring vsftpd: /etc/vsftpd/vsftpd.conf


Most Linux network applications use configuration files, which are usually human
readable, and can be edited using a simple text editor. In Red Hat Enterprise Linux,
configuration files are almost always found in the /etc directory. When learning a new
service, one approach to determining the relevant configuration file is to use rpm to list
all of the files for the relevant package, and grep for "etc".

[student@station ~]$ rpm -ql vsftpd | grep etc


/etc/logrotate.d/vsftpd.log
/etc/pam.d/vsftpd
/etc/rc.d/init.d/vsftpd
/etc/vsftpd
/etc/vsftpd/ftpusers
/etc/vsftpd/user_list
/etc/vsftpd/vsftpd.conf
/etc/vsftpd/vsftpd_conf_migrate.sh

Several files are found, but the file named most directly for the application,
vsftpd.conf, is probably a good guess. Of course, one can take the fun of guessing out
of it by examining the "man" page (with man vsftpd.)

VSFTPD(8) BSD System Manager's Manual


VSFTPD(8)

NAME
vsftpd - Very Secure FTP Daemon

SYNOPSIS
vsftpd [configuration file]

DESCRIPTION
vsftpd is the Very Secure File Transfer Protocol Daemon. The
server can
be launched via a "super-server" such as inetd(8) or xinetd(8).
Alterna-

...

OPTIONS
An optional [configuration file] may be given on the command
line. This
configuration files has to be owned by root. The default
configuration
file is /etc/vsftpd/vsftpd.conf.

SEE ALSO
vsftpd.conf(5)
...

As the synopsis implies, the vsftpd daemon is somewhat non-standard, in that it doesn't
support any command line switches. Instead, the vsftpd.conf configuration file is
essentially the only way to configure the daemon. The SEE ALSO section implies that
the configuration file is documented in it's own man page.

Configuration File Syntax

Example 1. The vsftd.conf Configuration File


# Example config file /etc/vsftpd/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample
file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd
options.
# Please read the vsftpd.conf.5 manual page to get a full idea of
vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment
this out).
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Default umask for local users is 077. You may wish to change this to
022,
...

Skimming the first few paragraphs of the vsftpd.conf man page (with the command
man vsftpd.conf), we find the following "rules" about the format of the file.

1. All lines which begin with a "#" character are comments, meaning they will be
ignored by the daemon. (Although the man page does not mention it, blank lines
are considered comments as well, and are ignored).
2. Lines that do not start with "#" will be considered directives, and must have the
form directive=value. Particularly important, there should be no spaces on
either side of the equals sign.
3. Each directive will accept one of a boolean ("YES" or "NO"), a number, or a
string.
4. Each directive has a default value, which will be used if the directive is not
listed, or it is "commented out".

This list of rules that define how a configuration file must look, but not necessarily what
anything does, is called the syntax of the file. Part of learning how to configure a
particular daemon is to learn its configuration file's syntax.

The above rules are typical of most Red Hat Enterprise Linux applications (with the
possible exception of "no spaces around the equals", which is a bit picky). Fortunately,
Red Hat Enterprise Linux almost always provides a default configuration file, from
which a file's syntax can usually be easily inferred.

Editing a Configuration File

Configuration files are usually edited using a simple text editor. As a security concern,
however, most network configuration files are only editable (and often only readable)
by the <username>root</username> user.
As an example of a configuration change, notice the greeting which greets the FTP
client in the following transcript.

[student@station ~]$ ftp localhost


Connected to localhost.localdomain.
220 (vsFTPd 2.0.3)
530 Please login with USER and PASS.
...
Name (localhost:student):
Before the ftp client even specifies a user, the vsftpd server issues a line
introducing itself a vsFTPd version 2.0.3. Such a greeting is often called a banner.

For security reasons, administrators often choose not to display the version of an
application to unauthenticated users. Or, the administrator might just want to make their
service more friendly. Searching through the vsftpd.conf man page for the text
banner, we can find the following directive.

ftpd_banner

This string option allows you to override the greeting banner


displayed by vsftpd when a connection first comes in.

Default: (none - default vsftpd banner is displayed)

Before editing the /etc/vsftpd/vsftpd.conf file directly, it is a good idea to make a


backup, such as copying the file to vsftpd.conf.orig. Then, using a text editor, the
following line can be added.

ftpd_banner=Welcome to the Red Hat Academy FTP Service

Where in the file should the line go? For the vsftpd daemon, the short answer is it
doesn't matter. There is an art, however, to configuring files so that someone coming
along 3 months after you can follow what you've done. Possible choices would be the
following.

1. Search for a similar line, or the same line which has been commented out. Put
your edit directly beneath that line.
2. Place all of your edits in one place at the bottom of the file.

But again, there's no one right answer.

Restarting the Service

After editing the configuration file, the vsftpd daemon must somehow be notified of the
change. Usually, this is done by using the service command to restart the service.

[root@station ~]# service vsftpd restart


Shutting down vsftpd: [ OK ]
Starting vsftpd for vsftpd: [ OK ]

Now, clients connecting to the FTP server see the new banner.
[student@station ~]# ftp localhost
Connected to localhost.localdomain.
220 Welcome to The Red Hat Academy FTP Service
530 Please login with USER and PASS.
...
Name (localhost:student):

Local vs. Anonymous Users

By default, the vsftpd daemon allows local users to connect to the FTP server, provided
that they can provide the correct password (the same password a user would supply
when logging into the machine).

The vsftpd daemon also allows a client to connect as the user


<username>anonymous</username> (or, equivalently, the user
<username>ftp</username>, which is a lot easier to spell and type). A little oddly, these
so called "anonymous users" are asked to provide a password, though any password will
be accepted. (Many FTP clients which connect anonymously, such web browsers, hide
this fact by supplying a password without ever prompting the user.)

The following directives can be used to control if real and/or anonymous users are
allowed.

Table 1. Allowed Users vsftpd Directives

Compiled RHEL
Directive Type Use
Default Default
Allow anonymous
anonymous_enable boolean YES YES
users
local_enable boolean NO YES Allow local users

Chrooting the vsftpd Daemon

Because there is no way to identify anonymous FTP clients, they are considered a
security risk. As a protection, the vsftpd daemon, when it forks a new child daemon to
serve an anonymous FTP client, takes the precaution of chrooting the child daemon
(pronounced "cha-root"). It will take a little bit to explain the term chroot.

Hopefully, it's familiar knowledge that every process carries around a reference to it's
current working directory. This directory is used as the starting point whenever the
process refers to a file using relative references (i.e., a filename that doesn't start with /,
such as .bash_profile). Processes can also easily change their current working
directory. (This is what the bash shell does when it cd's to a new directory.)

Less well known is the fact that every process carries around a reference to its root
directory. This directory is used as a starting point when referring to files using an
absolute reference (i.e, a filename that starts with /, such as /etc/passwd). Almost
invariably, a process's root directory is the root directory, /.
By chrooting a process, however, its concept of the root directory / can be mapped to
some other directory in the filesystem. The vsftpd daemon, when handling an
anonymous client, chroots to the /var/ftp directory. For example, what a normal
process would call the directory /var/ftp/pub would be refereed to as /pub by a
vsftpd daemon which has been chrooted to /var/ftp. The verb chroot stems from the
programmer's system call of the same name, which derives from change root directory.
The new root directory is sometimes referred to as the processes "chroot jail".

Figure 1. Perspective of a Process "Chroot"ed to /var/ftp

Only processes running as the <username>root</username> user can chroot, and it is


considered one of the strongest protections that can be put on a process. After a process
has been chrooted, it has no way of accessing files outside of it's new root directory. [1]

Anonymous FTP clients will always be chrooted to /var/ftp. The following directives
can be used to configure the vsftpd daemon to chroot for local users as well. What
directory do you think a local user would be chrooted to? (The answer will become
obvious in the following exercises).

Table 1. Chroot vsftpd Directives

Compiled RHEL
Directive Type Use
Default Default
Local users are chrooted to their
chroot_local_user boolean NO NO
home directories.
Enable a list of users to chroot or
chroot_list_enable boolean NO NO not chroot, depending on setting of
chroot_local_user.
Filename of a file containing a list
chroot_list_file string (none) (none)
of usernames
Exercises

Lab Exercise
Objective: Configuring the vsftpd Daemon

Estimated Time: 30 mins.

Specification

1. Ensure that the vsftpd package is installed. If not, install the package using the
YUM repository.
2. Use the service and chkconfig commands to start the service immediately, and
configure the system to start the daemon upon reboots.
3. Configure the banner to include the text "Red Hat Academy".
4. Configure the daemon so that real users are allowed to connect, but are chroot'ed
to their home directory.

If configured correctly, you should be able to reproduce a transcript similar to the


following.

[root@station ~]# ftp localhost


Connected to localhost.localdomain.
220 Welcome to Red Hat Academy FTP service.
...
Name (localhost:root): elvis
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /
250 Directory successfully changed.
ftp> ls
227 Entering Passive Mode (127,0,0,1,142,184)
150 Here comes the directory listing.
drwxr-xr-x 2 502 502 4096 Aug 07 16:19 Desktop
226 Directory send OK.

Deliverables

1. 1. A running vsftpd daemon.


2. The <service>vsftpd</service> service should be configured to start
automatically on bootup.
3. The banner should contain the text Red Hat Academy.
4. The user <username>elvis</username> should be able to log in, but be
chrooted to his home directory.

Note that in the act of grading this lab, <username>elvis</username>'s password


will be reset.
Managing xinetd Controlled Daemons

Key Concepts

The xinetd meta-daemon binds to various ports and listens for connections on
behalf of other network applications. Upon receiving a connection, the client is
handed off to the appropriate program.
Applications register with xinetd using configuration files found in
/etc/xinetd.d/.
The xinetd daemon is managed as the <service>xinetd</service> service.
Registered applications are most easily enabled and disabled using chkconfig
xinetd_managed_service on|off

In Red Hat Enterprise Linux 5, the xinetd packages is no longer installed by


default. Discussion

The History of xinetd

The xinetd daemon is a meta-daemon whose current design is to a large extent derived
from historical concerns. In earlier days of Unix, a system running network applications
would need to start a daemon for each network application, and have that daemon bind
to a well known port, listening for connections from clients. For example, the ftpd
daemon [1] might be bound to port 21, the telnetd daemon might be bound to port 23,
and so on.

Figure 1. Before xinetd

For early Unix systems, this approach was wasteful of resources, particularly memory.
The ftpd daemon might be used only once a day, but would need to stay running,
listening for new client connections.

To overcome this problem, a listening specialist was created: the xinetd daemon
(although in earlier days, it was called just inetd). Rather than starting independent
"standalone" servers, services can register with xinetd. The xinetd daemon then binds
to multiple listening ports, one for each service that registered with it.
Figure 2. Using xinetd to Listen for ftpd, telnetd, and pop3d

Not every service has to choose to use xinetd; they can chose to remain standalone
daemons. Many applications can be used either way, but must be configured
appropriately. [2]

When a client requests a new connection, the xinetd daemon doesn't follow the normal
"forking server" model, but instead forks and execs an application appropriate to the
port requested by the client connection. In the figure below, xinetd has started the
in.telnetd application to handle a new client request on port 23.

Figure 3. xinetd Handing a Connection to in.telnetd

Notice the subtle naming convention that is often (but not always) followed. Network
applications which run standalone are generally named serviced (such as httpd, sshd,
etc.). Services which are traditionally put under xinetd control are often named
in.serviced (such as in.fingerd and in.tftpd).

When using Red Hat Enterprise Linux, the choice to run a service standalone or under
xinetd control has already been made, based on the default configuration. Because
memory is not as precious as it used to be, most applications opt for the simplicity of
standalone services. Only a few older, simpler services now use xinetd. However, there
are still a few niche cases where xinetd is the right solution.

How does an application register itself with the xinetd daemon? The answer is found in
the /etc/xinetd.d directory.

Configuring xinetd: /etc/xinetd.conf and /etc/xinetd.d/

In Red Hat Enterprise Linux, if an application would like to register itself with the
xinetd meta-daemon, it drops a configuration file in the /etc/xinetd.d directory.

[root@station ~]# ls /etc/xinetd.d/


chargen-dgram daytime-stream echo-stream klogin tcpmux-
server
chargen-stream discard-dgram eklogin krb5-telnet tftp
cvs discard-stream ekrb5-telnet kshell time-dgram
daytime-dgram echo-dgram gssftp rsync time-stream

As a typical example, we'll examine the configuration file for the


<service>tftp</service> ("Trivial FTP") service, which is provided by the tftp-server.
TFTP is a minimal file server that is sometimes used to deliver kernel images to diskless
clients. (Don't worry if you don't know what that means). In the following, we discuss
only a few relevant configuration parameters.

[root@station ~]# cat /etc/xinetd.d/tftp


# default: off
# description: The tftp server serves files using the trivial file
transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware
printers, \
# and to start the installation process for some operating
systems.
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = yes
per_source = 11
cps = 100 2
flags = IPv4
}
The service name tells xinetd to which port it should bind. The actual port number
for the <service>tftp</service> service can be found in the /etc/services
configuration file.
The xinetd daemon "hands off" newly connecting clients to the application
specified by the server directive.
Any command line arguments for the newly started server are specified using the
server_args directive.
If disable is "yes", then the configuration file is ignored, and xinetd does not bind
to the relevant port.

Here's the kicker - because "disable = yes", the configuration file is ignored. Notice that
this is the default state for almost all configuration files found in the /etc/xinetd.d
directory.

[root@station ~]# grep disable /etc/xinetd.d/*


/etc/xinetd.d/chargen: disable = yes
/etc/xinetd.d/chargen-udp: disable = yes
/etc/xinetd.d/cups-lpd: disable = yes
/etc/xinetd.d/daytime: disable = yes
...

How is a service registered? If an administrator wanted to work hard, she could edit a
/etc/xinetd.d configuration file with an editor, setting "disable = no", and restart the
xinetd daemon, which is managed as the <service>xinetd</service> service: service
xinetd restart. But there's an easier way: chkconfig.

Enabling xinetd Managed Applications: chkconfig

Running chkconfig --list, two types of services are found in the resulting output.
The top portion of the output refers to standalone services, and reflects the runlevel in
which services will be started automatically (as you should be well aware from a
previous lesson).

[root@station ~]# chkconfig --list


acpid 0:off 1:off 2:off 3:on 4:on 5:on 6:off
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
apmd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
...

Towards the bottom of the output, however, chkconfig shifts gears, and lists xinetd
managed services.

...
portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off
isdn 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xinetd based services:
daytime: off
klogin: off
chargen-udp: off
krb5-telnet: off
...
tftp: off
echo: off
chargen: off

(If you are not seeing this, you might need to install the xinetd package).

Unlike standalone services, which have runlevel specific configuration, xinetd


controlled services have a simple on/off. How are xinetd controlled services enabled?
chkconfig. Before running chkconfig, the tftpd daemon is disabled, the default
configuration for most Red Hat Enterprise Linux network applications.
[root@station ~]$ grep disable /etc/xinetd.d/tftp
disable = yes

After running chkconfig, however, the /etc/xinetd.d/tftp file has been rewritten.

[root@station ~]$ chkconfig tftp on


[root@station ~]$ grep disable /etc/xinetd.d/tftp
disable = no

The next time xinetd is restarted, the tftpd will be enabled. If we take a look at
/var/log/messages, however, we find that chkconfig performed an additional step.

[root@station ~]$ tail /var/log/messages


...
Jul 7 11:09:17 station xinetd: xinetd -HUP succeeded
Jul 7 11:09:17 station xinetd[4923]: Starting reconfiguration
Jul 7 11:09:17 station xinetd[4923]: Swapping defaults
Jul 7 11:09:17 station xinetd[2187]: Starting reconfiguration
Jul 7 11:09:17 station xinetd[2187]: Swapping defaults
Jul 7 11:09:17 station xinetd[2187]: Reconfigured: new=1 old=0
dropped=0 (services)

Not only does chkconfig set the default state, but it also kicks (reloads) the xinetd
daemon, so that the change is implemented immediately.

[root@station ~]$ tftp localhost


tftp>

This is an important nuance. When managing standalone services, chkconfig only


changes the runlevel defaults. Any currently running daemons are not affected. When
managing xinetd controlled applications, however, chkconfig changes both the boot
time behavior and current configuration.

Remember the xinetd itself is a standalone service, and would need to be running for
changes to have immediate effect.

[root@station ~]$ service xinetd status


xinetd (pid 4923) is running...

Summary

Managing xinetd controlled services is easy. First, you need to make sure that the
xinetd packages is installed, and the <service>xinetd</service> service is running.

[root@station ~]$ service xinetd status


xinetd (pid 4923) is running...

That being the case, xinetd controlled services are managed by two simple commands.

[root@station ~]$ chkconfig service_name on


[root@station ~]$ chkconfig service_name off
What about all of those other interesting parameters found in a xinetd configuration
file? We focus on more advanced behavior of xinetd in another course, and a detailed
discussion will be deferred until then.

Exercises

Lab Exercise
Objective: Manage a xinetd Controlled Service

Estimated Time: 30 mins.

Specification

1. Ensure that the xinetd, tftp, and tftp-server packages are installed on your
system, using YUM to install any that are not.
2. Ensure that the xinetd service is running, and is configured to start automatically
at bootup.
3. Enable the <service>tftp</service> server. This service allows unauthenticated
clients to download files from the /tftpboot directory.
4. To confirm the service, place a copy of your /etc/services file in the
/tftpboot directory. You should now be able to download the file using the
tftp client.
5. [root@station ~]$ tftp localhost -c get services /tmp/services
6. By default, the in.tftpd daemon does not log transfers. Reading the in.tftpd(8)
man page, however, you discover that the -v command line switch causes more
verbose logging. Configure the service so that transfers are logged.

If configured correctly (including remembering to restart


<service>xinetd</service> so that changes take effect), you should find evidence
of your transfers in /var/log/messages.

Deliverables

1. 1. The <service>xinetd</service> service, currently running, and configured to


be started by default in the standard runlevels.
2. An operating tftp server.
3. The tftp server should log transfers to the file /var/log/messages.
SELinux: Secure Linux

Key Concepts

Red Hat Enterprise Linux ships with a security mechanism implemented by the
kernel, known as SELinux.
SELinux potentially casts every process into a SELinux domain, and every
resource (such as files) into a SELinux security context. A SELinux policy then
specifies which processes can access which resources.
The SELinux policy is implemented at a low level, and is in general not
configurable by an end system administrator.
The SELinux policy that ships with Red Hat Enterprise Linux 4 is know as the
targeted policy, and only effects selected networking daemons.
The system can boot into one of three SELinux related states, enforcing,
permissive, or disabled.
The default state can be set by editing the /etc/sysconfig/selinux
configuration file.
The SELinux state can be immediately switched from enforcing to permissive
and back using the setenforce command.
SELinux domains and contexts can be examined by adding the new -Z
command line switch to the traditional ps and ls commands.
The SELinux context of a file can be modified using the new chcon command.

Discussion

Introduction to SELinux ("Secure Linux")

As a feature of Red Hat Enterprise Linux, a fundamentally new approach to Linux (and
Unix) security has been introduced: SELinux. The result of an NSA development effort
targeted at securing computer infrastructure, SELinux allows administrators to define
highly customizable security policies which are enforced by the Linux kernel as it
performs its normal operations.

Using SELinux, processes can be cast into a particular SELinux domain, and every
resource on the system (such as files, networking sockets, system calls, and so on) can
be assigned a particular SELinux context. A SELinux policy loaded into the kernel
(usually as part of the system bootup process) then defines which process domains may
access which resource contexts.

The design of any security mechanism must be flexible enough to be useful, but simple
enough for an administrator to confidently implement the policy. As comparatively
simple as the standard Unix model of file ownerships and permissions is, it's probably
the most common source of administrative headaches - either because a file was left too
exposed, or not exposed enough.

SELinux falls way to the flexible and complex side of the simple-flexible spectrum. As
an administrator, you should never need to write or modify your own SELinux policy.
Instead, in Red Hat Enterprise Linux 4, your SELinux related decisions should be
limited to to the following.

1. Do I want to enable SELinux?


2. If enabled, do I want SELinux in the permissive or enforcing state?
3. What SELinux context do I want to assign to a particular file?

The targeted SELinux Policy

As mentioned above, designing an appropriate SELinux policy is a complex task. In


principle, one of several different policies could be chosen as a system boots. In
practice, Red Hat Enterprise Linux 4 only ships with a single SELinux policy, dubbed
the targeted policy. The targeted policy only affects the small selection of more
commonly used network applications listed below.

dhcpd
httpd
mysqld
named
nscd
ntpd
portmap
postgres
snmpd
squid
syslogd

Unless you are managing files which are used by one of these applications, the targeted
SELinux policy should not hinder interactive uses of a Red Hat Enterprise Linux
workstation. Many of these applications are covered in this course, however, so we will
be encountering SELinux.

Enabling SELinux: /etc/sysconfig/selinux, setenforce, and getenforce

Upon bootup, a Red Hat Enterprise Linux 4 machine enters one of three SELinux states.

enforcing: Any action that would violate the SELinux policy is prohibited, and
the violation is logged as a kernel message.
permissive: Any action that would violate the SELinux policy generates a
warning (in the form of a kernel message), but the action is allowed to continue.
disabled.

The default state is specified as part of the installation process, and recorded in the file
/etc/sysconfig/selinux. The default SELinux state can be changed by editing this
file, or the state can be changed immediately using the setenforce command.

The /etc/sysconfig/selinux configuration file

This simple configuration file is used upon bootup to determine the SELinux state and
policy.
[student@station ~]$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
The default SELinux state can be set using SELINUX. Changes will apply on the
next boot.
The policy can be chosen using SELINUXTYPE. As mentioned, the only relevant
policy for Red Hat Enterprise Linux 4 is the targeted policy.

The setenforce and getenforce commands

Assuming SELinux is not disabled, the SELinux state can also be immediately switched
from enforcing to permissive (and back) using the setenforce command. The command
expects a single argument, either a 0 or 1, which respond to the permissive and
enforcing states, respectively.

The following command switches SELinux to the permissive state.

[root@station ~]# setenforce 0


[root@station ~]# getenforce
Permissive

The following command switches SELinux to the enforcing state.

[root@station ~]# setenforce 1


[root@station ~]# getenforce
Enforcing

Note that getenforce merely displays the current state. The setenforce command takes
effect immediately, but does not change the default state if the machine is rebooted.
These commands are often helpful in debugging SELinux configuration problems.

Viewing SELinux contexts: ps -Z and ls -Z

As mentioned, each process belongs to a SELinux domain, and each file can be
assigned a SELinux context. The relevant domains and contexts can be viewed by using
the (new) -Z command line switch with the conventional ls and ps commands.

The following command can be used to view the SELinux domain of all running
processes.

[student@station ~]$ ps ax -Z
LABEL PID TTY STAT TIME COMMAND
user_u:system_r:unconfined_t 1 ? S 0:00 init [5]
user_u:system_r:unconfined_t 2 ? SN 0:00
[ksoftirqd/0]
user_u:system_r:unconfined_t 3 ? S< 0:00 [events/0]
user_u:system_r:unconfined_t 4 ? S< 0:00 [khelper]

...
user_u:system_r:syslogd_t 2251 ? Ss 0:00 syslogd -m
0
user_u:system_r:unconfined_t 2255 ? Ss 0:00 klogd -x
user_u:system_r:portmap_t 2277 ? Ss 0:00 portmap
root:system_r:httpd_t 3955 ? Ss 0:00
/usr/sbin/httpd
root:system_r:httpd_t 3956 ? S 0:00
/usr/sbin/httpd
...
user_u:system_r:unconfined_t 2973 pts/1 Ss 0:00 bash
user_u:system_r:unconfined_t 2994 pts/2 Ss+ 0:00 bash
user_u:system_r:unconfined_t 2995 pts/3 Ss+ 0:00 bash
user_u:system_r:unconfined_t 2996 pts/4 Ss+ 0:00 bash
user_u:system_r:unconfined_t 3135 pts/5 R+ 0:00 ps ax -Z

Notice that, with the exception of the above mentioned network service daemons, the
domain type is unconfined_t, implying that the process is not restrained by any SELinux
context. In particular, user interactive shells, and processes started by user interactive
shells (with the above mentioned exceptions) are not effected by the SELinux policy.

The SELinux context of files can be seen by adding -Z to the ls command. In the
following example, the -a switch is only necessary because the fairly recently created
home directory has not yet collected any "nonhidden" files.

[student@station ~]$ ls -a -Z
drwxr-xr-x student student root:object_r:file_t .
drwxr-xr-x root root ..
-rw------- student student user_u:object_r:file_t
.bash_history
-rw-r--r-- student student root:object_r:file_t
.bash_logout
-rw-r--r-- student student root:object_r:file_t
.bash_profile
-rw-r--r-- student student root:object_r:file_t .bashrc
drwx------ student student user_u:object_r:file_t .gconf
drwx------ student student user_u:object_r:file_t .gconfd
drwx------ student student user_u:object_r:file_t .gnome2
drwx------ student student user_u:object_r:file_t
.gnome2_private
-rw-r--r-- student student root:object_r:file_t .gtkrc
drwxrwxr-x student student user_u:object_r:file_t
.mozilla
-rw-r--r-- student student root:object_r:file_t .zshrc

Note that all of these files have the generic type file_t. Some were created by the user
<username>student</username> as she, for example, fired up the Firefox web browser,
others were created automatically when the account was added (before the student ever
logged on). The root and user_u portions of the SELinux context denote if the file was
created by the user, or created by root.

Exploration of the filesystem with the ls -Z command will produce a large number of
SELinux types associated with various files. (The /etc and /var directories are
particularly interesting).
Realize that knowing the SELinux domain of a process, or the SELinux context of a
file, is not enough. You also need to know what the current policy dictates.
Unfortunately, with the current set of SELinux tools, examining the current policy is not
easy, and the effects of the SELinux policy are generally only discovered when
something tries to violate it.

Monitoring SELinux violations: /var/log/messages

Whenever a SELinux violation occurs, a kernel message detailing the problem is


generated. By default, these kernel messages are logged to the /var/log/messages
file. If, when configuring or managing one of the above mentioned network services,
something goes awry, checking the /var/log/messages file for SELinux violations is
a reasonable first step.

Examples of SELinux violation kernel messages are found in the following excerpt
from a /var/log/messages file.

Jul 2 01:02:30 station4 kernel: audit(1122958950.735:0): avc: denied


{ read }
for pid=15842 exe=/usr/bin/ssh name=mounts dev=proc ino=1038221328
scontext=ro
ot:system_r:httpd_sys_script_t
tcontext=root:system_r:httpd_sys_script_t tclass=
file
Jul 2 01:02:30 station4 kernel: audit(1122958950.808:0): avc: denied
{ getatt
r } for pid=15842 exe=/usr/bin/ssh path=/etc/krb5.conf dev=hda3
ino=609458 scon
text=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:krb5_conf_t tcl
ass=file
The expression in brackets specifies what action caused the violation. In this case
(getattr), a process was looking up file attributes, such as the file's owner and
permissions.
The proceeding two tokens (pid=15842 and exe=/usr/bin/ssh) identify the process
that caused the violation.
The proceeding three tokens (path=/etc/krb5.conf, dev=hda3, and ino=609458)
identify the file that was being accessed, where dev refers to the partition
containing the file, and ino is the inode number of the file within that filesystem.
The proceeding two tokens identify the SELinux contexts of the process and the
target file.

By examining the log message, once can infer that processes in the
root:system_r:httpd_sys_script_t domain are not allowed to examine the metadata of
files in the system_u:object_r:krb5_conf_t context.

Changing the SELinux Context of a File: chcon

If the targeted SELinux policy is causing a problem, an administrator generally has two
options.
1. Disable SELinux.
2. Change the SELinux context of the file which is causing the violation.

We've already discussed how to disable SELinux (recall the setenforce command and
the /etc/sysconfig/selinux configuration file). Just as a file's owner, group, or mode
(permissions) are changed with chown, chgrp, and chmod (respectively), a file's
SELinux security context is changed with chcon.

Table 1. Common Command Line Switches for the chcon Command

Switch Effect
-R, --recursive change files and directories recursively
Use the security context of FILE to define the
--reference=FILE
resulting context.
-u, --user=USER; -r, --role=ROLE; set USER, ROLE, or TYPE component of the file's
-t, --type=TYPE security context, respectively.

Most commonly, an administrator would like a problematic file to take on the context of
a "known good" file. As an example, the following command would cause
/etc/named.conf to inherit the SELinux security context of
/etc/named.conf.rpmorig.

[root@station ~]# chcon --reference=/etc/named.conf.orig


/etc/named.conf

SELinux Booleans

The SELinux policy has been introduced as something that cannot be changed. This has
been a bit of a simplification. SELinux policies can support simple on/off parameters
which can be adjusted dynamically, referred to as SELinux booleans. Booleans can be
examined and manipulated with the getsebool and setsebool commands, respectively.

As an example, the getsebool can list the state of an individual SELinux boolean, or,
more commonly, all available SELinux booleans with the -a command line switch.

[root@station ~]# getsebool -a


allow_ypbind --> active
dhcpd_disable_trans --> inactive
httpd_disable_trans --> inactive
httpd_enable_cgi --> active
httpd_enable_homedirs --> active
...
syslogd_disable_trans --> inactive
winbind_disable_trans --> inactive
ypbind_disable_trans --> inactive

A boolean can be manipulated with the setsebool command. For example, the following
sequences can be used to switch off SELinux policy for the syslogd daemon.

[root@station ~]# getsebool syslogd_disable_trans


syslogd_disable_trans --> inactive
[root@station ~]# setsebool syslogd_disable_trans 1
[root@station ~]# getsebool syslogd_disable_trans
syslogd_disable_trans --> active

A bit awkwardly, setting the boolean to the active state is considered disabling, because
the boolean is cast in the negative. By default, changes made with setsebool are
dynamic, and are lost upon reboots. However, the default state of the booleans is
recorded in the file /etc/selinux/policy_name/booleans.

[root@station ~]# cat /etc/selinux/targeted/booleans


httpd_enable_cgi=1
httpd_enable_homedirs=1
httpd_ssi_exec=1
named_write_master_zones=0
httpd_unified=1
httpd_tty_comm=0

By adding the -P command line switch, changes made with the setsebool command will
not only take effect immediately, but also be stored in this file, and will therefore persist
across reboots.

[root@station ~]# setsebool -P syslogd_disable_trans 1


[root@station ~]# cat /etc/selinux/targeted/booleans
allow_ypbind=1
dhcpd_disable_trans=0
...
syslogd_disable_trans=1
winbind_disable_trans=0
ypbind_disable_trans=0

Most of the SELinux booleans supported by the targeted policy can be used to enable or
disable SELinux constraints for the simpler services, such as portmap, syslogd, and
dhcpd. For the Apache web server and BIND name server, however, more refined
options are available.

Managing SELinux with system-config-securitylevel

The SELinux configuration can be managed completely with command-line utilities


like getenforce, setenforce, getsebool, and setsebool commands, and the
/etc/sysconfig/selinux configuration file. The capabilities of these commands have
also been incorporated into the system-config-securitylevel and system-config-selinux
graphical applications.

While the system-config-securitylevel application is used to configure iptables Firewall


policies in Red Hat Enterprise Linux 3, in Red Hat Enterprise Linux 4, it gained a new
SELinux panel. In Red Hat Enterprise Linux 5, most of the functionality was placed in
the system-config-selinux utility.

Figure 1. Configuring SELinux Policy with system-config-selinux


From this panel, SELinux can be enabled or disable entirely (which requires a reboot to
take effect), the state can be switched from enforcing to permissive, one of several
policies could be chosen. Red Hat Enterprise Linux 5 installs only one policy--targeted.
However, Red Hat Enterprise Linux 5 ships with two others. SELinux booleans can be
adjusted, and port or file types can be defined. Any changes made through this utility
persist across reboots.

Online Exercises

Lab Exercise
Objective: Set appropriate SELinux contexts for a files

Estimated Time: 20 mins.

Specification
1. Your system should be in the SELinux enforcing state. If SELinux is not
enabled, edit the /etc/sysconfig/selinux file appropriately, and reboot your
machine. If SELinux is enabled but in the permissive state, simply use
setenforce. Either way, you should be able to reproduce the following
command.
2. [root@station4 html]# getenforce
3. Enforcing
4. Set the appropriate SELinux boolean to disable SELinux policy for the DHCP
daemon. Make sure that your change will persist across reboots.
5. In this lab, you will publish files using your web server. If you have not yet
started your web server (and you probably haven't), start it using the service
command.
6. [root@station8 ~]# service httpd start
7. Starting httpd: [
OK ]
8. [root@station8 ~]# service httpd status
9. httpd (pid 15611 15610 15609 15608 15607 15606 15605 15604
15601) is running...
10. You would like to publish a copy of your /var/log/dmesg file. (Don't worry if
you don't know what it is yet.) Copy the file to the /var/www/html directory,
and observe the ownerships and permissions. You should be able to view the
contents by pointing any browser to http://localhost/dmesg.
11. You would also like to publish a copy of the /var/log/rpmpkgs file, but you
realize this file is updated nightly. In order to automatically publish the updates
as well, hard link the file into the /var/www/html directory.
12. [root@station4 html]# ln /var/log/rpmpkgs /var/www/html/
13. [root@station4 html]# ls -i /var/log/rpmpkgs
/var/www/html/rpmpkgs
14. 180333 /var/log/rpmpkgs 180333 /var/www/html/rpmpkgs
15. [root@station8 html]# ll /var/www/html/rpmpkgs
16. -rw-r--r-- 2 root root 23076 Jul 2 04:04
/var/www/html/rpmpkgs

Although the file /var/www/html/rpmpkgs is readable by all, you should still


not be able to access http://localhost/rpmpkgs from a web browser. Why?

17. Use the chcon command, referencing the "working" file


/var/www/html/dmesg, to assign /var/www/html/rpmpkgs the appropriate
SELinux security context. If completed successfully, you should be able to
access http://localhost/rpmpkgs from a web browser.

Use ls -Z to observe the SELinux context of /var/log/rpmpkgs. Why did it


change as well?

Deliverables

1. 1. The system is in the SELinux enforcing state.


2. The SELinux boolean disabling policy for the DHCP daemon is active, and
defaults to active across reboots.
3. A web browser can access http://localhost/dmesg.
4. A web browser can access http://localhost/rpmpkgs.
5. The files /var/log/rpmpkgs and /var/www/html/rpmpkgs have the same
inode number (i.e., they are hard links of the same file).

Clean Up

After you have completed the exercise, restore your system to the desired SELinux
state, remove /var/www/html/rpmpkgs, and restore the appropriate context on
/var/log/rpmpkgs with the following command.

[root@station8 ~]# chcon --reference /var/log /var/log/rpmpkgs

Das könnte Ihnen auch gefallen