Intrusion Detection and Intrusion Prevention on a Large ... ?· Intrusion Detection and Intrusion Prevention…

Download Intrusion Detection and Intrusion Prevention on a Large ... ?· Intrusion Detection and Intrusion Prevention…

Post on 05-Jul-2018




0 download

Embed Size (px)


<ul><li><p>THE ADVANCED COMPUTING SYSTEMS ASSOCIATION</p><p>The following paper was originally published in the</p><p>Proceedings of the Workshop on Intrusion Detectionand Network Monitoring</p><p>Santa Clara, California, USA, April 912, 1999</p><p>Intrusion Detection and Intrusion Preventionon a Large Network: A Case Study</p><p>Tom Dunigan and Greg HinkelOak Ridge National Laboratory</p><p> 1999 by The USENIX AssociationAll Rights Reserved</p><p>Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercialreproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper.USENIX acknowledges all trademarks herein.</p><p>For more information about the USENIX Association:Phone: 1 510 528 8649 FAX: 1 510 548 5738Email: WWW:</p></li><li><p>Intrusion Detection and Intrusion Prevention on a Large Network.A Case Study.</p><p>Tom Dunigan, Network ResearchOak Ridge National Laboratory</p><p>Greg Hinkel, Computer &amp; Network SecurityOak Ridge National Laboratory</p><p>Abstract</p><p>This paper describes the general requirements for anIntrusion Prevention and Detection System and themethods used to prevent and detect intrusions into OakRidge National Laboratory's network. In this paper wedescribe actual intrusions, how they were detected, andhow they were handled. We also describe themonitoring tools we use for detecting intrusions.</p><p>Introduction</p><p>At Oak Ridge National Laboratory (ORNL), we have anopen environment in which researchers around theworld must collaborate with ORNL researchers. Theseusers want and need easy access to each other's data,programs, and correspondence. Furthermore, many ofthe researchers have been accustomed to unfetteredaccess to and from the Internet. Obviously, we alsohave data that should not be available to external users.</p><p>Our network consists of approximately 18,000computers running a variety of operating systems,including UNIX, VMS, Windows, and MacOS. Ourusers abilities range from "untrained" desktop users tohighly trained supercomputer programmers.</p><p>An open environment like ORNL's poses many securityconcerns. The dynamic nature of the work performed atORNL introduces additional security concerns in thatnew project initiatives, with new users and newcomputers, begin almost daily. These new projectsoften create sudden increases in network activity fromnew and different computer systems, and the suddenincreases make it difficult to weed out "new project"traffic from intrusion attempts. Also, many of our"users" are not physically located at ORNL. Trying todetermine if a remote user is the "legitimate user" is notan easy task. The question, "Was login informationsniffed by a hacker who is now logging in?," is quitedifficult to answer.</p><p>A security plan is essential. Knowing what to lookfor takes time, experience, diligence, and a lot ofluck. Our plan needed to answer the followingquestions.</p><p> What is the threat? What can happen if an intrusion occurs? What should we watch for? What should we report?</p><p> What should our intrusion detectionsystem report to us?</p><p> Should we report intrusions to someoneand if so, to whom?</p><p> What should we do if and when we suspectan intrusion?</p><p>Intrusion prevention is our goal. However, it wasclear that we would not be able to completelyprevent intrusions, so we decided to:</p><p> try to reduce the number of possibleintrusions, and</p><p> quickly detect any intrusions that did occur. </p><p>A simple solution to intrusion prevention anddetection was not possible at ORNL. Trying toreduce the number of intrusions would have to beaccomplished by providing secure mechanisms forend users to access their computer systems and theneducating those users and their systemadministrators about the proper use of those securemechanisms. Additional hardware and softwarewould be required for intrusion detection. Detectingintrusions in real time is preferable and in isolatedcases is possible. However, to reduce the likelihoodof terminating a legitimate connection and to bemore effective at detecting intrusions, it was clearthat we would have to log and analyze users'activities. There are commercial packages thatsatisfy some of our requirements; however, nonewould satisfy all of our requirements. Therefore, wehad to implement a specialized program that usedcommercial packages in conjunction with solutionsdeveloped in-house.</p><p>At ORNL, we use a layered approach to networksecurity because multiple layers make penetration</p></li><li><p>more difficult while making detection a bit easier. Wedefine our layers as follows:</p><p>1. firewall for limiting access,2. external monitoring for detecting attacks,3. internal monitoring for detecting attacks and</p><p>reducing vulnerabilities,4. system administration for reducing</p><p>vulnerabilities, and5. end users for reducing vulnerabilities.</p><p>The security staff must be knowledgeable securityprofessionals and they must:</p><p> know what to look for (i.e., what kinds ofattacks might occur?);</p><p> know what they are seeing (i.e., what does thedata "on the wire" or in the log filesrepresent?);</p><p> know (or have an idea) what to do if theircomputers come under attack and know who tocontact for additional information or assistance;and</p><p> educate the users and system administratorsabout computer and network security issues,and keep them informed of current attackmethods and counter measures.</p><p>We think it is important for the security staff to have agood rapport with users. Users and systemadministrators should trust the security professionalsand look to them for advice; users should be able todepend on the security professionals to keep themabreast of current attack methods and countermeasures.</p><p>At ORNL, we need fast data collecting machines thatare tightly controlled, with all unneeded services turnedoff. Encrypted communication is the only means ofentry into these machines (except for console access).Our security staff is trained to use these encryptedchannels correctly.</p><p>We also need plenty of disk space for log files becausewe planned to keep at least one month's worth of dataonline.</p><p>Policy Decisions</p><p>Q. What is the threat?A. We generally consider the users on our network tobe "trusted." Our main concern is people outside ournetwork trying to get into our network. Many of ourusers log in through their ISP (Internet ServiceProvider); from a conference floor; or from a remotenetwork (e.g., at a collaborator's site) using insecureapplications, such as telnet, ftp, or POP. Therefore, wehave determined that our biggest threat is fromauthorized remote users who access our machines andhave their login information sniffed at the remote site. </p><p>Our second greatest threat is misconfigured orunpatched systems. We have several users thatcannot (or do not want to) spend time/money toensure the integrity of their machines, or they do notunderstand the threat and importance of keepingtheir machines secured. Our computers have been"hacked" because of "misconfigured" or unpatchedsystems. However, our decision to use a commercialsecurity package, Internet Security Scanner (ISS),and to develop customized tools for checking fornetwork vulnerabilities, have significantly reducedour vulnerabilities. An internal scan may show no vulnerabilities oneday, but that is no assurance that a vulnerabilitywill not be present the next day. For example, wescanned our address space for "named" service andnotified appropriate system administrators ofpotential vulnerabilities. The day after that scan,one of our users rebooted his machine fromWindows 95 to Linux, which was running anunpatched "named." That night our network wasscanned by a remote site, and that machine wascompromised via a buffer overflow in "named."</p><p>Q. What can happen if an intrusion occurs?A. Possible problems for us include:</p><p>1. loss of data;2. modification of data, which can be more</p><p>serious than loss of data;3. misuse of equipment;4. loss of employee time and/or CPU time;5. time spent assessing damage and cleaning</p><p>up; and6. embarrassment to the company/project/</p><p>individual.</p><p>Q. What should we watch for and what should ourintrusion detection system report to us?A. Because our biggest security threat is legitimateusers having their login information sniffed at aremote site, we need to watch for unusual activityfor each user. For example, if a user typically logsin from Knoxville and suddenly logs in from Peru,we need to be notified. Likewise, if a user typicallyuses a computer for editing, compiling, and runningFORTRAN programs, and suddenly begins usingIRC (Internet Relay Chat), we need to be notified.Following the activity patterns of users requiresmonitoring the commands they issue, which meanta network keystroke logger was needed. Because port scanning is very popular and becausewe need to watch other network services (in additionto those that the keystroke logger picks up), itseemed prudent to detect incoming connectionrequests, which meant we also needed a "touchlogger." </p></li><li><p>These monitors do not usually provide real-timenotification, so we use a third party Intrusion DetectionSystem (IDS) which does provide real-timenotification. We also knew that there would be timeswhen we would have to monitor specific services and/orhosts (for "special case" needs), so we added anadditional machine for this purpose.</p><p>Q. What should we do if/when we suspect anintrusion?A. Possible actions are:</p><p>1. remove compromised machine from thenetwork,</p><p>2. setup additional monitoring,3. deny access to effected machines and/or</p><p>subnets,4. deny access to specific users, and5. notify essential personnel.</p><p>Q. Should we report intrusions (and attempts), and towhom should we report them?A. We decided to report everything we determined tobe "unfriendly activity." We report them to CIAC aswell as to the registered administrator of the "attacking"subnet. We notify others as necessary, such asAUSCERT and EUROCERT. Our hope is that bynotifying central security facilities, information aboutattacking sites could be disseminated to other"legitimate" facilities who could then watch moreclosely for activity from those sites. We have alsoreceived very favorable responses from ISPs, where, inmany cases, accounts were terminated. Figure 1 showsthe number of messages we sent to remote sites in1998, as well as the number of intrusions that we hadlast year.</p><p>Figure 1</p><p>Hardware Configuration</p><p>At ORNL, we have several dedicated computersystems that collect network data coming from andgoing to external networks. They are all time-synchronized to ensure accurate "reconstruction" ofeach attack. Time synchronization is also necessarybecause with that information, personnel at theoffending site can track the attacker much moreeasily.</p><p>These machines log successful and unsuccessfulTCP connections, UDP packets, and userkeystrokes with tools developed in-house. Anadditional computer logs selected connections andsessions with a third party IDS package. Anothersystem assimilates the data, processes it, andgenerates human readable reports, which are mailedto security personnel several times a day. Thesereports show "interesting" traffic patterns, where"interesting" is defined as things that appear to bepotentially unfriendly. A few examples follow:</p><p> external machines connecting to TCP ports111 (portmap) or 15 (netstat) or UDP port31337 (the default for BackOrifice),</p><p> external machines attempting to log into ourcentral name servers,</p><p> external hosts scanning internal hosts orports,</p><p> connections to/from local hosts that haverecently been compromised,</p><p> connections to/from hosts that have recentlybeen the source of an attack, or</p><p> hosts that generate the most network traffic.</p><p>1998 Probes and Intrusions</p><p>13</p><p>21</p><p>28</p><p>40</p><p>48</p><p>61 6064</p><p>78</p><p>55</p><p>69</p><p>101</p><p>2 1 1 1 3 3 2 0 2 0 0 00</p><p>20</p><p>40</p><p>60</p><p>80</p><p>100</p><p>120</p><p>Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec</p><p>ORNL Probes/ReportsORNL Intrusions</p></li><li><p>We have additional computers that can be used for"special case" monitoring when needed. Such specialcases would include monitoring all traffic going to/froma given host or subnet (in the case of a hacked system),or it may include collecting all data related to aparticular port (in the case of an ongoing port scan). These machines also can be configured to provide real-time alerts for specific activities.</p><p>Logging all TCP connections, whether successful ornot, helps in the detection of port scans and also isvaluable in determining where an attacker comes fromand goes after gaining access to one of our machines. We also use this information to determine which of ourcomputers respond to particular services. When anattacker runs a port scan against our computers, wecollect the responses so that we can follow up on them(hopefully before the attacker does).</p><p>Our most useful intrusion detection tool is our"keystroke logger," which records session keystrokes. It is virtually impossible to detect intrusions withoutthis tool. Because our users log in from around theworld at all times of the day and night and all havedifferent tasks, it is not possible to determine authorizedsessions from unauthorized sessions by simply lookingat the connections. Also, attackers often "clean up"system log files, so relying on end users and systemadministrators is not sufficient. Our reviews of users'keystrokes often indicates hacker activity.</p><p>Additional computers can be placed on selected subnetsfor special-case monitoring or for "replacement" of ahacked system. We do this to learn "back door"accounts that the attacker may have planted, as well asto learn more about the attacker's methods. Case 3below shows an example of a modified telnet daemonthat appears, to the attacker, to allow access to arecently compromised system for a given user. In thatcase, we held the attackers attention long enough tocontact his ISP and determine his location.</p><p>Implementation</p><p>At ORNL, we use a layered approach to networksecurity because multiple layers make penetration moredifficult while making detection a bit easier. Ourlayers, both physical and administrative, are defined asfollows:</p><p>1. a firewall,2. external monitoring,3. internal monitoring,4. system administration, and5. end users.</p><p>Our layered approach follows:</p><p>1. A Firewall.</p><p>A firewall is used to limit access to ournetwork. Services, hosts, and subnets areselectively permitted or restricted fromaccessing our network. Occasionally, localhosts are restricted from accessing theInternet.</p><p>2. External Monitoring. Several computers, as mentionedpreviously in "Hardware Configuration,"are set up to monitor traffic coming fromand going to our network. These machinesdetect probes and intrusion attempts andalert security personnel of such events.</p><p>3. Internal Monitoring.We have several machines (honeypots)instrumented and alarmed to notify securitypersonnel of particular events (e.g., afollow-up attack trying to exploit avulnerability in a service that an attackeridentified through a previous port scan). We also have our main WEB, mail, andDNS servers instrumented to notifysecurity personnel of suspicious events,such as a...</p></li></ul>