لطفا منتظر باشید ...
Using inetd
Normally, a server runs and ties itself to a specific port (a resource identified by protocol type and a number
between 1 and 65,535). Incoming requests are directed to specific ports
associated with particular server types. For instance, Simple Mail Transfer
Protocol (SMTP) mail servers conventionally use TCP port 25, and Hypertext
Transfer Protocol (HTTP) servers (Web servers) normally use TCP port 80.The inetd
program is one of two common super servers for
Linux. These are servers that function as intermediaries; instead of running
the target server itself, the computer runs the super server, which links itself
to the ports used by all of the servers it needs to handle. Then, when a
connection is made to one of those ports, the super server launches the target
server and lets it handle the data transfer. This has two advantages over
running a server directly. First, the memory load is reduced; a super server
consumes little RAM compared to the servers it handles, particularly if it
handles many servers. Second, the super server can filter incoming requests
based on various criteria, which can improve your system's security. The
drawback is that it takes time for the super server to launch the target
server, so the time to connect to a server may be increased, although usually
only by a second or two. As a general rule, it's good to use super servers for
small or seldom-used servers, whereas big and frequently used servers should be
run directly.
The
/etc/inetd.conf File Format
You can configure inetd
through the /etc/inetd.conf
file. Aside from comments (lines that begin with a pound sign, # , that inetd
ignores), inetd.conf consists of
a series of lines, each of which defines a single server. A sample line
resembles the following: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Each line consists of a series of fields, which are separated
by spaces or tabs. The meaning of each field is as follows: Server name The first field is
the name of the server protocol, as recorded in /etc/services . In the case of the preceding example, the
server protocol name is telnet ,
and if you check /etc/services ,
you'll see that this name is associated with 23/tcp in
other words, TCP port 23. There must be an entry in /etc/services in order for inetd
to handle a server. For this reason, you may need to edit /etc/services if you want inetd to handle some unusual server. In
most cases, though, /etc/services
has the appropriate entries already. Socket type The second field
relates the network socket type used by the protocol. Possible values are stream , dgram ,
raw , rdm , and seqpacket . Protocol type The third field
is the name of the protocol type, which in this context means a low-level
network stack protocol such as TCP or UDP. Possible protocol values appear in /etc/protocols , but the most common values
are tcp and udp . Wait/Nowait The fourth field
takes just one of two values, wait
or nowait , and is meaningful
only for datagram ( dgram ) socket
types (other socket types conventionally use a nowait
value). Most datagram servers connect to a socket and free up inetd to handle subsequent connection
attempts. These servers are called multi-threaded,
and they require a nowait entry.
Servers that connect to a socket, process all input, and then time out are said
to be single-threaded, and they require wait entries. You may optionally add a
number to these values, separated by a period, as in wait.60 . This specifies the maximum number
of servers of the given type that inetd
may launch in one minute. The default value is 40 . Username You can tell inetd to launch a server with a specific
user's privileges. This can be an important security feature, because
restricting privileges for servers that don't require extensive access to the
system can prevent a bug from causing a security breach. For instance, the
Apache Web server usually doesn't need unusual privileges, so you could launch
it as nobody or as some special
account intended only for Apache. The preceding
example shows the username as root
because root privileges are
needed to launch the login processes required by a Telnet server. If you add a
period and a group name, the specified group name is used for the server's
group privileges. For instance, nobody.nogroup
launches a server with the username nobody
and the group nogroup . Server program The sixth field
specifies the name of the server program that inetd
launches when it detects an incoming connection. The preceding example gives /usr/sbin/tcpd as this program name. In
reality, tcpd is not a server;
it's the program file for the TCP Wrappers program, which is described shortly.
Most Linux distributions that use inetd
also use TCP Wrappers, and so launch most inetd -mediated
servers through tcpd . You can
bypass TCP Wrappers for any server you like, although it's generally best to
use TCP Wrappers for reasons that are described shortly. Server program arguments The
final field is optional. When present, it contains any arguments that are to be
passed to the server program. These arguments might modify the server's
behavior, tell it where its configuration files are, and so on. In the case of
servers launched through TCP Wrappers, the argument is the name of the ultimate
target server, such as in.telnetd
in the preceding example. (You may add the ultimate server's arguments to this
list, if it needs any.) You can edit /etc/inetd.conf
using any text editor you like. Be sure that any new entries you create, or
existing ones you modify, span a single line. (Long filenames, server
arguments, and the like sometimes produce lines long enough that some editors
will try to wrap the line onto two lines, which will cause problems.) If you
need to add an entry for a server you've installed, consult the server's
documentation to learn what its inetd.conf
entry should look like. In some cases, you can model an entry after an existing
one, but without knowing what values to enter for the server name, socket type,
and so on, such an entry might not work.Most distributions that use inetd
ship with an /etc/inetd.conf
file that contains entries for many different servers. Many of these entries
are commented out, so they're inactive. You can activate a server by
uncommenting such a line, if the matching server is installed. Some inetd.conf files include multiple entries
for any given service; for instance, a file might have two or three different
entries for different FTP servers. If yours is like this, be sure you uncomment
only the line corresponding to the specific server you've installed, such as
ProFTPd or WU-FTPD.TIP
align=left border=0> One of the first things you should do after installing Linux
is to go through /etc/inetd.conf
(or the xinetd configuration
files, as described shortly) and comment out entries related to servers you
don't need. A good rule of thumb is to eliminate any entries you don't
understand; Linux doesn't need any of the servers listed in inetd.conf to boot, although it may need
some to accept network logins. Eliminating unnecessary servers improves your
security by limiting avenues of attack available to undesirable outsiders.
Unfortunately, you can't do the same thing with SysV startup scripts, because
many of these start vital nonnetwork services upon which Linux relies to do
useful things.
Using TCP Wrappers
As mentioned earlier, TCP Wrappers functions as an
intermediary between inetd and
the ultimate target server. The reason for doing this is security: TCP Wrappers
can apply rules to determine whether or not a given connection should be
allowed, thus protecting the server from unwanted accesses. For instance,
suppose you want to allow only people on your own local network to access your
computer's Telnet server. If you were running the Telnet server directly, it
would have to be programmed to reject unwanted accesses, but not all servers
include such code. Placing the responsibility for limiting access in TCP
Wrappers extends the flexibility of the system without requiring extensive
rewriting of all your server programs.TCP Wrappers is controlled through two files: /etc/hosts.allow and /etc/hosts.deny . These files have
identical formats, but they have opposite actions hosts.allow specifies computers that are to be allowed
access to the computer, with all others denied access; hosts.deny specifies computers that are to
be denied access, with all others allowed access. When a server is listed in
both files, hosts.allow takes
precedence. This allows you to set a restrictive policy in hosts.deny but override it to grant access
to specific computers. For instance, you could disallow access to all computers in hosts.deny ,
then loosen that restriction in hosts.allow .
If a server isn't specified in either file (either explicitly or through a
wildcard, as discussed shortly), TCP Wrappers grants access to that server to
all systems.NOTE
align=left border=0> In some ways, TCP Wrappers is similar to a local firewall,
as discussed in
provides broader-based protection, but TCP Wrappers can provide both
redundancy in case of a firewall failure and a few features that iptables can't provide, such as the
ability to filter based on an NIS netgroup name.
As with many other configuration files, a pound sign ( # ) at the start of a line indicates a
comment. Other lines take the following form: daemon-list :client-list
The daemon-list
is a list of one or more servers to which the rule applies. If the list
contains more than one server, commas or spaces may separate the server names.
The names are those listed in /etc/services .
The ALL wildcard is also
accepted; if the daemon-list
is ALL , then the rule applies to
all servers controlled by TCP Wrappers.WARNING
align=left border=0> Remember that not all servers are run through TCP Wrappers.
Thus, an ALL wildcard for the daemon-list may not apply to all servers run on the computer.
Similarly, listing a server in daemon-list
won't protect it unless the server is run through inetd and TCP Wrappers or uses TCP Wrappers directly.
The client-list
is a list of computers that are to be allowed or denied. As with the daemon-list , the client-list can consist of just one
entry or a list separated by commas or spaces. You can specify computers in any
of several ways: IP addresses You can list
complete IP addresses, such as 10.102.201.23 .
Such an entry will match that IP address and that IP address only. IP address range There are
several ways to specify ranges of IP addresses. The simplest is to provide
fewer than four complete bytes followed by a period. For instance, 10.102.201 . matches the 10.102.201.0/24
network. You can also use an IP address/netmask pair, such as 10.102.201.0/24 . IPv6 addresses are also
supported, by a specification of the form [n:n:n:n:n:n:n:n]/len ,
where the n values are
the IPv6 address and len
is the length in bits of the range to be matched. Hostname You can provide a
complete hostname for the computer, such as badcracker.threeroomco.com . This will match that
computer only. Because this method relies upon a hostname lookup, though, it's
subject to problems if your DNS servers go down or if the person who controls
the domain modifies its entries. Domain You can match an entire
domain or subdomain much as you can match a single hostname. The difference is
that you must precede the domain name with a period, as in .threeroomco.com this example
matches all the computers in the threeroomco.com
domain. NIS netgroup name If a string
is preceded by an at symbol ( @ ),
the string is treated as a Network Information Services (NIS) netgroup name.
This method relies upon your network having a functioning NIS configuration.In addition, the client-list
specification supports more wildcards than does the daemon-list specification. Specific
wildcards you may use include the following: ALL This
wildcard matches all computers. LOCAL This
wildcard is intended to match all local computers, based on hostname. If the
computer's hostname lacks a period, it's considered local. UNKNOWN
This wildcard matches computers whose hostnames aren't known by your name
resolution system. KNOWN This
wildcard matches computers whose hostname and IP addresses are both known to
the system. PARANOID
This wildcard matches computers whose names and IP addresses don't match.These last three options should be used with care, since they
usually depend upon proper functioning of DNS, and DNS can be unreliable
because of transient network problems. For instance, if a client's own DNS
system is down or inaccessible, you might be unable to verify its hostname. As
an example of a short but complete /etc/hosts.allow
file, consider the following: telnet,ftp : 192.168.34. dino.pangaea.edu ssh : LOCAL .pangaea.edu
The first line specifies identical
restrictions for the Telnet and FTP servers, allowing access only to the
192.168.34.0/24 network and the host called dino.pangaea.edu . The second line applies to SSH and restricts access to local
computers and all those in the pangaea.edu domain. Because no
other servers are listed in the daemon-list fields,
TCP Wrappers doesn't block access to any other server. For instance, if you
were to run Apache through inetd and TCP Wrappers, everybody would be granted access to Apache with
this configuration.In addition to matching entire computers, you
can use the user @computer form to match individual users of the remote system. This form,
however, requires that the client computer run an ident (aka auth ) server,
which returns the name of the user who is using a given network port. Your own
server can query the client's ident server about the connection attempt,
thus getting the username associated with that attempt. This may cause
additional delays, however, and the information often isn't particularly
trustworthy, especially from random hosts on the Internet. (You're more likely
to want to use this feature to control access from specific users of systems
that you control.) The EXCEPT operator is
another special keyword; it specifies exceptions to the rules just laid out. For
instance, consider the following /etc/hosts.deny entry: www : badcracker.org EXCEPT goodguy@exception.badcracker.org
This example denies access to the Web server
to all the computers in the target="_blank">badcracker.org domain, unless the connection is coming from goodguy@exception.badcracker.org . (Because /etc/hosts.allow takes precedence over /etc/hosts.deny , entries in the former can
also override those in the latter.) If your goal is to run a very secure system,
you may want to begin with the following /etc/hosts.deny file: ALL : ALL
This blocks access to all computers for all
servers handled by TCP Wrappers. You must then explicitly open access to other
servers in /etc/hosts.allow . You should open access as little as possible. For instance, you
might only give access to computers in a specific network block or domain for
sensitive servers like Telnet. (Telnet passes all data in an unencrypted form,
so it's a poor choice for logins over the Internet as a whole. See
Maintaining Remote Login Servers, for a discussion of this issue.)
