Implementation Guide Protecting the Network from Denial of Service Floods Juniper’ we Junip Part Nanber 801003-001 June 2008Protecting the Network from Denial of Service Floods Table of Contents Introduction 4 Scope 4 Design Considerations 4 Perimeter Locations and Roles 4 Denial of Service atacks 4 ‘Types of DoS Attacks 5 SYN Foods 5 CMP Foods 5 UDP Floods 5 ‘egal TCP Fag Flood 5 Disiibured DoS Floods 5 Spooted Address Floods 6 Adaptive Threat Management and bas tacks 6 Implementation Guidelines 7 iigating Large Scale DoS Artacks on the Nerwork 7 Opuizing che Firewall 8 Implementing Sttefl Inspection 8 Lmplementing Stef SYN Proxy Mechanisms ° Limiting the Number of SYNs per Second per Source I? ° Limiting the Number of SYNs per Second per Destination 1 10 Limiting the Number of Sessions per SourcelDestinatin IP 10 Preventing ICMP Floods 10 Preventing UDP Floods 0 opurniing the Router n Contguring }#low for Detecting Tale n Enable the Flow Collector atthe Interface: 2 Expont the Information to STAM 2 Ratediming TOP Contr Tate 2 Rate-Limiting [CMP 2 RateLimiting UDP 15 Ratedimitng Other IP Protocols 6 tmplementing Reverse Path Validation 15 Drop Non-tocal Subnets with Fikers 8 Responding to Large Floods 15 Responding Upstream 5 ‘satomating a Response % Configuring STAD 1“ Using STRM to Pot! Statistics Automatically 14 Using STRM to Determine Attack Status 15 2 ‘copie 62008,Protecting the Network ffom Denial of Service Floods, Summary 16 Appendix A Basolining Network Traffic using Router and Firewall Counters 17 Configuring the Router 7 Configuring the Firewall 18 Configuring NSM to Export Logs to STRM 19 Appendix 8 JUNOS Software Router Configuration for Counting Traffic 20 Appendix C Baseline SCREEN Serings at Appendix D Optimized Firewall Configuration 2 Appendix & Optimized Router Configuration 4 Appendix F Test Results 26 [About juniper Networks: 28 List of Figures Figure 1. Reference Test Network 7 Figure 2. Device, Layer. Optimization and Types of DoS Protections 7 Figure 5. Stateless Screening Routers Sutrounding Stateful Firewals, 8 Figure 4. Handling SYN-Cookie on Juniper Networks Firewall, " Figure 5. Communicating to Upstream ISP Devices to Address Floods 1“ Figure 6. STRM Dashboard Showing Attacks 15 Figure 7. STRM Offense Manager Showing DoS Attack Details 15 Figure 8. Detling Down on the Astacker 16 Figure 9. Action Parameters Window of NSM 19 Figure 10. Selecting Device Log Action Criteria on NSM 19 3 ‘oper 62008, pe NetwareProtecting the Network from Denial of Service Floods Introduction Scope Denial of Service (DoS) and Distributed DoS (DD05) floods are commonplace across today's Internet ‘This paper describes several types of DoS Noods that are plaguing today’s enterprise networks and describes in detal how to detect and counter them, Eninanced tools are now avatlable to analyze snd respond to these attacks, reducing complexity and streamlining operational responses. This document describes the steps necessary to optimize the network to survive the heaviest of floods and how to elfecwvely respond when they occur ‘This document helps the reader co implement Juniper Networks security products on their newwork to protect from external DoS and DDoS attacks on the network perimeter For the purposes of this document, we will focus on two strategies. a single Juniper Networks Secure Services Gateway (SSG) class device running SereenOS, and a hybrid higher throughput termination that combines a JUNOS™ software based roucer with an SSG/SG (Integrated Security Gateway) class firewall running ScreenOS. Design Considerations ‘his section describes the various types of DoS attacks and the eitical design considerations to address ther. Perimeter Locations and Roles ‘The frst question that should be asked in a security posture evaluation is: what am J defending? In this case, we are protecting the network perimeter from external atacks. The perimeter of an autonomous system (for example, your enterprise routed network) is not homogeneous in its composition; different devices will be used co terminate WAN traffic based on role. The most common deployment scenatio for an Internet connected enterprise network is to use a private network of some kind to connect trafic securely between the branches, campus and data centers ‘while allowing spit cunneling for Internet bound traffic, While this simplifies the touting of raffic to the Incemet, i increases risk by exposing all termination points to potential DoS attacks. Detecting and mitigating these astacks will equite a combination of edge device configuration with centralized analysis and conteol elements, Branch offices are generally smaller and don’t have onsite staf to maintain network devices, In this role, an “all m one” termination device is usually used in smaller and possibly mid-sized deployments. The device that would be deployed in this location would be an SSG class device running SereenOS. The detection and mitigation of DoS attacks will depend on screening, logging and firewall configuration, ‘The campus location requires the ability to handle higher trafic Toads and more advanced and. complex routing configurations Here, a standalone M-series multiservice edge router or J-series router handles the connectivity, while higher end SSG Series or ISG Series firewalls perform the security function, This requites that both the JUNOS software and SereenOS element of the system be configured to detect and mitigate atacks at each layer. Denial of Service Attacks ‘The goal of a DoS attack isto deny access to a particular network resource, This is often accomplished through a flood of iegitimate connections targeted to a resource in ar atternpt 10 overwhelm that resource. Unfortunately, DoS floods sent ata high enough volume can also exhaust available network bandwidth and place additional burdens on stateful devices such as firewalls found along the path between the atracker and target system. ‘Goprig® 62008, unger Rework, reProtecting the Network ffom Denial of Service Floods, Types of DoS Attacks While the goal of any DoS attack isto generate large amounts of ilegtimate trafic, each type of Dos tack works by exploiting specific weakness in an IP protocol. This reguites unique devecvion and. protection mechanisms for each type of atiack. Next, we will examine some common Dos attacks and identify steps one can take to detect and prevent these flows. For a more detailed description of specific types af DoS foods, refer to Concepts & Examples ScreenOS Reference Gulde Volume 4: Attack Detection and Defense Mechanisms Release 6.0.0, Rev. O5ihitp:www juniperneUtechpubsisoftwarel scteenosisereenos6.0.0/CE_v4 pa) SYN Floods [A SYN flood works by establishing half-open connections ta a node. When the target receives a SYN packet to an open port, the target will respond with a SYN-ACK and try to establish a connection However, during a SYN flood, the three-way handshake never completes because the client never responds to the server's SYN-ACK. As a result, these “connections” remain in the half-open state until they time out Imagine this process occurring several thousand times per second, Soon, the target server will tun out of memorylzesources, or cause a system crash, Additionally. any stateful devices in the path between, the attacker and target ill also be overwhelmed with connection requests, possibly filing up the session table on those devices ifthe SYN flood is not dealt with effectively. Because SYN packets are normal and necessary for TCP communication, a system cannot simply 4rop all SYN packets as inthe case of a "Ping of Death” DoS attack, for example. SYN floods can be mitigated effectively up to a certain point using a SYN proxy feature in a stateful firewall, Above this rate, a stateless screening router can be used to further limit TCP-SYNs ICMP Floods ‘While several types of Internet Contral Message Protocol (ICMP) Noods exist, each exploits the openness of the ICMP protocol self, and the fact that most systems with IP stacks will respond to most ICMP messages. Large ICMP floods can affect available network bandwidth and impose extra load on the firewall, which must examine and inspect each ICMP packet. These risks ean be mitigated by implementing a Juniper Networks firewall with ICMP flood protection, in combination ‘with adjacent routers to ratedimit ICMP trafic and prevent the attack from impacting bandwidth and frewall performance UDP Floods |A User Datagram Protoco! (UDP) flood can cause significant impact on network bandwidth ‘Addisonally, ia UDP flood is direcred to an unopened port, the target server will respond to each packer with an ICMP unceachable message, creating an ICMP flood in the opposite direction. To mitigate the impact of UDP Noods, a stateful Srewall with both UDP and ICMP flood protection should be implemented. To survive a larger UDP flood, rate limits on UDP traffic may need to be implemented on adjacent routers to protect available bandwidth Megal TeP Flag Flood Certain combinations of TCP Mags, such as a SYN packet withthe BIN bit se, are ilegal and shouldn't be seen on any network. Whyle a fiewall will clearly detect and drop these anomalies, 1 will only handle these illegal packets up to a certain rate. Above this rate, these packets should be ratelimited by adjacent routers to & rate that the stateful firewall can handle Distributed Dos Floods Further compounding the flood problem isthe proliferation of zombies, which are actually hosts that are infected with malware. A crafty atacker can infect thousands of machines and ditect therm allo attack a specific system at once. In this scenario, the attacks originate from several hundred to many thousands of source IPs, making detection and prevention more dificult. Ta mitigase DDoS floods, customers should implement per-destination IP session limits and SYN proxy destination theesholds ‘oper 62008, pe NetwareProtecting the Network from Denial of Service Floods on a stateful firewall, While this will mitigate any trafic passing the Firewall, the incoming tink can stil be saturated. Ifthe network under aitack is part of a network that is routed with BGP, mitigation can be achieved upstream of the ink via BGP Slow Specification commands. This is best accomplished a the service provider level, as t requires a modification to the peering agreement and the provider ‘being willing to accept flow specification information from routers they don’t directly contol ‘Spoofed Address Floods Some DoS attacks use spoofed or illegal IP addresses, which will never be properly routed back 10 the source, To mitigate these spoofed attacks, one should implement reverse path validation on ingress routers in combination with dropping nor-iocal subnets at egress routers This combination of ingress and egress filtering will drop these illegal packets before they reach the Firewall, Adaptive Threat Management and DoS Attacks Adaptive Threat Management is the ability to detect and respond to security threats in a quick and exible manner, allowing timely mitigation ofthe security issue. To function properly, Adaptive Threat Management depends on three primary elements: + A sensorlenforcement point, Any device that is aware of network security status and can send logs is a sensor In this case, we use SSG and ISG firewalls, JUNOS software routers and Aedicated Juniper Networks Intrusion Detection and Prevention (IDP} systems. Our sensors are also enforcement points that can be configured to defend agains the attacks + A contra point of configuration and control. The log output ftom the $SG, ISG and IDP is more efficiently collected by the Juniper Network and Security Manager (NSM) system, Using NSM to collect the logs reduces the CPU required on the individual security elements and scales to large deployments, It also allows a centralized point of contol to push out system updates that can respond to the attack + An analysis system. Security Threat Response Manager (STRM) has the ability to accept network performance and security metrics from all elements af :he network, including the servers. This allows the security professional to have a "birds-eye view" of the entire security posture, The STRM system also aufomaticaly baselines the system and presents preformatied reports based on tested sampling analysis to highlight and alert on threat conditions. “The frst step in evaluating your flood state isto establish a traffic baseline under normal network operating conditions. Normal operating conditions are defined as average trafic and application flow crossing the network edge devices averaged over time while the network is not under attack. The period used could be as shor: as a day, but a week is a good starting ime interval for trafic analysis ‘The basic idea is to monitor your newwork traffic and determine protocol distribution, connection rates and average session durations under normal (non-lood) circumstances Civen this baseline information, one can make some assumptions about abnormal trafic patterns tac indicate a traffic flood, Even if there is no firewall in place, simple counters on a router can, provide some insight into what's going on, However, a simpler approach is to use Juniper Networks Security Threat Response Manager (STRM). STRM allows aggregation of data and performs meta analysis of trending to identify security threats. See the appendices for configuration of manual trafic baselining on the routers and firewalls, ‘The elements of the reference network ate as follows ‘+ 8505 and 186 2000 as firewall-based sensors and enforcers, DP 100 as a detector, and Juniper M7s routers as detectors ‘+ Centralized configuration sestings are provided by NSM v2007.5r1 ‘Analysis provided by a STRM 500 v2008.1.0 Build 52 (6.1.1.28) ‘Goprig® 62008, unger Networks, reProtecting the Network ffom Denial of Service Floods, Figure 1 iikstrates an example of DoS attacks on a data center network Evil Hacker Example of DoS Attacks on Data Center Network Implementation Guidelines In this section, we discuss two important topes “+ How to mitigate large seale DoS attacks en the network ‘+ How to respond to large scale flood attacks Mitigating Large Scale DoS Attacks on the Network “The entire network must be opuimized to contol large floods. Stateless screening routers and stateful firewalls both play smportans goles in flood protection, Device Layer___Optimized For DoS Protections Flow Inspection Seren, Session Limits EEA] beep inspection SynCookie Packet Inspection LineRate ACLs BEI) Frame inspection Rate Limits Figure 2. Device, Layer, Optimization and Types of DoS Protections ‘oper 62008, pe NetwareProtecting the Network from Denial of Service Floods Juniper Networks frewalls perform stateful inspections and correlate flows into sessions giving much rneeded visibility into the source, destination and rates of attacks. SCREEN features allow advanced detection and blocking of many types of floods. Juniper Networks frownlls also implement session limits to control the total number of sessions that may be allocated co any single user. A SYN-cookie feature enables the firewall to do a stateless SYN proxy when under heavy SYN attack Routers perform Layer 2-4 stateless inspection at high speed. However, they lack visibility into flows ns and typically cannot provide detailed statistics about an atiack, By combining the DoS protection features available an both routers and Grewalls, the network ean bbe optimized to handle large foods at a much higher rate con al interfaces by stateless screening routers that implement access lists, specifically to deal with flood traffic. This best practice dates back tothe early days wh fal Grewalls should be protected sn software firewalls or proxies were protected by adjacent routers File ‘Application Session Flow ¥ Packet Packet Frame Frame —t L__, > = =; Router Firewall Router Figure 3. Stateless Screening Routers Surrounding Stateful Firewalls Optimizing the Firewall “The firewall SCREEN settings must be optimized according ‘These optimizations can be calcul enabled on all appro facing side ard the “Trust” zone represents the campus-acing side of the firewall ed from the traffic baseline data, SCRI 3 must be inte zones. In the above illustration, the resents the Internet Inthe next section, we will explore how to fine tune the SCREEN settings for your particular network's profile and the individual impact of each setting. Appendix F af this document provides the full configuration of Firewall SCREEN settings used in the solution Implementing Stateful Inspection Asta inspection firewall provides both visibility and protection against floods up to their rated capacity, in addition to security features outlined in juniper Networks Stateful Inspection Firewall (FirealllVPN Feature Brief) at hutp:fsruw juniper netiproductslintegrated!stateful_inspection_Srewall paf z Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, Because a stateful firewall monitors the TCP control trafic and associates flaws with sessions, it can easily identify illegal or abusive control trafic. The following sectings enable TCP sequence number checking for all connections, including resets. It also prevents TCP sessions from being created if SYN packet is not seen set flow check tep-ret-sequence tunset floy no-tep-seq-check set fow tep-syn-check Implementing Stateful SYN Proxy Mechanisms Most firewalls implement a SYN proxy type mechanism specifically for dealing with SYN floods, ‘When a Juniper Networks ScreenOS firewall receives SYN packeis at a rate higher than the defined threshold toa specific destination, she Srewall wil begin responding to each SYN with a SYN-ACK ‘between the protected zones to thwart the attack I is important to set ths threshold at least two times higher than the baseline trafic rate of SYN per second because under ordinary circumstances, the firewall should not be used to proxy SYN requests, ‘When rates exceed an alarm threshold, aleris are generated via alarms pertaining 10 the flood. “This tate is the amount that exceeds the attack threshold before the alarms occur In the following example, alarms will not be generated tnt 8 20,000 PPS of SYN ate proxied through the firewall “The queue size represents the total number of proxy connection requests held before the Brewall begins rejecting new connections. The queue size should be set to the maximum possible value set ow syn-proxy syn-cookle set zone Trust sereen syn-flood attack-threshold 10000 set zone Trust sereen syn-flood alare-threshold 20000 set zone Untrust screen syn-flood attack-threshold 10000 set 2one Unrust sereen syn-flood alare-threshold 20000 set zone Trust screen syn-flood timeout 5 set zone Untrust screen syn-flood timeout 5 set zone Trust screen syn-flood queve-size 20000 (use max value) set zone Untrust screen syn-flood queue-size 20000, Beginning with ScreenOS 5.4r1, all NetScreen firewalls support the SYN-Cookle feature, This feasure "works tn conjunction with the SYN proxy mechanisms. When enabled, sessions will not be set up unless a valid SYNIACK is recetved from the client in respanse so the server's SYN, On the NetSezeen ISG Sertes firewalls, chis SYN-Cookte is done in the Packet Processing Unit (PPU) without affecting the CPU. The use of SYN-Cookie an any platform dramatically lowers CPU and session uslaation. To enable SYN-Cookle, enter in the folowing command using the Command Line Interface (CL) set flow syn-proxy syn-cookie Limiting the Number of SYNs per Second per Source IP ScteenO$ firewalls can also limit the number of SYNs per second from a particular source IP. if a client sends SYNs through the firewall above this rate, The firewall will simply ignore the adettional SYN packets above this threshold and nor perform the SYN-Proxy function, This lemitation provects the CPU further when the majority ofthe flood originates from a small nurnber of IP addresses, Note: SCREEN settings and thresholds are specific tothe ingress zane, For the “Unttust” zone, choose a higher value because Network Address Translation (NAT) can often make large organizations appear as a single IP when accessing the network, set zone Trust screen syn-flood source-threshold 250 set one Untrust scrsen syn-flood source-threshold 500 ‘oper 62008, pe NetwareProtecting the Network from Denial of Service Floods Limiting the Number of SYNs per Second per Destination IP Limiting the number of SYNs per second targeting a specifi sion prevents a distributed SYN food from taking out a particular destination IP. Again, the firewall will simply ignore any additional SYN packets exceeding this threshold that target the same destin address and will not perform any SYN-Proxy destin Note: SCREEN settings and thresholis are specific tothe ingress zone. For the “Trust” zone, choose a higher value, as many users may connec: to the same popular sites on large networks set zone Trust sereen syn-flood destination-threshold 10000 set zone Untrust screen syn-flood destination-threshold 2000 Limiting the Number of Sessions per Source/Destination IP Limiting the total number of sessions that can be established toffrom a specific IP address eliminates the chance of any particular user consuming too much of the firewall session capacity. These settings are especially helpful in preventing the effects of network worms or zombie-connections where a large number of legitimate connections are established in an attemp' to overflow the network, get gone Trust screen Limit-session source-sp-based set zone Trust screen limit-session source-ip-based 1000 et zone Trust screen limit-session dastination-ip-based set zone Trust screen Limtt-seasion destination-sp-based 10000 et zone Untrust screen Limit-session source-ip-based set zone Untrust sereen Limit-session source-ip-based 1000 et zone Untrust screen Limit-session destination-sp-based set zone Untrust soreen limit-session dostination-sp-based 10000 Preventing ICMP Floods PING Moods and other ICMP-based flood attacks can have a dramatic effect on the firewall, as each ICMP packes must be examined for checksum, sequence number and type Large ICMP packets can also have an impact on available bandwidth. The following SCREEN settings will protect against large ICMP packets and lirvt the total number of ICMP packets per second to 1000. When that thteshold is exceeded, the Brewall ignores further ICMP packets forthe remainder of that second plus the next second, Set zone Trust screen Lemp-lerse et zone Trust screen ienp-flood set zone Trust screen emp-tlood threshold 1000 set zone Untrust screen Lcmp-large set zone Untrust soreen iomp-flood set zone Untrust screen emp-flood threshold 1000 Preventing UDP Floods UDP floods generally have the least impact on the firewall itself because UDP is a connectionless protocol, and a stateful inspection firewall needs only to perform minimal inspection of UDP. The UDP flood can affect network availabilty by using excessive bandwidth. Because of this, using the firewall SCREEN protection to limit the number of UDP packets per second that targets a destination [P is recommended, Note: Beginning with ScreenOS 5.42, UDP flood thresholds can be set per destination IP. This is especially useful for Domain Name System (DNS) servers, which may receive many requests per second in a large network, io Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, et zone Trust screen udp-lood set zone Trust screen udp-flood threshold 10000 set zone Untrust sereen sp-food set zone Untrust sereen udp-flood threshold 10000 ‘Optimizing the Router Many network environments typically place routers in front of the firewall. This allows the router to inspect, count and drop certain types of traffic befote it reaches the frewal. Juniper Networks IMeseries routers, for example, feature the Internet application-specific integrated circult (ASIC) suppor line rate Access Control Lists (ACLs), counting and policing. These features enable JUNOS software-based routers ¢o provide additional pratection against large floods. The following actions can be taken on any JUNOS software-based router co mininize the impact af large foods an both the firewall and available network bandwidth. Appendix & summarizes this configuration. ‘A large Dood can present a challenge to any network as it ean consume all available network bandwidth and may requite extra processing by stateful rewalls. Large Doods cause high CPU usage sand slow response times. ‘While stateful firewalls provide both much needed visibility and fine-grade protection against @ variety of floods, all stateful firewalls have an upper limit in their capacity to deal with certain types of foods such as SYN oF ICMP floods. If faced with a flood beyond its capacity, the firewall experiences high-CPU load and as a result can drop legiimate traffic, The specific rate of attacks varies per firewall, depending upon its configuration and software version ‘To protect the firewall and network against massive floods, rate limits should be implemented on routers protecting all interfaces of a firewall. The goal is to limit certain types of traf, such as “TCP contol traffic and [CMP types, to rates that will nor impact available bandwidth and overwhelm the firewall ‘The Following diagram shows how a small SYN attack can be handled by che firewall alone. However, a lagger SYN attack that exceeds the frewall’s packet processing rave can be ratelimited by adjacent routers to protect the firewall and network self from the impact ofa large food Figure 4. Handling SYN-Cookie on Juniper Networks Firewalls Configuring JFlow for Detecting Traffic Flow statistics allow for greater granularity in the traffic data that is forwarded to the analysis engine Enabling flow-based accounting in routers is an important step in gathering information for detecting. DoS attacks. Follow these steps to enable accounting on the JUNOS software-based devices. ‘oper 62008, pe Netware ihProtecting the Network from Denial of Service Floods Enable the Flow Collector at the Interface: interfaces ( e-0/0/1 { anit 0 family inet ¢ ster ¢ Export the Information to STRM: Forwarding-options ( sampling ( Anput. { And/or output, if desired family inet ( ranclength 1s > output ( cflovd ; 8's best to use a loopback address for the source > Now that we can see the attack, how do we ratesimit i? Ratesjimiting TCP Control Traffic Inv normal baselined network, the percentage of limes or RSTS) should typically not exceed 5 percent of ability to conitol packers. Once the counters have been imp the percentage of TCP contol trafic inthe ing this traltc to further prote ol wale (SYN, FIN, register suppression, ndwidth, Most stateless routers support the and a wale work is established, one should consider limit che baseline ratedims the network, If under normal conditions the network experiences less than 2 percent TCP control traffie—and. sauddeniy the util this can indicate a large flood attack ‘To ensure available bandwidth and protect the stateful devices within the network from being overwhelmed, ratedimiting TCP conttol traffic between 2 and 5 times above the baseline rates causes the router to start dropping TCP control trafic under heavy flood conditions ion increases to 10 or 20 percent However because the router can not distinguish between legitimate connections and floods, some leglumate connection requests are dropped as well If2 petcent of the trafic is legitimate TCP contol traffic, and the remaining 8 percent a flood, then rate‘miting the TCP conttol traffic to 5 percent ‘ill effectively block 4 percent of the flood and t percent ofthe legitimate control traffic. Any flood axtacks allowed by she router are further detected and blocked by the firewall SYN-proxy mechanism, described on page 10, Optimizing the Router. Rate-Limiting ICMP Rate limits should also be used to protect the firewall against ICMP floods, Typically ICMP tr should nor exceed 1 percent of bandwidth, By rate-limiting all ICMP trafic on the routers surrounding the firewall, the firewall will never be overwhelmed with more ICMP floods then it can handle, and TEMP floods will never have a significant impact on a network's avalable bandwidth @ Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, Rate-Limiting UDP In most circumstances, UDP traffic does not need to be ratedimited to protect the firewall. However, rate limits could be implemented if desired to prevent UDP from consuming all available network bandwidth, The percentage of UDP traffic ean vary Irom less than 5 percent to more then 50 percent of network talc. Alter establishing & baseline, one can decide if is necessary to rate-limt UDP to preserve bandwidth for other protocols Rate-Limiting Other IP Protocols ‘While a food of nonP traffic will not have a major effect on the firewall, could have a large impact fon bandwidth utlization, With the exception of routing, VPN and tunneling protocols, other IP protocols should typically be limited (o 1 percent of network bandwidth, This helps prevent a Nood of ronlP walfic rom consuming all avatlable network bandwidth Implementing Reverse Path Validation Validating the return path prior to forwarding a packet can ensure that each packet allowed into the network has a valid return path. Validation helps eliminate the possibilty of spoofed or illegally addressed packets entering the network. Drop NonLocal Subnets with Filters Internal trafic destined for the Internet should be subject to an access list which validates the source IPisuonet information. The ACL prevents spoofed packets from leaving she network before they reach the firewall For detailed snformation concerning enacting rate limiting policies with policing, refer to _hupuWwonw juniper nedtechpubssaftware/unostjunes91 sweontig policyltrameset html Configure the system to limit trait tothe parameters suggested above and log the results, These logs can be used to determine the attack status atthe router Responding to Large Floods For sustained floods at rates 210 3 times higher than the router's rate-limit seting, the impact of the flood may cause excessive TCP reities in the network, as some legitimate SYNs may be dropped by the rate limits in addition co the flood traffic. The larger the floods, the more likely the rate limits will drop legitimate trate and cause excessive retties or connection timeouts. In this instance, some "good" traffic ts dropped sacrificially o preserve the network's avallabilty (One can minimize the effects of @ large ood by blocking the source IPs of the lood in upstream routers, However, blocking the entie source IP or subnet is nat possible in all cases because you could bbe blocking the firewall NAT address of a large organization, thereby blocking legitimate users from accessing the network. An alternative to blocking all taffic from the source IP is to rateslimt that traffic to a conservative amount. This will block the rate of flood and still allow legitimate trafic froma the source, albeit at a reduced speed Note: By using counters on biachlist rules, you can constantly monitor if an aitack is still in progress Responding Upstream ‘When floods are large enough to start reducing your available bandwidth and creating network congestion, upstream devices are the best method of addressing this problem, Typically, Internet Service Providers ('5Ps) will ratelimit or drop trafic from a specific set of source IPs that are targeting the network, By selecting to rate-limit rather than block trafic, the size of the flood is reduced to a manageable level while still accepting legitimate connections from those source IPs, Again, counters can be used to indicate when the flood stops, opie 62008, ripe Netware 3Protecting the Network from Denial of Service Floods =F] ape Most SYNs tered ais? Figure 5. Communicating to Upstream ISP Devices to Address Floods Automating a Response If an awomated response ts preferred, scripts can be used to automaticaly blacklist offending 1P addresses on the router When the firewall detects an excessive flood above the alarm threshold, a SYSLOG message is sent indicating the source IP ofthe attacker. Periodic monitoring ofthe SYSLOG. messages can trigger a scrip that will log into the router and blacklist or ratesimit that IP address, Continual monitoring of the counters associated with each blacklisted IP will indicate when the flood event stops, and the non-offerding IP addresses can then be removed from the blacklist. Juniper Networks is also working with Internet Engineering Task Force (ETF) members in the BGP community and has implemented a BGP notification message that can be configured to automatically Dlackist or ate-limit offending IP addresses on upstream routers. This mechanism is used ioday by many service providers to block a flood closer ta its source. The mechanism on which the response is ‘based is called BGP Flow Specification cis possible co implement BGP Flow Specification in an enterprise network tha i sufficiently lange and has a BGP-based routing architecture, However, « would requite that the enterprise renegotiate the peering agreements with their service providers and convince them to allow routing tables vo be modified by the enterprise, This s not likely. The better Way of achieving DDOS protection isto use a service provider based mitigasion service. Configuring STRM ‘Using STRM to Poll Statistics Automatically STRM isa seculty analysis and reporting system that can aggregate and apply rule to ll data frorn network and server assets in your network. This system has the capabilly to baseline and report anomalous behavior inthe network. The configuration of this system is covered in detail bythe product documentation at hitp ww juniper et, but here ae the basi steps to enable the system 1 Configure all devices to send logging and SNMP data to the STAM. If devices such as SSG, ISG and IDP are controlled by Network Security Manager (NSM), use NSM to aggregate logging data and sond it up to the STRM, This s configured by adding an action parameter under the Action Manager dialog that specifies the STRM IP address as the upstream sysiog server This reduces the CPU load on the individual firewall devices. See Figure 5 2. Be sure to select what log parameters ta be sent upstream wit the “Device Log Action Criteria" configuration under the “Action Manager" tab on NSM. This command selects what log types and severity to send up to STRM. In the case of a SYN attack, we need to be sure that we're sending TCP and DoS events, See Figure 4 ‘5. STRM will now automatically store and analyze the security events sent from NSM, The system presents a number of pre-generated reports that are quite useful for baselining network trafic. The reporis also include dela taftic—from one day tothe next—and automatic threat detection reports. See Appendix D, Optimized Firewall Covyiguration. for examples of automatically generated reports 4 ‘Goprig® 62008, unger Networks, reProtecting the Network ffom Denial of Service Floods, Using STRM to Determine Attack Status Enabling all of the recommendations discussed earller provides a large amount of rich log activity for STRM to analyze The system will now automatically detect and report attacks. The dashboard will show the attack status and the corresponding events can be used to “drill down” to determine the attack source and destination, See the following three figures for an example of a captured attack. ‘This attack was accomplished by using HPINGS to send fragmented SYN packets against the data center firewall, The altack was at a constant rate (faster) and executed for more than 12 hours from ‘There are a large number of automatically generated reports avalable as soon as STRM receives data Refer to the STRM documentation at hp www junipernet for a complete overview of available reports and instructions on how to build customized reports, Figure 6 details the initial “Dashboard” display of a DoS aitack. The event created is an “IDS SYN stack” and Is reported in the Most Severe Offenses by default. STRM Is preconfigured to classify and categorize common security events Figure 6. STRM Dashboard Showing Attacks ‘The attack can be analyzed in greater detail by clicking on its hyperlinked location on the Dashboard Figure 7 shows greater detail on the incident, eluding the soutce, destination and evers counts = seen otenses res Qtr Deets Saree hairs Figure 7. STRM Offense Manager Showing DoS Attack Details ‘oper 62008, pe Netware 8Protecting the Network from Denial of Service Floods Summary Further detail on the attacker is provided by following the link on the Offense Manager page for the tack Figure & shows detail on the attacker, including last known attack and all known attacks Figure 8. Dring Down on the Attacker In most cases, flood protection is typically implemented as a reflex reaction after an attack has taken place and exhausted network resources, The results of such attacks inthe past have included impact toa company’s reputation, lost customers or lost data, ultimately leading to impact on a company’s financial health. The proactive approach discussed inthis document requires minimal time and due dlligence to configure and maintain, The benefit is a network that is capable of withstanding the Impact ofa large flood without sacrificing network avalabilty—clearly an exercise worth expending Understanding a network's normal operating behavior, establishing baseline measurements and continuously monitoring events are critical in identifying DoS Rods and optimizing the countermeasures discussed. When used together, stateful firewalls and stateless routers each provide complementary mechanisms to help mitigate the effects of DoS attacks on network availability by aropping the majority of undeniably unwanted flood tralic ‘The combination of STRM, NSM and network elements can be used to rapidly analyze and respond to attacks, STRM allows operators to quickly locate attacks, attackers and targets, NSM allows a network. administrator to quickly take preventive action. The net result is a more secure network, better visibility and a reduced burden on operations i6 ‘copie 62008,Protecting the Network ffom Denial of Service Floods, Appendix A Baselining Network Traffic using Router and Firewall Counters Configuring the Router Counters should be implemented on routers to count TCP con ICMP and UDP pach traversing the network, By comparing these counters withthe toral numer of packets seen, one can derive a percentage of tal packets and bandwidth, Appendix ‘which could be applied co any interface. vides an example of such counter fiers Te following example shows counter values used to caloulate the percentage of SYN packets and bytes compared with cotal packets and bytes. adnin€M7ia> show firewall Filter: input-transit ame Bytes Packets count-ping 33768 402 count-iemp 55668 994 count-ayn, ass9s106 14220 count-rst, 47042208 a17276 admin€M7ia> sho interface extensive 3e-0/2/0 trafic statistics: Input bytes + 2es22316613 292786872 bps output bytes + zvai2702368 261606532 bps Input packets: 43059013, 54100 pps output packets: goiaiaa 60153 pps ation (814280 / 43059013) * 100 (45599104 / 27812702368) * 100 0.164 percent 1.89 percent ofall packets are SYN packets all bytes are SYNs ‘Typically TCP control traffic should be less then 5 percent of packets and 1 percent of bytes, as shown, inthe above example, By monitoring interface counters from the router command line, one can easily calculate the percentage of SYN packets seen in the network. In the example below, 18 ofall packets are SYNs—this network ts exp Flood Condition Calewlations acmin€M7ia> show Srewall Filter: input-transit counters: ing heavy SYN flood. same Bytes Packets count-ping 048i 492 count~iemp 62664 aus count-syn sessas) ae2ei013 count-rst 50405246 1015695 acminéM7ia> sho interface extensive g2-0/2/0 trafic statistics: Inpat bytes 37724535633 375357040 bps output bytes + seaszeaoo16 230827360 bps Input packets: 7e210883 344162 pps output packets: ‘73980105 208047 pps 7Protecting the Network from Denial of Service Floods (14241015 78210485) * 100 = 18.2 percent ofall packets are SYN packets (585549488 / 57724535635) * 100 = 1.55 percent ofall bytes are SYNs Sirilar logic can be applied to ICMP, UDP and RST foods using the ACLs documented Appendee & Configuring the Firewall Ifa Juniper Networks firewall is deployed within the network, it can give detailed visibility into the source and destination ofthe floods, See Appendix F for implementing the baseline SCREEN settings fn she firewall that provide baseline settings for detecting these attacks (Once enabled, SCREEN will create alarms when triggered. These are directed to the event log SYSLOG or NSM Server. Detailed SCREEN statistics can be seen from the fitewall’s CLI and the number of avacks per second can be counted, This number can then be compared with the total number of connections counted to derive a percentage of flood traffic, 41sg2000a(M)-> get count sersen zone Internet Screen counter on zone Internet CHP flood protection ° oP Mood protection UDP food count for destination TP: WinNoke attack protection ° Port scan protection ° IP sweep protection ° Teardrop attack protection ° SYN food protection 5242 SYN Flood(same source) ssa SYN Flood(same destination) 2230 IP spoof attack protection ° 1sg2000a(M)=> get count flow zone Internet Plow counter on zone Internet in bytes 740547675 | out bytes 345229152 | tep prosy 12997 tear drop © | in vian © | out vian o in permit 828895568 | out permit 1005933079 | sre route ° no g-parent © | ping of death 0 | no gate sess o address spoot 0 | in icmp 215240 | no nat vector ° land attack 0 | in seit © | no map o icmp food © | in un-auth © | no conn ° dp flood © | dn unk prot 0 | no atp o winnoke © | in vpn © | no gate ° port sean 0 | dn other 0 | no xnét vont ° ip sweep © | 0 mac 0 | no route o top out of seq 22 | mac relearn 0 | no frag set ° wrong inté © | slow mac 0 | no frag netpak o wrong slot. 0 | trang queue 0 | no sa ° icmp broadcast. © | temng drop 0 | no sa poticy o Alege pak | thay frag 0 | aa inactive ° orl block © | syn frag 0 | sa policy deny o encrypt fail © | connections 1478769 | policy deny ° ie Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, Configuring NSM to Export Logs to STRM 1. Lag int the NSM system and expand the Action Manager men item on the eft sde ofthe page a ns > coe Figure 9. Action Parameters Window of NSM 1. Configute the Action Parameters to send Syslog messages to the STRM servers IP address, with the Syslog Server Facility set to local use 0 (local0) 2. Select the events that must be forwarded to this syslog target Select Action Manager/Device Log Action Criteria subment: with the following main categories included: SCREEN, INFO, ALARM, SIGNATURE and TRAFFIC. ll priorities were selected and most sub-categories as well See Figure 10. awe (sane Je] eowiceteanaion cee Se Bee gee lepee =a is ES Figure 40. Selecting Device Log Action Criteria on NSM opie 62008, ripe Netware 38Protecting the Network from Denial of Service Floods Appendix B JUNOS Software Router Configuration for Counting Traffic Note: These Firewall terms must be ap applied to multiple rmulliple identical terms and use one for each int plied vo interfaces before counting will occur The term can be per intetface, you should create interfaces. However, you wish to track counter Set Growall Siter in term Ifrag from firet-fregnene, et Grewal Ster in term lfcag then count ifzag Set Growall Siter in term frag then next term et Srewall Slter in term 2frag from is-fragnent set Srevell Slter in term 2frag then count 2freg set Srewall Slter in term 2frag then next term Set Srevall Siter in term option from ip-aptions any set Srevall Siter in term option then count option set Srevall Siter in term option then next term jet Growall Slter in term ping from protocol icmp set Grewal Siter in term ping from Lenp-type echo-request set Srowall Slter in term ping from icmp-type echo-roply set Srevall Siter in term ping then count ping set frevall filter in term ping then next term set Srovall Siter in term icmp trom protocol icmp et Srowall Siter in term icmp then count Somp set Srevall Siter in term syn from protoco) tep set Grewal Silter in term syn from top-flags “(syn & tack)” set frevall Siter in term syn then count syn set firewall filter in term synack from protocol top set Srovall Siter in term synack from top-flags “(syn & ack)* Set Srevall Siter in term synack then count synack et Srewall Slter in term fin from protocol top Set Srovall Siter in term fs from tep-flags fin set Srewall Slter in term fin then count fin set firewall Slter in term rst from protocol tep set Srewall Slter in term ret from top-fiags rst set fevall Silter in term eat then count rat set Srowall Slter in term dns from protocol wp act firewall iter in term dne from destination-port 53 lot firewall Slter in term dns then count dns set firewall filter in Lerm other fom protocol-except tep sot Srowall Slter in term other from protocol-except wap fet Srewall Slter in term other fzom protocol-except ah set Grewal Siter in term other from protocol-except exp et Srewall Slter in term other from protocol-except gre set Grewal Silter in term other then count other et Grewal diter in term default-permit then accept ‘#apply the Filters to the appropriate Interface for your Network. et interface ge0/2/0 unit 0 family inet filter input in 20 Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, Appendix ¢ Baseline SCREEN Settings Note: 1 were previously enabled lowing Basel We Scr the device. Settings for Internet IN setings may be used as a starting point ino SCREEN settings shown; however, the settings should be enabled on all zones subject to DoS attacks, set tone “Internet “taternet* “internet “internet” “tnternet* stemp-flood edp-flood vdp-flood threshold 10000 syn-flood Sp-spooting ayn-frag, tep-ne-flag omp-large ayn-tin fin-no-ack syp-flood alarm-threshold 10000 syn-flood quoue-size 20000 syn-flood attack-threshold 10000 syn-flood source-threshold 500 syn-flood destination-threshold 500 Limit-session source-ip-based 10000 Limit-session dastination-ip-based 10000 aProtecting the Network from Denial of Service Floods ‘The following example conf the implementation section of this document. The example is based on th Open Access Necwork) solution and impli ‘background trafic” and an 1SG Series fi set flow check tep-rst-sequence unset flow no-tep-seq-check Appendix D Optimized Firewall Configuration ements all of the SCREEN and flow settings deseribed in TOAN (Securing the les 1 GB Internet uplinks, 1500 Sessions/Second of nos ‘ewall with the SYN-Cookie performed entirely in haedware set set zone "Internet" set zone “Internet set zone “Internet set zone “Internet set zone “Internet™ set zone “Internet set zone “Internet: set zone “Internet set zone “Internet* set zone “Internet set zone “Internet set zone “Internet ffow tep-syn-check flow syn-proxy syn-cookie iemp-flood \edp-fload swinmake port-sean ip-spoofing ping-death ip-titer-sre land syn-frag epeno-fag ip-bad-option ip-record-route ip-tinestanp-opt Ap-secursty-opt ip-loose-sre-route ip-strict-sre-route ipretream-opt omp-fragnent Lemp-Large syn-fin fin-no-aek Limit-session sourc ip-based Lin{t-session destination-ip-based iemp-ia Ap-sweep threshold 100000 port-scan threshold 100000 \edp-flood threshold 10000 Limit-session source-ip-based 1000 syn-flood alarm-threshold 1000 yn-flood sttack-threshold 1000 syn-flood source-threshold 250 ayn-flood destinstion-threshold 250 Limit ion destination-ip-based 10000 2 Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, set set set sot set set set set ‘campus "campus" “campus” "campus" campus” "campus" “campus” “campus "campus" "campus" campus" campus" campus” campus" "campus" “campus” "campus" ‘campus "campus" “campus” "campus" campus" "campus" campus” "campus" campus” "campus" "campus" campus" campus" campus" "campus" “campus” campus" campus" siemp-flood udp-flood winnoke port-scan teardrop syn-flood Ap-spooting ping-death Apeilter-ore land aynefeag ‘top-no-flag Ap-bad-option ipcrecord-route ip-timestamp-opt ip-seourity-opt ip-Loose-sre-route ipcstrict-sre-route ip-streamopt iemp-fragnent. omp-Large syn-tin ‘fn-no-ack Limit-session source-tp-bened init: ssion destination-ip-based semp-id snold 100000 ip-sweep thr: port-scan threshold 200000 Limit-session source-sp-based 1000 Limit-session destination-ip-based 10000 ayn-flood alarm-threshold 1000 syn-flood attack-threshoid 1000 syn-flood source-threshold 250 syn-flood dostination-threshold 250 23Protecting the Network from Denial of Service Floods Appendix E Optimized Router Configuration ‘The following configura ‘The example is based on th to the 186 2000 « necessary to harden set set set set set set set Srewall ‘Srewall Srewall ‘Srewall ‘Srewall Srevalt ‘Srewall ‘irewall ‘Srewall ‘firewall ‘Srowall ‘srowall ‘Srewall Srewall ‘srewall Srewall ‘Srewall Srewall ‘srowall ‘Srewall Srewall ‘Srewall ‘firewall ‘Srewall ‘Seawall ‘Srowall ‘frewall ‘Srewall ‘Srewall ‘Srowall ‘Srewall Srewall ‘Srewall Srewall ‘srewall Srevall ‘Srewall Srewall Srowall Srevall policer policer policer policer police: policer policer policer polices policer polices policer siter alter ster alter siter alter ster alter siter slter siter siter alter alter alter siter alter siter alter siter slter siter alter ster alter siter siter ster alter siter oot ost ost ost ost ost ost ements all ofthe rate limits and Glters discussed previously. SSTOAN solution and implied 1 GB uplinks, Rate limits ate get according labled. This ts only the flood configuration. Configurations one-percent if-exceeding bandvidth-Linit 10m percent if-exceeding burst-size-linit 100k one-percent then forwarding-cless network-contrel point-2-percent if-exceeding bandwidth-linit Sm point-2-percent if-exceeding burst-size-Limit 150% point-2-percent then discard Sverpercent (f-exceeding bandvideh-Linis 50m Sve-percent if: sxceeding burst-size-limit 150k discard Sverpereent then if-exe! point-2-percent2, point-2-percent2 sding bandwidth-Linit 5m Lf-exceeding burst-size-Linit 150k point-2-percent? then discard orm source from source-addross 0.0.0.0/32 ‘term source then log orm source then discard erm destination from destination-address 0.0.0.0/32 orm destination then 203 erm destination then discard term ifrag from ficst-fragnent. ifzag then policer one-percent frag then next cere tore term 2frag from is-fragnent term 2frag then policer one-percent 2£rag then next term options from ip-options any ‘term options then policer one-percent options then next term ping ping ping ping ping emp cap emp emp then policer point-2-percent2 syn from protoce} tep term ping from protocol icnp emp-type echo-request iemp-type echo-reply policer point-2-percent term ping from orm ping then next term term icmp from protocol icmp iemp-type-except scho-request emp-type-except echo-reply term icmp from term iemp trom orm icmp then term syn from tep-flags “(syn & Lack)” term syn then policer five-percent erm synack from protocol top term synack from top-flags “(syn & ack)* term synack then policer five-percent, 2a Goprign 62008, nip Networks reProtecting the Network ffom Denial of Service Floods, sot set Srewall ‘Srowall ‘firewall ‘Srewall ‘Srewall ‘Srowall ‘Srewall ‘Srewall ‘Srewall Srowall ‘srewall Srewall ‘Srewall alter siter alter siter alter siter alter siter alter siter alter siter siter oot ost ost ost ost erm fin from protocol tep ‘corm fin from top-flags fin term fin then policer five-percent term rst from protocol top term rst from tep-tlags rat torm rst then policer five-percent term other fron protocol-except tep term other from protocol-except udp term other from protocol-except ah torm other from protocol-excopt esp term other from protocol-excapt gre term other then policer one-percent term defavlt-permit then accept Wpply the Filters to the appropriate Interface for your Network. Set interface g00/2/0 unit 0 family inet filter output out 2Protecting the Network from Denial of Service Floods Appendix F Test Results Extensive DoS testing was performed on the STOAN solution, which consists of an ISG 2000 firewall placed between a pair of Juniper Networks M-sertes routers on sts "Untrust” and “Trust” zones ‘Testing was performed both with and without the above mentioned rate limit in place on the routers. The router and frewall configurations used for the tests were the same as referenced in the appendices of this document, Testing was performed with ScreenOS 5.471 using the configuration referenced above Background traffic of 420 Mbps (1700 sessionsisec) was run constantly during testing to create a normal walic baseline. Floods were introduced for @ period of § minutes and results recorded ‘The results clearly show the improvement that the rate limits provide in dealing with farge floods For SYN floods smaller then 150,000 packets per second (PPS) (or 75 Mbps), the ISG firewall with SYN- Cookie mechanism can proxy enough connections to suppress the flood and pass the background. traffic with a comfortable CPU level of 22 percent utilization A ates slightly above this, the router ACLs wil start dropping SYNs. The trade off is that now some legluumate SYNs will be sacrificed to protect she network. In a normal network, this will result in occasional retries and timeouts much better alternative then a camplete network outage. As the flood rate increases above the settings ofthe rate limits, che firewalls CPU and session table evel out ‘A final cest was tun with a mix of Noods: SYN flood, PING fload and UDP Mood, each being sent through the solution at 107,000 PPS, for a total of $21,000 PPS (or 150 Mbps) of food traffic. At these rates, both the SYN and ICMP rate limits were exceeded and trafic was dropped sacriietally to protect the network, Alter five minutes, the Brewall CPU remained a constant 50 percent and legitimate PING and SYN response times through the network were acceptable Firewall CPU Usage at various Flood Rates with and without Rate-Limit ACLs no floods baseline ‘SynCook OnACl. OF 450K ‘Syno0k OnACL On 450K ‘Synook OnACL Off 300k ‘SynCook OnACl. On 300k ‘SynCook OnACL Off 150K ‘SynCook OnACL On 150k ‘SynCookie Off 150k 0 10 20 30 40 50 60 70 80 90 100 26 ‘copie 62008,‘oper 62008, Joiner Netware Protecting the Network ffom Denial of Service Floods, FW Session Table Size at various Flo with and without Rate-Limit ACLS Rates no Hoods baseline ‘SynCook OnACL Of 450% SynGook OnACL On 450% ‘SynCook OnACt off 300% ‘syndook Ons. on 300% ‘SynCook OnACL Off 150% SynGook OnACL On 150% Syncookle OF 150% ° 20000-40000 +~~«60000~+~—«80000 ~—«100000 2Spanning Tree Protocol in Layer 2/Layer 3 Environments About Juniper Networks Juniper Networks, nc. isthe leader in high-performance networking. Juniper offers high performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. Ths fuels high-performance businesses. Additional snfermation can be found at ww juniper net coaporae wezoqunnens uno woe ea en ast cons ome ‘tuo Elona hus eADUNRTERS so aes wexogune om earn SES EABQURTERS pe Nee re oni sour ane Soe tae (ies erga ie siathontoasc srk hone Sresaaec0 cee vente feaigistaseeso coop 208 sets. et snes ge et. ¢ >) wpe To purchase Juniper Networks solutions, please nose we acorns of aie, eM ern, deg contact your Juniper Networks sales representative ieee Nos rs ry at 1-866-298-6428 or authorized reseller. I