لطفا منتظر باشید ...
Monitoring for
Intrusion Attempts
Unfortunately, even systems that are very
well maintained, with good account and password policies and no unnecessary
servers running, are sometimes compromised. Knowing how to spot an intrusion
can be critically important to minimizing the damage from such an event. There
are several intrusion-detection tools available for Linux, and there are also
symptoms for which you can look to help you identify a compromised computer.
Intrusion-Detection Tools
Crackers who break into computers frequently
alter the system's configuration in some way. Examples of changes include
defaced Web pages, modified password files with new accounts to simplify future
break-ins, modified program files that do things other than what you expect,
and hidden surprises in just about any configuration or data file. Unfortunately,
it's impossible to predict precisely what files a cracker will modify. This is
part of what makes a successful intrusion so serious: Because you don't know
precisely what was done to your system, you can't trust any of it any longer. The
safest course of action is to completely delete all data on the computer and
re-install it or restore it from a backup made before the compromise. (The
upcoming section, "
however, can be used as a way to detect them. The idea is to record information
on critical system files, like /etc/passwd and various files in /bin , in such
a way that this information can't be modified. The information might be
encrypted or stored on a removable medium, for instance. You can then compare
your stored information against the critical files on a regular basis. If a
file that should not have changed has changed, you should suspect an intrusion.
(Of course, there are also innocent explanations for some changes, such as the
legitimate addition of users causing changes to /etc/passwd .)
Using Package Databases
One tool that can be used in this endeavor
already exists on most Linux distributions: Your package database. The Debian
package system and RPM system both store a wide variety of information about
all installed packages in package database files. You can use the --verify (or -V ) option to rpm to check
an installed package against its original file contents, thus: # rpm -V postfix S.5....T c /etc/postfix/aliases S.5....T c /etc/postfix/main.cf
This output shows the names of files that
have changed in some way from their original state. The string at the start of
each line of output indicates the information that no longer matches. For both
of the files reported in this example, the S indicates that the file
size has changed, the 5 means that the MD5 sum is different, and the T refers to an
altered file modification time. In this particular case, these changes are not
a problem, because both the files in question are configuration files that should be different than what was delivered with the
original package. If the Postfix executable had changed, though, there would
be cause for concern.On Debian systems, dlocate
provides similar functionality, but as of Debian 2.2, this tool isn't part of
the standard system. Once you've installed it, you can issue a command like the
following: # dlocate -md5check postfix
This checks the postfix
package's MD5 sums, and reports whether this sum is correct for each file in
the package.In addition to checking just one package, you can check all
your installed packages on an RPM-based system by typing rpm -Va . The resulting output is
likely to contain hundreds of lines, mostly referring to changed configuration
files and other innocent alterations. You may want to redirect the output to a
file or pipe it through more or less so that you can more readily examine
the output.One drawback to using rpm
or dlocate in this way is that
it doesn't allow you to track changes to configuration files made after the package was installed. Because you're
likely to make such changes, package tools aren't sensitive to intruders who
might modify your system's unique configuration files. Another problem is that
an intruder need only add software via your package manager to hide that fact
from you. For instance, if an intruder wanted to change /bin/bash on an RPM-based system, the
cracker could do so by installing a new bash
RPM package, and rpm -Va
wouldn't detect the change. For these reasons, it's best not to rely upon a
package manager as your sole intrusion-detection tool. It's worth mentioning as
something you might use if you believe you have been compromised. Although you
can't be certain that a system hasn't been compromised if rpm -Va doesn't turn up any problems, you
can be suspicious if it turns up changes to critical binary files.
Using
Tripwire
A tool that's designed to detect intruders is called Tripwire
(http://www.tripwire.org ).
This program ships with many Linux distributions, or you can download it from
its Web site. A version that ships with your distribution is far easier to set up,
because it will be preconfigured for your distribution's particular mix of
files and file locations. Tripwire works by storing information on various
files in its database. In this respect, Tripwire is similar to RPM or Debian
package management tools. Tripwire was designed as a security tool, though, so
it has certain advantages over package management tools for this purpose. Most
importantly, Tripwire can be configured to store information on an arbitrary
set of files at some point after they're installed,
so you can change configuration files and then
record their information. Tripwire can also use encryption to reduce the odds
of a miscreant modifying the Tripwire database. For better security, you can
store the Tripwire database on a read-only or removable medium, and mount it
only when you want to perform a database check or update.Tripwire runs in one of four different modes: Database generation The first
run of Tripwire initializes its database. You do this by typing tripwire -initialize after editing its
configuration file. This process can take some time to execute, because it must
compute hashes of all the files it's to monitor. The resulting database file
may be placed in the databases subdirectory under the current directory, but it
should normally be moved to /usr/lib/tripwire/databases ,
which ideally should be a read-only filesystem after you've created the
database file. Database update If you make
changes to your system, you can use the database update mode by typing tripwire -update /path/to/file , where /path/to/file is the file whose entry
you want to update. Interactive update If you make
substantial changes to your system, such as adding a large package, you can
type tripwire -interactive .
This enters an interactive mode in which the program reports files that have
changed and asks if you want to update the entry. Integrity checking This is the
default mode for Tripwire; you run it by typing tripwire with no options. This mode checks your files
for changes and reports them. You might run this check on a daily basis in a
cron job.The Tripwire configuration file is /etc/tripwire/tw.config . Like many configuration files,
pound signs ( # ) indicate
comments in this file, and text after these characters is ignored. Other lines
indicate directories that Tripwire is to check. The format of these lines is as
follows: [!|=] entry [ select-flags | template ]
The meaning of each component is as follows: Inclusive prune ( ! )
An entry that's preceded by an exclamation mark indicates that the specified
directory or file is not to be examined. In the case of directories, all its
subdirectories are ignored, as well. Exclusive prune ( = )
This code is used on directories that should be checked, but whose children
should not be checked. It's often used on directories like /home . When an exclusive prune is
indicated, Tripwire tells you that the directory has changed if files or
directories in it have been added or deleted, but Tripwire won't identify which
files have been added or deleted. entry
The entry is the name of
a file or directory that's to be checked, such as /etc or /usr .
If you list a directory, all its subdirectories are scanned as well, unless
they reside on separate filesystems. Thus, if /usr/local
is on a different partition than /usr ,
you'd need to create entries for both /usr
and /usr/local to scan the
entire tree. select-flags
You can tell Tripwire what types of changes to report by specifying select-flags . These take the form [+|-] [pinugsamc123456789]... . The + or -
indicates that Tripwire should or should not report changes, respectively. Each
subsequent character indicates an attribute to check: p for permission changes, i for inode number changes, n for number of links, u for user ID of the file's owner, g for the group ID of the file's owner, s for file size, a for access timestamp, m for modification timestamp, c for the inode creation timestamp, and 0 through 9
for various hashes and checksums. template
Instead of specifying a select-flags
entry, you can use a shorthand template .
The default is R , which stands
for +pinugsm12-ac3456789 . Other template entries include L ( +pinug-sacm123456789 ),
which is useful for log files; N
( +pinugsamc123456789 ), which is
very time-consuming but thorough; and E
( -pinugsamc123456789 ), which ignores
everything.Once you've set up a Tripwire configuration file, you should
run the program in database generation mode. This produces a file in the databases directory. Subsequent runs of
Tripwire expect to find the file in /usr/lib/tripwire/databases .
Because this file is so sensitive, you should take steps to protect it against
modification. Some possibilities include the following: You can store the database file on a write-protected removable
medium, such as a write-protected floppy (if the file will fit; it may not) or
CD-ROM, and permanently mount that medium at /usr/lib/tripwire/databases .
This is the safest approach, but it may be the least convenient. A variant is
to leave the medium unmounted and mount it only when you run a check. If you
run checks in cron jobs, this may be inconvenient. You can create a small partition that you mount in a read-only
manner to house the Tripwire database file. There are several possible variants
on this. For instance, you might use a write-protected CD-ROM disc image or a
filesystem type for which Linux has read-only but no read-write support. (The
latter would obviously require the intervention of another OS.) These variants
can make it more difficult for an interloper to modify your Tripwire database
file, but a truly competent and determined cracker could probably overcome
these measures. Back up your Tripwire database file to a removable medium and
manually compare it to the stored version every now and then. If the stored
copy has changed, that may indicate a break-in. If you use this approach, you
should compare the two files before you make any modifications yourself, then
replace the backup with the updated database file. Some Tripwire packages support encryption, usually through a
third-party utility. When so used, an interloper would have to know your
encryption password to modify the database.If you take reasonable precautions, you can be quite confident
in your Tripwire database's veracity, and therefore in the trustworthiness of
your computer. It's important to note, though, that Tripwire is best used when
it's installed on a fresh Linux installation. If you install Linux, then wait a
day or two, then install Tripwire, you'll learn of changes to your system made
after Tripwire's installation, but if your system was invaded before that time,
Tripwire won't detect that fact.
General
Intrusion Detection Procedures
In addition to using intrusion detection tools like Tripwire,
there are various actions you can take and procedures you can follow to help
you detect an intrusion. These include: Monitor log files Log files,
most of which appear in the /var/log
directory tree, contain a great deal of information about server activity. As
described earlier, monitoring them manually can be tedious at best, but with the
help of a tool like SWATCH, you may be able to spot at least some suspicious
activity, such as local logins by users who you know to be on vacation
thousands of miles away. Monitor system health If a
server suddenly begins behaving strangely, this could
be a sign of an intrusion, because crackers frequently damage your
configuration in making their changes. You shouldn't be too alarmed by a sudden malfunction, though; there
are many other less sinister possible causes. The possibility of an intrusion
is worth investigating, though. User complaints Crackers
sometimes break in via ordinary user accounts, and just as a cracker may damage
your system's configuration, a cracker may damage a user's settings. As with general
system health issues, there are other possible explanations for user complaints
like "forgotten" passwords or mysteriously altered shell defaults,
but you might want to check details like the change dates on configuration
files and passwords to see if these might be suspicious. Strange files You may notice
peculiar files appear on your computer. These are frequently the detritus of
intrusion scripts, or perhaps your original program files under new names,
called by replacement scripts to help mask the replacements' presence.
Intruders also sometimes delete or alter log files, so suspicious gaps in your
log files can be a clue to an intrusion. Unusual network traffic If the
amount of network traffic a server sees suddenly increases, one possible explanation
is that your system is under attack or is being abused. Of course, it's also
possible that your system has simply jumped in popularity. For instance, a link
to a small Web site on the popular Slashdot (target="_blank">http://slashdot.org )
frequently swamps a small Web site. (This effect is so well known that it's
spawned a worda site so affected is said to be Slashdotted. )
You might also notice unusual connections coming from a computer. For instance,
if a Web server is used only as a Web server,
logs on other computers on your network showing Telnet attempts from the Web
server could indicate that the Web server system has been compromised.Ultimately, it's up to you to spot unusual events. Most
network intrusions are the work of script kiddies crackers
with little skill who work from intrusion scripts created by others. (Some
people prefer not to call script kiddies crackers, reserving the latter term
for more skilled computer miscreants.) The scripts that script kiddies deploy
frequently leave identifiable traces behind. Unfortunately, each intrusion
script leaves behind its own unique fingerprint of changes, so it's impossible
to give a short list of files to watch. Security Web sites frequently include
discussions of the symptoms of particular intrusion methods, so using such a
site's search function can help you identify the nature of an intrusion.It's also important not to overreact or jump
to the conclusion that your system has been cracked. Hardware failures,
software misconfiguration, and bugs can all produce symptoms that resemble
those of intrusions.
What to Do if You Discover an Intruder
What should you do if you detect an intruder?
The general recovery steps are as follows:1. Disconnect the
computer from the network A compromised
computer might be used to cause problems for others or to infect other systems
on your own network. If your cracked system contains sensitive data, the longer
it's networked, the more likely it is your sensitive data will be stolen.2. Verify the nature of
the compromise You should verify that your
problem is due to a security breach. As noted earlier, many less sinister
problems can be mistaken for a break-in. You should also try to identify the
route that the attacker used to gain entry to your system. Even if you clean
the infection, if you don't lock the door the intruder used to get in, the
intruder will be able to gain entry in the same way again. Unfortunately,
identifying the specific security problem may be easier said than done, so you
may have to settle for upgrading your software and increasing your security
level generally.3. Back up vital data If your system isn't backed up routinely or hasn't been backed up
recently, you should back up regular user data. You may also want to create a
backup of the entire compromised system. You can peruse this backup later, and
it might become important evidence if the break-in becomes a criminal matter.4. Restore a clean
system Unfortunately, cleaning out only
infected files is not safe. You might get most altered files but miss something
important, thus leaving the intruder a way back in. You should wipe your hard
disk clean, or at least the partitions on which Linux itself resides; you might
be able to leave /home untouched. You can then re-install Linux from scratch or restore it
from a backup that you're sure was made prior to the intrusion.Do not configure your system's network functions at
this point, though; leave it disconnected from the network.5. Restore data files If you wiped out the entire hard disk in Step 4, you should
restore the user data you backed up in Step 3. You should also alter your
configuration to suit your needs, if you re-installed everything from scratch
in Step 4.6. Correct the security
problem You should correct whatever problem
existed that allowed the intruder entry to your system, as identified in Step
2. You may also want to take steps to improve security generally, such as
installing Tripwire if it wasn't installed already, setting up a local firewall
as described in
on.7. Return the system to
the network After you've recovered the system
and fixed its problems, you can restore it to its normal duties.There are other steps you can take along the
way, if you like. For instance, if you can trace the intrusion back to a
specific remote site, you might try contacting that site's administrator. Crackers
like to use several systems as stepping-stones to their true targets, so
there's a good chance that the site that launched an attack on you was itself a
compromised system. If your losses due to the intrusion were substantial, you
can contact the FBI or other law enforcement agencies; however, the amount of
cracking activity and difficulty of obtaining convictions means that you're
unlikely to see much action unless your case is very clear-cut or involves
substantial losses. (In the United States in 2002, losses must exceed $5,000
before the FBI will take notice.)
