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.