LPI Linux Certification in a Nutshell (68 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
With the original
inetd
service, the
servers that were managed rarely had any advanced access control options
of their own. These services were often remnants of the early days of
the Internet, when systems were a little more trusted than they are
today. Examples of these mostly deprecated services are
finger
,
echo
,
daytime
,
telnet
,
shell
,
exec
, and
talk
, to name a few.
xinetd
added some more advanced controls, but both
inetd
and
xinetd
are able to utilize the TCP_WRAPPER
service to aid in access control.
In order to utilize TCP_WRAPPERS,
inetd
needs
to call the user-space program
/usr/bin/tcpd
with an
argument of the desired service, in order to “wrap” that service in the
access control. This is not necessary with
xinetd
,
as the
xinetd
binary has TCP_WRAPPERS support
built-in, by nature of its link with the
libwrap
library. You can see this with the
/usr/bin/ldd
command:
#ldd /usr/sbin/xinetdlinux-gate.so.1 => (0x0012d000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0012e000)libwrap.so.0 => /lib/libwrap.so.0 (0x00149000)libnsl.so.1 => /lib/libnsl.so.1 (0x00151000)
libm.so.6 => /lib/libm.so.6 (0x0016a000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00193000)
libc.so.6 => /lib/libc.so.6 (0x001c5000)
libdl.so.2 => /lib/libdl.so.2 (0x0031e000)
/lib/ld-linux.so.2 (0x00110000)
Other services also have native TCP_WRAPPERS support by nature of
their links to
libwrap.so
, including
/usr/sbin/sshd
and
/usr/sbin/sendmail
. You can run a simple shell
script to determine what binaries in
/usr/sbin/
are
linked against
libwrap.so
:
#cd /usr/sbin#for file in *>{>if [ -f $file ]; then>result=`ldd $file | grep -c libwrap`>if [ "$result" -gt "0" ]; then>echo "/usr/sbin/$file is linked to libwrap.so">fi>fi>}/usr/sbin/exportfs is linked to libwrap.so
/usr/sbin/gdm-binary is linked to libwrap.so
/usr/sbin/mailstats is linked to libwrap.so
/usr/sbin/makemap is linked to libwrap.so
/usr/sbin/praliases is linked to libwrap.so
/usr/sbin/rpcinfo is linked to libwrap.so
/usr/sbin/rpc.mountd is linked to libwrap.so
/usr/sbin/rpc.rquotad is linked to libwrap.so
/usr/sbin/sendmail is linked to libwrap.so
/usr/sbin/sendmail.sendmail is linked to libwrap.so
/usr/sbin/smrsh is linked to libwrap.so
/usr/sbin/snmpd is linked to libwrap.so
/usr/sbin/snmptrapd is linked to libwrap.so
/usr/sbin/sshd is linked to libwrap.so
/usr/sbin/stunnel is linked to libwrap.so
/usr/sbin/vsftpd is linked to libwrap.so
/usr/sbin/xinetd is linked to libwrap.so
TCP_WRAPPERS is configured in two files,
/etc/hosts.allow
and
/etc/hosts.deny
. These files contain rules
that govern either all services or individual services. Like a
firewall, it is usually good practice to adopt either a “block
everything, only open what you need” mentality or an “open everything,
block only what you don’t need” mentality when it comes to
TCP_WRAPPERS. Here is an example of a sample configuration that blocks
everything by default, but opens up access for a few services:
#more /etc/hosts.denyALL: ALL
#more /etc/hosts.allowsshd: ALL EXCEPT 192.168.1.10
vsftpd: 192.168.1.0/24 EXCEPT 192.168.1.10
The TCP_WRAPPERS files are read in real time by the servers that
support them, so changes made to these files go into effect
immediately. The example configuration denies all access by default,
and then opens it up specifically for the
sshd
and
vsftpd
services. Users from everywhere except
the system 192.168.1.10 are allowed to connect to the
sshd
service, and all users on the
192.168.1.0/24 network, except for 192.168.1.10, are allowed to
connect to
vsftpd
.
Let’s assume that we have
xinetd
configured
and running, with the
imap
configuration as
listed earlier. In addition, the
/etc/hosts.deny
and
/etc/hosts.allow
files are the same as our
example. Our server system has an IP address of 10.0.0.1, and our
client system has an IP address of 10.0.0.112. When an attempt is made
to connect to the
imap
server on 10.0.0.1 from
10.0.0.112, the connection times out. We can see the details in
/var/log/messages
on the
server:
# tail /var/log/messagesJan 26 15:22:42 server xinetd[15959]: xinetd Version 2.3.14 started with \
libwrap loadavg labelednetworking options compiled in.
Jan 26 15:22:42 server xinetd[15959]: Started working: 1 available service
Jan 26 15:23:23 server xinetd[15959]: START: imap pid=15975 \
from=::ffff:10.0.0.112
Jan 26 15:23:28 server xinetd[15959]: EXIT: imap status=1 pid=15975 \
duration=5(sec)
Jan 26 15:26:30 server xinetd[15959]: START: imap pid=16035 \
from=::ffff:10.0.0.112
Jan 26 15:26:30 server xinetd[16035]: libwrap refused connection to \
imap (libwrap=imapd) from ::ffff:10.0.0.112
Jan 26 15:26:30 server xinetd[16035]: FAIL: imap libwrap \
from=::ffff:10.0.0.112
Jan 26 15:26:30 server xinetd[15959]: EXIT: imap status=0 \
pid=16035 duration=0(sec)
We can see from the
syslog
messages that
our attempt to connect to
imapd
was denied. In
order to enable this access, we need to add the following line to
/etc/hosts.allow
:
imapd: ALL
or, if we want to limit it somewhat:
imapd: 10.0.0.0/24
After this change, we try our
imap
connection from the client again, and we get a connection. Logfiles on
the server show our success:
# tail /var/log/messagesJan 26 15:34:37 fileserv xinetd[15959]: START: imap pid=16083 \
from=::ffff:10.0.0.112
Jan 26 15:34:42 fileserv xinetd[15959]: EXIT: imap status=1 \
pid=16083 duration=5(sec)
Remember that you need to do more than simply configure
/etc/hosts.deny
and
/etc/hosts.allow
to secure your system.
Many popular applications, such as the Apache web server, do not link
against
libwrap.so
, so they do not honor the
entries you place in these configuration files.
Also, it is more and more common on network-enabled Linux
machines (especially those connected directly to the Internet) to not
run
inetd
or
xinetd
at all.
If there are services that need to be run, such as
imapd
or
ftpd
, they are
often run as standalone daemons, largely because the lack of necessary
memory in a server is not as much of a concern as it was years ago,
and many of these newer services have built-in access controls that
rival the ability of TCP_WRAPPERS. So if you are in doubt about
whether or not you need a service that is handled by
xinetd
, you are probably safe to disable it,
rather than having to worry about securing a service that might not be
necessary.
On the Exam
Although the
inetd
service has largely been
replaced by
xinetd
, be familiar with the syntax
of the
inetd.conf
file, because
there is a good chance you will encounter questions about it on the
LPI exams. The syntax of the
/etc/hosts.deny
and
/etc/hosts.allow
files also will be a
focus.
Data with Encryption (Topic 110.3)
This Topic focuses on the methods used to secure Linux servers
and workstations. Securing servers includes two basics steps: communicating
between servers in a secure way, and then encrypting data on the servers
themselves. The LPI knows that SSH is the most common method for
communicating securely between servers. Therefore, the topic is covered
fairly extensively on the exam and in this chapter.
SSH is used for many more purposes than simply communicating across
insecure networks; it is used throughout the industry to configure remote
systems and tunnel all sorts of traffic, from X Windows to email and
FTP.
The second part of securing a server—making sure that stored data is
properly
encrypted
—can be handled in
myriad ways. However, the LPI recognizes that GNU Privacy Guard (GPG) has
become the standard. Before we take a deep look at how SSH and GPG work,
make sure that you understand this LPI Objective’s description
perfectly:
- Objective 3: Securing Data with
Encryption The candidate should be able to use public key techniques to
secure data and communication. The key knowledge areas are:Perform basic OpenSSH 2 client configuration and
usage.Understand the role of OpenSSH 2 server host keys.
Perform basic GnuPG configuration and usage.
Understand SSH port tunnels (including X11 tunnels).
Following is the list of the used files, terms, and
utilities:ssh
ssh-keygen
ssh-agent
ssh-add
~/.ssh/id_rsa and
id_rsa.pub~/.ssh/id_dsa and
id_dsa.pub/etc/ssh/ssh_host_rsa_key
and
/etc/ssh/ssh_host_rsa_key.pub/etc/ssh/ssh_host_dsa_key
and
/etc/ssh/ssh_host_dsa_key.pub~/.ssh/authorized_keys
and
~/.ssh/authorized_keys2/etc/ssh_known_hosts
gpg
~/.gnupg/*
As you can see from this Objective, you need to know more than how
to issue a couple of commands on a remote system. You also have to
understand how to configure systems for public key encryption and how to
use common SSH and encryption commands, including GPG.
SSH, also known as Secure Shell, is a replacement for the
obsolete
telnet
command and
rsh/rlogin/rcp
suite. The primary use for SSH is to
conduct encrypted shell sessions to remote hosts. However, it can also be
used to copy files and to tunnel other protocols.
SSH is a server/client protocol offering
sshd
as the server and the
ssh
and
scp
commands as the
client. The client connects to the server, they establish an encrypted
session, and then the server demands authentication before finally logging
in the client.
The
ssh
command can be used either to execute a
single command and return to the local terminal, or to establish a remote
session that acts and feels just like logging into the remote system. In
this regard,
ssh
acts like the obsolete
rsh
command; used to log in,
ssh
acts like
rlogin
and
telnet
.
The
scp
command copies files and directories to
or from a remote system, acting like the obsolete
rcp
command.
In addition to simple login sessions and file copying, SSH can also
provide transparent port forwarding, and as an extension of this, X
authentication and forwarding. When you have an
SSH session, you can start an X client on the remote
machine, and the X Window System protocol will travel encrypted over your
connection and display on your local machine without the need for settings
such asDISPLAY=foo:0or the
xhost
or
xauth
commands.
The implementation of SSH generally used on Linux systems is
OpenSSH
.
OpenSSH may or may not be installed on your system by default.
When the SSH server (
sshd
) runs for the first time,
it generates a host key for your machine. This key will serve to
authenticate your host in subsequent SSH sessions. Then you will
typically want to create SSH authentication keys for your own personal
account, as well as the root account. After that, as the administrator
you should review the configuration of
sshd
, to see
that you are comfortable with it.
The standard place for the central configuration of OpenSSH is the
/etc/ssh
directory. Here you will find the server
configuration in
sshd_config
and default client
configuration in
ssh_config
. Here are some
highlights from the server configuration as installed on Debian:
# What ports, IPs and protocols we listen for
Port 22
Protocol 2
Port 22 is the standard port for the SSH protocol. Version 2 of
the protocol is the most secure, whereas version 1 has some flaws that
were hard to overcome. It is recommended to accept only version 2 now.
To support both versions, put2, 1on
theProtocolline of the
configuration file.
On the Exam
SSH uses TCP port 22. Be prepared to know the preferred version
of SSH (2) as well. The second version of SSH is preferable, because
version 1 has long been known to have a weak encryption algorithm that
has been broken.
# Authentication:
PermitRootLogin yes
PubkeyAuthentication yes
# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
# (for protocol version 2)
HostbasedAuthentication no
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
OpenSSH ignores the host operating system setting for permitting
root logins on nonconsole terminals. Instead, OpenSSH has its own
setting inPermitRootLogin. ThePubkeyAuthenticationsetting allows
or denies login authentication based purely on
public-key cryptography. You can trust this as far as
you can trust the host on which the private parts of those keys are
stored (unless they are protected by passphrases, in which case you
can trust them a bit further).
IgnoreRhostsallows or denies
the old-fashioned—and very insecure—
rhosts authentication, used by the
rsh/rlogin/rcp
suite. This way of authenticating
connections is not only insecure, but also made obsolete by public-key
authentication. If you combine rhosts authentication with public-key
authentication of the connecting host, on the other hand, it’s
immediately a lot more secure—but host keys cannot be protected by
passphrases. Use of the rhosts authentication is still not
recommended, but in some settings it is appropriate, andHostbasedAuthenticationenables it.
PasswordAuthenticationallows
or denies authentication by the old-fashioned passwords read and
stored by rhosts authentication. This requires that your users
exercise good password maintenance, as with all other password-based
authentication schemes.
X11Forwarding yes
If X11 forwarding is enabled on the server and your client
requests it (using the-Xoption),
the client and server will forward traffic from a port on the server
side to yourDISPLAY. The server
sets the remoteDISPLAYto the
local port that
sshd
uses to transfer X Window
System traffic to your local screen, as well as to accept input from
your local devices. To secure this forwarding activity, the server
will install an
xauth
authentication token that it
will enforce for all new connections. This port forwarding and extra
authentication, which we’ll return to, makes OpenSSH a very versatile
remote terminal program.