System Administration: Maximizing Linux Security: Part 2
So far, we have focused on security issues that arise in the context of a single computer system. However, most systems are connected to networks, and so must deal with the variety of threats which arise from that context.
Standard TCP/IP offers only limited mechanisms for controlling network access, and they are designed for convenience of access rather than true network security. In its standard form, the /etc/hosts.equiv file contains a list of systems trusted by the local host, and users with the same user name on one of these remote systems can log into the local system via the network without having to provide a password.
Under normal circumstances, this makes sense. The problem comes when an account on a remote system has been compromised; trusting that system then puts your own system at risk as well. Of course, this problem is magnified many times when it is a remote root account that has been broken into. For this reason, it is a very bad idea to allow password-less root access between systems, and the /etc/hosts.equiv mechanism does not do so (however, the other method for setting up account equivalence does),
Each entry in a .rhosts file contains a hostname and (optionally) one or more user names. It allows password-less access to the local account from the listed remote user names (or to a user with the same user name, if the entry contains only a hostname). For example, when the following .rhosts file is in user chavez's home directory, it will allow user vasquez on hamlet and user chavez on romeo to log in to her account via the network without a password:
hamlet vasquez romeo
The problem with the TCP/IP notion of trusted systems is that trusting another system has implications beyond the interactions between the local system and the trusted remote system. Inevitably, trust operates in a transitive fashion: if system A trusts system B, and system B trusts system C, then to some extent, system A trusts system C whether it wants to or not and whether it knows it or not. Such chains can go on indefinitely, and hackers are notoriously good at exploiting them.
Accordingly, the following precautions will minimize the risks of trusted network access to your system:
Include the minimum number of hosts in /etc/hosts.equiv.
Make sure there is no [cw]+[ecw] entry in hosts.equiv (this acts as a wildcard and trusts every system in the universe).
Use the - entries supported by the Linux version of this file as appropriate. A hostname preceded by a minus sign in /etc/hosts.equiv requires a password from every user from that system who wants to log in to the local system. It also nullifies any entries for that host in all .rhosts files on the system. Thus, this mechanism serves as a ways to override transitive trust.
The Linux version of /etc/hosts.equiv allows hostnames to be optionally followed by a username, which gives that user password-less access to any non-root account on the local system. I don't recommend using this feature.
No /.rhosts file should exist on the system; remote root access should always require a password (if it is allowed at all).
Monitor users' ~/.rhosts regularly for inappropriate entries.
The traditional hosts.equiv mechanism allows for only the crudest level of access control. The TCP Wrappers package, which is included with nearly every Linux distribution, provides for much more detailed control over which remote hosts use what local network services, as well as the ability to track and record network-based system access.
The TCP Wrappers package provides the tcpd daemon which introduces an additional layer between inetd, the primary TCP/IP daemon, and the score of subdaemons that it manages. Daemons for services like the telnet facility are started on an as-needed basis by inetd; once TCP Wrappers is installed, requests for telnet services go to it first and are granted only if the system configuration allows it.
Once the tcpd daemon is built, you simply modify inetd's configuration file, /etc/inetd.conf, placing any and all of its subdaemons under tcpd's control. For example, Figure 2 shows how to change the entry for the telnet daemon to use TCP Wrappers.
#service socket protocol wait? user program arguments telnet stream tcp nowait root /usr/sbin/in.telnetd
is changed to:
#service socket protocol wait? user program arguments telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Access to network resources is controlled by TCP Wrappers' configuration files, /etc/hosts.allow and /etc/hosts.deny. The first file contains entries specifying which hosts may use which services:
in.telnetd : hamlet romeo in.fingerd : LOCAL EXCEPT juliet
The first entry says that telnet requests from hamlet and romeo will be honored, and the second entry says that remote finger commands may be run from any local system except juliet (a local system is defined as one not containing a period in its name).
The hosts.deny file contains entries denying specific services:
netstat : fool in.tftpd : ALL ALL : ALL
The first entry denies the use of the netstat service to host fool, the second entry disables the trivial ftp facility, and the third entry acts as a catch-all, denying everything that hasn't been explicitly allowed to everyone.
When tcpd considers a request for network services, it uses the following process:
If hosts.allow authorizes its use, the request is granted. The first applicable line in the file is used.
If no entry in hosts.allow applies, then hosts.deny is consulted. If that file denies the service, the request is denied, and again the first applicable line in the file is used.
If no entry in either file applies, the request is granted (note that an ALL:ALL entry in hosts.deny prevents this case from coming into play).
TCP Wrappers logs its activity to the syslog subsystem via its daemon facility. It generates lots of data which can be cumbersome to examine manually. The swatch package provides a useful way of automatically sorting through any output stream for events you specify in advance, and it is very useful in conjunction with TCP Wrappers.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Back to Backups
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Google's Abacus Project: It's All about Trust
- Secure Desktops with Qubes: Introduction
- Seeing Red and Getting Sleep
- A New Version of Rust Hits the Streets
- Fancy Tricks for Changing Numeric Base
- Secure Desktops with Qubes: Installation
- Working with Command Arguments
- Linux Mint 18
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide