Documente Academic
Documente Profesional
Documente Cultură
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).
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.
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.
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.
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).
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.
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?
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.
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 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.
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
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.
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.
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.
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.
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.
If fortunate enough to be the root user, we can include -p to confirm that sshd is the
process which has opened it.
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.
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.
The fact that the the sshd daemon forked a new child can be confirmed with the ps
command.
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?
Now the netstat command reflects four connections related to port 22.
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.
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.
Specification
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.
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)
Discussion
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").
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.
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.
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.
======================================================================
=======
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)
Once installed, another rpm query can be used to list all of the files which are owned by
the package.
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".
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.
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.
If you don't yet trust the service scripts, check to see if the vsftpd daemon is running
with the ps command directly.
Want to start the <service>vsftpd</service> service? Call the service script with the
start argument.
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.
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.
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.
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.
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.
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.
By "chkconfiging" a service on, starting the service will become part of the normal
bootup process.
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.
Again, the commands you need to know from this section are summarized in the
following table.
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.
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.
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.)
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.
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.
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.
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
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.
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.
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):
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 following directives can be used to control if real and/or anonymous users are
allowed.
Compiled RHEL
Directive Type Use
Default Default
Allow anonymous
anonymous_enable boolean YES YES
users
local_enable boolean NO YES Allow local users
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".
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).
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
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.
Deliverables
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
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.
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.
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.
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.
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.
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.
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).
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).
After running chkconfig, however, the /etc/xinetd.d/tftp file has been rewritten.
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.
Not only does chkconfig set the default state, but it also kicks (reloads) the xinetd
daemon, so that the change is implemented immediately.
Remember the xinetd itself is a standalone service, and would need to be running for
changes to have immediate effect.
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.
That being the case, xinetd controlled services are managed by two simple commands.
Exercises
Lab Exercise
Objective: Manage a xinetd Controlled Service
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.
Deliverables
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
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.
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.
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.
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.
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.
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.
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.
Examples of SELinux violation kernel messages are found in the following excerpt
from a /var/log/messages 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.
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.
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.
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.
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.
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.
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.
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.
Online Exercises
Lab Exercise
Objective: Set appropriate SELinux contexts for a files
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
Deliverables
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.