LPI Linux Certification in a Nutshell (67 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
lsof
lsof[options] [names]
lsof
lists open files. Since
everything in Linux is a file, this tool can tell you a fantastic
amount of information about your running system. It is primarily
used to tell what processes have what files open, but it can also be
used to view TCP and UDP connection information, among other
things.
- -c
x Only show files that are open by processes whose
executable starts with the character(s) specified byx.- -i
x Instead of showing open files, show sockets whose
Internet address isx. Ifxis not specified, show all IP
connections. This is functionally equivalent to
netstat –anp
.- -u
username Show only the files that
usernamehas open.- -P
Do not convert port numbers to port names (for example,
show25instead ofsmtp).
The
lsof
command is often used to
determine what processes have files open on removable media so they
can be terminated, allowing the media to be unmounted:
#pwd/public#umount /publicumount: /public: device is busy
#lsof | grep"/public"
smbd 17728 adamh cwd DIR 8,65 8192 5 /public
bash 21712 root cwd DIR 8,65 8192 5 /public
lsof 21841 root cwd DIR 8,65 8192 5 /public
grep 21842 root cwd DIR 8,65 8192 5 /public
lsof 21843 root cwd DIR 8,65 8192 5 /public
This shows us that the
smbd
process
(controlled by user
adamh
) and a
bash
,
lsof
, and
grep
process all have the file handle for the
directory
/public
open. Now we’ll change
directories and run
lsof
again:
#cd /#lsof | grep"/public"
smbd 17728 adamh cwd DIR 8,65 8192 5 /public
We see now that only
smdb
has a file open
on the
/public
directory.
In this example, we’ll see how
lsof
can
be used to determine what connections exist between a machine and a
remote host. Our machine in this case has an IP address of 10.0.0.1
and is running the Samba daemon (
smbd
). The
remote machine at 10.0.0.104 is connected to the Samba
daemon
:
#lsof -P [email protected]COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
smbd 1329 root 5u IPv4 252713 TCP 10.0.0.1:139->\
10.0.0.104:1568 (ESTABLISHED)
The machine at 10.0.0.104 is connected to TCP port 139 on
10.0.0.1, and is communicating with the processes named
smbd
, which has a PID of 1329.
On the Exam
The
lsof
command is an important tool
for any good system administrator to have in his arsenal. Be
prepared to answer questions about its general usage, and be
familiar with common options, including viewing socket information
and files open by process name and username.
Security (Topic 110.2)
This chapter describes the practical steps one needs to take to begin
to secure a Linux system. The important thing to remember regarding security
is that it is a process, not a destination. Maintaining a secure system is a
job that is never complete. This chapter covers the second objective of
Topic 110:
- Objective 2: Set Up Host Security
Candidates should know how to set up a basic level of host
security. Weight: 3.
As mentioned previously, the key to good host security is
knowledge. A good system administrator knows at all times what is
happening on systems he manages, and has processes in place to tell him
when things stray from the norm.
Previous chapters have covered the topics of shadow passwords,
knowledge of the
/proc
filesystem,
maintaining startup services in
/etc/rc.d
, and other areas of host-based
security. This chapter will finish this topic by discussing the
inetd
and
xinetd
services, and their role in system
security.
Modern Linux systems are often asked to perform many
functions. Because of the broad appeal of Linux, its use is in
everything from firewalls to set-top boxes. Because of this, there are
many network services that are commonly seen on a Linux system. These
services oftentimes do not see constant use, but need to be active and
available when the need arises. Some examples of these important but
often seldom used services are
ftp
,
finger
,
telnet
,
imap
, and
pop3
.
You may notice that these examples all represent network services
that are considered relatively “old” (at least in terms of modern day
computing). This is essentially true. Years ago, when hardware was more
expensive and harder to come by, the amount of system resources,
especially memory, that each process consumed was of great importance.
The problem was that administrators wanted to consolidate a lot of their
network services on one Linux machine, but were running into memory
limitations. The solution was to come up with a listening service, or
“super-server,” that handled incoming connections and started the
correct networking service to handle them. Thus the
inetd
service was born.
The
inetd
service has two important
characteristics: It is a single process that can listen on multiple
ports for incoming connections, starting the appropriate service when a
connection comes in and connecting the inbound connection with the
service
. Also,
inetd
supports a sophisticated security scheme for
allowing and disallowing access to these “simpler” networking services,
many of which don’t have advanced access controls built into them. So
the creation of
inetd
solved two problems: limited
memory was conserved, and administrators gained a finer level of control
over what systems or networks could access their services.
The main configuration file for
inetd
is
/etc/inetd.conf
. An example looks
like this:
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols.
#
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat
#talk dgram udp wait root /usr/sbin/tcpd in.talkd
#ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp wait nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers." Do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
#
#finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
#
# Authentication
#
#auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
#
# End of inetd.conf
Like most Linux configuration files, a line starting with a#symbol denotes a comment. In this
example, only the
ftp
,
telnet
, and
imap
services
are active. Each line of the file describes a unique service and is
made up of seven sections, described in
Table 23-1
.
Table 23-1. Fields in /etc/inetd.conf
Field | Name | Description |
|---|---|---|
1 | Service name | The name of the service, which must |
2 | Socket type | One of |
3 | Protocol | One of the following:
|
4 | Connection options |
The
|
5 | User | What user account the service should |
6 | Server | Full path to the service that |
7 | Server | Command-line arguments (if any) that |
Using this table as a guide, if we want to enable the
imap
service in our
inetd
configuration but limit
imap
to a maximum of 10
concurrent connections and prevent more than 5 concurrent connections
from a single IP address, the line would look like this:
imap stream tcp nowait/10/0/5 root /usr/sbin/tcpd imapd
Notice that we’re not actually starting the
imapd
service, but instead the server
/usr/sbin/tcpd
with an argument of
imapd
. This is the TCP_WRAPPERS service, which is
described later in this chapter.
The real advantage of
inetd
comes into play
only when you have many services enabled, thus maximizing the amount
of memory you are saving by not running all of these little-used
services all the time, listening for connections.
The original
inetd
service is
seldom seen in more recent Linux distributions. It has been replaced
with
xinetd
, the Extended Internet Daemon.
xinetd
improves upon the original goals of
inetd
by increasing the logging and access
control ability around the managed services, in addition to adding
defense mechanisms to protect against attacks, such as port scanners
or denial of service.
The
xinetd
configuration file is
/etc/xinetd.conf
, but most services are
configured as individual files in the directory
/etc/xinetd.d
. This makes adding and
removing
services
much easier
for a distribution’s package management utility. The
/etc/xinetd.conf
file contains global
configuration options, as seen in this example:
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.
defaults
{
# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#
# enabled =
# disabled =
# Define general logging characteristics.
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT
# Define access restriction defaults
#
# no_access =
# only_from =
# max_load = 0
cps = 50 10
instances = 50
per_source = 10
# Address and networking defaults
#
# bind =
# mdns = yes
v6only = no
# setup environmental attributes
#
# passenv =
groups = yes
umask = 002
# Generally, banners are not used. This sets up their global defaults
#
# banner =
# banner_fail =
# banner_success =
}
includedir /etc/xinetd.d
As you can see,
xinetd
offers some more
advanced configuration options, such as
cps
(connections per second) and the ability to set the
umask
for files created by the managed services.
Here is the example
imap
configuration file at
/etc/xinetd.d/imap
:
service imap
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/imapd
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
}
Table 23-2
describes the different popular configuration options available in
these service files. For a complete list of options, consult the
manpage for
xinetd.conf
.
Table 23-2. Popular fields in
/etc/xinetd.d/servicename
Field name | Description |
|---|---|
id | Name of the service. |
flags | Common flags are:
|
disable | Boolean option determining whether |
socket_type |
|
protocol | Must be a valid protocol listed in |
wait | Normally, TCP services have wait set |
user | Username the service runs |
group | Group the service runs |
instances | The number of services that can run |
nice | Server priority (nice |
server | Full path to the server program that |
server_args | Command-line arguments passed to the |
only_from | Allows you to restrict access by IP |
no_access | Deny access from this IP address, |
access_times | Determines what hours of the day |
log_type | Options are SYSLOG or |
log_on_success | What variables will be logged on a |
log_on_failure | What variables will be logged on a |
port | What port |
bind | What IP address |
per_source | Maximum number of connections from a |
max_load | After the one-minute load average of |
Once the
disable = no
option is set in our
/etc/xinetd.d/imap
file and the
xinetd
service is restarted, we can use the
netstat
command to verify that
xinetd
is ready for incoming
imap
connections:
# netstat --tcp -anp | grep ":143"
tcp 0 0 :::143 :::* LISTEN 15959/xinetd
