Intrusion Detection Systems
IDS (Intrusion Detection Systems) is badly named. The sorts of things these systems are designed to detect include far more than intruders, and in fact the "intruder" might well be an ordinary, trusted user. "Misuse Detection" is much closer to what these systems really do.
There are probably three general areas that can be looked at for misuse:
- file checksums
- log file analysis
- user activity analysis
Of the three, user activity analysis is perhaps the most difficult. Both that and log file analysis is in the strange position of possibly being useless if security actually has been compromised, while at the same time being very useful in detecting patterns that indicate attempts to breach security. Only file checksums can reliably detect misuse after a breach, and even that is more difficult than it might first appear.
Log File Analysis
Most webmasters will tell you that their http logs are filled with records indicating attempts to execute /cgi-bin/FormMail.pl and Formail.cgi and all permutations of case. These are so-called "script-kiddies" trying to exploit weaknesses in a well known Perl script. I don't think too many sites run insecure versions of that any more, so these attempts probably deliver very little fruit, but the point is that these are people up to no good. An IDS system might immediately add their ip's to a blocked list just on general principle. There are many other less common, but still indicative, accesses.
The syslog or messages logs can also show suspicious activity: daemons starting up and failing (hopefully because whatever weakness being exploited was not present), login attempts, unusual ftp data transfers, unusually high disk, cpu or network usage can of course indicate unusual but "normal" activity, or even be from system problems, but can also be signs of misuse. It can be particularly useful to note the time of unusual activity. At one site I was involved with, we noted (from lp logs) that a sales manager who gave notice of leaving had printed many hundreds of pages the night before. The natural suspicion was that he had printed off customer records and intended to take them with him. I was not involved with the confrontation of him with the evidence, but without looking at the logs we never would have suspected this at all. This should also serve to underline the earlier point that misuse is not necessarily intrusion or even an actual breach of security per se.
At many sites we routinely log user activity at the time of the system backup. More than once this logging, though instituted for entirely different purposes, has shown suspicious activity by employees who had no legitimate reason even to be in the office at that time of night. Regular perusal of Unix's "last" output can also show unexpected usage patterns.
Just simple monitoring of available disk space at another site turned up a directory filled with objectionable images. Ordinarily, that would be a good sign of a break-in and and indication that the system was being used to serve these on the web, but in this case it was just an employee avidly collecting. That is still serious misuse, of course, though we were relieved to find that the system hadn't actually been compromised.
The examples above came from human analysis of logs and information. IDS systems that include this sort of checking would have rule sets and would use base-line comparison to determine suspect activity. Anything unusual (such as the late hour printing noted above or unexpected disk usage) would trigger an "event" which, depending on severity, might be logged to another machine or might set off immediate alarms and pull some poor person out of their bed to investigate.
User Activity Analysis
IDS's that provide user activity analysis may include log file reading, but will also usually do real time monitoring of user activity. Specific actions (such as attempts to su, or searches for suid programs) might trigger flags, but generally these try to look at the system statistically for activity that exceeds some established baseline. CPU usage jumping to 80% at 2:00 AM might be something benign at a 9:00 to 5:00 outfit, but it probably isn't meaningless. Network traffic will likely be monitored for patterns, including things like "Formail.pl" previously discussed. The monitoring aspect is very similar to the way virus scanners look for patterns that indicate viruses, and may even include the same patterns - viruses and worms are misuse, of course.
The problem with any of this, and of course the log files previously mentioned, is that a "rooted" system can cover all of that up so that everything appears normal, or perhaps even replace the IDS itself with a hacked version that reports nothing that its owner doesn't want reported. If the system misses the activity leading up to the takeover (and hackers can be very clever at evading notice), and the hacker then installs a "root kit" that will hide all further activity, humans and IDS systems won't know anything bad happened. That's not a reason not to use such analysis, of course, it's just a reason not to depend upon it completely. Systems that log to other machines are a little more trustworthy only in the sense that what led up to a total takeover might be safely recorded elsewhere, though suddenly silent afterward.
Conceptually, this is simple: record a checksum and owner/permission information for every executable and configuration file. This has to be done on a freshly installed system before it has been exposed to the network. You then later compare the information stored with the present state of the system. In practise, it's more difficult because you need to shutdown, boot from known secure media, and compare the files then. Otherwise it is quite possible that the system can return false information that is designed to match your records. There's also the problem of updated binaries, and changes to configuration files. These changes have to be reflected in the secure database, but obviously the updating process has to be secure also. It's no good to let the running machine notify the database of changes; that would just let a compromised machine report its files as good. For new binaries, the updates have to be done from a secure, non-connected machine and then (if you are being completely paranoid) transported on physical media to the active system. Configuration files are even more difficult to handle securely. Tripwire, available in both OpenSource and commercial versions, is one of the most well known systems that provide this type of checking, but there are many others.
The unfortunate reality is that you are never safe. Firewalls and IDS systems increase your security, but you can never be 100% protected from misuse. That was true even before machines were routinely connected to the Internet, and it is even more true now. You just need to balance risk against cost. It makes no sense for me to spend thousands of dollars or large amounts of time with free software to protect my web site from attack. Of course I have basic firewalling in place, and don't run insecure scripts etc. but my main protection is just simple backup: if someone ever does hack me, I'll rebuild from my backup files. There's no point in my doing anything more than that. However, if I had a high volume e-commerce site, where a lot of money could be lost from an intrusion, it would make sense for me to spend more. That's basic business sense, but too often we see people who should be more concerned about what they have to lose, but aren't doing much of anything to protect it. On the other hand, I have been in companies where there are locks upon locks and extensive monitoring, checking etc. for no real reason: they aren't protecting anything worth all that trouble and expense. That probably comes from the usual hysterical tone of articles like this, where the base assumption that you need anything at all is never even examined, but the most unlikely of threats are presented as imminent and ubiquitous.
One small anecdote: just a very few years ago, I came across a server that had been directly connected to the internet for many years. It was naked and unprotected, and its software was old, unpatched and very vulnerable. Yet, amazingly enough, it had never been hacked, and wasn't even being used as a mail relay (which it would have happily done for anyone at all). While there are hundreds of stories of servers being attacked within minutes of connecting to the net, this server ran for years, unnoticed, untouched, unabused. Random luck? Probably so, and of course we locked that up much more securely immediately, but my point is that while there are bad guys on every corner, sometimes you can walk right through the "Combat Zone" district with hundred dollar bills tucked behind your ears and still get home safely (you probably shouldn't test this proposition though). Your mileage will vary, results are not typical, read the fine print all of that and more, of course.
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic
Inexpensive and informative Apple related e-books:
Take Control of Security for Mac Users
Sierra: A Take Control Crash Course
Are Your Bits Flipped?
Take Control of the Mac Command Line with Terminal, Second Edition
Take Control of Apple Mail, Third Edition