Bảo mật hệ thống mạng part 43 docx

276 Network Security: A Beginner’s Guide MANAGING AN IDS The concept of intrusion detection is not new to security. However, it was not until re - cently that IDS systems have become available on the commercial market. As of this writ - ing, several network- and host-based IDS systems are available from different vendors. There are also several systems that are available at no cost. Before the decision is made for an organization to implement an IDS (commercial or not), the organization should understand what the goals of this program are to be. You will notice that IDS is not included in the recommended best practices in Chapter 8. This is not because intrusion detection does not work but because the value of intrusion detec - tion is not proven. The level of effort necessary to properly configure and manage an IDS is significant and this effort may be better spent performing intrusion prevention (by cre - ating a good security program). That being said, if an IDS is to be implemented, proper resources are necessary for a successful program. If the goals of the IDS program include the ability to monitor attacks on a 24/7 basis, staff members will be needed to respond at all hours of the day and night. At the same time, system administrators will be required to work with the security staff to determine if the attack was successful and if so, how the incident should be handled. Ideally, an incident-handling procedure will be created and tested prior to the implemen- tation of the IDS. Understanding What an IDS Can Tell You An intrusion detection system can only report what it has been configured to report. There are two components to an IDS configuration. First are the attack signatures that have been programmed into the system. Second are any additional events that the ad- ministrator has identified as being of interest. This may include certain types of traffic or certain types of log messages. With regard to the pre-programmed signatures, the vendor or the creator of the sys - tem has placed their own interpretation on the importance of these events. The impor - tance that should be assigned within a given organization may be very different than those assigned by the manufacturer. It may be appropriate to change the default priority settings on some signatures or just turn off signatures that do not apply to the organization. Keep in mind that the IDS will only warn of events that it sees. If the system being monitored by an H-IDS sensor does not log certain events, the H-IDS sensor will not see these events. Likewise, if a N-IDS sensor cannot see certain traffic, it will not alarm even if the event occurs. Understanding What an IDS Is Telling You Assuming that the IDS has been properly configured, there are three types of events that the IDS will show you: Chapter 14: Intrusion Detection 277 ▼ Reconnaissance events ■ Attacks ▲ Suspicious or unexplained events By far, the majority of time will be spent examining suspicious events. Reconnaissance Events Reconnaissance events are attempts by an attacker to gather information about a system or systems prior to an actual attack. These events can be divided into five categories: ▼ Stealthy scans ■ Port scans ■ Trojan scans ■ Vulnerability scans ▲ File snooping The majority of these events will occur on the network and most of those will occur from the Internet against systems with external addresses. Reconnaissance events are attempts to gain information about systems. They are not events that will compromise a system. Some commercial IDS systems configure recon- naissance events as high priority. Given that these events do not provide a mechanism to compromise a system, this seems inappropriate. It should be noted that the source of such traffic may be a compromised system and this information should be shared with the sys- tem administrators at that site. Stealthy Scans Stealthy scans are attempts to identify systems that exist on the network in such a way as to prevent the source system from being identified. This type of scan will appear as an IP Half Scan or IP Stealth Scan on N-IDS sensors and it will usually be tar - geted across a large number of IP addresses. The response to such a scan is to identify the source and inform the owner of the source system that it is likely a compromised system. Port Scans Port scans are used to identify the services offered by systems on the net - work. Intrusion detection systems will identify a port scan when some number of ports (the threshold) on a single system are opened in a short period of time. N-IDS sensors and some H-IDS sensors will identify a port scan and report it as such. The appropriate re - sponse to this type of scan is the same as that for a stealth scan. Trojan Scans There are many Trojan programs in existence. N-IDS sensors have signa - tures that identify many of them. Unfortunately, traffic to Trojan programs is often iden - tified by the destination port of the packet. This causes many false positives to be generated. In the case of a Trojan event, examine the source port of the traffic. Traffic that is sourced on port 80, for example, is likely to be return traffic from a Web site. 278 Network Security: A Beginner’s Guide The most common type of Trojan scan is that for BackOrifice. BackOrifice uses port 31337 and very often an attacker will scan a range of addresses for this port. The BackOrifice con - sole also includes a “ping host” function that will do this automatically. This is not something to worry about unless traffic from an internal system is seen. Again, the appropriate response is to contact the owner of the source system as the system is likely compromised. Vulnerability Scans Vulnerability scans will appear on an N-IDS as a large number of dif - ferent attack signatures. Usually, such scans are targeted at a few systems that do exist. It is unusual to see a vulnerability scan that targets a range of addresses without active systems. Vulnerability scans from hackers are impossible to distinguish from vulnerability scans performed by security testing firms. In any case, the scan itself is unlikely to com - promise a system but if a hacker performed the scan and any of the systems are vulnera - ble to an attack, the hacker now knows this information. The owner of the source system should be contacted and internal systems should be checked to make sure they are up to date on patches. File Snooping File snooping or the testing of file permissions is normally performed by an internal user. The user is attempting to identify which files can be accessed and what they may contain. This type of reconnaissance will only show up on an H-IDS sensor and only if the system is logging unauthorized access attempts. Single events are probably honest mistakes but if a pattern is seen, the user should probably be contacted to deter- mine what was being done. Attacks Attack events are the events that require the quickest response. Ideally, the IDS is config- ured to only identify a high priority event if a known internal vulnerability is exploited. In this case, the incident response procedure should be implemented immediately. Keep in mind that the IDS will not know the difference between an actual attack and a vulnerability scan that looks like an attack. The IDS administrator must evaluate the in - formation that is presented by the IDS to determine if it is an actual attack. The first thing to look for is the number of events. If a number of different attack signatures have been seen in a short period of time against the same system, it is likely a vulnerability scan and not a true attack. If a single attack signature is detected against one or more systems, it may be a real attack. Suspicious Events Events that do not conveniently fall into one of the other categories are left as suspicious events. A suspicious event is simply an event that is not understood. For instance, a Reg - istry key on a Windows NT server changed for no apparent reason. It does not appear to be an attack and there is no indication as to why it changed. Another example might be a packet with header flags that violate the protocol standard. Is this an attempted recon - naissance scan, a system with a bad network interface card, or a packet that took an error in transit? The information that is provided by the IDS does not provide sufficient infor - mation to answer the questions and identify the event as benign or an attack. Equally as suspicious might be unexpected network traffic that appears on an inter - nal network. If a desktop computer starts requesting SNMP information from other sys - tems, is this an attack or a badly configured system? Suspicious events should be investigated to the extent allowed by available resources. Investigating Suspicious Events When suspicious activity occurs, there are four steps that can be taken to determine if the activity constitutes an actual or attempted intrusion, or if it is benign behavior. These steps are 1. Identify the systems. 2. Log additional traffic between the source and destination. 3. Log all traffic from the source. 4. Log the contents of packets from the source. Following each of the steps, a determination should be made as to whether sufficient evidence has been found to identify the activity as an attack or not. There is one thing to keep in mind while investigating an event: If the event occurs once and does not repeat, it is very difficult to learn any additional information (other than where the traffic came from). Single anomalies are almost impossible to completely investigate. 1. Identify the Systems The first step in an investigation of suspicious activity is to identify the systems involved. This may just be a matter of resolving the IP addresses to host names. In some cases, the host name cannot be found (the system may not have a DNS entry, it could be a DHCP cli - ent, the remote DNS server may not be active, and so on). If the DNS lookup fails, you should attempt to identify the host by doing a lookup through other means such as the American Registry of Internet Numbers (ARIN) at http://www.arin.net, the Internic at http://www.networksolutions.com, or other Internet directories. Failure to identify the source or destination of the suspicious activity is not sufficient evidence that the event is actually an attack. Likewise, successful identification of the systems does not usually pro - vide evidence that the activity is benign. It should be noted that the source of the suspicious traffic might not be the ultimate source of an attempted attack. Denial-of-service attempts will usually have spoofed source addresses and unauthorized access attempts or probes may come from other systems an attacker has already exploited. 2. Log Additional Traffic Between the Source and Destination Seeing a single isolated event (such as an IP protocol violation) may not provide the com - plete story of traffic between two systems. In other words, it is important to understand Chapter 14: Intrusion Detection 279 280 Network Security: A Beginner’s Guide the context of the suspicious activity. A good example of this is the Sendmail WIZ attack signature. This is a signature that identifies an attempt to exploit the WIZ command in Sendmail. This security event identifies any instance of “WIZ” in a mail message. If WIZ occurs in the body of the message, it is clearly not an attempted intrusion. Understanding the context of the event helps to identify this as a false positive. Configure the IDS to look for all traffic between the source of the suspicious activity and the destination. An example can be found in Table 14-3. Now the question is: what does this tell us? First, it gives us an idea of what other traf - fic is occurring between the source and destination. If the WIZ packet were the only traffic between the two systems that would tell us that it might well have been an attempt to vio - late the system. On the other hand, if we find a large number of SMTP (mail) traffic be - tween the two systems, we are most likely looking at legitimate mail traffic. 3. Log All Traffic from the Source Assuming that the data collected by logging all the traffic between the two systems was insufficient to determine if the activity was legitimate or not, we can begin collecting other traffic from the source. Keep in mind that this may be somewhat limited. If the source of the suspicious activity is on some remote network, you will only be able to see traffic coming to your site. If the source is local, you may be able to collect all traffic from that machine and thus have a much better idea of what is really going on. To begin the collection of all traffic from the source, configure the IDS detector to col- lect all the information from the suspicious source. An example of such a configuration can be found in Table 14-4. This configuration is likely to generate some information that is not valuable to your investigation. As long as you can examine the information objectively, you can use this Event Name Action Source IP Destination IP Protocol Source Port Destination Port SUS_ACT Notify, Log Source of suspicious activity Destination of the suspicious activity TCP, UDP, and/or ICMP, depending on the type of activity seen Any Any Table 14-3. An Example IDS Configuration to Log all Traffic Between Two Systems TEAMFLY Team-Fly ® Chapter 14: Intrusion Detection 281 log to give you a good picture of the interactions that go on between the source and your site. Try to understand the activity that you are seeing. Is it Web traffic? Is it mail traffic? Does the traffic originate at the suspicious source or on your site? At this point in the investigation you should know ▼ The source system’s name ■ The type and frequency of traffic exchanged between the source and the destination ▲ The type and frequency of traffic exchanged between the source and any systems at your site This information gives you a pretty good idea as to the nature of the suspicious traffic. However, the evidence may not allow you to say this is or is not an attempted attack. 4. Log the Contents of Packets from the Source The final step in the investigation is to log the contents of the packets from the source. It should be noted that this technique is only useful on text-based protocols such as telnet, FTP, SMTP, and HTTP (to some extent). If binary or encrypted protocols are in use, this tech - nique is not helpful at all. To do this, modify your IDS configuration, as shown in Table 14-5. By logging the packet contents, you can gather a complete record of the session and what commands are actually being sent to the destination. Once you have captured some data, examine what you have found. Does the session in - dicate a potential attack or does it look legitimate? This information combined with the other information you have already gathered should provide the answer. If you cannot make the determination, try to find an individual with expertise in the protocol under investigation. Event Name Action Source IP Destination IP Protocol Source Port Destination Port SUS_SRC Notify, Log Source of suspicious activity Any TCP, UDP, and/or ICMP, depending on the type of activity seen Any Any Table 14-4. An Example IDS Configuration to Collect All Traffic from a Particular Source Address 282 Network Security: A Beginner’s Guide Event Name Action Source IP Destination IP Protocol Source Port Destination Port SUS_ACT Notify, Log packet contents Source of suspicious activity Destina tion of suspicious activity TCP or UDP Any Port to which the suspicious traffic is destined SUS_ACT Notify, Log packet contents Destina tion of suspicious activity Source of suspicious activity TCP or UDP Port to which the suspicious traffic is destined Any Table 14-5. An Example IDS Configuration to Capture Packet Contents PART IV Platform-Specific Implementations 283 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. This page intentionally left blank. . of activity seen Any Any Table 14-4. An Example IDS Configuration to Collect All Traffic from a Particular Source Address 282 Network Security: A Beginner’s Guide Event Name Action Source IP Destination IP. the suspicious traffic is destined Any Table 14-5. An Example IDS Configuration to Capture Packet Contents PART IV Platform-Specific Implementations 283 Copyright 2001 The McGraw-Hill Companies, Inc. Click