README.modules
$Id: README.modules,v 1.9 1999/03/22 04:57:19 crowland Exp crowland $ HostSentry - Login Anomaly Detector Introduction =-=-=-=-=-=- HostSentry is designed to be modular. This modularity means that end users can decide what aspects of logins and logouts they want to monitor and even design their own modules for custom needs. The default modules that ship with HostSentry perform a variety of functions. These modules are better described below: moduleLoginLogout =-=-=-=-=-=-=-=-= Description: This module simply logs whenever any user logs into or out of the system. This is a generic audit trail module designed to supplement existing logging you may already be doing. Login Signature Verification Procedure: - Login from host. - Observe log file for login entry. - Users listed in katana.ignore should not be processed. Logout Signature Verification Procedure: - Logout from host. - Observe log file for logout entry. - Users listed in katana.ignore should not be processed. Notes: - Always leave active to keep audit trail running for logins. moduleFirstLogin =-=-=-=-=-=-=-=- Description: Most users have no idea what a Unix shell is let alone how to access and use it. As a result I *always* recommend that you do not give users shell access to ANY system unless they specifically request it or it is necessary for your particular application to function. Because of the above phenomena, it is a significant auditable event when a user who has never logged into a shell before suddenly does. This may be normal, it may not be normal. The admin needs to decide whether it is OK for Susie the secretary to be logging in interactively when she can barely type. This module's sole purpose is to alert you to first time logins. This module is especially useful for getting a first alert after a user's password has been sniffed. I'd recommend you pay attention to this module if you have a fairly stagnant user population as many problems start here. Login Signature Verification Procedure: - Login from host with user that has not been used since HostSentry began operation (or one you deleted from the user database). - Observe log file for alert notifying admin of first time login - Users listed in katana.ignore should not be processed. Logout Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed. Notes: - This module will false alarm for a few days after HostSentry is installed. This is normal as users login and begin activity. After a week or so of use false alarms will decline and this module will provide more reliable results. moduleForeignDomain =-=-=-=-=-=-=-=-=-= Description: Often attackers who compromise a system account with sniffers and such will login from domains that clearly have no business connecting to your site. Therefore I *always* recommend that you wrap your system services or protect them with filters that only let your local domain interact with your host. This module's purpose is to look at system logins and look up the remote host domain. If this domain is *not* listed in the file: moduleForeignDomain.allow Then it is classified as "foreign" and you will get an alert. This is especially useful if you run an ISP in the *.com domain and you find a login from someone in Malaysia (My apologies to the Malaysian users of this tool :) ). If you wish to add known good domains to this file, simply pull it into an editor and have at it. This file is processed with regex so be careful about using restricted characters. Login Signature Verification Procedure: - Login from host not listed in moduleForeignDomain.allow file. - Observe log file for warning about foreign domain login. - Login from host listed in moduleForeignDomain.allow file. - No log entry should be given. - Users listed in katana.ignore should not be processed Logout Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed Notes: - This module may not work on some Unix hosts whose ut_host entry is too short (most *BSD and some Linux). Check the file utmp.h for the size of these strings, if they are 16-32 bytes long (typical) then you can expect inconsistent results. On RedHat and most other Linux systems tested this size is 255 bytes long which is sufficient for proper operation. - See README.wtmp for more information. moduleRhostCheck =-=-=-=-=-=-=-=- Description: A user who makes dangerous modifications to their .rhosts file may be up to no good or just ignorant of the security implications. This module will look at a user's .rhosts file on logout and if it contains a wildcard ('+') it will log the event so an admin can investigate. Of course you should never allow your users to use .rhosts file in any event, they are a horrible risk to security (many daemons allow you to shut this feature off). Login Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed Logout Signature Verification Procedure: - Create .rhosts file with wildcard entry ("+" or "+ +"). - Login and logout as that user. - Check log file for warning about wildcard in .rhosts file for user - ** CAUTION ** : erase the .rhosts file after this test is done!! - Make sure .rhosts file does not exist in user directory. - Login and logout as that user. - No log file entry should be made. - Users listed in katana.ignore should not be processed Notes: - Low false alarm rate. - Don't run rsh or rlogin if you don't need to. - ** CAUTION **: ERASE THE .rhosts FILE AFTER THIS TEST IS DONE!! moduleHistoryTruncated =-=-=-=-=-=-=-=-=-=-=- Description: This module will check the user's history file (depending on what shell they are using from /etc/passwd). This will fire an alarm if one of the following conditions occurs: 1) The history file for the shell being used does not exist (it may have been erased to cover tracks). 2) The history file is 0 bytes long (truncated to cover tracks). 3) The history file is a symbolic link. Commonly linked to /dev/null to prevent logging of commands. This is almost always an indication of a compromise. Right now it only checks for history files for: bash, csh, and tcsh. I'm not completely familiar with all the shells so if you have a history file/shell type to contribute please mail me. If you see this module fire you need to check your system for compromise. This is assuming of course the intruder didn't break root already and stop HostSentry. :) Login Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed Logout Signature Verification Procedure: - Make sure .history file exists with non-zero byte length in user's directory (make sure history file type is appropriate for their shell type [.history, .bash_history, etc.]) - Login and logout as that user. - No log file entry should be made. - Either: - Erase history file - symlink history file (usually to /dev/null) - Truncate to zero bytes (cp /dev/null .history) - Login and logout as that user. - Check log file for warning about truncated/missing/sumlink history file for user - Reset history file to default. - Users listed in katana.ignore should not be processed Notes: - This module relies on the fact that I know what the history file is called for the user's particular shell (bash, csh, ksh, etc). If the history file is not known for the current shell then this check will not perform its operation. - Send me any shell/history file combinations not covered by this module accurately. - If you are using Unix secure levels and immutable flags you should consider setting all users' history files to append only (see chattr(1)) to make covering of tracks harder. moduleOddDirnames =-=-=-=-=-=-=-=-= Description: The user's home directory contains one or more suspicious directories. Usually hackers will make a local directory named in an odd way to hide their work. This module will look for a directory name beginning in ".." (exempting of course the real ".."). Common intruder directory names include: ".. " "..." etc. This module is not totally reliable as it cannot of course check every permutation. It can help the more common methods that you'll see beginning hackers or users who are trying to hide something employ. If this module fires you need to check the user's directory for the strange directory. Login Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed Logout Signature Verification Procedure: - Make sure no directories exist with a leading ".." - CAUTION : Be careful not to delete the ".." directory that is listed in every directory on your file system. This translates to "parent directory" and if you try to "rm -rf" it you will trash a lot of things. If you don't understand this statement then find someone who does before you do this, or use the rmdir command instead - Login and logout as that user. - No log file entry should be made. - Either: - mkdir ".. " - mkdir "..." - etc. - Login and logout as that user. - Check log file for warning about suspicious directory for user. - rmdir the directory created. - Users listed in katana.ignore should not be processed Notes: - Low false alarm rate. - Not as complete as it should be. moduleMultipleLogins =-=-=-=-=-=-=-=-=-=- Description: A user is logged in from one or more different host concurrently. This is a classic sign of an intrusion as user accounts are shared among hackers. It is not uncommon to see multiple logins from foreign domains which makes multiple signatures fire off simultaneously. Hosts listed in the file: moduleMultipleLogins.allow will never be processed if they are seen in *any* user login. This is useful for users who keep a login session from say a terminal at work and then go home to do work concurrently. Login Signature Verification Procedure: - Login from host not listed in moduleMultipleLogins.allow. - Login from DIFFERENT host not listed in moduleMultipleLogins.allow file. - Observe log file for warning about concurrent logins from different hosts. - Logout users. - Login from host not listed in moduleMultipleLogins.allow TWO times. - No log entry made (same host with concurrent login is normal) - Logout users. - Login from host LISTED in moduleMultipleLogins.allow - Login from host not listed in moduleMultipleLogins.allow - No log entry made. (ignored one of the two hosts) - Logout users. - Users listed in katana.ignore should not be processed Logout Signature Verification Procedure: - None - Users listed in katana.ignore should not be processed Notes: - This module may not work consistently on some Unix hosts whose ut_host entry is too short (most *BSD, and some Linux). Check the file utmp.h for the size of these strings, if they are 16-32 bytes long (typical) then you can expect inconsistent results. On RedHat systems and most other Linux systems tested this size is 255 bytes long which is sufficient for proper operation. - See README.wtmp for more information. moduleOddLoginTime =-=-=-=-=-=-=-=-=- The user is logging in at an odd time. To be determined. moduleInvalidUtmp =-=-=-=-=-=-=-=-= The user's utmp entry on logout has been altered/missing. To be determined. moduleHistorySuspicious =-=-=-=-=-=-=-=-=-=-=-= The user's history file contains suspicious commands. To be determined. moduleNetworkDaemon =-=-=-=-=-=-=-=-=-= The user left a listening network daemon on logout. To be determined. moduleFileExists =-=-=-=-=-=-=-=-=-= The user has a file/directory in their home directory that matches a pre-defined list of banned/monitored files. To be determined.