Open-Source Intrusion-Detection Tools for Linux
Logcheck is a script that scans system log files and checks for unusual activity and attacks. This assumes that an intruder has not gained root privileges to a host and cannot alter the log files. One of the big problems with keeping good log files is a lot of information gets collected. Manually scanning log files could take days on large systems. Logcheck streamlines the task of system log monitoring by categorizing the logged information and e-mailing it to the system administrator. Logcheck can be configured to report only the information you want to see and to ignore all information you don't want to see. Logcheck can be downloaded from www.psionic.com/tools/logcheck-1.1.1.tar.gz. It is part of the Abacus Project, an Intrusion Prevention System, however, not all the other components are at stable releases yet. Logcheck is based on a log-checking program called frequentcheck.sh, part of the Gauntlet Firewall Package.
The logcheck.sh script is installed into /usr/local/etc/ along with the keyword files. The script can be downloaded at ftp.linuxjournal.com/pub/lj/listings/issue78.
Logcheck scans the log files for active system attacks first, then security violations, and then unusual system events. Logcheck then e-mails a report to root (see Figure 1).
In this sample Logcheck e-mail, I purposely logged on to my system from a host that was not allowed to connect, and then used some common hacking probe commands on my sendmail port. Logcheck detected the attempt to gather userids using sendmail and listed it as an “Active System Attack Alert”. It found that a user ftp'ed on to the system in the “Security Violations” section; they may have misspelled their legitimate user ID, or may be a cracker probing the system for user IDs. It also found system trying to connect to us that is not allowed to connect.
Finally, in the “Unusual System Events”, anything out of the ordinary that is not specifically ignored is shown. Logcheck creates a .offset file to mark the portions of logs it has scanned to avoid repeating information it has previously processed.
Logcheck is based on the assumption that syslog is configured to log as much information as possible, and, if possible, to log all activity to one file for easier parsing. Parsing only one file ensures that information will not be missed. We logged all our information to /var/log/messages in addition to the standard log files. This requires more disk space, but it makes debugging system problems easier. Logcheck is heavily biased toward Firewall Toolkit and BSDish messages from TCP wrapper. Systems not using Firewall Toolkit or TCP wrappers may need to add keywords for their security/monitoring programs.
Logcheck is useful only to help administrators spot attacks and take precautionary measures, but once a intruder gains access to your system, one of their first steps will be to hide their tracks by disabling logging.
We use Logcheck as a tool to monitor attacks on our system, intrusion activity and system problems. We pay specific attention to individual attacks on our system and cross reference older Logcheck outputs to try to establish patterns of probing and attacks that occur over weeks or months. The distributed or time-spaced probing of our system is considered high-priority because it usually shows a determined or organized attacker with the patience to look for, and take advantage of, new exploits and program holes. We run logcheck in cron daily, and change to an hourly check if we suspect active probing or attacks.
One of the best-known and most useful tools in intrusion detection and recovery is Tripwire. Tripwire creates a signature database of the files on a system, and when run in compare mode, will alert system administrators to changes in the file system. Tripwire is different from Tiger in that it is a dedicated file signature program, which can use multiple hash functions to generate digital signatures.
Tripwire was developed for the Computer Operations Audit and Security Technology (COAST) laboratory at Purdue University. The publicly available version, Tripwire version 1.2, is available from www.cs.purdue.edu/coast/archives Tripwire version 1.2-2 is shipped with Red Hat on the powertools CD as RPMs and is also available from ftp://ftp.redhat.com/pub/redhat/powertools/. Tripwire has been available as a commercial product since January 1999 from Tripwire Inc. Tripwire 1.3 is distributed as an Academic Source release. 2.x.x versions are available in binary-only form. Both can be downloaded from www.tripwire.com/downloads/index.cfmlfor noncommercial use. Tripwire Inc. has announced it will be adopting an open-source model for Tripwire by the third quarter of 2000, but has not yet settled on a licensing scheme.
A great many articles about Tripwire exist, so we will concentrate on using Tripwire as an intrusion detection tool rather than how to use Tripwire.
As I mentioned before, when an intruder penetrates a system, one of the first things they will try to do is hide themselves and their activities from the system. In order to accomplish this, they will commonly substitute system files with Trojan horse binaries—binaries with code added to them—which filter their activities. Common Trojan binaries are TELNET, login, su, FTP, ls, netstat, ifconfig, du, ps, inetd and syslogd. Intruders will also try to create back doors for themselves by adding a user to passwd or a service to inetd. In most cases, they will try to take the /etc/passwd file and run Crack on it hoping to find users with weak passwords.
Intruders will also install tools to allow them to monitor the network or maintain access to a system. They will try to install programs with known vulnerabilities to allow them to gain root access, often in “hidden” files. They may also install network scanners, and probes to collect information and possibly passwords from network traffic sent in clear text.
Tripwire as an intrusion-detection tool requires a pristine image database of the system, a snapshot of your system in a known uncompromised state. The best scenario (see Figure 2) is to be able to take a clean snapshot or “fingerprint” when the system is first installed. As programs are installed and upgraded, the system administrator compares the new file signatures to make sure only the programs they worked on are updated to the database and that no other system files were altered.
Capturing the digital signature of the entire file system can create an information overload for the system administrator. Parts of the file system are supposed to be changed with normal operations, so capturing the files in /var/spool, /tmp, or even /var/log can be useless because they are constantly being altered. At the same time, we need to be able to identify files hidden in the system if we detect a compromise. To accomplish the different need of the scans, we create two Tripwire configuration files with two Tripwire databases: one to scan the entire system and one to scan only critical system files.
System administrators have different opinions as to which files are “critical”. We take the view that system binaries and libraries should not change unless we change them. So all *bin and *lib directories, such as /bin, /sbin, /usr/bin, /usr/sbin, /lib and /usr/lib should be fingerprinted by Tripwire. In addition, all system configuration files in /etc should be fingerprinted. The files and directories to be scanned can be configured using tw.config. We can redirect the config file and database to be used by using the -c and -d switches of Tripwire.
Tripwire can be used as an intrusion-detection tool by having it run comparisons as a cron process. Any system files that were altered without the system administrator's knowledge would be a sign that the system has been compromised and that immediate action needs to be taken to limit the damage. Clear signs that a system has been compromised are changes to system files involved in login, access privileges, and process monitoring or accounting.
When an intrusion is detected or suspected, Tripwire can give the system administrator an indication of the extent of the damage by identifying the files that have been changed. If an intrusion has been detected early, the cracker may not have had time to penetrate the system, and may have had time only to start the process by bringing over tools and programs. This is where the fingerprint of the full system is valuable. Using a full scan of the system, hidden files and directories can be identified and investigated. Rather than manually scanning the file system for new directories and files, Tripwire will flag them and output them to the Tripwire report.
A knowledgeable cracker, one who knows about intrusion detection, will commonly try to hide programs in the file structure where they knew the system files would be changed during normal operations, thereby hiding themselves from abridged cron Tripwire comparisons. Places where a system adminstrator should pay especial attention is /tmp, /dev and /var/spool directories because files are created and deleted during normal operations. Crackers will try to hide their directories by prefixing them with . (dot), so they do not show in a normal ls command.
File integrity checkers should be a part of every system's security; Tripwire is the “best of breed” in this area. It can be used as an alarm to a system penetration and in intrusion recovery.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space