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.
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
- Preparing Data for Machine Learning
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi
- From vs. to + for Microsoft and Linux
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide