README.intro
$Id: README.intro,v 1.5 1999/03/22 04:57:36 crowland Exp crowland $ Introduction =-=-=-=-=-=- HostSentry is a host based intrusion detection tool that operates on the principle of Login Anomaly Detection (LAD), or what I sometimes call login cross-correlation. What HostSentry does. =-=-=-=-=-=-=--=-=-=- HostSentry will react to login/logout activity and process them with any number of login or logout modules. These modules are written to detect a problem and report it. When a problem is found HostSentry will either: a) Log the event. b) Disable the user account. (NOT IMPLEMENTED YET) c) Drop the route to the offending host. (NOT IMPLEMENTED YET) d) Block the IP of the offending host. (NOT IMPLEMENTED YET) e) Log the user off the host. (NOT IMPLEMENTED YET) f) All of the above. (NOT IMPLEMENTED YET) These modules and their detection capability are described in README.modules. What HostSentry does NOT do. =-=-=-=-=-=-=-=-=-=-=-=-=-=- HostSentry is designed to detect anomalies in users logging in through a shell account with either Telnet, SSH, or other such process. HostSentry only looks at the wtmp/utmp entries (in real-time), and will generally not be able to see processes like POP logins unless they update the wtmp/utmp file (which most don't). HostSentry also is NOT designed to be run on a host that is compromised. Although it may help you track down what user accounts are compromised, it is important to remember that the HostSentry process and program code can be altered just as easily as other sources. Also HostSentry will do nothing to prevent shell access that is not writing out to wtmp. This means trojan horses, remote shell holes, and other such problems will go completely undetected by this tool. Fortunately many hackers use telnet, FTP, and other protocols to quickly move between boxes. Once on they will clean the wtmp, but that is too late because HostSentry would have already processed the entry. This is the space where HostSentry is designed to function effectively. How it began. =-=-=-=-=-=-= This tool originated as a C prototype begun over two years ago as of this writing (11/98). The idea was a direct result of an experience I had cleaning out an intruder from an ISP. In the above case the systems compromised were actually fairly well secured. One morning however an administrator logged into a host at one of their remote sites. After running "top" he noticed a strange process running and using up a large amount of CPU. The process, a password sniffer, had been running for quite some time before it was found and managed to collect quite few account names and passwords. I was called in to help with the incident and several things were observed: 1) The person doing the hacking was not very good, which is fortunate for the ISP. 2) The system had been compromised for about 1-2 days before it was found. 3) The method of entry was a sniffed password for a user coming in from a Southern U.S. University (POP3 client). 4) The user had a *really* good password. Why it matters. =-=-=-=-=-=-=-= The above is important for several reasons: 1) Many intruders today are beginners. 2) Although the problem in this case was found reasonably fast, it was still not fast enough to prevent a sniffer and dozens (hundreds?) of other accounts from being compromised. 3) No "elite 0-day warez" exploits were used for entry against any of the system daemons. 4) The protocols that the Internet relies upon for operation were not designed to be secure. Indeed, RFC authors continue to submit (and have approved) protocol designs that have no security considerations built in even though issues like this are well known.[1] Actually I would suspect that many hosts are penetrated first by a compromised account than by any other method (although I have nothing but observed experience to back this claim). Typically intruders, once gaining a foothold on a system, will immediately set up a sniffer to grab passwords and use these accounts for rapid network compromise. Most of the popular Internet protocols of today will in fact succumb to this attack method.[2] Where does defense end and the clean-up begin? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- If an intruder manages to gain shell level access to your host the game is over. Period. I don't care what OS you run or what patches you have applied. It is almost always a matter of time before root access is obtained. Remember too that the vast majority of all system services are available to non-root users anyway. Even if you do manage to stall the intruder for a while from gaining root access, they can still be a hassle by launching attacks from the compromised host, installing IRC bots, erasing/altering user-accessible files, forging mail from the user, etc. I think many people focus too much on preventing root access and not enough time in keeping the unauthorized person off the system to begin with. Using the above, it is clear that the key to host security is really quite simple: Do not allow the person onto your host. Easier said than done of course, but I've found that attaining the above is substantially easier when administrators place ample focus on one key concept: Awareness Where does HostSentry fit in? =-=-=-=-=-=-=-=-=-=-=-=-=-=-= The first two tools of the Abacus Project (logcheck and PortSentry) were designed to bolster your existing security mechanisms. These are what I call "second tier" security products because they are not improving the security of your system directly from attack (by patching holes, wrapping services, etc.) but provide awareness of a potential problem. Here are the tiers of security software as I see them (sorry if I irritate anyone with my opinions). Also these lists are not complete but designed to give you just feel for what I'm talking about.: First Tier - The first tier directly protects your host or network from attack by actually stopping the attack from happening. These are the more traditional security procedures you'll see deployed. They work because they prevent the attacker from gaining access not only to a particular host, but to your entire network, which of course is the most important aspect of security. These methods should always be used together for maximum effect and any organization that can successfully deploy these methods will have *very few* problems with intruders. First Tier ---------- - Organized security effort to prevent problems. (most important) - Packet filters/Firewalls/Intrusion Detection Systems - Local host wrappers and filters. - Patched and up-to-date systems. - Unnecessary services disabled. - Encryption. - Compartmentalization of information (seperate networks). - User Education. - Secured dial-in access points. - Many others I can't list here. Second Tier - The second tier are generally the tools you run to promote awareness of a problem on a system before an attacker has actually obtained access. These tools are not designed so much to prevent attacks (although they often can) as they are to let someone know that something is going on that needs to be watched. Second Tier ----------- - Logfile auditing tools (logcheck). - Portscan detection (PortSentry). - Intrusion Detection Systems (Many systems can serve in first, second, and third tier positions) Third Tier - This is an area where an attack is in fact happening against a local host but defenses can still be mounted to prevent, or at least warn, that a system is being actively compromised. Third Tier ---------- - Login Anomaly Detection (HostSentry). - Some Host/Network Intrusion Detection methods. Fourth Tier - This is your last bastion of hope before a system is doomed, and this is debatable. These tools are generally only useful to notify you that you are in fact compromised (assuming they aren't disabled by the attacker). Usually at this point the system is lost and you should consider a re-load of all software. Fourth Tier ----------- - Filesystem checksums. - Nightly cron security scripts. - Some Host-based Intrustion Detection methods. - Sysadmin noticing a problem/web page hacked. If an intruder reaches fourth tier protection mechanisms your security has failed -- Period. At this stage you need to assess the situation to determine the appropriate course of action and how to correct the situation from repeating itself. Usually cleanup at this stage is a major hassle and difficult to get back to 100%. Unix and wtmp =-=-=-=-=-=-= Most (non-trusted) Unix OS's employ a very weak form of login auditing utilizing two main files: wtmp and utmp. These files typically store the following information: Username Login Host Login Time Login TTY This information is available to utilities such as at, who, and so on. This provides a very basic auditing scheme. Typical daemons such as telnet and ftp will add entries as logins and logouts occur on the host. HostSentry watches wtmp in real-time to process login and logout information and make a separate audit trail of these events that (I hope) will be more robust. Future versions are going to deploy strong cryptographic methods to protect logs from tampering by traditional means (editing, zap, etc.). Extrapolating meaning from wtmp. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Normally this data is only used in the rudimentary fashion described above: basic auditing of who logged in when. This is very two dimensional though and can be greatly expanded upon when a paranoid security bent is placed on the data. Basically this is: All logins are serious security events. Indeed I would go so far as to say that the biggest security problem with Unix is not any one particular service at all. Rather it is the fact that it allows interactive logins so easily to any user that asks. When this is realized a wealth of data can be derived from these four basic data points: 1) Has the user logged in before? 2) Where are they logging in from? 3) What time are they logging in? 4) What did they do during their login that can be checked during logout? 5) Where can I safely place this login information so it can't be tampered with? 6) etc. This is the basis of HostSentry. Auditing logins from the viewpoint that they are significant security events and should be treated as such. When this approach is taken a large number of useful possibilities begin to emerge from a single login record. What is an anomaly? =-=-=-=-=-=-=-=-=-= An anomaly is any event that falls outside of "normal." In the context of auditing logins, it is any event that seems just a little out of place for a known user. Take the following examples: - John the accountant, who doesn't even know how to spell Unix, suddenly logs into his shell account for the first time. - John the accountant, who doesn't even know how to spell Unix, suddenly logs into his shell account for the first time at 3:00 AM. - John the accountant, who doesn't even know how to spell Unix, suddenly logs into his shell account for the first time at 3:00 AM from China. - John the accountant, who doesn't even know how to spell Unix, suddenly logs into his shell account for the first time at 3:00 AM from China, Sweden, Malaysia and South Korea. Sadly, this isn't too much of an exagerration of an actual attack at many sites. What it all means. =-=-=-=-=-=-=-=-=- It is entirely possible that you run a secure host, but for various reasons you need to allow shell access and run insecure protocols that present clear-text passwords. Often you can't help it as much as you'd like to. For these cases a tool like HostSentry just may give you an edge to spot a login problem before it becomes an embarrassing incident. -- Craig <crowland@psionic.com> [1] - Justin Pettit <jpettit@raznick.com> suggests that any new protocol being submitted for a standards commitee be completely audited for security issues before being approved. I think this is a prudent recommendation. [2] - Telnet, FTP, POP2, POP3, IMAP, rlogin, HTTP, etc.