1. INTRODUCTION2. MISUSE CASE SCENARIO3. ARCHITECTURE4. idsh – the shell interface5. IDS engine – the “brains”5.1 The training phase5.2 The production phase6. Notifier7. ATTACKS AGAINST the IDS8. LIMITATIONS8.1 Command Sequences not detected8.2 Tolerance Limit not adaptive8.3 Does not detect application level anomalies8.4 No support for GUI interfaces8.5 Training period risk8.6 Loss of connection to IDS server9. REFERENCESShell Based Intrusion Detection SystemAmit [email protected] this paper, I describe a prototype for a UNIX shell based host intrusion detection system (HIDS). This system is anomaly based IDS. KeywordsIDS, UNIX, shell, anomaly1. INTRODUCTIONIntrusion detection systems are an integral part of any securityinfrastructure. Of crucial importance is to capture the events in asystem in real-time and attempt to diagnose whether an intrusionis currently taking place. IDSs fall into two broad categories. There are signature basedand anomaly based IDSs. Signature based IDSs have a pre-defined list of attacks that are defended against. Anomaly basedIDSs attempt to determine whether the behavior of the systemdeviates from the norm.This shell based IDS (which will be referred to as IDS in the restof this paper) does not use signature based intrusion detection.The reason for this is that from a command perspective it ispossible to enforce such constraints via permissions. If we do notwant a user to execute a particular program, we simply structurethe user and group permissions to disallow such access. The focus of this paper is how a user shell can be tied into ananomaly based IDS. In this case the user shell directly, asopposed to system log files, will be used as the view into thesystem.2. MISUSE CASE SCENARIOFigure 1.Misue case diagramUsing Sindre, et all’s [3] nomenclature for misuse, figure 1depicts a misuse case diagram which is what our IDS isattempting to prevent. The use case where Trudy scans forvulnerabilities is where the IDS should detect that an anomalyhas occurred. This is due to the fact that the commands thatTrudy would execute would most probably not be in line with thecommands that Bob normally executes. In fact, most probablythere would be new commands that are executed by Trudy thatBob has never executed before. If we are successfully able to detect that Trudy is scanning forvulnerabilities, we can lock out the Bob’s account and stop Trudybefore she is able to elevate privileges. Of course Bob will notbe happy that his account has been locked, but he can be scoldedfor most probably having a weak password.Clearly, a detection at this stage is crucial as if the intruder isable to elevate privileges, a rootkit (as described in [1]) can beinstalled to make it much more difficult to determine what isactually going on in the system. For all practical purposes, if themachine were compromised in this way, it would need to berebuilt.3. ARCHITECTUREThe architecture for the system involves the followingcomponents (depicted in Figure 2):a) idsh (the shell interface)b) IDS engine (the brains)c) Notifier (the alerting engine)i d s hi d s hi d s e n g i n en o t i f i e ri d s hi d s hFigure 2. High level architecture4. idsh – the shell interfaceIn a UNIX environment, a shell is still a dominant user interface.The idsh component involves implementing a small hook into anormal shell that simply sends the information about thecommands being executed to the ids server. The prototype includes a small shell-like utility that only doeswhat is required for the IDS to function. It is not a full functionalshell. However, the above requirements could easily be added toa standard shell (bourne, korn, tcsh, etc) without much work.5. IDS engine – the “brains”The IDS engine is the policy engine that makes the decision as towhether an anomaly has occurred. The class diagram for the IDSengine is depicted in figure 4. Source code for the classes can befound in the appendix.B o b T r u d yA u t h e n t i c a t e a s B o b C r a c k P a s s w o r dC h e c k e m a i l S c a n f o r V u l n e r a b i l i t i e sR e g i s t e r f o r C l a s s e s E l e v a t e P r i v i l a g e s I n s t a l l R o o t k i t S t e a l S S N sFigure 4 – Class Diagram for the IDS engine.There are two phases that the IDS engine is concerned with:a) the training (or learning) phaseb) the production phase5.1 The training phaseThe training phase is responsible for cataloging the users normalbehavior. This phase takes place when we are sure that the useris logged in and is executing commands themselves. Of utmostimportance is to have the user execute enough commands to get agood statistical distribution of commands. An exampledistribution is in Figure 3.Com m and Distribution - Trainingls13%cd12%uptime3%rm2%df1%pine36%netscape4%cat9%vi15%more5%Figure 3. Command Distribution during the Training Phase5.2 The production phaseAfter the users have completed the training phase, they continueto use the systems, as they normally would do. In the production phase we are now concerned with whether theusers in the training phase are executing commands in line withtheir normal usage patterns. An example distribution for a userin the production phase in depicted in figure 4.Com m and Distribution - Productionls14%cd7%uptime3%rm2%df2%pine32%netscape5%cat6%vi20%more9%Figure 4. Command Distribution during the Production PhaseThe statistical method used to determine whether an anomaly isoccurring takes the probability distribution of all the commandsexecuted during the training phase and compares them to thecurrent command usage pattern. Of course, there needs to besome amount of tolerance based on the normal variability ofcommand usage for any user. Currently, the tolerance percentageis inversely proportional to the amount of commands executed.So, as we increase our commands executed in our session, thetolerance for a statistical abnormality reduces. The toleranceplateaus at 5% as this is the amount of variability that is deemedappropriate for each command once enough command have beenexecuted. The tolerance variability is described in
View Full Document
Unlocking...