THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the Workshop on Intrusion Detection and Network Monitoring Santa Clara, California, USA, April 9–12, 1999 Intrusion Detection and Intrusion Prevention on a Large Network: A Case Study Tom Dunigan and Greg Hinkel Oak Ridge National Laboratory © 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Intrusion Detection and Intrusion Prevention on a Large Network. A Case Study. Tom Dunigan, Network Research Oak Ridge National Laboratory Greg Hinkel, Computer & Network Security Oak Ridge National Laboratory Abstract A security plan is essential. Knowing what to look for takes time, experience, diligence, and a lot of This paper describes the general requirements for an luck. Our plan needed to answer the following Intrusion Prevention and Detection System and the questions. methods used to prevent and detect intrusions into Oak • What is the threat? Ridge National Laboratory's network. In this paper we • What can happen if an intrusion occurs? describe actual intrusions, how they were detected, and • What should we watch for? how they were handled. We also describe the • What should we report? monitoring tools we use for detecting intrusions. – What should our intrusion detection system report to us? – Should we report intrusions to someone Introduction and if so, to whom? • What should we do if and when we suspect At Oak Ridge National Laboratory (ORNL), we have an an intrusion? open environment in which researchers around the world must collaborate with ORNL researchers. These Intrusion prevention is our goal. However, it was users want and need easy access to each other's data, clear that we would not be able to completely programs, and correspondence. Furthermore, many of prevent intrusions, so we decided to: the researchers have been accustomed to unfettered • try to reduce the number of possible access to and from the Internet. Obviously, we also intrusions, and have data that should not be available to external users. • quickly detect any intrusions that did occur. Our network consists of approximately 18,000 A simple solution to intrusion prevention and computers running a variety of operating systems, detection was not possible at ORNL. Trying to including UNIX, VMS, Windows, and MacOS. Our reduce the number of intrusions would have to be users abilities range from "untrained" desktop users to accomplished by providing secure mechanisms for highly trained supercomputer programmers. end users to access their computer systems and then educating those users and their system An open environment like ORNL's poses many security administrators about the proper use of those secure concerns. The dynamic nature of the work performed at mechanisms. Additional hardware and software ORNL introduces additional security concerns in that would be required for intrusion detection. Detecting new project initiatives, with new users and new intrusions in real time is preferable and in isolated computers, begin almost daily. These new projects cases is possible. However, to reduce the likelihood often create sudden increases in network activity from of terminating a legitimate connection and to be new and different computer systems, and the sudden more effective at detecting intrusions, it was clear increases make it difficult to weed out "new project" that we would have to log and analyze users' traffic from intrusion attempts. Also, many of our activities. There are commercial packages that "users" are not physically located at ORNL. Trying to satisfy some of our requirements; however, none determine if a remote user is the "legitimate user" is not would satisfy all of our requirements. Therefore, we an easy task. The question, "Was login information had to implement a specialized program that used sniffed by a hacker who is now logging in?," is quite commercial packages in conjunction with solutions difficult to answer. developed in-house. At ORNL, we use a layered approach to network security because multiple layers make penetration more difficult while making detection a bit easier. We Our second greatest threat is misconfigured or define our layers as follows: unpatched systems. We have several users that 1. firewall for limiting access, cannot (or do not want to) spend time/money to 2. external monitoring for detecting attacks, ensure the integrity of their machines, or they do not 3. internal monitoring for detecting attacks and understand the threat and importance of keeping reducing vulnerabilities, their machines secured. Our computers have been 4. system administration for reducing "hacked" because of "misconfigured" or unpatched vulnerabilities, and systems. However, our decision to use a commercial 5. end users for reducing vulnerabilities. security package, Internet Security Scanner (ISS), and to develop customized tools for checking for The security staff must be knowledgeable security network vulnerabilities, have significantly reduced professionals and they must: our vulnerabilities. • know what to look for (i.e., what kinds of attacks might occur?); An internal scan may show no vulnerabilities one • know what they are seeing (i.e., what does the day, but that is no assurance that a vulnerability data "on the wire" or in the log files will not be present the next day. For example, we represent?); scanned our address space for "named" service and • know (or have an idea) what to do if their notified appropriate system administrators of computers come under attack and know who to potential vulnerabilities. The day after that scan, contact for additional information or assistance; one of our users rebooted his machine from and Windows 95 to Linux, which was running an • educate the users and system administrators unpatched "named." That night our network was about computer and network security issues, scanned by a remote site, and that machine was and keep them informed of current attack compromised via a buffer overflow in "named." methods and counter measures. Q. What can happen if an intrusion occurs? We think it is important for the security staff to have a A. Possible problems for us include: good rapport with users. Users and system 1. loss of data; administrators should trust the security professionals 2. modification of data, which can be more and look to them for advice; users should be able to serious than loss of data; depend on the security professionals to keep them 3. misuse of equipment; abreast of current attack methods and countermeasures. 4. loss of employee time and/or CPU time; 5. time spent assessing damage and cleaning At ORNL, we need fast data collecting machines that up; and are tightly controlled, with all unneeded services turned 6. embarrassment to the company/project/ off. Encrypted communication is the only means of individual. entry into these machines (except for console access). Our security staff is trained to use these encrypted Q. What should we watch for and what should our channels correctly. intrusion detection system report to us? A. Because our biggest security threat is legitimate We also need plenty of disk space for log files because users having their login information sniffed at a we planned to keep at least one month's worth of data remote site, we need to watch for unusual activity online. for each user. For example, if a user typically logs in from Knoxville and suddenly logs in from Peru, we need to be notified. Likewise, if a user typically Policy Decisions uses a computer for editing, compiling, and running FORTRAN programs, and suddenly begins using Q. What is the threat? IRC (Internet Relay Chat), we need to be notified. A. We generally consider the users on our network to Following the activity patterns of users requires be "trusted." Our main concern is people outside our monitoring the commands they issue, which meant network trying to get into our network. Many of our a network keystroke logger was needed. users log in through their ISP (Internet Service Provider); from a conference floor; or from a remote Because port scanning is very popular and because network (e.g., at a collaborator's site) using insecure we need to watch other network services (in addition applications, such as telnet, ftp, or POP. Therefore, we to those that the keystroke logger picks up), it have determined that our biggest threat is from seemed prudent to detect incoming connection authorized remote users who access our machines and requests, which meant we also needed a "touch have their login information sniffed at the remote site. logger." Hardware Configuration These monitors do not usually provide real-time notification, so we use a third party Intrusion Detection At ORNL, we have several dedicated computer System (IDS) which does provide real-time systems that collect network data coming from and notification. We also knew that there would be times going to external networks. They are all time- when we would have to monitor specific services and/or synchronized to ensure accurate "reconstruction" of hosts (for "special case" needs), so we added an each attack. Time synchronization is also necessary additional machine for this purpose. because with that information, personnel at the offending site can track the attacker much more Q. What should we do if/when we suspect an easily. intrusion? A. Possible actions are: These machines log successful and unsuccessful 1. remove compromised machine from the TCP connections, UDP packets, and user network, keystrokes with tools developed in-house. An 2. setup additional monitoring, additional computer logs selected connections and 3.