|
|
| Previous | Table of Contents | Next |
There are at least four ways to deal with protecting /etc/passwd:
Shadow password files store the encrypted password in a file that is accessible only to root; the regular /etc/passwd file is world-readable. Combining this with a restriction on where root can log in can make getting a copy of the encrypted passwords difficult.
Note: On some Linux systems and HP-UX, the /etc/securetty lists those ttys that can be used to log in as root. Only ttys that are physically under control, such as console, or terminals connected to the serial ports, such as tty00 or tty01, should be listed. For Sun and other systems, the /etc/ttytab file lists all ttys. Adding the word secure to the option list at the end of an entry permits the entry, such as console, to be a source for a root login. For other systems, /etc/login.defs or /etc/default/login file can be used to do this. Study the login man page to find out details on your system.
Password-selection enforcement programs basically replace the standard Unix passwd program with a version that tries to guess the proposed new password. Essentially, these programs run something like Crack against the proposed new password before accepting it.
One-time passwords, using programs such as S/Key or Opie, require users to type a new password at each login. Each user has a paper (or online) printout of passwords and is required to generate new lists occasionally. Although this appears to be quite safe, an attack against the predictability of the sequencing is the greatest threat, though the security of a printed (or online) copy of the passwords is really the greater source of problems.
Another approach is to use smart card password security programs smart cards, such as the SecurID from Security Dynamics, that require a PIN number to be typed in and then send a password. This seems to offer safety comparable to one-time passwords, without the threat of a printed list of passwords.
If the target system has an X Windows vulnerability, the intruder can gain access to all typed keystrokes, effectively canceling many of the preceding password security approaches.
It is important that non-user accounts in /etc/passwd, such as tftp or bin, have an * in the password field and reference /bin/false as the shell. This prevents hackers from gaining access to these accounts.
ttys
Each xterm, telnetd, or rlogind invokes a pty/tty to interact with the user. The application opens a pseudo-tty, or pty, which acts as the master and is associated with a slave tty. The application then typically invokes a shell (xterm) or /bin/login (telnetd, rlogind) that invokes a shell.
When the user types on the keyboard, the keystrokes are sent to the pty. If the user is typing on a remote network connection, using rlogin or telnet, the rlogind or telnetd writes the keystrokes to the master pty.
The pty is described by a device file, such as /dev/pty/ttys2. The permissions on this file are determined by the mesg command. For example:
% ll ‘pty’ crw 1 bkelley users 17 0x000032 Nov 20 00:51 dev/pty/ttys2 % mesg is n % mesg y % ll ‘pty’ crwww 1 bkelley users 17 0x000032 Nov 20 00:51 dev/pty/ttys2 % mesg n % ll ‘pty’ crw 1 bkelley users 17 0x000032 Nov 20 00:51 dev/pty/ttys2 %
The mesg command mesg command enables the user to permit other users to invoke the talk or write command to send messages or interactively talk to this user. A remote user can indicate talk root@m2.notreal.com and send messages to that user if mesg y has been set by root on m2.notreal.com.
The problem is that it is possible to cause commands to be executed on ptys. For example, by echoing commands directly onto the pty device and embedding termcap sequences to invoke those commands, a user can cause commands to be executed by the owner of that pty device. If that owner is root, the user can gain access to root using this technique.
In general, users should be wary of leaving a pty world-writeable. The global /etc/profile (or /etc/cshrc) should use a default of mesg n so that users are required to specifically indicate this service.
Rwall (an rpc service available through portmap) and the talk network service (517/UDP, 518/UDP) permit a remote user to send messages to many remote systems, but these commands merely print to the screen. Unless the termcap capabilities of the remote terms permit the ability to embed execution strings, there is no way to gain access remotely.
RIP Updates
A Unix system can maintain routing tables, either for optimized local routing or to act as a router, by running the gated program. Gated can support many routing protocols, from DVMRP to OSPF, but most gated implementations use RIP, which is also supported by many hardware routers. If the gated program does not filter routing updates by source address, a hacker can modify the routing tables on the target system. This could lead to disruption of service and facilitate other attacks.
In gated versions 1.x, the gated.conf file can be modified to listen only to certain sources for routing information by adding a line such as this:
trustedripgateways gateway [ gateway ] … trustedhellogateways gateway [ gateway ]
Only the routing updates from the indicated RIP or HELLO gateways are recognized as valid.
In gated versions 2.x and 3.x, the gated.conf file can include a trustedgateways clause to specify the same access controls for RIP, HELLO, and ICMP redirects.
RIP-2 packets can use a password authentication. The password consists of a quoted string, 0 to 16 bytes long. OSPF can also use an authentication key, which consists of 1 to 8 octets. A hacker with a packet sniffer could gain access to these passwords and spoof a routing packet.
EGP and BGP require explicit listings of peers in the configuration file. Once again, IP spoofing by a hacker could be used to insert false routing updates.
Gated broadcasts RIP routes that could provide a hacker with routing information even if the hacker is unable to make modifications to the system.
DNS Searchlists
By default, a hostname lookup using the DNS resolver proceeds by appending the current domain to the hostname and attempting a lookup. On failure, the resolver removes the leftmost part of the current domain and retries.
| Previous | Table of Contents | Next |