lsg24.htm

来自「linux-unix130.linux.and.unix.ebooks130 l」· HTM 代码 · 共 947 行 · 第 1/2 页

<BR>



<P>For most Linux users, protecting the system from access through an Internet gateway isn't important because few users have an Internet access machine directly connected to their Linux box. Instead, the main concern should be to protect yourself from break-in through the most accessible method open to system invaders: modems.



<BR>



<P>Modems are the most commonly used interface into every Linux system (unless you are running completely stand-alone or on a closed network). Modems are used for remote user access, as well as for network and Internet access. Securing your system's modem lines from intrusion is simple and effective enough to stop casual browsers.



<BR>



<BR>



<A NAME="E69E143"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Callback Modems</B></FONT></CENTER></H4>



<BR>



<P>The safest technique to prevent unauthorized access through modems is to employ a callback modem. A callback modem lets users connect to the system as usual, and then hangs up and consults a list of valid users and their telephone numbers and calls back the user to establish the call. Callback modems are quite expensive, so this solution is not practical for many systems. Callback modems have some problems, too, especially if users change locations frequently. Also, callback modems are vulnerable to abuse because of call-forwarding features of modern telephone switches.



<BR>



<BR>



<A NAME="E69E144"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Modem-Line Problems</B></FONT></CENTER></H4>



<BR>



<P>The typical telephone modem can be a source of problems if it doesn't hang up the line properly after a user session has finished. Most often, this problem stems from the wiring of the modem or the configuration setup.



<BR>



<P>Wiring problems may sound trivial, but many systems with hand-wired modem cables don't properly control all the pins; the system can be left with a modem session not properly closed and a log-off not completed. Anyone calling that modem continues where the last user ended. To prevent this kind of problem, make sure the cables connecting the modem to the Linux machine are complete. Replace hand-wired cables that you are unsure of with properly constructed commercial ones. Also, watch the modem when a few sessions are completed to make sure the line hangs up properly.



<BR>



<P>Configuration problems can also prevent line hangups. Check the modem documentation to make sure your Linux script can hang up the telephone line when the connection is broken. This problem seldom occurs with the most commonly used modems, but off-brand modems that do not have true compatibility with a supported modem can cause problems. Again, watch the modem after a call to make sure that it is hanging up properly.



<BR>



<P>One way to prevent break-ins is to remove the modem from the circuit when it's not needed. Because unwanted intruders usually attempt to access systems through modems after normal business hours, you can control the serial ports the modems are connected to by using cron to change the status of the ports or disable the port completely after hours. If late-night access is required, one or two modem lines out of a pool can be kept active. Some larger systems keep a dedicated number for the after-hours modem line, usually different than the normal modem line numbers.



<BR>



<BR>



<A NAME="E69E145"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>How a Modem Handles a Call</B></FONT></CENTER></H4>



<BR>



<P>For a user to gain access to Linux through a modem line, the system must use the getty process. The getty process itself is spawned by the init process for each serial line. The getty program is responsible for getting usernames, setting communications parameters (baud rate and terminal mode, for example), and controlling time-outs. In Linux, the /etc/ttys file controls the serial and multiport board ports.



<BR>



<P>Some Linux systems allow a dialup password system to be implemented. This kind of system forces a user calling on a modem to enter a second password that validates access through the modem. If this feature is supported on your system, it is usually with a file called /etc/dialups. The Linux system uses the file /etc/dialups to supply a list of ports that offer dialup passwords; a second file (such as /etc/d_passwd) has the passwords for the modem lines. Access is determined by the type of shell used by the user. You can apply the same procedure to UUCP access.



<BR>



<BR>



<A NAME="E68E130"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Using UUCP</B></FONT></CENTER></H3>



<BR>



<P>The UUCP (Unix to Unix CoPy) program allows two Linux systems to send files and e-mail back and forth (see <A HREF="lsg27.htm">Chapter 27</A>, &quot;UUCP&quot;). Although this program was designed with good security in mind, it was designed many years ago and security requirements have changed a lot since then. A number of security problems have been found over the years with UUCP, many of which have been addressed with changes and patches to the system. Still, UUCP requires some system administration attention to ensure that it is working properly and securely.



<BR>



<P>UUCP has its own password entry in the system password file /etc/passwd. Remote systems dialing in using UUCP log in to the local system by supplying the uucp login name and password. If you don't put a password on the system for the UUCP login, anyone can access the system. One of the first things you should do is log in as root and issue the command



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">passwd uucp</FONT></PRE>



<P>to set a UUCP password. If you want remote systems to connect through UUCP, you have to supply them with your password, so make sure it is different than other passwords (as well as difficult to guess). The slight hassle of having to supply passwords to a remote system administrator is much better than having a wide-open system.



<BR>



<P>Alternatively, if you don't plan to use UUCP, remove the uucp user entirely from the /etc/password file or provide a strong password that can't be guessed (putting an asterisk as the first character of the password field in /etc/passwd effectively disables the login). Removing uucp from the /etc/passwd file doesn't affect anything else on the Linux system.



<BR>



<P>Set permissions to be as restrictive as possible in all UUCP directories (usually /usr/lib/uucp, /usr/spool/uucp, and /usr/spool/uucppublic). Permissions for these directories tend to be lax with most systems, so use chown, chmod, and chgrp to restrict access only to the uucp login. Set the group and username for all files to uucp as well. Check the file permissions regularly.



<BR>



<P>UUCP uses several files to control who is allowed in. These files (/usr/lib/uucp/Systems and /usr/lib/uucp/Permissions, for example) should be owned and accessible only by the uucp login. This setup prevents modification by an intruder with another login name.



<BR>



<P>The /usr/spool/uucppublic directory can be a common target for break-ins because it requires read and write access by all systems accessing it. To safeguard this directory, create two subdirectories: one for receiving files and another for sending. You can create more subdirectories for each system that is on the valid user list, if you want to go that far.



<BR>



<P>A neat trick to protect UUCP is to change the UUCP program login name so that random accessing to the uucp login doesn't work at all. The new name can be anything, and because valid remote systems must have a configuration file at both ends of the connection, you can easily let the remote system's administrator know the new name of the login. Then no one can use the uucp login for access.



<BR>



<BR>



<A NAME="E68E131"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Controlling Local Area Network Access</B></FONT></CENTER></H3>



<BR>



<P>Most LANs are not thought of as a security problem, but they tend to be one of the easiest methods into a system. If any of the machines on the network has a weak access point, all the machines on the network can be accessed through that machine's network services. PCs and Macintoshes usually have little security, especially over call-in modems, so they can be used in a similar manner to access the network services. A basic rule about LANsis that it is impossible to have a secure machine on the same network as non-secure machines. Therefore, any solution for one machine must be implemented for all machines on the network.



<BR>



<P>The ideal LAN security system forces proper authentication of any connection, including the machine name and the username. A few software problems can contribute to authentication difficulties. The concept of a trusted host, which is implemented in Linux, allows a machine to connect without hassle assuming its name is in a file on the host (Linux) machine. A password isn't even required in most cases! All an intruder has to do is determine the name of a trusted host and then connect with that name. Carefully check the /etc/hosts.equiv, /etc/hosts, and .rhosts files for entries that may cause problems.



<BR>



<P>One network authentication solution that is now widely used is Kerberos, a method originally developed at MIT. Kerberos uses a very secure host that acts as an authentication server. Using encryption in the messages between machines to prevent intruders from examining headers, Kerberos authenticates all messages over the network.



<BR>



<P>Because of the nature of most networks, most Linux systems are vulnerable to a knowledgeable intruder. There are literally hundreds of known problems with utilities in the TCP/IP family. A good first step to securing a system is to disable the TCP/IP services you don't use at all, as others can use them to access your system.



<BR>



<BR>



<A NAME="E68E132"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Tracking Intruders</B></FONT></CENTER></H3>



<BR>



<P>Many intruders are curious about your system but don't want to do any damage. They may get on your system with some regularity, snoop around, play a few games, and then leave without changing anything. This activity makes it hard to know you are being broken into and leaves you at the intruder's mercy should he decide he wants to cause damage or use your system to springboard to another.



<BR>



<P>You can track users of your system quite easily by invoking auditing, a process that logs every time a user connects and disconnects from your system. Auditing can also tell you what the user does while on your system, although this type of audit slows the system down a little and creates large log files. Not all Linux versions support auditing, so consult your man pages and system documentation for more information.



<BR>



<P>If you do rely on auditing, scan the logs often. It may be worthwhile writing a quick summary script program that totals the amount of time each user is on the system so that you can watch for anomalies and numbers that don't mesh with your personal knowledge of the user's connect times. You can write a simple shell script to analyze the log in gawk. You can also use one of the audit reporting systems available in the public domain.



<BR>



<BR>



<A NAME="E68E133"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Preparing for the Worst</B></FONT></CENTER></H3>



<BR>



<P>If someone does break in to your system, what can you do? Obviously, backups of the system are a help, as they let you recover any damaged or deleted files. But beyond that, what should you do?



<BR>



<P>First, find out how the invader got in and secure that method of access so it can't be used again. If you are not sure of the access method, close down all modems and terminals and carefully check all the configuration and setup files for holes. Also check passwords and user lists for weak or outdated material.



<BR>



<P>If you are the victim of repeated attacks, consider enabling an audit system to keep track of how intruders get in and what they do. If you are concerned about damage, force off any intruders as soon as you see them log in.



<BR>



<P>Lastly, if the break-ins continue, call the local authorities. Breaking into computer systems (whether a large corporation or your own home system) is illegal in most countries, and the authorities will usually know how to trace the intruders back to their calling points. They're breaking into your system and shouldn't get away with it!



<BR>



<BR>



<A NAME="E68E134"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>



<BR>



<P>For most Linux systems, security isn't an issue because you are the only one who is using the machine. If, however, you share your machine with others or make it available for on-line access to anyone on the network (or the Internet), don't underestimate the chances of someone trying to break in; they will. Make your system as secure as you can. Common sense helps a lot, but don't forget that hackers are a wily, industrious, and tenacious bunch.



<P ALIGN=LEFT>



























</td>
</tr>
</table>
<!-- begin footer information -->


</body></html>