CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)

---

These files contain a number of settings:

service—This keyword must be followed by the service name, such as telnet.

disable—Values include yes (which disables the service and no connections are accepted) and no (which doesn’t disable or enables the service for connections).

flags—Many and varied flags exist; the most common is REUSE, which allows the port and service to accept multiple connections.

socket type—This can be stream, dgram, raw, rdm, or seqpacket.

wait—Use the wait parameter for single-threaded servers that grab the socket and operate until timeout; use nowait for multithreaded servers that free up the socket when not active.

user—The user or group this service should run as, giving you the ability to restrict a risky service to an account that’s not root.

server—This is the full path and filename of the server or daemon program run when a client requests a connection.

log_on_failure—This can also be log_on_success, and values include HOST, USERID, and PORT, to name a few options.

access_times—This setting lets you set access timeframes for the service, such as from 8 a.m. to 5 p.m. in the previous file.

only_from—This can be a list of hostnames, IPs, globs of addresses, and defined networks by name from the /etc/networks file.

To enable a service governed by xinetd, such as the previous telnet service, use the chkconfig telnet on command. This changes the previous file to contain the following line:

disable = no

The service is now enabled and can accept requested connections. Changes to the file for a service don’t require any restarting of services or xinetd; those changes take place for the next and subsequent instances of the service whose file you changed.

If you edit the /etc/xinetd.d/telnet file by hand, the xinetd service might have to be restarted for the change to take effect. This is done automatically by the chkconfig command.

To disable the service completely from being initiated and governed by xinetd, use the chkconfig telnet off command.

This disables the service and xinetd ignores requests for this service from this point on.

The inetd service must be restarted after a new configuration is written to the /etc/inetd.conf file, but the xinetd service reads the service configuration files in the /etc/xinetd.d directory dynamically and requires restarting only if you manually edit /etc/xinetd.conf file.

Using TCP Wrappers for Securing Services

If you want to protect your on-demand services, use TCP wrappers as one of the layers of protection for seldom-used services.

The common concept of using TCP wrappers is that only services in the /etc/inetd.conf file can be wrapped or protected, but that’s untrue. The TCP wrappers package includes a library called libwrap.a that an increasing number of Linux services reference for security.

inetd and TCP Wrappers

When used with inetd, the concept of using TCP wrappers is to place a controlling daemon with instructions as to who’s allowed and denied in front of each service that runs on your machine. Most services in the era of widespread inetd usage didn’t have any built-in protection, so they were configured to be run as parameters of the tcpd daemon.

The tcpd daemon is set up to refer to the /etc/hosts.allow and /etc/hosts.deny files for the hosts that are allowed and denied access to services protected by tcpd.

xinetd and TCP Wrappers

If you are using xinetd or running a current distribution of Linux, many of the services are developed to use the libwrap.a library, finally divorcing TCP wrappers from the /etc/inetd.conf file.

In the case of current distributions and xinetd, any service capable of referencing libwrap.a has the potential to benefit from the protection that the /etc/hosts.allow and /etc/hosts.deny files provide.

Additionally, if you wanted to run a set of services that were both secure and fast, you would use TCP wrappers and a standalone daemon, instead of putting the service under inetd or xinetd control. Anytime you put services behind inetd or xinetd, they must be started to function, and that means a small though noticeable delay—often enough that a client request times out.

The hosts.allow and hosts.deny Files

The two tables that affect which clients can connect to which services (provided the service uses libwrap.a or is controlled by inetd/xinetd) are /etc/hosts.allow and /etc/hosts.deny.

The format of a typical hosts.allow or hosts.deny file is as follows:

daemons: hosts : option : option

Daemons or services can be specified several ways, including

ALL—This means just that, all services.

service—A single service name affects only that service.

daemon,daemon—Multiple daemons affected by an entry should be separated by spaces or commas.

Hosts can be specified by many methods, including

hostname—This affects a single unqualified hostname, typically from the local domain.

hostname.example.com—This affects a resolvable, fully qualified hostname, typically from a remote domain.

@group—This is used by NIS to denote a Net group and is unlikely to appear on the exam.

10.1.1.0/255.255.255.0—This notation affects the hosts 10.1.1.1–10.1.1.255. The /XX notation for bits can be used, too, such as /24 to denote a default Class C subnet mask.

/path/filename—This causes the listed file (full path and filename) to be referred to as the list of hosts that will be affected.

Wrapper Read Order

The following rules are important to understand when using TCP wrappers to protect services:

1. The /etc/hosts.allow file is read and parsed first. Any matches in it cause access to be allowed, skipping the /etc/hosts.deny file entirely.

2. The TCP wrapper files are read each time a service is requested. Therefore, any changes to the hosts.deny and hosts.allow files are immediately used.

3. The files are read sequentially. This means that two conflicting entries in the same file cause the first one to be matched, ignoring the second and subsequent entries.

4. The files are read only if they exist. If they don’t exist, no rules can be applied, allowing complete access for services as far as TCP wrappers are concerned.

The most important point about how these files are processed is the order in which rules are matched from the files.

Format of hosts.allow and hosts.deny

It’s important to choose what you want to deny or allow with the following guidelines:

Deny by default—You deny all host access to all services by inserting an entry that reads ALL: ALL in the /etc/hosts.deny file; then you can allow any specific hosts with entries in the /etc/hosts.allow file.

Allow by default—If you trust everyone more than not, don’t have an allow file and just put the bad hosts or domains in the deny file.

Mix and match—The most complex style, this is when you don’t have a clear delineation of good and bad. You should carefully inspect the allow files for lines that invalidate your deny rules.

Sample Configurations

Scenario #1: Deny all access, as shown in Figure 20-2.

Figure 20-2 How all access is denied.

In this scenario, all access is denied. The presence of an /etc/hosts.allow file in this example is unnecessary because we’re denying everyone, so no allow rules are needed.

Scenario #2: Deny all access from a specific domain, with the exception of one machine within the domain, as shown in Figure 20-3.

Figure 20-3 The order in which the allow and deny rules are read.

The rule in the /etc/hosts.allow file is read before any rules from the /etc/hosts.deny file. As a result, the somehost.example.com machine is permitted access to the local system. All other machines from this domain are denied access based on the rule in the /etc/hosts.deny file. If a machine from any other domain attempts to connect to the local system, that machine is granted access since no rule would apply to that situation.

Another way to accomplish the preceding is to not have the /etc/hosts.allow file and in the /etc/hosts.deny file have the following line:

ALL: EXCEPT somehost.example.com

Scenario #3: Allow all systems to connect to the named and sendmail servers. Deny access to all other servers, as shown in Figure 20-4.

Figure 20-4 Using Service Names to allow access

To have more granular control of who can access services, you can use service names to deny and allow access to just that service. The following /etc/hosts.deny file entry allows access to all services but named:

named: ALL

Using Rule Options

Remember that the /etc/hosts.allow and /etc/hosts.deny files have the possibility of four configuration fields:

daemons: hosts : option : option

The real strength of using TCP wrappers comes out when you use the option fields to add characteristics to the entries that control access to services. Options can be a single keyword or take the form of keyword values when using programs or utilities that need arguments.

For example, if you wanted to log the fact that a host had attempted to access one of your services configured to be denied, you might use the following line in the /etc/hosts.deny file:

service: badhost : severity auth.info

This entry not only denies the host access to the service, but also logs to the auth facility any messages that are severity level info or higher when the denial occurs.

Two useful keywords in the option fields are twist and spawn. You use the twist keyword when you want to booby-trap what would appear to be a service with another program or action. For example, if you wanted to cause a message to be sent back to an offending host that tries to use your finger daemon, you might employ the following entry in the /etc/hosts.deny file:

in.fingerd: ALL : twist /bin/echo "421 Buzz off!"

This sends a standardized message to the host’s console telling it access is denied.

The last keyword we cover is spawn. Often you want to allow some host to connect to a service, but at the same time be notified of the access. For example, to be notified via email every time someone accesses telnet so you can in turn email him with an SSH FAQ and scolding note to stop using telnet, you would use the following entry in the access file:

in.telnetd: ALL : spawn /bin/echo 'date' from %h | mail root

This works for just about any service, as long as it can use the TCP wrappers or can be configured to work from inetd or xinetd.

If you spawn a command, it runs the command as a child of the current shell, but if you use twist to run the command, it replaces the current process with the command you run.

Watch carefully for denial file modifications, such as twist and spawn statements. Being able to verify which entries are valid or invalid is essential.

Understanding Permission Problems

When you install a distribution, a number of files are set with special bits or permissions, mostly to make it easier for normal users to accomplish mild setup tasks. You should run a find command that shows these files right after you install the system and then keep that output in a file in a different location for referral later.