Tải bản đầy đủ
[Chapter 12] 12.5 Access Control

[Chapter 12] 12.5 Access Control

Tải bản đầy đủ

[Chapter 12] 12.5 Access Control

Now when inetd receives a request for fingerd, it starts tcpd instead. tcpd then logs the fingerd request,
checks the access control information, and, if permitted, starts the real finger daemon to handle the request.
Make a similar change for every service you want to place under access control. Good candidates for access
control are ftpd, tftpd, telnetd, rshd, rlogind, rexecd, and fingerd. Obviously, tcpd cannot control access
for daemons that are not started by inetd, such as sendmail and NFS.
Using the wrapper on our Slackware 96 Linux system is even easier. There is no need to download and
install the tcpd software. It comes as an integral part of the Linux release. You don't even have to edit the
/etc/inetd.conf file because the sixth field of the entries in that file already point to the tcpd program, as
shown below:
finger

stream

tcp

nowait

nobody

/usr/sbin/tcpd

in.fingerd -w

12.5.1.1 tcpd access control files
The information tcpd uses to control access is in two files, /etc/hosts.allow and /etc/hosts.deny. Each file's
function is obvious from its name. hosts.allow contains the list of hosts that are allowed to access the
network's services, and hosts.deny contains the list of hosts that are denied access. If the files are not found,
tcpd permits every host to have access and simply logs the access request. Therefore, if you only want to
monitor access, don't create these two files.
If the files are found, tcpd checks the hosts.allow file first, followed by the hosts.deny file. It stops as soon
as it finds a match for the host and the service in question. Therefore, access granted by hosts.allow cannot
be overridden by hosts.deny.
The format of entries in both files is the same:
service-list : host-list [: shell-command]
The service-list is a list of network services, separated by commas. These are the services to which access is
being granted (hosts.allow) or denied (hosts.deny). Each service is identified by the process name used in the
seventh field of the /etc/inetd.conf entry. This is simply the name that immediately follows the path to tcpd
in inetd.conf. (See Chapter 5, Basic Configuration , for a description of the arguments field in the
/etc/inetd.conf entry.)
Again, let's use finger as an example. We changed its inetd.conf entry to read:
finger

stream

tcp

nowait

nobody

/usr/etc/tcpd

in.fingerd

Therefore, we would use in.fingerd as the service name in a hosts.allow or hosts.deny file.
The host-list is a comma-separated list of hostnames, domain names, Internet addresses, or network
numbers. The systems listed in the host-list are granted access (hosts.allow) or denied access (hosts.deny) to
the services specified in the service-list. A hostname or an Internet address matches an individual host. For
example, peanut is a hostname and 172.16.12.2 is an Internet address. Both match a particular host. A
domain name matches every host within that domain; e.g., .nuts.com matches almond.nuts.com,
file:///C|/mynapster/Downloads/warez/tcpip/ch12_05.htm (2 of 4) [2001-10-15 09:18:58]

[Chapter 12] 12.5 Access Control

peanut.nuts.com, pecan.nuts.com, and any other hosts in the domain. When specified in a tcpd access
control list, domain names always start with a dot (.). A network number matches every IP address within
that network's address space. For example, 172.16. matches 172.16.12.1, 172.16.12.2, 172.16.5.1, and any
other address that begins with 172.16. Network addresses in a tcpd access control list always end with a dot
(.).
A completed hosts.allow entry that grants FTP and telnet access to all hosts in the nuts.com domain is shown
below:
ftpd,telnetd : .nuts.com
Two special keywords can be used in hosts.allow and hosts.deny entries. The keyword ALL can be used in
the service-list to match all network services, and in the host-list to match all hostnames and addresses. The
second keyword, LOCAL, can be used only in the host-list. It matches all local hostnames. tcpd considers a
hostname "local" if it contains no embedded dots. Therefore, the hostname peanut would match on LOCAL,
but the hostname peanut.nuts.com would not match. The following entry affects all services and all local
hosts:
ALL : LOCAL
The final field that can be used in these entries is the optional shell-command field. The shell command
specified in this field will execute whenever a match occurs. The command is executed in addition to the
normal functions of the access list match. In other words, if a match occurs for an entry that has an optional
shell command, tcpd logs the access, grants or denies access to the service, and then passes the shell
command to the shell for execution.
A more complete example of how tcpd is used will help you understand these entries. First, assume that you
wish to allow every host in your local domain (nuts.com) to have access to all services on your system, but
you want to deny access to every service to all other hosts. Make an entry in /etc/hosts.allow to permit
access to everything by everyone in the local domain:
ALL : LOCAL, .nuts.com
The keyword ALL in the services-list indicates that this rule applies to all network services. The colon (:)
separates the services-list from the host-list. The keyword LOCAL indicates that all local hostnames without
a domain extension are acceptable, and that the .nuts.com string indicates that all hostnames that have the
nuts.com domain name extensions are also acceptable. To prevent access from everyone else, make an entry
in the /etc/hosts.deny file:
ALL : ALL
Every system that does not match the entry in /etc/hosts.allow is passed on to /etc/hosts.deny. Here the entry
denies access to everyone, regardless of what service they are asking for. Remember, even with ALL in the
services-list field, only services started by inetd, and only those services whose entries in inetd.conf have
been edited to invoke tcpd, are affected. This does not provide security for any other service.

file:///C|/mynapster/Downloads/warez/tcpip/ch12_05.htm (3 of 4) [2001-10-15 09:18:58]

[Chapter 12] 12.5 Access Control

Previous: 12.4 Security
Monitoring
12.4 Security Monitoring

TCP/IP Network
Administration
Book Index

Next: 12.6 Encryption
12.6 Encryption

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch12_05.htm (4 of 4) [2001-10-15 09:18:58]

[Chapter 12] 12.6 Encryption

Previous: 12.5 Access
Control

Chapter 12
Network Security

Next: 12.7 Firewalls

12.6 Encryption
Encryption is a technique for limiting access to the data carried on the network. Encryption encodes
the data in a form that can be read only by systems that have the "key" to the encoding scheme. The
original text, called the "clear text," is encrypted using an encryption device (hardware or software)
and an encryption key. This produces encoded text, which is called the cipher. To recreate the "clear
text," the cipher must be decrypted using the same type of encryption device and an appropriate key.
Largely because of spy novels and World War II movies, encryption is one of the first things that
people think of when they think of security. However, encryption is not always applicable to network
security. Encrypting data for transmission across a network requires that the same encryption
equipment, or software, be used at both ends of the data exchange. Unless you control both ends of
the network and can ensure that the same encryption device is available, it is difficult to use end-toend data encryption. For this reason, encryption is most commonly used to exchange data in
individual applications where the software at both ends of the network is defined by a single vendor.
For example, a Web server and a Web browser from the same vendor use the same encryption.
Encrypting all types of data is limited to places where the entire system is under the control of a single
authority, such as military networks, private networks, individual systems, or when the individuals at
both ends of the communication can reach personal agreement on the encryption technique and key.
What is needed to make encryption truly useful in a global network are universally recognized
encryption standards and a trusted infrastructure to support those standards. Public-key encryption is
the technology that will make encryption an important security technology for an open global network
like the Internet. Public-key systems encode the clear-text with a key that is widely known and
publicly available, but the cipher can only be decoded back to clear-text with a secret key. This means
that Dan can look up Kristin's public key in a trusted database and use it to encode a message to her
that no one else can read. Even though everyone on the Internet has access to the public key, only
Kristin can decrypt the message using her secret key. Kristin can then look up Dan's public key to
encrypt her reply. This encrypted communication takes place without Dan or Kristin ever divulging
their secret keys. However, to ensure that the keys have not been tampered with, public-key
cryptography requires a trusted system for distributing public keys. And because the encrypting key is
available to everyone, it requires a digital signature system to authenticate that a message is really
from whom it purports to be from.
Government and industry are working on the standards and infrastructure for public-key
file:///C|/mynapster/Downloads/warez/tcpip/ch12_06.htm (1 of 2) [2001-10-15 09:18:59]

[Chapter 12] 12.6 Encryption

cryptography. The type of encryption used in the examples in this section is symmetric encryption. It
requires that the same encryption technique and the same secret key is used for both encrypting and
decrypting the message. It does not rely on public keys, digital signatures, or a widely accepted
infrastructure, but its usefulness is limited. Truly effective public-key cryptography must wait for the
creation of a trusted public-key infrastructure.

12.6.1 When is symmetric encryption useful?
Before using encryption, decide why you want to encrypt the data, whether the data should be
protected with encryption, and whether the data should even be stored on a networked computer
system.
A few valid reasons for encrypting data are:





To prevent casual browsers from viewing sensitive data files
To prevent accidental disclosure of sensitive data
To prevent privileged users (e.g., system administrators) from viewing private data files
To complicate matters for intruders who attempt to search through a system's files

Encryption is not a substitute for good computer security. Encryption can protect sensitive or personal
information from casual snooping, but it should never be the sole means of protecting critical
information. Encryption systems can be broken, and encrypted data can be deleted or corrupted just
like any other data. So don't let encryption lull you into a false sense of security. Some information is
so sensitive or critical that it should not be stored on a networked computer system, even if it is
encrypted. Encryption is only a small part of a complete security system. To find out more about file
encryption, see PGP: Pretty Good Privacy, by Simson Garfinkel (O'Reilly & Associates). It provides
a book-length treatment of PGP, an encryption program used for files and electronic mail.

Previous: 12.5 Access
Control
12.5 Access Control

TCP/IP Network
Administration
Book Index

Next: 12.7 Firewalls
12.7 Firewalls

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch12_06.htm (2 of 2) [2001-10-15 09:18:59]