366 Network Security: A Beginner’s Guide Initial Indications The organization’s Help Desk is getting calls about slow response from the Internet. At about the same time, system administrators notice that the Web/FTP server is showing high disk utilization and little free space. No alarms have been set off that might indicate the system has been hacked or that the organization might be under some type of denial-of-service attack. What Really Happened Someone made a mistake on the FTP server configuration. This mistake left a writable directory where anonymous FTP users can access it. Someone noticed and placed a large amount of illegal copies of software on the system in a hidden directory. The sys - tem is now being accessed from around the world and copies of the software are being downloaded. What the Team Will Find Firewall logs show no attacks or unusual amounts of dropped traffic. If complete logging is enabled on the firewall, it will show a large amount of FTP traffic to the FTP server. The logs on the FTP server are showing a lot of requests for files. All requests are for files in the ~ftproot/… directory (note that there is a space after the third dot). If a directory listing is performed before the log file is checked, make sure the admin- istrator requests an ls –a listing to show the file. If the administrator tries to look into the file, he must make sure he changes to the correct directory (three dots and a space). Inside the directory, the administrators will find approximately five gigabytes of soft- ware including illegal copies of Windows software. The permissions on the FTP directory structure are wrong as they allow an anony- mous user to write files to the system. Scenario Closeout Once the directory has been found, allow the scenario to end after the administrators look for how this came about. Make sure they perform an ls –l on the directory to show the permissions. Recommended Use Scenario 2 is recommended for use with the team together in a conference room talking through the issues. Provide the initial indications to them and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. SCENARIO 3—FILES MODIFIED BY UNKNOWN PERSON This scenario can be kicked off by a file integrity checker or by an administrator noticing that files have been changed when they should not have been. The issue here is that the change was caused by an employee not following proper procedure, not a hacker. Appendix D: Incident Response Procedure Testing Scenarios 367 Initial Indications The initial alarm can be raised by a file integrity checker that detects a change to binary files on a server. If the organization is not using such a device, the administrator of the system might notice that certain files have changed when they should not have. What Really Happened In reality, this is not an attack at all but a developer moved new binaries to the system without following proper change control procedure. This meant that the file integrity checker and the system administrator were not notified of the change. What the Team Will Find Examination of the system will not find any indications of an attack. Logs will show that the last login (before the administrator) was a developer. The logs will not show what ac - tions the developer performed on the system. If the administrator looks in the devel - oper’s history file (on a Unix system), the actions of the developer can be seen. Scenario Closeout Allow the team to work through their procedures to determine if there really was an at- tack against the system. If the team identifies the possibility of an unauthorized configu- ration change, you can end the scenario there. If the team gets hung up on the lack of hacker evidence, you should end the scenario before the team gets too far down the rat hole of looking for an attacker. Recommended Use Scenario 3 can be used with the team together in a conference room or you could have someone make a change to a file on a system. This works best if your organization is using an automatic file integrity checker. If you do this around a conference table, provide the initial indications to the team and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. SCENARIO 4—UNAUTHORIZED SERVICE FOUND ON A SYSTEM Organizations should perform regular service and vulnerability scans of their internal systems. This scenario takes advantage of these regular scans by introducing an unautho - rized service on an internal system. There are several ways this scenario can be played out: the service could be a simple Web server on a high-numbered port, or you could make the service malicious, such as a Back Orifice server or a distributed denial-of- service controller. 368 Network Security: A Beginner’s Guide Initial Indications The initial indication of the event is the fact that a service scan identifies a new service running on an internal system. What Really Happened Depending on the variation you choose, the service could be a user who wants to run his own Web server or it could be a malicious program on a system. The third alternative is for a system administrator to have installed a new Web-enabled tool on the system. What the Team Will Find A scan of the system identifies the service running. Looking at the processes on the sys - tem may or may not show which process is using the port. If the system is a Unix system and lsof is used, the team will identify the process and can then trace it back to a user. Scenario Closeout Close out the scenario when the team identifies what the new service is and why it is in place on the system. Variations The variations below present different options for why the new service was started. Other variations can be constructed to make this scenario more appropriate for your environment. Variation A A user starts a Web server for his own use on the system. It is started from his cron file and thus will restart if it is stopped by the administrator. It is listening on port 8080. Variation B Either accidentally or on purpose, a user has loaded a back door program on the system. The program could be something like Back Orifice on a Windows system or it could be a distributed denial-of-service tool like Trinoo or TFN2K on a Unix system. Variation C A system administrator loads a new software tool that is Web-enabled and starts its own Web server on the system. Recommended Use Scenario 4 is recommended for live systems. The port can be opened on the system and found by a security scan or regular administrative checking. This is a good scenario for an unannounced test. Appendix D: Incident Response Procedure Testing Scenarios 369 SCENARIO 5—SYSTEM LOG FILE MISSING An administrator looking at a system notices a log file is missing. This scenario assumes that log files on Unix systems are rotated on a daily basis so it is very obvious that an en - tire log file is missing. Initial Indications The administrator of the system was examining the log files on the system and noticed that the messages file from the previous day was missing. All other log files appeared to be in the right location. What Really Happened The system in question was hacked. The attacker came through a buffer overflow in an RPC program and loaded a sniffer. The log file was deleted to cover evidence of the attack. What the Team Will Find Examination of the system will find a hidden directory under /usr/man/man4 called .hack. The directory contains a sniffer that is started by a cron job under root. The sniffer is running as a process called update. If this is a Solaris system, the team cannot see the sniffer by using ifconfig, they must load ifstatus first (see Chapter 15 for details on this). Running ps will show update run- ning out of /usr/man/man4/.hack, which should tip off the team. It will be impossible to identify what vulnerability was used to enter the system. Guesses could be made based upon vulnerabilities on the system, but conclusive proof was removed with the logs. Scenario Closeout Close out the scenario when the team finds the sniffer and determines where the file is on the system. You could also allow the team to work through the clean-up procedure. Recommended Use Scenario 5 is recommended for use with the team together in a conference room talking through the issues. Provide the initial indications to them and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. Alternatively, you could use this as a real scenario but you will have to have a system on which you can load the sniffer. SCENARIO 6—THE NETWORK IS SLOW Calls are coming into the Help Desk complaining about slow network response on the in - ternal network. In reality, a system has been configured with the same IP address as one of the routers. 370 Network Security: A Beginner’s Guide Initial Indications The calls to the Help Desk say it all—the network is running slow. There is no obvious sign that a security event has occurred, but the network staff is not sure what the problem is. What Really Happened Someone configured a system with the same IP address as a network router. Since all sys - tems on the subnet are using the router as the gateway off the subnet, traffic is very slow. The misconfigured system is also responding to all packets to the router’s IP address but not routing traffic. What the Team Will Find None of the systems on the network will show any signs of an attack. However, the net - work is very slow. If a sniffer is placed on the wire it will show the traffic problem. The team will have to look specifically for duplicate arp responses to identify the problem. Keep in mind that some sniffers will show duplicate IP addresses. Once the problem is identified, the team will have to find the misconfigured system. At this point, only the MAC address of the system will be known. Scenario Closeout Close out the scenario when the team learns of the duplicate IP address. Alternatively, you could continue until the team figures out how to find the misconfigured system. Recommended Use Scenario 6 is recommended for use with the team together in a conference room talking through the issues (unless you wish to cause problems on your network). Provide the ini - tial indications to them and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. SCENARIO 7—INTERNAL ROUTER ATTACK An internal router comes under a password-guessing attack. The attack is picked up by internal systems configured to alarm on multiple failed login attempts. Initial Indications If a mechanism exists to detect failed login attempts on internal routers, the system will pick up the attack and alarm. The source of the attack is an internal system. What Really Happened An internal employee is attempting to guess the password on an internal router. To do this, he has created a script that guesses various passwords on a continuous basis. TEAMFLY Team-Fly ® Appendix D: Incident Response Procedure Testing Scenarios 371 What the Team Will Find The source address of the attack is an internal system. The system could be a shared server or a desktop system. On the system, the team finds a script running that is attempting various password combinations against the router. NOTE: If the system is a shared system, the team will need to identify the correct process. Lsof will be needed if the system is a Unix system. Scenario Closeout Close out the scenario when the team identifies the script that is being used for the attack. Recommended Use Scenario 7 is a good scenario for a real-world test. The script can be written using perl and expect. Have the script run from a user’s account on an internal system and target one or more internal routers. Make sure that the network administrators will notice the failed login attempts before running the test. SCENARIO 8—VIRUS ATTACK Many employees in the organization receive Melissa- or ILOVEYOU-type e-mail viruses. The virus is activated and spreads throughout the organization. Initial Indications Initial indications are very slow e-mail responses and heavy loads on the e-mail servers. Some users may call the Help Desk and ask about problems. Later, the number of Help Desk calls increases as more and more employees see strange e-mails in their inboxes. What Really Happened Several employees received the e-mail and opened the attachments. The virus was new enough to not trigger the anti-virus software on the systems. The message was then sent to every employee in the organization. The organization is now fully infected. What the Team Will Find The team will find the virus script and they can create a script to get rid of the virus or they can create a manual procedure. Scenario Closeout This scenario is designed to work the team through a simple but large-scale incident in the organization. Once the team defines their approach to fixing almost all the desktop systems and removing the e-mail from the e-mail servers, the scenario should end. 372 Network Security: A Beginner’s Guide Recommended Use Scenario 8 is recommended for use with the team together in a conference room talking through the issues. Provide the initial indications to them and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. SCENARIO 9—THE IDS REPORTS AN ATTACK The organization has deployed a network-based IDS. The IDS reports an attack against one of the organization’s systems. Initial Indications The IDS shows an alarm. This alarm can be shown on the screen or the notification can be sent to the security team depending on how the organization has the system configured. What Really Happened An attack was launched against a system. The system was not vulnerable so the attacker did not gain access to the system. What the Team Will Find An examination of the system will show that the attack was not successful. The IDS cor- rectly reports the attack and the source (external to the organization). Scenario Closeout Close out the scenario when the team determines that the attack was not successful. Variation Launch an attack against the system that is successful. Have the team investigate the at - tack and identify the fact that it succeeded and what the attacker did to the system. Recommended Use Scenario 9 is recommended for use either with the team together in a conference room or as a real test of the Incident Response Procedure. SCENARIO 10—EXTORTION A high-level executive of your organization receives a demand for money. The demand states that if the money is not paid, the thief will either disclose sensitive information or bring down sensitive systems of the organization. Initial Indications The only indicator that the organization receives is the demand sent to the executive. There are no other indications. What Really Happened In this case, the extortion is a hoax. No systems were penetrated. What the Team Will Find Any systems that are searched will reveal no sign of penetration or signs of a back door that might allow the intruder to gain access to the systems. Scenario Closeout This scenario is designed to force the team to create a procedure to examine each system and to provide a concise recommendation to the senior management of the organization. When the team has defined a course of action, the scenario can end. Variations According to the latest information from the FBI, this scenario has really occurred at a number of organizations. As such, this scenario may prove to be somewhat realistic. The variations below will put additional pressure on the team. Time limits (like that proposed in Variation A) should not give the team sufficient time to do everything they have to do. Variation A For added pressure on the team, give the extortion demand a time limit. Have the team work through the exercise with that time limit in mind. Variation B Get the cooperation of one of the executives of the organization and have him deliver the news of the demand to the team. Recommended Use Scenario 10 is recommended for use with the team together in a conference room talking through the issues. Provide the initial indications to them and set the stage for the event. As the team tells you what actions they take, give them the results of these actions. Appendix D: Incident Response Procedure Testing Scenarios 373 This page intentionally left blank.