Section 2.8 Limiting Unreasonable Access
2.8 Limiting Unreasonable AccessVarious common problems with unreasonable access to sensitive parts of the system are discussed and solutions offered. These are common problems that are often neglected allowing vulnerabilities. 2.8.1 Limit Which Terminals Root May Log In From
Linux allows the SysAdmin to make it impossible for an intruder to get the chance to guess the root password or even to use it if he knows it. This is part of the "Rings of Security" policy. This is done by allowing root to log in only on certain tty devices that are considered secure. A secure tty is defined as one where physical access by untrusted people is limited. On insecure terminals the would-be intruder first has to log in as an ordinary user and then use the su command. This requires him to know two passwords instead of one. Before he can even try to break the password of an ordinary user, the intruder must determine the names of some accounts to crack. See "Account Names" on page 50, "Do Not Get the Finger" on page 94, and "Turn Off rwhod" on page 95 for ways to keep account names secret. When root attempts to log in, the login program first consults the configuration file /etc/securetty to see whether the tty device that root is trying to log in from is listed. (The leading /dev/ should not be specified in /etc/securetty.) If the device is not found in /etc/securetty, login considers the tty insecure, cheerfully prompts for a password anyway, and then says Login incorrect. If there is no /etc/securetty file, root might log in from any tty so if this file is missing there is a vulnerability in the system. This file is documented in section 5 of the online manual as securetty. The reason for saying Login incorrect is to prevent someone from trying to guess the root password from an unsecured terminal where he will not be observed and then spend minimal time on the secure terminal actually logging in and planting a Trojan.
Some old UNIX systems would say root login not allowed if someone supplied the correct password and Login incorrect otherwise. This allowed someone to guess the root password on an insecure tty without having to do su from an ordinary account (su commands get logged). Then when the correct password was guessed a quick su was followed by erasing the logs. Some ancient Linux systems will say root login refused on this terminal prior to accepting a password. This is only slightly less secure than the monolithic Login incorrect. You will need to decide which devices should be considered secure, and thus worthy to be listed in /etc/securetty. The console device is used as a login device if virtual consoles are not enabled. Even if you use virtual consoles it is a good idea to enable root to log in on console, in case virtual consoles accidentally get disabled. If virtual consoles are in use, they use devices tty1, tty2, etc. Including all of these devices in /etc/securetty is reasonable. There may not be a need to list more than six or eight tty devices here, that is, tty1 through tty6. 2.8.2 Dialing the World (Wardialing)
Wardialing is the term used when someone programs his computer's modem to dial a whole sequence of phone numbers searching for those with modems connected to them that answer. This is for the purpose of finding computers to break into and it is a standard cracker technique. The very ambitious cracker will try all 10,000 numbers in a phone exchange. In this situation if your number is up, it is up. Frequently a cracker will pick one or more companies to target. Perhaps Pentacorp has announced that it will go public next week. All a cracker needs to do is to telephone Information in the appropriate area code and be told that Pentacorp's main number is 555-642-6000. The cracker then has his system wardial all numbers between 555-642-6000 and 555-642-6999, note which ones answer with modem tones, parse the login prompt for operating system type and version and system name, and start cracking. The operating system type and version tells him what exploits to try and the system name tells him whether it might have interesting data. See "Update /etc/issue" on page 327 for advice on limiting the information given. The solution to this is rather simple. Change the numbers. Instead of a number off the organization's switchboard or Centrex, get an entirely different number with a different exchange. The slight increase in cost will be well worth the increased security. Remember, any modem behind the corporate firewall can compromise security. See "Stopping End Runs Around Firewalls" on page 74. 2.8.3 Stopping Uncontrolled Access to Data
In "Finding Permission Problems" on page 59, you saw how to use the find command to search the entire file system for files with modes that are too lax and correct them. Presumably, if the files were owned by users, you either corrected them or discussed the problem with them. The issue here is that many users and programmers are much too busy to worry about permission. If it is a choice of missing a deadline or skimping on security, well, you know the answer to this one. As a consequence there might be some files that need to be world-readable or even world-writable due to the programmer's implementation. In some cases this problem is due to not wanting a "set-UID to root" program or because set-UID shell scripts are "bad." Expect this problem in connection to CGIs and database work. The answer is to get the programmers to alter the implementation to not require this access. Instead of a set-UID script, use a small set-UID C program that execs the script (without forking). In other words, the small set-UID C program should start the script with execl() or execv() and should not use fork(). Another possible problem is that while the Linux permissions might be strict and proper, the application's internal configuration will let anyone at the data. A perfect example here is where CGI code is used to access a database but the database itself has no rules restricting access. Thus anyone who knows SQL can alter the data, either an inappropriate user or even a cracker who might be in your system as an unprivileged user. Most database programs offer different grades of information that different sets of people are allowed to access. This should be used to prevent this problem. 2.8.4 Limiting Server Interfaces
Although it is desirable to have different systems perform different functions to increase security, in small networks this expense may not be considered reasonable. Thus, one system may serve as the firewall, Samba server, AppleTalk server, Web server, NFS server, etc. If you are not careful, this will cause access to these servers to be granted to everyone on the Internet even when this is not desired. Although you may "limit" access to a system with particular IP addresses, these can be spoofed easily. Although IP Chains rules will block this when used and properly configured, the "Rings of Security" concept suggests an additional ring of security that should be used too. Although many servers default to accepting requests on all of a system's network interfaces, most offer configuration options to limit which interfaces that they listen on. The documentation of each affected service should be consulted for the techniques. For Samba, the [global] section of /etc/smb.conf should contain the following lines: interfaces = IP1/mask1 IP2/mask2 bind interfaces only = true IP1 and IP2 should be the standard dotted quad and the masks should indicate the appropriate bit masks to define these networks. For the Novell server, the /etc/nwserv.conf file's section 4 should specify the interface devices, such as eth0. |
| Top |
EAN: N/A
Pages: 260