Bảo mật hệ thống mạng part 53 pps

APPENDIX C Resources to Learn More About Security 361 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. P eople constantly ask about places to learn more about security. Unfortunately, there are very few places that have intensive programs. The following is a list of organizations that sponsor security-related conferences. This is far from an ex - haustive list but it will provide a pointer to the majority of the large security confer - ences. It should also be noted that a number of technical conferences are featuring security tracks so it may be possible to find a conference in your area of interest that will also teach about security. ▼ Computer Security Institute (http://www.gocsi.com) CSI runs the annual Computer Security Conference and Exhibition as well as the NetSec conference. Other seminars are held throughout the year. ■ SANS Institute (http://www.sans.org) SANS runs approximately four major and nine regional conferences each year. They also have online training programs and e-mail newsletters. ■ MIS Training Institute (http://www.misti.com) MIS runs a number of conferences each year including INFOSEC and WebSEC. They also hold a number of smaller conferences targeted at specific industries, such as HealthSec, as well a smaller symposia and seminars. ■ USENIX (http://www.usenix.org) USENIX runs a number of technical conferences every year. Most of them have security tracks within the larger conference. USENIX also holds an annual Security Symposium. ■ Forum of Incident Response and Security Teams (http://www.first.org) FIRST holds an annual conference specially regarding incident response issues. ■ IEEE Computer Society Technical Committee on Security and Privacy (http://www.ieee-security.org) The IEEE holds an annual Symposium on Security and Privacy as well as a workshop on Computer Security Foundations. ■ Recent Advances in Intrusion Detection (http://www.raid-symposium.org) RAID holds annual conferences regarding intrusion detection. These conferences are focused internationally. ■ International Federation for Information Processing (http://www.ifip.tu-graz.ac.at/TC11/) The IFIP runs an annual conference in information security. The IFIP is focused internationally as well. ■ Internet Society (http://www.isoc.org) The Internet Society runs an annual conference on Internet security called the Network and Distributed System Security Symposium. ▲ Annual Computer Security Applications Conference (http://www.acsac.org) The ACSAC is an annual conference that focuses on the application of security to real-world environments. 362 Network Security: A Beginner’s Guide APPENDIX D Incident Response Procedure Testing Scenarios 363 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. I n many sections of this book we have talked about testing plans and procedures. No - where is this more important than with the Incident Response Procedure. Unfortu - nately, it is sometimes difficult to come up with testing scenarios. The following scenarios are provided to be used as is or modified to suit your environment. Some work well as dry runs with the team sitting around a conference table. Others will work better as live, unannounced tests. Recommendations are made for how each may be used and you are free to use or to change them as you see fit for your organization. For each of the scenarios, I will provide a brief description of the event for the person running the test. The “Initial Indications” section is what can be told to the incident re - sponse team. “What Really Happened” provides you (the person running the test) with all of the information that you will need to give appropriate answers to team member questions. In the “What the Team Will Find” section, I attempt to anticipate what the team might do to learn what is going on. Provide this information to the team as they be - gin to respond to the incident. In “Scenario Closeout,” I will give you a recommended end point for each scenario and key points to make to the team with regard to the scenario. SCENARIO 1—WEB PAGE HACK Scenario 1 is the all too familiar situation of a Web site being defaced. The Web server is running on Windows NT 4.0 under IIS. The Web server is behind a firewall, and the firewall policy blocks all traffic to the Web server but port 80. Initial Indications The organization is alerted to the fact that the site has been hacked by a customer who goes to the Web page over a weekend. He calls the organization and tells them about it. The new Web page is written in Portuguese and seems to claim the Web site has poor security. What Really Happened Someone left Microsoft FrontPage Extensions on the system and allowed external access to author.dll. The evidence of this hack is all in the IIS log files. Only the Web site files were modified. The attacker could not get to any other files on the Web server. What the Team Will Find If the firewall logs are examined, they will show normal Web traffic to the site and no other scans or dropped packets. If the organization has an intrusion detection system, it will not show any alarms. No unusual processes are running on the Web server, and the Web server event logs show no failed login attempts or unusual log messages. If the Web server logs are examined, they will show that the attacker requested the URL for author.dll. Further examination of the Web server will show no other exploitable vulnerabilities, but it will show that FrontPage Extensions were left turned on. 364 Network Security: A Beginner’s Guide Scenario Closeout End the scenario after the team checks the Web server logs. The key point in this scenario is to check all of the available logs, not just the firewall and event logs. If you allow your organization to have an IDS in place, they will complain that the IDS should have seen the attack. The answer to this is “not necessarily,” as the URL for author.dll is not an attack per se and thus may not be captured by many IDS detectors. Variations Variations can make this scenario more realistic. Below you can find two such variations: Variation A adds a public relations twist while Variation B adds the possibility that sensi - tive customer information may have been obtained by the intruder. Variation A For an added twist if you wish to exercise your Public Relations department, the cus - tomer called not only your organization but also the local TV station. The story makes the evening news and the TV station is calling for an interview. The reporter will know that the site was hacked and will attempt to rush information out of the organization in time for the reporter’s deadline (say, in 30 minutes). You can use real time for this part to make it more realistic. Talk with your Public Relations department about how the reporter should have been handled or what information should have been provided. Variation B In addition to modifying the Web site, the logs indicate that sensitive information that was located on the Web server was uploaded by the attacker (as part of the FrontPage capture of the Web site). No information is available as to what the attacker may have done with the information. The information contains customer information. Recommended Use Scenario 1 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. Make sure to specify the time and day of the week of the attack (making it a weekend can add some interest). As the team tells you what actions they take, give them the results of these actions. SCENARIO 2—UNEXPLAINED HIGH TRAFFIC VOLUME In this scenario, a warez site (someplace hackers place illegal copies of software) is estab - lished on your Web server. This type of situation may go unnoticed for quite some time until the high traffic volume on the site causes problems with legitimate traffic. Appendix D: Incident Response Procedure Testing Scenarios 365 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. . deadline (say, in 30 minutes). You can use real time for this part to make it more realistic. Talk with your Public Relations department about how the reporter should have been handled or what. by the intruder. Variation A For an added twist if you wish to exercise your Public Relations department, the cus - tomer called not only your organization but also the local TV station. The story. that sensitive information that was located on the Web server was uploaded by the attacker (as part of the FrontPage capture of the Web site). No information is available as to what the attacker