|
|
| Previous | Table of Contents | Next |
The most common indicator of a computer break-in involves improper account usage. An account that has been inactive for months that suddenly starts utilizing large amounts of system time is definitely suspect. An account designated for the secretarial staff that suddenly starts trying to view files owned by an engineering group is another good indication of possible intruder activity.
Some common security bugs used by intruders often leave traces in various system logs. Recent sendmail bugs have caused errors to be generated during the invocation of the bug. These showed up in the sendmail log files and in the postmaster mail spool. Another recent lpd bug has caused errors to be reported to printer error log. Staying informed of security holes exploited by intruders and knowing how their side effects can be revealed in system logs is critical for the security-minded administrator.
Regular reviews of TCP wrapper logs often reveal activities indicative of break-in attempts. Incoming TCP-based connections—such as telnet, ftp, and finger—from strange sites might be warning signs of intruder activity.
Even though system logs provide the administrator with a wealth of information, they by no means offer a complete solution for tracking security violations. System logs are subject to data corruption, modification, and deletion. In many cases, they only generate entries after a break-in has occurred. The practice of reactive security measures, rather than proactive, is not a good idea.
Note: On more than one occasion, individuals have generated fake syslog messages to have it appear as if numerous invalid root login attempts had occurred by specific users from foreign sites. In some cases, these acts were done to frame other users; in other cases, they were done to draw attention away from other, more serious breaches of security. The logs were determined to be false by comparing login records at the remote site and determining that the user indicated in the logs was not online at the time the syslog messages indicated.
Today, most computer break-ins involve several steps, as follows:
Compromised System Logs
When intruders gain access to a system, they almost immediately try to remove themselves from view. Most intruders have a wide array of tools to edit lastlog, WTMP, UTMP, and other logs. Such logs are usually modifiable only by root, but a surprisingly large number of systems still have UTMP world-writable.
Depending on how careless the intruder was and the tools used to edit the logs, some indications of the modification might be left visible to the administrator. One common lastlog editor used by the underground community writes null characters over the entry it wants to remove, rather than actually completely removing it. Although it appears as if the entry has been removed when viewed with last, an examination of the log file clearly shows that the entry has been tampered with.
Modified System Utilities
To ensure that they can always get back into a system after they have broken into it the first time, most intruders replace utilities with modified versions that contain backdoor passwords. Along with these back doors, the modified utilities also remove any routines that generate log entries. An intruder might install a modified login program, for example, that allows him or her super-user access when a certain backdoor password is entered, and grants him or her shell access without updating UTMP, WTMP, or lastlog.
Because source code for almost all Unix platforms has fallen into the hands of the underground community, it stands to reason that members of that community have the capability to modify every utility that contributes logging information. It doesn’t take too much time or skill to search through source code and look for syslog calls or other logging functions.
In some recent cases, the intruders had recompiled the Unix kernel itself with a special set of instructions to use when dealing with specific utilities such as ifconfig, netstat, ls, ps, and login. Not only had these utilities been modified to hide the intruders, but whenever the kernel received instructions to open or execute these files, it was set to report back information that made it look as if they had not been modified. Because the kernel itself was modified to report back false information about itself, administrators would have never found the intruders had they not booted from the distribution CD and mounted their old root file system under a different kernel to do a full investigation.
In most cases, when an administrator feels that a utility has been tampered with, he or she merely replaces it with an original from a distribution tape or CD. In this case, however, the administrators reinstalled the entire operating system and rebuilt the kernel.
| Previous | Table of Contents | Next |