Slackware Linux Idiosyncrasies
|
| < Free Open Study > |
|
Like any distribution, Slackware Linux has its own peculiar quirks and ways of doing things. In Chapter 4, you learned some of the equivalent idiosyncrasies of Red Hat Linux; after you've read this section, you'll have seen some of the differences between two distributions, and will be another step closer to mastery of the concepts, and not just the techniques of using and managing a Linux system.
Configuring Inetd
The inetd superserver (sometimes called metaserver) was discussed in Chapter 4 in the context of Red Hat Linux. Red Hat uses the xinetd package as the inetd implementation for their distribution. Slackware, however, uses an older, traditional inetd implementation. This implementation will be very familiar to anyone who's ever worked with inetd on another traditional Unix-like system. In fact, users who have may wish to skip this section, since there will be no new material; less experienced users, however, will be able to apply the content in this section to other systems.
Recall that the purpose of inetd is to make it easy to write basic server applications. It's a sort of "cookie cutter" that can be used to stamp out similar servers. Software authors write small programs that handle operations, and then map their application to a port in the configuration for inetd. The inetd server, in turn, binds to all the ports indicated in its file and routes incoming requests to the appropriate service program depending on what port the request arrived on.
Generally, traditional inetd is pretty simple to configure. Slackware's implementation is in the tcpip1 package (along with a number of other things) and essentially consists of three files: the inetd program executable, the /etc/inetd.conf file which configures the server, and the /etc/services file that establishes meaningful names for port numbers.
The /etc/services File
The /etc/services file is used to map names to port numbers. This is purely a cosmetic issue; it simply lets humans refer to port numbers by names, since keeping track of all the ports numerically can be confusing. (This is similar to how Internet IP addresses are mapped to server names by the DNS system; the names are purely for human consumption.) Actually, the /etc/services file is used by more programs that just inetd; it can be used by any application that needs or wants to find a human-meaningful name for a port number. (An API is provided to applications to allow them to look up the name of a port number, or to locate a service by its human-readable name.)
Each line in the /etc/services file has this syntax:
<symbolic name> <port>/<protocol> <aliases>
The <symbolic name> is the human-meaningful term, such as "http" or "telnet." The port is the TCP/IP port number of the service, and the protocol must be either of the literal strings, "tcp" or "udp", depending on whether the service uses a TCP (i.e., stream-oriented) or a UDP (i.e., datagram-oriented) protocol. The aliases are optional, and simply indicate alternate names for the same port number.
 |
Don't worry too much about the difference between TCP and UDP; generally, these are used only by server and client applications to establish connections of the appropriate type. A given protocol will be based on TCP or UDP depending on its needs. If you've written a server yourself and are adding it to inetd, you'll know whether it is TCP or UDP; if you're just installing one, the documentation for the software will state which it uses. In fact, many protocols listed in /etc/services have entries for both TCP and UDP, even though most only use one or the other. This mapping is mostly for human reference, and has no impact on the functioning of the software, anyway.
|
Here are some examples from the /etc/services file that is included with Slackware 8. This is the line for WWW servers:
www 80/tcp http # WorldWideWeb HTTP
This line indicates that the "www" protocol has port number 80, is a streambased (TCP) protocol, and is also known as "http." Contrast this with the Trivial File Transfer Protocol (TFTP) line, which is a UDP-based protocol that runs on port 69 and has no aliases:
tftp 69/udp
A few moments' search through this file will turn up lots of familiar port numbers and protocols, such as telnet (for remote access) on port 23, HTTP (for web servers) on port 80, POP3 (for accessing email) on port 110, and SMTP (for transferring email) on port 25.
The /etc/inetd.conf File
The actual configuration file for the inetd server is /etc/inetd.conf. The contents of the file are also straightforward. Each line in the file configures a separate service program and binds it to a port number. The lines have this syntax (which is also documented in the file itself):
<service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
The <service_name> parameter is either a numeric port number, or the symbolic name of a port as specified in /etc/services. (If a non-numeric port is specified here, the /etc/services file will be searched to find a port number.). The <sock_type> must be either "stream" or "dgram" (which is short for datagram). The next field, <proto>, must be either "tcp" or "udp", and must match the <sock_type> field. That is, if <sock_type> is "stream", then <proto> must be "tcp" and vice versa; The "udp" and "dgram" fields are similarly linked.
| Note | If a system used an underlying network protocol other than TCP/IP, it could use something other than "udp" and "tcp" for the datagram and stream protocols. However, the vast majority of computers today use TCP/IP, so it's really just a theoretical issue. |
The <flags> field must be either "wait" or "nowait" to indicate whether the inetd server should wait for the secondary program to finish before processing more connections. The "wait" flag means that inetd will essentially hand off ownership of that port to the designated program when a connection is received; the program will then manage (or not manage) additional connections on that port itself. This allows performance-critical applications (such as web servers) to manage connections themselves during times of peak usage. Doing so is more efficient and memory-friendly than having inetd spawn off a new process for each incoming request, since the service can essentially shut itself down when it's not needed, and be woken up by inetd again when additional connections arrive.
The <user> field is the username of the account that should own the secondary program; usually, this is the root user, but can be any user account with appropriate permissions. The <server_path> is the path to the secondary program that inetd is to kick off. Everything after the program name is considered to be arguments that get passed to the program when inetd invokes it.
Examples, as usual, are the best way to demonstrate this. The following line defines the entry for the telnet remote-login service, and creates it as a stream-oriented TCP server bound to the telnet port.
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
This line also indicates that inetd should not wait for telnet to return before accepting another telnet connection. (If this were set to "wait", then inetd would wait for the telnet program to return before accepting another connection; in that case, the in.telnetd program would have to manage additional incoming requests itself.) The process runs as the root user (but the telnet program itself will switch to the appropriate user once she logs in), and the program to be run is /usr/bin/tcpd with an argument of in.telnetd.
Installing a New inetd-Based Service
Installing a new service to be managed by the inetd superserver is done in just two steps:
-
Add an entry to the /etc/services file defining a name for the new service.
-
Edit the /etc/inetd.conf file to refer to the new service and assign a program to be run when a connection is received on the desired port.
| Cross-Reference | Chapter 12 will demonstrate a sample installation of the Concurrent Version System (CVS) as an inetd server. |
|
One important "gotcha" about inetd services is how arguments are passed from inetd to the secondary programs. Some implementations of the inetd program only allow a fixed number (typically five) of arguments to be passed to the secondary program—and the first argument is the name of the program to be run! If you're using an inetd implementation with that limitation (whether on a Linux system or another Unix system), you can usually work around it by writing a shell script that launches your real program with all the parameters it needs, and creating the entry in /etc/inetd.conf to invoke the shell script.
|
Ensuring System Security
This section will describe how to improve the security of a Slackware installation. Slackware's focus is on simplicity and stability. To a certain degree, moreover, the Slackware developers expect administrators to assume a responsibility for the system. This means that administrators are expected to understand and stay on top of all aspects of their system, including security. So, Slackware places the burden of securing a system in the hands of its administrator. In practice, this means that default installations of Slackware are optimized for maximum functionality, rather than security. They're a "vanilla" installation intended as a starting point for setting up the required functionality, rather than a "fire-and-forget" server.
A default Slackware installation is running many services; in fact, it runs essentially every service it can run! Many new users' first reaction to this is to ask, "So what? If I don't need it, I just won't use it. It's not hurting anything by running, right?" Well, no, the services aren't hurting anything. However, no software program is 100% bug-free, and the vast majority of security breaches occur when malicious attackers exploit these bugs to gain access to the system. The services themselves don't harm anything, but their bugs can be exploited. So, any server program that's running is a potential security hole. If they're left running, they are a security risk; if they're shut off, no functionality is lost because they're not being used, but the potential security holes are eliminated. In a nutshell, good security policy is to disable any services and processes that aren't absolutely necessary.
So, how does an administrator disable these processes on a Slackware system? In Chapter 4, the mechanisms used by Red Hat Linux were discussed— the chkconfig and service tools. These tools manipulate the shell script framework that Red Hat's system uses to manage the system and services. Slackware Linux, however, has no such tools. The absence of these tools means that the shell scripts have to be modified by hand. Earlier in this chapter, the Slackware system startup scripts were described. This section will draw on that material to describe how to disable unnecessary services.
Generally, a new Slackware installation will typically have these servers running:
-
inetd services
-
portmap daemon
-
lpd printer daemon
-
Sendmail SMTP server
-
Apache HTTP server
This list may vary, depending on what software was selected during the installation; if you have a Slackware installation, your list may be different. Many of the services discussed in this section can be reconfigured to be more secure; for example, some can be configured to answer only to requests that originate from the local system (and not over the network). Administrators and users who need these services should read the documentation to learn what options are available to secure the software. In general, though, if you don't need a service running, it's a good idea to disable it, and so the remainder of this section will discuss how to disable each of these services.
Disabling the inetd Services
There are two ways to disable inetd services: either disabling them one by one in the configuration file for inetd itself, or simply disabling the entire inetd process outright, so that it never gets started. (If inetd isn't running, obviously neither are any of its services.) Disabling individual inetd services, as discussed earlier in this chapter, can be accomplished by simply placing a "#" character at the beginning of the line to be commented. If you find that you don't need any of the inetd services at all, however, you can disable the entire server outright.
Recall that Slackware has two files that govern most network configurations: rc.inet1, and rc.inet2. Both scripts are located in the /etc/rc.d directory. The rc.inet1 script configures the network itself, while rc.inet2 starts most of the network servers, including inetd. To disable inetd, then, you simply comment out the lines in the script that start the program. These are the lines you should look for:
# Start the inetd server: if [ -x /usr/sbin/inetd ]; then echo "Starting Internet super-server daemon: /usr/sbin/inetd" /usr/sbin/inetd else echo "WARNING: /usr/sbin/inetd not found." fi # Done starting the inetd meta-server.
Simply comment out the lines between (and including) the if and the fi statements by placing a "#" character at the beginning of each line, and inetd will not be started during the boot-up process.
Disabling the Portmap Daemon
The portmap daemon is the "portmapper" server originally developed by Sun Microsystems that is used by a number of programs, including NFS (Network File System) servers and clients. If a system is using NFS (either as a server or a client) to share disks across the network, then it will need the portmap daemon running. However, if NFS is not being used, then portmap can be disabled.
The actual program name is rpc.portmap, and like inetd, it is started from the rc.inet2 file during system boot. To disable portmap, simply locate and comment out these lines:
# This must be running in order to mount NFS volumes. # Start the RPC portmapper: if [ -x /sbin/rpc.portmap ]; then echo "Starting RPC portmapper: /sbin/rpc.portmap" /sbin/rpc.portmap fi # Done starting the RPC portmapper.
Again, the lines can be commented by simply adding a "#" character to the beginning of the line.
The portmap daemon is actually notorious as a security risk. It's such a large risk, in fact, that it should never be run on a system exposed to the Internet at large (such as a home computer or a public server). If it's absolutely necessary to run portmap, then the system should be placed behind a firewall so that only local computers can access the daemon.
| Cross-Reference | A firewall case study is discussed in Chapter16. |
|
The portmapper is a standard for RPC (Remote Procedure Calls). The portmap service is a way to access a program running on a server across a network. It's used for many applications, but the most important one is the Network File System (NFS) protocol used on many networks. NFS is used to provide access to a single filesystem (such as a user's home directory) on many different machines, and NFS usually relies on portmap. If you're using an application such as NFS, then you will probably need to leave portmap running. If you're not, though, you should seriously consider disabling portmap, since it can be quite a security risk.
|
Disabling the lpd Printer Daemon
The lpd daemon is used to provide access to printers. It can either manage a local printer connected to the PC, or can provide access to a remote printer across the network, or can also act as a server, receiving print jobs from across the network that are to be printed on a local printer. Unless these printing services are required, the lpd daemon should be disabled. As with inetd and portmap, lpd can be disabled by commenting these appropriate lines in rc.inet2:
# Start the BSD line printer spooler daemon: if [ -x /usr/sbin/lpd ]; then echo "Starting BSD line printer spooler daemon: /usr/sbin/lpd" /usr/sbin/lpd fi # Done starting the BSD line printer spooler daemon.
Disabling the Sendmail SMTP Server
Sendmail is a popular SMTP server. SMTP servers are vulnerable to two types of security problems: In addition to the "remote exploit" vulnerabilities that other processes have, it's also possible to have Sendmail misconfigured to allow it to be abused by attackers as a way to send unsolicited email (that is, spam) to unsuspecting users. This typically causes the spam email to appear (at least upon casual inspection) as though it originated from the server used as the "relay." For these reasons, it's doubly important to make sure that the Sendmail installation is either current and properly configured, or disabled.
Sendmail is notoriously difficult to administrate, so unless it's actually required, it's generally a good idea to disable it. Generally, the only reason to leave Sendmail running on any system that is not a mail server is for the benefit of some email clients that can't make use of an SMTP server running on a host across the network. However, almost every graphical email client has this capability, so Sendmail can usually be disabled.
Unlike the other services, however, disabling Sendmail is not done in the rc.inet2 file. The rc.inet2 file is for core network services that absolutely must be running for the system to function normally. Other, less crucial servers (like SMTP and HTTP servers) are started from the file rc.M.
The rc.M file works by first checking to see if a given server program is installed. If it is present, it is executed; if it's not, it is skipped. There are, therefore, two ways to disable a server started from rc.M. You can either rename the program so that rc.M no longer "sees" it and therefore skips it, or you can simply comment out the lines in rc.M that look for the script in the first place. It's probably better to comment out the lines in rc.M than to rename a program executable, however, since renaming (or deleting) a program might cause issues later on down the road. For example, another administrator or user may wish to reenable the server, but may not if it was renamed something excessively cryptic. If the program was deleted, it can't be recovered at all, without reinstalling it!
To disable Sendmail, comment out these lines in rc.M:
# Start the sendmail daemon: if [ -x /usr/sbin/sendmail ]; then echo "Starting sendmail daemon: /usr/sbin/sendmail -bd -q15m" /usr/sbin/sendmail -bd -q15m #fi
Disabling the Apache HTTP Server
The Apache HTTP server is a web server, and so is capable of serving up various types of static and dynamic content to web browsers and other clients. Like Sendmail, the Slackware startup scripts launch Apache from the /etc/rc.d/rc.M file. These lines need to be commented out to disable Apache:
# Start Web server: if [ -x /etc/rc.d/rc.httpd ]; then . /etc/rc.d/rc.httpd start fi
Astute readers will notice that in this case, Apache is not being started directly. Rather, a shell script (/etc/rc.d/rc.httpd) is being invoked, which in turn starts Apache. That shell script is very simple, however, and itself simply invokes Apache's own "control" script, called apachectl.
Other Servers
Recall that depending on what software was chosen, a given Slackware installation may have a set of servers different than the ones discussed in this section. However, no matter what the server is, it will be started either from /etc/rc.d/rc.inet2 or from /etc/rc.d/rc.M directly. Since Slackware expects users to be on top of the administration of their own systems, it's vitally important to review these files for every new Slackware installation, to make sure unnecessary services aren't running.
|
| < Free Open Study > |
|
EAN: 2147483647
Pages: 159