ch46.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

<P>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.</P>

<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 is seldom a problem 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 it is hanging up properly.</P>

<P>One way to prevent break-ins is to remove the modem from the circuit when it's

not needed. Because access through modems by unwanted intruders is usually attempted

after normal business hours, you can control the serial ports that the modems are

connected to by using <TT>cron</TT> to change the status of the ports or disable

the ports completely after-hours.</P>

<P>For most systems this is not practical, but for many businesses it is a simple-enough

solution. 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 from the normal modem line numbers.

<H4 ALIGN="CENTER"><A NAME="Heading8<FONT COLOR="#000077">How a Modem Handles

a Call</FONT></H4>

<P>In order for a user to gain access to Linux through a modem line, the system uses

the <TT>getty</TT> process. The <TT>getty</TT> process itself is spawned by the <TT>init</TT>

process for each serial line. The <TT>getty</TT> program is responsible for getting

user names, setting communications parameters (baud rate and terminal mode, for example),

and controlling time-outs. With Linux, the serial and multiport board ports are controlled

by the <TT>/etc/ttys</TT> file.</P>

<P>Some Linux systems enable a dialup password system to be implemented. This forces

a user calling on a modem to enter a second password that validates access through

the modem. If a dialup password system is supported on your system, dialup passwords

are usually set in a file called <TT>/etc/dialups</TT>.</P>

<P>The Linux system uses the file <TT>/etc/dialups</TT> to supply a list of ports

that offer dialup passwords, while a second file (such as <TT>/etc/d_passwd</TT>)

has the passwords for the modem lines. Access is determined by the type of shell

utilized by the user. The same procedure can be applied to UUCP access.

<H3 ALIGN="CENTER"><A NAME="Heading9<FONT COLOR="#000077">UUCP</FONT></H3>

<P>The UUCP program was designed with good security in mind. However, it was designed

many years ago, and security requirements have changed considerably 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.</P>

<P>If you don't plan to use UUCP, remove the <TT>uucp</TT> user entirely from the

<TT>/etc/passwd </TT>file or provide a strong password that can't be guessed (putting

an asterisk as the first character of the password field in <TT>/etc/passwd</TT>

effectively disables the login). Removing <TT>uucp</TT> from the <TT>/etc/passwd</TT>

file won't affect anything else on the Linux system.</P>

<P>You should set permissions to be as restrictive as possible in all <TT>UUCP</TT>

directories (usually <TT>/usr/lib/uucp</TT>, <TT>/usr/spool/uucp</TT>, and <TT>/usr/spool/uucppublic</TT>).

Permissions for these directories tend to be lax with most systems, so use <TT>chown</TT>,

<TT>chmod</TT>, and <TT>chgrp</TT> to restrict access only to the <TT>uucp</TT> login.

The group and user name for all files should be set to <TT>uucp</TT>. Check the file

permissions regularly.</P>

<P>UUCP uses several files to control who is allowed in. These files (<TT>/usr/lib/uucp/Systems</TT>

and <TT>/usr/lib/uucp/Permissions</TT>, for example) should be owned and accessible

only by the <TT>uucp</TT> login. This prevents modification by an intruder with another

login name.</P>

<P>The <TT>/usr/spool/uucppublic</TT> 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 files. Further subdirectories can be created for each system that is on the

valid user list, if you want to go that far.

<H3 ALIGN="CENTER"><A NAME="Heading10<FONT COLOR="#000077">Local Area Network

Access</FONT></H3>

<P>Most LANs are not thought of as a security problem, but they tend to be one of

the easiest methods of getting into a system. However, if any of the machines on

the network has a weak access point, all of 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 LANs is that it's impossible to

have a secure machine on the same network as nonsecure machines. Therefore, any solution

for one machine must be implemented for all machines on the network.</P>

<P>The ideal LAN security system forces proper authentication of any connection,

including the machine name and the user name. A few software problems contribute

to authentication difficulties. The concept of a trusted host, which is implemented

in Linux, enables 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 <TT>/etc/hosts.equiv</TT>, <TT>/etc/hosts</TT>, and

<TT>.rhosts</TT> files for entries that might cause problems.</P>

<P>One network authentication solution that is now widely used is Kerberos, a method

originally developed at MIT. Kerberos uses a &quot;very secure&quot; host, which

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.</P>

<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 because other people can use them to access your system.

<H3 ALIGN="CENTER"><A NAME="Heading11<FONT COLOR="#000077">Tracking Intruders</FONT></H3>

<P>Many intruders are curious about your system but don't want to do any damage.

They might get on your system with some regularity, snoop around, play a few games,

and leave without changing anything. This makes it hard to know that you are being

broken into, and it leaves you at the intruder's mercy should he decide he wants

to cause damage or use your system to springboard to another.</P>

<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. Not all Linux

versions support auditing, so consult your man pages and system documentation for

more information.</P>

<P>If you do rely on auditing, you should scan the logs often. It might be worthwhile

to write 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. A simple shell script to

analyze the log can be written in <TT>gawk</TT>. In addition, some audit reporting

systems are available in the public domain.

<H3 ALIGN="CENTER"><A NAME="Heading12<FONT COLOR="#000077">Preparing for the

Worst</FONT></H3>

<P>Assuming that someone does break in, what can you do? Obviously, backups of the

system are helpful because they let you recover any damaged or deleted files. But

beyond that, what should you do?</P>

<P>First, find out how the invader got in, and secure that method of access so it

can't be used again. If you're not sure of the access method, close down all modems

and terminals and carefully check all the configuration and setup files for holes.

There has to be one, or the invader couldn't have gotten in. Also check passwords

and user lists for weak or outdated material.</P>

<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. As soon as you see an intruder

log in, force him off.</P>

<P>Finally, if the break-ins continue, call the local authorities. Breaking into

computer systems (whether in a large corporation or a home) is illegal in most countries,

and the authorities usually know how to trace the users back to their calling points.

They're breaking into your system and shouldn't get away with it!

<H3 ALIGN="CENTER"><A NAME="Heading13<FONT COLOR="#000077">Summary</FONT></H3>

<P>Following the simple steps outlined in this chapter will give you enough security

to protect your systems against all but the most determined and knowledgeable crackers.

You can't do any harm with the steps mentioned, so you may as well perform them for

all Linux systems that have modems or network connections.









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


</body></html>