Network Working Group Kathleen Moriarty Internet Draft Hudson Williams, Inc. Expiration Date: June 2000 November 2000 DDoS Incident Handling: Management Information Base to trace Incidents - Revision 1 draft-moriarty-ddos-mib-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Distribution of this memo is unlimited. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Table of Contents 1.1 Abstract.................................................1 2.1 Internet Security Incidents..............................2 3.1 Proactive ISP Monitoring.................................2 4.1 Tracing Internet Security Incidents......................3 4.2 Tracing an attack with filters...........................3 4.3 Trace approach via SNMP..................................4 4.3.1 SNMP Trace Implementation..............................4 5.1 Communication amongst ISPs...............................8 6.1 Summary..................................................9 7.1 References...............................................9 8.1 Author Information.......................................9 Moriarty [Page 1] Internet-Draft November 2000 1.1 Abstract One of the latest trends in Internet security is the distributed Denial of Service (DDoS) attack. Internet Service Providers (ISPs) need to be equipped and ready to assist in tracing these attacks with tools and procedures in place before the occurrence of a DDoS attack. This paper proposes a proactive system as well as an SNMP based tracing mechanism that can be used by ISPs to identify the source(s) of an attack. It is imperative that ISPs have defined quick communication methods to implore the assistance of neighboring ISPs to assist in tracking a security incident across the Internet. 2.1 Internet Security Incidents There have been a number of recent Distributed Denial of Service attacks against high profile Internet companies such as Yahoo and E- Bay. These attacks are characterized by large amounts of traffic destined for a particular Internet locations and can originate from multiple sources. Tracing a DDoS attack can be extremely difficult or near impossible as a result of the nature of the attack. The attacks can be launched from systems across the Internet unified in their efforts or by compromised systems that are controlled by servers, which can provide anonymity as to the true origin of the attack. The compromise of these systems can occur through means such as a hacker releasing a Trojan within a seemingly innocent program. An unknowing end user installs the program, which provides a backdoor to their computer for the hacker to use later. The attacker then determines where the compromised systems are and can initiate an attack through the use of the compromised hosts. The attacks typically seek to hide their origin through the use of other systems as well as altering the packets to spoof the source. In order to mitigate the effects of an attack, measures can be taken at ISP border routers providing ingress, egress, and broadcast filtering. These filters would ensure that the traffic leaving and entering client locations would contain valid source and destination addresses. 3.1 Proactive ISP monitoring ISPs typically manage and monitor their networks from a centralized network management system. This system usually performs trending analysis for bandwidth utilization as well as reporting communication problems. As a part of the bandwidth trending analysis performed, denial of service detection or unusually unexpected increases in bandwidth could also be reported or cause an alert to be generated. With the capabilities of the network management server to see the entire network, it could be used to trace to the origin of the traffic. This would enable ISPs to become proactive in handling denial of service attacks through the use of tools already in existence on Moriarty [Page 2] Internet-Draft November 2000 their networks. This concept may require the use of an additional server if trending is not already performed for bandwidth utilizations. The program would also need to account for traffic redirection resulting in bandwidth fluctuations due to networking problems in other areas of an ISP's backbone. Ideally, this system would have the ability to perform a trend analysis on the network to determine if there was an unusually large increase in traffic without explanation, such as a network event elsewhere on the backbone. Once it can be determined that the event may be significant, a trace of the increased traffic should be determined through analysis on the neighboring connections on the network. If possible, the trace could also drill down into the packets to determine any pattern so reverse path may be easier to identify. This may be accomplished through identifiers in the IP packet such as the source and destination IP addresses or ports or if there are any flags set in the packets, which would distinguish them from other packets. The incident along with any available automated trace data should trigger an alert to the ISPs security team for further investigation. 4.1 Tracing Internet Security Incidents DDoS attacks are difficult or near impossible to trace because of the nature of the attack. Some of the difficulties in tracing these attacks are o The attack may originate from multiple sources o The attack may include various types of traffic meant to consume server resources such as a SYN flood attack o The type of traffic could include valid destination services that the client end cannot block without hurting their business such as DNS or HTTP requests. o The attack could also include ICMP or other traffic that may be dropped at the client border router, but has the side effect of consuming the sites bandwidth and preventing valid connections from reaching their servers If the source(s) of the attack cannot be determined from tracing the increased bandwidth utilization, it may be possible to trace the traffic based on the type of packets seen by the client. This paper proposes two methods that can be used to trace back to the source of an attack, one via filtering and the other via an SNMP implementation. 4.2 Tracing an attack with filters The MCI Security team wrote a program a few years back to identify the origin of a SYN flood attack. The program started at the ISP border router for a client and determined if the router was seeing the attack. If the router was passing this traffic it would then go out to each of the neighboring routers and determine if the neighboring router was also seeing this SYN flood attack. If the router did not see the traffic, the program Moriarty [Page 3] Internet-Draft November 2000 would cease at that router. If the traffic was seen another iteration would take place until the source of the traffic or bordering ISP was identified. ________ | router | |________| ________ ________|--------->---------| | router |--------X---------| router | |________| |________| ^ | | ________ | router | |________| ^ | | _________ _______ | router |------X--------| router| |_________| |_______| ^ | | _________ | router | |_________| Router trace of traffic from border router to source This method of detection could be generalized to trace back connections with the destination IP address and type of traffic seen by the site under attack. Since DDoS attacks may involve multiple source(s) with spoofed addresses, there may only be a small amount of traffic from each of the originating hosts making it difficult to trace back. The sources may also alternate the type of traffic as well as vary the sources from within the pool of servers launching the attack. Immediate action would need to be taken to have any hopes of locating the origin(s) of the attack. One method of implementing the trace described above would be to place a temporary filter list to permit the undesirable traffic and then log it through the routers. As in the SYN Flood detection script mentioned above, this trace would be initiated at the client's border router and would spider out to connected routers to trace back to the source. In the case of a DDoS attack, it may even be fruitful to locate one of the remotely controlled computers and then use that to try to locate the true source of the attack. This may not be a practical method that can be used by ISPs as many do not have the router resources Moriarty [Page 4] Internet-Draft November 2000 available to enable them to implement any filtering or logging on their backbones. 4.3 Trace approach via SNMP An SNMP variable might also be used to track the traffic passing through a router. If this was at a lower level in the router, there may be a way to implement this feature as not to utilize an excess of router resources. When tracing back an attack, the ISP could elect to enable this tracking feature and then poll the routers on their network for the types of traffic they are seeing during the attack. In order for this SNMP trace of traffic to be meaningful, the destination IP of the packet would be necessary as the traffic is traced back through the network. If the SNMP tracking implementation allowed for an IP destination to be set in the device (router) for tracking, this may be a viable means to trace back traffic quickly through a network. The implementation to allow for this functionality could be a logical extension to the IP group, which has similar functions for TCP, UDP and ICMP. The TCP information in the IP table contains similar entries for each connection, but lacks the counting function to maintain the information for incident tracing. The UDP objects contains local information to the device but does not contain session details because the traffic is connectionless. The ICMP objects maintains information on the number of each type of ICMP packets that traverse the router, but does not keep track of the source or destination IP address information. Below is a proposed extension to the IP group section of the mib to facilitate this proposal. 4.3.1 SNMP Implementation DestinationIP OBJECT-TYPE SYNTAX IPAddress ACCESS read-write STATUS optional DESCRIPTION "This variable is used to set the destination IP address of packets traversing the network to be used for tracing traffic back to the true source and determining the actual path taken." ::= { ip 24 } CapturedProtocol OBJECT-TYPE SEQUENCE { CapturedICMP(1) SEQUENCE, CapturedTCP (6) SEQUENCE, CapturedUDP (17) SEQUENCE, CapturedESP (50) COUNTER, CapturedAH (51) COUNTER, Moriarty [Page 5] Internet-Draft November 2000 CapturedSWIPE (94) COUNTER, OTHER (100) INTEGER } ACCESS read-only STATUS optional DESCRIPTION "IP protocols passing through router destined for the IP address specified in the DestinationIP group. All are set to zero initially and then set to 1 if there is a match for the destination IP address." ::= { DestinationIP 1 } CapturedICMP OBJECT-TYPE SYNTAX SEQUENCE { Echo-Reply0 COUNTER, Destintation-unreach3 COUNTER, Time-Exceed2 COUNTER, Source-Quench4 COUNTER, Redirect5 COUNTER, Echo8 COUNTER, Time-Exceed11 COUNTER, Traceroute30 COUNTER } ::= { CapturedProtocol 1 } Echo-Reply0 OBJECT-TYPE SYNTAX Counter ACCESS Read-Only STATUS Optional Description "Count of ICMP type 1 packets that have traversed the router or device" ::= { CapturedICMP 1 } . . . Traceroute30 OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS Optional Description "Count of ICMP type 1 packets that have traversed the router or device" ::= { CapturedICMP 31 } Moriarty [Page 6] Internet-Draft November 2000 CapturedTCP OBJECT-TYPE SYNTAX SEQUENCE { Port0 COUNTER, Port1 COUNTER, Port2 COUNTER, Port3 COUNTER, Port4 COUNTER, Port5 COUNTER, Port6 COUNTER, . . . Port65535 COUNTER } ACCESS read-only STATUS optional DESCRIPTION "Count of the number of packets passing through the router of this protocol and port. The count would be important in tracking a significant amount of traffic. A logical extension for intrusion detection would be the interface of the router that the traffic entered the router from to assist in tracing the traffic back to the origin. Port 0 is included even though it is invalid because spoofed or mangled packets can contain this as the destination port for a packet." ) ::= { CapturedProtocol 6 } Port0 OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION "count Of the number of packets destined for DestinationIP on port 0" ::= { CapturedTCP 0 } . . . Port65535 OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION Moriarty [Page 7] Internet-Draft November 2000 "count Of the number of packets destined for DestinationIP on port65535" ::= { CapturedTCP 65535 } CapturedUDP OBJECT-TYPE SYNTAX SEQUENCE { Port0 COUNTER, Port1 COUNTER, Port2 COUNTER, Port3 COUNTER, Port4 COUNTER, Port5 COUNTER, Port6 COUNTER, . . . Port65535 COUNTER } ACCESS read-only STATUS optional DESCRIPTION "Count of the number of packets passing through the router of this protocol and port. The count would be important in tracking a significant amount of traffic. A logical extension for intrusion detection would be the interface of the router that the traffic entered the router from to assist in tracing the traffic back to the origin. Port 0 is included even though it is invalid because spoofed or mangled packets can contain this as the destination port for a packet." ) ::= { CapturedProtocol 17 } Port0 OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION "count Of the number of packets destined for DestinationIP on port 0" ::= { CapturedUDP 0 } . . . Port65535 OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only Moriarty [Page 8] Internet-Draft November 2000 STATUS DESCRIPTION "count Of the number of packets destined for DestinationIP on port65535" ::= { CapturedUDP 65535 } CapturedESP OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION "Count of the number of ESP packets traversing the router or device destined for the set destination IP address" ::= ( CapturedProtocol 50) CapturedAH OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION "Count of the number of AH packets traversing the router or device destined for the set destination IP address" ::= ( CapturedProtocol 51) CapturedSwipe OBJECT-TYPE SYNTAX COUNTER ACCESS Read-Only STATUS DESCRIPTION "Count of the number of ESP packets traversing the router or device destined for the set destination IP address" ::= ( CapturedProtocol 94) 5.1 Communication amongst ISPs Expediting the communication between ISPs is essential when responding to a security related incident such as a denial of service attack which crosses network access points, (Internet backbones) between providers. As a result of the urgency involved in this inter-ISP security incident communication, there must be an effective system in place to facilitate the interaction. This system should involve multiple means of communication to avoid a single point of failure. Email may be the best way to transfer in formation about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call. Each ISP should dedicate a number to reach a member of their security incident response team. The phone number could be dedicated to inter- ISP incident communications and must be a Moriarty [Page 9] Internet-Draft November 2000 hotline that provides a 24x7 live response. The phone line should reach someone who would have either the authority and expertise or the means to expedite the necessary action to investigate the incident. This may be a difficult policy to establish at smaller ISPs due to resource limitations, so another solution may be necessary. An outside group may be able to serve this function given the necessary access to the ISPs network. The outside resource should be able to mitigate or alleviate the financial and experience resource limitations. Procedures for incident handling need to be established and well known by anyone that may be involved in incident response. The procedures should also contain contact information for internal escalation procedures as well as external assistance groups such as CERT, GIAC, and the FBI. 6.1 Summary Denial of service attacks have always been difficult to trace as a result of the spoofed sources. With the recent increasing trend toward using distributed denial of service attacks, it has become near impossible to identify the true source of an attack. ISPs need automated methods as well as policies in place in order to attempt to combat the hacker's efforts. Proactive monitoring and alerting of backbone and client bandwidth with trending analysis is an approach that can be used to help identify and trace attacks quickly without resource intensive side effects. Subsequent more detailed analysis could be used to complement the bandwidth monitoring. Timely communication between ISPs is essential in incident handling. 7.1 References [RFC1213] "Management Information Base for Network Management of TCP/IP-based internets: MIB-II". K. McCloghrie, M . Rose. March 1991. http://www.infowar.com/index.shtml?http://www.info- sec.com/denial/infosece.html-ssi 8.1 Author Information Kathleen M. Moriarty Hudson Williams, Inc. 11 Broadway New York, New York 10004 Phone: +1-212-422-9000 x32 Email: kmoriarty@hudsonwilliams.com Email: moriartk@cs.rpi.edu