|
Hardening Linux Authors: Terpstra J.H., Love P., Reck R.P. Published year: 2004 Pages: 45-46/113 |
 |
Name Switching Service (NSS)
The Name Switching Service (NSS) tells your system where to look to find the mapping of names to other information, such as machine addresses, service port numbers , and so on. This is handled by the file /etc/nsswitch.conf. This file consists of lines of text. The # symbol denotes a comment and is ignored. Entries consist of an entry name followed by a colon , then a space-separated list of places to find the information. Order is important, as the resources are checked in order.
Here are some sample entries from /etc/nsswitch.conf:
passwd: files shadow: files group: files hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: nisplus publickey: nisplus automount: files nisplus aliases: files nisplus
If you re not running in an NIS/NIS+ environment, then the references to NIS should be removed. Probably the most commonly referenced entry is the hosts line. Our example line tells the system to look in files, then use the domain name service. So the system s resolver will first look in /etc/hosts, then use the name server listed in /etc/resolv.conf to find a host. Since we re not in an NIS+ environment, we wouldn t want the system to use a network information server to resolve hostnames (any NIS server on our network would be a hostile machine!). Files come before DNS because we want the ability to force a hostname to a particular IP address in /etc/hosts for several reasons. We can then blackhole a malicious machine by setting its address to loopback, make and test changes on a per-system basis, and override a DNS response if the DNS has been cache poisoned, compromised, or if the server is down. This requires keeping /etc/hosts up to date. If we switch the order, we can have DNS answers go first, then the /etc/hosts file, which would give us a fallback if DNS was down, but not protect from the other issues raised.
You can simply delete the word nisplus from every single entry where it s found to batten down the system. Removing NIS from the equation not only makes it more difficult for an attacker to redirect such services, but also removes a lot of potentially buggy library code from the execution path of the system.
If you are in an NIS/NIS+ environment, then you should decide which resources you want to get from the NIS server, and remove the dependencies from the other entries.
Chapter 9: Restricted Execution Environments
A strong network and system security policy implements redundant and complementary countermeasures to the threats faced by computers deployed on a network. Whether you want to consider an onion, a castle, or a domino theory as an appropriate metaphor for this strategy, the approach is a solid one that can reduce the scope of a compromise, help maintain service uptime, and enable administrators to take on a proactive security role rather than a continuous reaction to bug reports and security updates. This chapter details the steps necessary to create a restricted execution environment with the Linux chroot command. Other types of restricted environments are User Mode Linux and the BSD family s jail command. chroot is present by default on most Linux distributions, therefore we will focus on that command.
Restrict Functionality
One of the ideal ways to improve the security for a network service is to provide as little extraneous functionality to the service as possible. The definition of what is extraneous will vary. In the following example, a web server is used. Customers may need access to an e-commerce web server or employees may need access to an internal HR web application. In each case, the service itself (a web server) has a specific collection of data and scripts necessary to support its users. The service does not need access to a C++ compiler, text editor, web browser, or dozens of the dynamic libraries installed on the host operating system. A service has a level of risk associated with its current patch level and configuration. While the presence of additional tools, programs, and libraries does not affect the web server s initial risk of compromise, their presence does contribute to the level of impact should a compromise occur. Without a strong host configuration and restrictive policies, a single attack can fully compromise the host or even place other hosts on the network in danger.
A major threat to network services is the buffer overflow exploit. A successful buffer overflow typically gives the attacker root access to the entire host. Since it is impossible to protect a service from a zero-day exploit for which no patch exists, the administrator must be able to design a configuration in which a successful buffer overflow “based attack dumps the attacker into a non-root, limited privilege environment. Otherwise, the attacker will have immediate access to sensitive information (passwords, e-mail, databases, file shares) or additional attack vectors, such as turning user nobody access into root access via a local buffer overflow exploit. If you remove the password file and delete the vulnerable library used to gain root, the web server will still run normally, but the attacker will have to spend a lot more time trying to escalate privilege.
The restricted environment may or may not make your web server more resistant to a buffer overflow or other attack, but if the system is compromised, your hardening work can reduce the amount of time you need to spend containing, analyzing, and cleaning an attack. For example, if you have removed the password file, you will not have to spend time changing passwords for all servers on a network or instructing users to change their passwords. You may not have to rebuild the host from scratch. Any work that has to be done has a direct effect on the time ”and money ”that goes into managing your network.
|
Hardening Linux Authors: Terpstra J.H., Love P., Reck R.P. Published year: 2004 Pages: 45-46/113 |
|