Security Deployment Strategy

Technical Solution Guide DefensePro 4.01.01

North America Radware Inc. March 2008

575 Corporate Dr. Suite 205 Mahwah, NJ 07430 Tel 888 234 5763 International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666

www.radware.com

Table of Contents
Introduction ...................................................................................................................3 The incentive for using this Guide .............................................................................3 Before you start .........................................................................................................3 Versions used in this Guide .......................................................................................3 Operational Modes ........................................................................................................4 New Security Features (DefensePro 4.0)......................................................................5 Server Cracking Protection........................................................................................5 HTTP Mitigation .........................................................................................................5 Recommended Protection Configuration Strategies .....................................................6 BDoS TCP SYN Flood Protection and SYN Cookies Protection ...............................6 DoS Shield Protection................................................................................................6 Network Anti- Scanning (Zero Day Worm Propagation) Protection...........................7 Server Cracking Protection........................................................................................7 Signatures Protections...............................................................................................8 Policy Direction ..........................................................................................................8 Working with MPLS VPNs .........................................................................................9 Working in Asymmetrical Network Environments ......................................................9 Cases and Solutions ...................................................................................................10 Scenario 1: Enterprise (Corporate) GW and DMZ...................................................10 Scenario 2: Campus Network - University ...............................................................15 Scenario 3: Protecting your E-Commerce Servers..................................................18 Scenario 4a: Protecting the Carrier Data Center .....................................................21 Scenario 4b: Cleaning the Carrier Link....................................................................24 Scenario 4c: Network based Managed Security Services (MSS)............................26 Defining Policy Direction .............................................................................................28 Appendix A Anti-Scanning Technical Note ..............................................................33 Appendix B Server Cracking Protection ...................................................................43 Appendix C MPLS RD..............................................................................................49 Appendix D - Working in Asymmetric Network............................................................56

Introduction
The Technical Solution Guide presents the officially recommended scenarios for installing DefensePro in your network. The purpose of this guide is to assist you in choosing the best installation scenario according to your application security needs.

The incentive for using this Guide

In this Guide you will find the most commonly used DefensePro installation scenarios, which include detailed scenario advantages and limitations, a reference network diagram and step-by-step configuration procedures. The recommended installation scenarios will help to ensure a fast and smooth installation process and easier troubleshooting in the future.

Before you start

Before considering the implementation scenarios, follow the initial installation and configuration procedures described in the Getting Started chapter in the DefensePro User Guide. The user guide can be downloaded form the web at:
http://www.radware.com/content/document.asp?_v=about&document=7826

This will ensure that your DefensePro appliance is ready for work and your APSolute Insite management system is ready to configure security policies and monitor the security events and activities.

Versions used in this Guide

PRODUCT DefensePro APSolute Insite SOFTWARE VERSION 4.01.01 2.70.16

Operational Modes
To allow optimal adaptation to the network environment during the initial deployment of Radwares DefensePro as an in-line Intrusion Prevention and DoS protection switch, the following Operational Modes should be used during the deployment phases:
Phase 1: (usually 5-10 minutes) Deploy DefensePro in Transparent (Switch-

Switch) mode. Transparent mode allows you to confirm that DefensePro is operating properly and is successfully connecting to your network.
Phase 2: (usually 1-7 days) Deploy DefensePro security policies in Report

only mode. This mode allows you to see all the attacks for which protections are configured in DefensePro, and the prevention measures that would have been taken had DefensePro been in the Block mode. During this phase, you can fine-tune your protection and detection policies to match real-world security conditions. The adjustments can be made by modifying the policies or tuning the protection parameters. The information gathered from Phase 2 enables you to properly adjust your organizations security strategy to meet your needs before implementing actual active protections.
Phase 3: Deploy DefensePro security policies in Block mode to protect your

network from all forms of attack identified in your security strategy. Note: Operational Mode can be configured separately for each network security policy if you require more time to analyze traffic patterns for some attack types.

New Security Features (DefensePro 4.01.01)

This section reviews the main features that were introduced in DefensePro software version 4.01.01. To read the full feature set and details that were added with version 4.01.01, refer to DefensePro 4.01.01 Release Notes.

Server Cracking Protection

Server Cracking Protection profile defends the applications in your network, protecting against cracking attempts and applications vulnerability scanners. Application scanning and authentication brute force attempts are usually precursors to more serious exploitation attempts. The attacker is trying to gain access to a restricted part of the application or to find a known vulnerability through the process of sending a list of legitimate looking requests and analyzing the responses. Both cracks and scanning attempts are characterized by a higher (frequency and quantity) than usual error responses from the application to specific users. Blocking such attempts helps preventing the higher volume and higher severity attacks. Server Cracking Protection profiles provide application level protection that identifies the higher (frequency and quantity) than usual error responses from various applications and blocks the sources that are responsible for these hacking attempts, while allowing legitimate traffic to pass through.

HTTP Mitigation
HTTP flood is an application level attack that aims to inflict denial of service on web servers by sending legitimate requests in high volume, requesting large files from the site or invoking scripts such as search functions. Since the requests used in this type of attack are legitimate, it is very difficult to control them and prevent such attacks. The HTTP Mitigator protection uses an adaptive behavioral-based analysis to collect and build a statistical model of the protected server traffic, and fuzzy logic inference systems and statistical thresholds to detect traffic anomaly. Prevention is done according to more in-depth HTTP traffic parameters that are analyzed once traffic anomaly is detected. The protection is a part of the new server based protections, which means that all statistics are collected per a protected server object. Attack mitigation is made per protected server as well. The HTTP Mitigator's aim is to cover a few possible scenarios of attacks against web servers. All attack scenarios share similar characteristic that include a repeated sequence of HTTP "page" request, as follows: a. An attack that uses a repeated HTTP request pattern from the same source address. b. An attack that uses a repeated HTTP request pattern in the same TCP connection. c. Scenarios (a) or/and (b) that are generated from multiple source IP addresses. In this case we assume that there are thousands of source IP addresses that participate in these attacks. d. Scenarios (a) or/and (b) that are generated from infinite source IP addresses. In this case mitigation will be based on the HTTP request that take part in the attack.

Recommended Protection Configuration Strategies

BDoS TCP SYN Flood Protection and SYN Cookies Protection
DefensePro provides the following two protections against SYN Flood attacks: SYN Protection - a server-based SYN Flood protection that uses advanced hardware based SYN cookies mechanism. This feature is designed to detect and protect stealthy, SYN attacks, which misuse individual server resources. SYN Protection can detect low rate attacks but can prevent attacks in rates higher than the device throughput. Behavioral DoS (BDoS) SYN Flood protection a network-wide protection feature designed to detect and prevent high-rate SYN Flood attacks that misuse bandwidth resources.

The two protections complete each other to provide full protection of the network. Lower-rate SYN attacks are detected by the Stateful Inspection mechanism based on the number of non-established connections on the protected server, and blocked through a SYN cookies mechanism. The SYN cookie challenges the legitimacy of a source IP. This protection prevents attacks that can harm servers without affecting the network but can scale to high volume attack. Network wide attacks that do not target a specific server and can cause a Distributed Denial of Service attacks are prevented using the BDoS protection with an advanced attack footprint analysis. . Radware recommends using the Behavioral DoS for network-wide protection against SYN floods (among other DoS/DDoS floods protections). The use of SYN Protection (SYN Cookies) shall be set per specific server, preventing SYN attacks, starting from attacks that might not be characterized by the Behavioral DoS feature, to high rate attacks. Note, that the Behavioral DoS protection against SYN Floods can be deployed in asymmetric routing environment, while the SYN Protection based on SYN Cookies requires symmetric environment due to its Stateful operation.

DoS Shield Protection

DoS Shield provides protection against known flood attacks that cause a denial of service effect, making a computer resource unavailable to its intended users. DoS Shield profiles prevent known denial of service attacks that can not be protected using behavioral analysis due to the anomalous nature of the attack packets. DoS Shield attacks signatures can be configured for lower thresholds and can be customized by the user. DoS Shield protection attacks are defined using signatures from the Radware Signature. This database is constantly updated and it contains protection against all the known threats. Radware Signature profiles include all the DoS Shield signatures as part of the Signature database. Radware predefined profiles already include DoS Shield attacks protection. If you want to create a user define profile and include DoS Shield attack, you need to define a profile with the Threat Type attribute set to Floods. (See DefensePro user guide Configuring Signature Protection with User Defined Profiles, page 3-60)

The DoS Shield mechanism is sampling packets flowing through the device and compare them to the attack signatures, once a preconfigured threshold has passed DefensePro will apply the action in this signature on each packet (out of the full traffic without sampling) that matches the attack signature.

Network Anti- Scanning (Zero Day Worm Propagation) Protection

DefensePro provides zero-day protection against Network Scans and Worm Propagation activity. The anti-scanning feature has four detection sensitivity options. Radware recommends using the default profiles. By tuning the detection sensitivity, scan detection mechanisms can be configured to respond only to the level of scanning your security policy requires. More about that is specified in this paper per deployment scenario. For more details about how the Anti Scanning feature works, refer to Appendix A Anti Scanning Technical Note. Note: Scanning activity is very prevalent on the internet, if DefensePro is not reporting on scanning activity after the installation and configuration please consider to increase the sensitivity.

Server Cracking Protection

Server Cracking Protection defends the applications in your network, protecting against authorization hacking (e.g. Brute Force, Dictionary attacks), vulnerability scanning (e.g., Web scan, SIP scan) and application floods. Server cracking protections offers four detection sensitivity levels. Radware recommends using the default profiles. The detection mechanism is based on the analysis of application response code. Non-updated or non-maintained Web server may return error codes at such a rate as to cause false positive alerts for Web scan activity. In this case, you may wish to use a less-sensitive detection level. During Detection mode operations, you can determine whether DefensePro has detected actual Web Crack activity or false positive alerts from a non-maintained server by examining the attack frequency and source of attack. If the requests appear to be normal Web traffic (e.g., many different source IP addresses are detected simultaneously which is not a typical scan attack), the alert can be considered to be associated with normal Web service activity. In this case, Radware recommends applying appropriate updates to your Web server. You can also adjust the sensitivity of Web scan to a lower value. For a non-updated or maintained Web server with many outdated links, Radware recommends using Low sensitivity. For more details about how the Server Cracking feature works, refer to Appendix B Server Cracking protection Technical Note.

Signatures Protections
Signatures protection detects and prevents network-oriented attacks, Operation System (OS) oriented attacks and Application oriented attacks by comparing each packet to the set of signatures stored in the Signatures database. You can configure Signature protection using Radware profiles, OR using user defined profiles. When creating a user defined Signature profile, you need to state a rule or a set of rules that suit the network segment that you want to protect. DefensePro activates attacks from the Signature database that comply with this rule set. The user defined profile is constantly updated when downloading Signatures database. The rule-based intrusion profile configuration tool enables you to define an intrusion prevention profile based on various parameters that identify and characterize your network environment, applications, threat level and risk levels. Each attack signature has attributes in each one of the categories: Services Defines which protocols are used in your environment, for example, FTP, HTTP, DNS and so on. Only attack signatures that match these protocols are selected for this rule. Platforms Defines what operating systems exist in the segment, for example, Windows, Linux, Unix and so on.,. Only attack signatures that match these OS are selected for this rule. Applications Defines what type of applications are in the segment you are protecting, for example, web servers, mail servers, browser, and other servers. Threat Type Defines the threats against which you want to protect your system, for example, buffer overflows, worms, and so on. Risk The Risk level represent the severity of an attack. For example, attacks that their impact on the network is very severe are considered with high risk. Confidence Is defined as the level of certainty to which an attack can be trusted. The confidence level is the opposite of the false-positive level associated with an attack. Complexity - Is defined as the level of complexity the attack filter has. Higher complexity may have higher performance implications. Virtual Groups - Allow the user to create a group of rules that are not necessarily defined through the above mentioned attributes.

For more details about configuring Signature profiles, refer to the DefensePro 4.0 User Guide, Section 3-6.

Policy Direction
DefensePro network security policies are set with direction, protecting against inbound attacks or inbound and outbound attacks. The policy direction is configured as a part of the policy action settings. This guide details per each solution the policy direction for optimal attack detection and protection.

Considerations
Use one way policy from-to in order to protect a network from the outside world. Use two way policy when DefensePro is placed between two similar networks such as LAN segments or carrier networks. Always give the policy a direction either using the physical port or using the network segments.

Working with MPLS VPNs

MPLS-VPN also known as L3VPN is a method of creating Virtual Private Networks, providing traffic isolation and differentiation, without substantial overhead. While the network provides many advantages for network administrators and customers alike few problems are discovered. Each of the MPLS-VPN customers may use the same private IP address range for communication, and the MPLS tag is changed randomly. For these reasons neither IP address nor MPLS tag can be used to identify and distinguish MPLS VPN customers and create network security policies per customer. For more details of DefensePro support for MPLS-VPN clients based on VRF information, specifically MPLS RD (route distinguisher) value, refer to Appendix C.

Working in Asymmetrical Network Environments

One of DefensePro's strong points is the ability to work in asymmetrical routing network. DefensePro's ability to work in stateless mode enables it to inspect ingress or egress traffic without the need to see both traffic sides on the same port pair or device. For more details about how to deploy DefensePro, refer to Appendix D.

Cases and Solutions

Scenario 1: Enterprise (Corporate) GW and DMZ
If you are managing an enterprise network security, you are required to provide protection and ensure availability of your company DMZ servers and protect the enterprise network against attacks arriving through the enterprise Internet access. Following this scenario you will define set of security policies designed best for the company internet access and DMZ servers. DefensePro is deployed as an inline device.

Suggested Physical Implementation:

Users Segment Policies

Description Two policies shall be created for the users segment. The first is an inbound policy containing signature protection profile and anti-scanning profile to prevent intrusions, pre-attack probes and worm propagation that target the enterprise hosts. The second is a two-way policy containing Behavioral DoS profile and DoS Shield signatures profile that ensures high availability of network resources. Network Policy Suggestion Typically, both policies shall be created with direction from Any (the internet) to the user segment IP addresses or NAT address that is configured on the firewall. This ensures the accuracy of the detection and the efficiency of the inspection.

10

Inbound security policy:

Signature-Protections Profile: Apply the predefined Corp-GW profile for this scenario. The Corp_GW signature profile is designed to protect the corporate internet access against Major vulnerabilities and malware that could target hosts that access the internet. Anti-Scanning Profile: Apply the Anti Scanning GW profile type with Medium detection sensitivity level. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other types of intrusion attacks.

Bi-directional security policy

The following DoS & DDoS protections ensure internet access availability to the corporate users. DoS Shield: Apply the predefined All_DoS Shield profile. Note: starting with DefensePro version 3.10 or later, DoS Shield signatures are included in the Signature protections module. BDoS: Create a Behavioral DoS profile and activate all attacks. Note: You must configure BW and Quota settings according to the maximum volume of traffic that is expected on your links. Note about network scan behind NAT address: Scanning activity from users located behind a proxy server or NAT device is difficult to differentiate, and only very high-rate scanning activity is accurately attributable to a single host. Therefore, in case anti-scan is activated on the outbound traffic direction then a 3rd outbound policy should be configured (e.g., From: NAT address, To: Any) with GW profile and Minor detection sensitivity.

11

DMZ segment Policies

Description Two policies should be created for the DMZ segment. The first one is an inbound policy that protects the DMZ servers against Intrusions, Server Cracking attempts and HTTP floods, ensuring full spectrum protection to the DMZ servers. The second one is a two-way policy that protects against Denial of Service attacks, anti-scan and Worm Propagation prevention. The second policy protects the DMZ servers against inbound worm propagation, while allowing the detection of already infected servers by the outbound protection. Network Policy Suggestion Both policies should be created with direction from Any (the internet) to the public address or addresses of the DMZ servers. This ensures the accuracy of the detection and the efficiency of the inspection. Inbound security policy: Signature Protections: Apply the predefined "Corporate DMZ" profile. This profile is designed to protect against a wide set of application vulnerability exploitations, such as web vulnerabilities, mail vulnerabilities, FTP, VoIP and so on. This profile also protects against common malware, such as Trojans, backdoors, worms and known DoS attack tools while ensuring minimal false positive and highest performance. Administrators may create a user defined profile and tune the profile farther by selecting only services and platforms that apply to the corporate real DMZ servers. Server-Cracking Protection: Apply a Server-cracking profile with the attacks per each service that is supported by your DMZ. Available protections: Brute Force FTP Brute Force POP3 Brute Force SIP (TCP) Brute Force SIP (UDP) Brute Force SMTP Brute Force Web Brute Force MSSQL Brute Force MySQL SIP Scan (TCP) SIP Scan (UDP) Web Scan

HTTP Mitigator: Apply protection against HTTP floods for each web server that is installed in your DMZ.

12

Bi directional security policy Anti-Scanning: Apply the Anti Scanning GW profile type with Medium detection sensitivity level. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other type of intrusion attacks. Notes about anti scanning (zero-day worm propagation prevention) protection in DMZ deployment: Inbound Scans - Generally, no inbound scanning activity from the Internet to the protected network is considered legitimate. Radware suggests using the Medium sensitivity setting for inbound network scans when DefensePro is deployed as a perimeter security device that protects the DMZ. Outbound Scans - Outbound scanning activity from the protected network to the Internet or to an external segment in your network is problematic because of bandwidth utilization. Slow scans are not as much of an issue, since they use very little bandwidth, but high-rate scans or worm propagation can cause a decrease in performance. Therefore, the outbound detection sensitivity is lower than the inbound detection sensitivity. Since network scanning and network worm propagation is a permanent phenomenon, if no scanning activities are detected during the first week after installation, then it is recommended to change the setting of the scan detection sensitivity to a higher level (i.e., in this case from Medium to High).

BDoS: Create a Behavioral DoS profile and activate all attacks. SYN Protection: Apply a SYN protection profile defending the DMZ servers against lower rate SYN flood attacks. Add to the profile SYN attacks according to the services deployed in your DMZ, such as: SMTP POP3 IMAP HTTP (Port 80) FTP Telnet

Note: The above services are preconfigured in the SYN Protection feature. It is also possible to configure additional service protections. For more information consult the DefensePro 4.0 User Guide. When you are done configuring all of the above, the Connect & Protect table displays the following:

13

14

Scenario 2: Campus Network - University

In the campus (public network) model, DefensePro protects several segments (buildings, departments and so on) as well as server segments. The campus model assumes that attacks may arrive from the Internet as well as from the internal segments. Users who are students or non-organizational members may launch attacks from the internal network. Hackers may also infect campus hosts with bots and other malware, which enables them to launch distributed attacks using the campus network resources.

Suggested Physical Implementation:

Description This campus security policy is designed to protect the internal LAN segments in University type of networks. In this type of network, the workstations are not

15

trustworthy. Therefore, significant number of attacks are likely to originate from the hosts in the local area network. University networks have to accommodate different needs of different research groups and as result are very lenient in blocking policies. As a result firewall, in many cases, is not deployed. Protecting the campus network requires several policies, each suited for different segment. The university data center should be protected with an enterprise DMZ profile. The buildings, departments, or user segments, should use the security policy that is recommended below. Network Policy Suggestion Each segment should have its own network policy protecting form "any" to the specific network IP ranges. This ensures protection of each segment against attacks generated by its own hosts, as well as from attacks arriving from the Internet or from other segments.

User segments policies

Bi-directional security policy: Signature Protections: Apply the predefined University-LAN profile. Anti-Scanning: Apply the Anti Scanning GW profile type with Low detection sensitivity level between the segments and the Internet, and use LAN profile with Low detection sensitivity level between the various segments. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other types of intrusion attacks. Notes about Anti Scanning (zero-day worm propagation prevention) protection in LAN deployment: In the majority of networks, there is a legitimate scanning activity taking place within the network, such as network health monitoring, QoS applications, and other monitoring applications. Radware suggests configuring anti-scan LAN profile when deploying DefensePro between user segments on the internal network. The recommended configuration permits the legitimate scanning activity to pass filters and stops the most intense high-rate scanning activity. This is how using of the Anti Scanning protection allows monitoring applications to function normally, while providing protection from illegitimate scanning activity generated by infected users (e.g., worm propagation activities). BDoS: Create a Behavioral DoS profile and activate all attacks. Note: You must configure BW and Quota settings according to the maximum volume of traffic that is expected on your links.

16

Server Farm policies

See Enterprise DMZ security profile recommendations. When you are done configuring all of the above, the Connect & Protect table displays the following:

Note: Multiple polices and performance. There is a tradeoff between multiple policies and performance. Multiple policies are better for manageability but may impact the performance of the device. If you see that you need to create too many policies (rule of thumb more than 10) you may consider consolidating the policies and use the physical ports as the policy direction. Please refer to the Defining Policy Direction section for more information.

17

Scenario 3: Protecting your E-Commerce Servers

Description The major concern of E-Commerce sites is to maintain high availability of their revenue generating web site. E-Commerce sites are the main target of denial of service attacks. In this scenario DefensePro is deployed to protect against network flooding and application flooding that aim to misuse network and server resources.

Suggested Physical Implementation:

Network Policy Suggestion

The security policy should be created to protect against attacks arriving from the internet (Any) to the servers with any-to direction. The "to" segment should include all the network addresses that are exposed to the world (public IP addresses of the servers). This ensures that the different protections are applied with the correct direction for highest accuracy.

18

Inbound security policy:

DoS Shield: Apply the predefined All-DoS-Shield profile. Note: Starting with DefensePro version 3.10 or later, DoS Shield signatures are included in the Signature protections module. BDoS: Create a Behavioral DoS profile and activate all attacks. Note: You must configure BW and Quota settings according to the maximum volume of traffic that is expected on your links. SYN Protection: Apply a SYN protection profile defending the servers against lower rate SYN flood attacks. Add to the profile SYN attacks according to the services deployed in your site: HTTP (Port 80) HTTPS (Port 443) Server-Cracking Protection: Apply a Server cracking profile to protect your servers from brute force attacks and web vulnerabilities scanning. Recommended protections: Brute Force Web Brute Force MSSQL Brute Force MySQL Web Scan HTTP Mitigator: Configure HTTP Mitigator per each web server to protect against HTTP flood attacks.

Bi-directional security policy

Anti-Scanning: Apply the Anti Scanning GW profile type with Medium detection sensitivity level. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other type of intrusion attacks. Notes about network scans (zero-day worm propagation) protection in E-Commerce deployment: Inbound Scans - Generally, no inbound scanning activity from the Internet to the protected network is considered legitimate. Radware suggests using the Medium sensitivity setting for inbound network scans when DefensePro protects public servers. Outbound Scans - Outbound scanning activity from the protected servers to the Internet is a concern because of bandwidth utilization. Slow scans are not as much of an issue, since they use very little bandwidth, but high-rate scans or worm propagation can cause a decrease in performance. Therefore, the outbound detection sensitivity is lower than the inbound detection sensitivity (the system automatically adjusts the sensitivity level). Since network scanning and network worm propagation is a phenomenon that exists all the time, if no scanning activities are detected during the first week

19

after installation, then it is recommended to change the configuration of the scan detection sensitivity to a higher level (i.e., in this case from Medium to High). When you are done, the Connect & Protect table should look like this:

20

Scenario 4a: Protecting the Carrier Data Center

Description
The carrier (or Service Provider) deploys data centers, usually located in the central POP, to support the Internet service and value-added services. The Carrier data center usually hosts DNS servers, VoIP servers, Mail servers and Web servers. The Data center should be protected to maintain the service survivability by removing attacks exploiting known server vulnerabilities, service cracking attempts, misuse of server resource and high volume bandwidth consuming attacks.

Suggested Physical Implementation:

Network Policy Suggestion

Network policy should be created with Any-to direction. The "to" should include all network addresses that are exposed to the world (public IP addresses of the servers). This ensures that the different protections are applied with the correct direction for high accuracy. In order to improve the detection sensitivity of the BDoS, it is recommended to create multiple network policies (e.g., 1 to 5 policies). Each policy is intended to protect a

21

different segment of servers. The activation of the BDoS protection is also done separately for each policy. This way the BDoS protection creates a more granular normal base line that fits the behavior of each servers' segment. For example: Policy 1: Any -> Web servers segment Policy 2: Any-> DNS servers segment Policy 3: Any-> Mail servers segment

Global Security policy

Configure 2 policies to protect your data center. Inbound security policy Signature Protections: Apply the predefined "Corporate DMZ" profile. This profile is designed to protect servers from various application vulnerability exploitations, such as Web vulnerabilities, mail vulnerabilities, DNS, VoIP, FTP and more. This profile also protects against common malware such as Trojans, backdoors, worms and known DoS flood tools, while ensuring minimal false positives and highest performance. You may create a user defined profile and tune the profile farther by selecting only services and platforms that apply to the data center servers. SYN Protection: Apply a SYN protection profile defending the servers against lower rate SYN flood attacks. Add to the profile SYN attacks according to the services deployed in your data center, such as: SMTP POP3 IMAP HTTP (Port 80) FTP Telnet

Note: The above services are preconfigured in the SYN Protection feature. It is also possible to configure additional service protections. For more information consult the DefensePro User Guide. Server Cracking Protections: Apply a Server Cracking profile with the attacks per each service that is supported by your data center: Available protections: Brute Force FTP Brute Force POP3 Brute Force SIP (TCP) Brute Force SIP (UDP) Brute Force SMTP Brute Force Web Brute Force MSSQL

22

Brute Force MySQL SIP Scan (TCP) SIP Scan (UDP) Web Scan

HTTP Mitigator: Apply protection against HTTP floods for each web server that is installed in your data center.

Bi-directional security policy Anti-Scanning: Apply the Anti Scanning GW profile type with Medium detection sensitivity level. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other type of intrusion attacks.

BDoS Security policies

As mentioned above, create a security policy per each server segment in your data center. BDoS: Create a Behavioral DoS profile and activate all attacks. Notes: You must configure BW and Quota settings according to the maximum volume of total traffic that is expected on your links. You can apply the same BDoS profile per each policy protecting a server segment.

When the configuration is done, the Connect & Protect table should look as follows:

23

Scenario 4b: Cleaning the Carrier Link

Description
The term "Clean Link" defines the capability of any Carrier to provide, through its infrastructure, a full capacity of Internet connectivity to its customers. To achieve this goal, the carrier needs to filter attack traffic that misuses its bandwidth resources and, at the same time, continue to provide high quality services to its legitimate customers. Malicious traffic can consume the carriers revenue-generating bandwidth and overload its infrastructure devices (e.g., routers, switches, etc.). Therefore, it is vital for carriers to maintain a clean link. To have a "Clean Link" at the carrier core network, you need a system that will be capable of processing traffic in multi-gigabit rates. Therefore, Radware recommends using the DefensePro 6000 (high end DoS/DDoS protection device) for this type of deployment.

Suggested Physical Implementation:

In this scenario, DefensePro is deployed behind a peering point router as an inline solution to clean inbound and outbound traffic.

24

Network Policy Suggestion

In case IP ranges cannot be defined, a Network policy with direction from Any to Any should be created. Please use the physical port as the policy direction as explained in the Defining Policy Direction section.

Security policy
The following protections should be activated: DoS Shield: Apply the predefined All-DoS-Shield profile. Note: Starting with DefensePro version 3.10 or later, DoS Shield signatures are included in the Signature protection. BDoS: Create a Behavioral DoS profile and activate all attacks. Note: You must configure BW and Quota settings according to the maximum volume of traffic that is expected on your links. When the configuration is done, your Connect & Protect should look as follows:

25

Scenario 4c: Network based Managed Security Services (MSS)

Description
MSS provider can offer clean link services for its customers using DefensePro devices. Worm propagation, Phishing, spyware, Trojan, IRC bots are the main intrusion threats faced by users nowadays. DoS attacks are the major concern, because it is easy to consume the users bandwidth resources. The only effective way to prevent it is by a topology in which the DoS prevention is provided by the carrier at the customers upstream. In this case the pipe does not get congested and legitimate traffic can still pass through the pipe, even while under attack.

Suggested Physical Implementation:

A typical deployment of DefensePro units is next to the BRAS routers, employing policy based routing (PBR). This ensures that only paying customers (users) are opted into a local scrubbing center that provides the managed security services.

Network Policy Suggestion

Network policy should be created with the Any-to direction. The "to" should include the address range of all users.

Inbound security policy

Signature Protections: The following Signature Protection profile is designed to protect the MSSP customers. In this scenario, you will configure DefensePro to

26

protect the customers from major vulnerabilities and malware that could affect workstations that access the internet. Apply the following Radware defined profile: MSSP. Note: Radware MSSP profile was created to ensure both the protection from high risk attacks while reducing the amount of non relevant alerts that overload the MSSP NOC's personal. The profile was created to maximize performance in MSSP environment.

Anti-Scanning Profile: Apply the Anti Scanning GW profile type with Medium detection sensitivity level. This profile inspects inbound traffic for pre-attack probes and scanning attempts that precede worm infections and/or other type of intrusion attacks. The following DoS & DDoS protections ensure internet access availability to the corporate users. DoS Shield attacks are included as part of the MSSP profile, Anyway you cannot apply two profiles of the same protection. BDoS: Create a Behavioral DoS profile and activate all attacks. Note: You must configure BW and Quota settings according to the maximum volume of traffic that is expected on your links.

27

Defining Policy Direction

DefensePro version 4.0 introduces the new Connect & Protect table, which simplifies the policy configuration process. Using this table, it is possible to create new security policies as well as edit the existing ones or remove them. The following steps must be performed prior to scenario implementation: 1. In the APSolute Insite main window right-click the DefensePro icon and select APSolute OS Security. The main security configuration window named "Connect & Protect Table appears.

) to create a new security policy. The Add 2. Click the new policy button ( Policy window appears. Enter the Policy Name (in this example: Users) and click Ok to apply.

28

3. Configure the physical ports for the scanned traffic. Right-click on first cell in the Port column and select Add. The Port Groups window appears.

4. Click the Add button to add a new port group. The port group represents the ports on which traffic is scanned. The Edit Physical Port Group screen appears. 5. In the Edit Physical Port Group window, type a name for this new group (for this example we use "Users") and select the ports to be associated with that group. Select only in the inbounds ports as the outbound are picked from the "Static Forwarding" Table.

6. In the Edit Physical Port Group window click Ok to save your changes. The Edit Physical Port Group window closes. The Port Groups window remains opened. Associate the group you created with the security policy that you currently configure. Select the row with the newly created port group and click

29

Ok.

7. The Connect & Protect table now looks as follows .

8. Right-click on the cell below the Action column and select Edit. A pop up window appears. Select the scanning direction: oneway or twoway and type of action: block malicious traffic and report about it (Block and Report) or Report Only

30

9. Click Ok to save changes and to close the pop up window. 10. The Source and Destination columns represent the network subnet which is scanned. By default, those columns are set to any. This means all IPs are scanned. Important Note: To improve security accuracy and in order to prevent false positives, it is highly recommended to configure specific network ranges (i.e. Any specific network range). 11. To define a specific network range (either in the Source or in the Destination column), right-click once on the cell under the source/destination columns and select Add. The Add Network Source (or Destination) window appears.

12. In the Add Network Source (or Destination) window, click the Add button. 13. The Edit Network Table window appears.

31

14. Select the Network Type (a single host or a network segment), type a network/host name and fill in the IP mask details or IP range details. Click Ok to apply changes. The new policy appears in the Connect & Protect table.

32

Appendix A Anti-Scanning Technical Note

Abstract A computer worm is a self-replicating program. It uses a network to send copies of itself to other nodes (computer terminals on the network) and it may do so without any user intervention. These programs are often designed to launch massive distributed denial of service (DDoS) attacks or otherwise disrupt corporate operations, and therefore, cause a loss of revenue. Over the past several years, worms disseminated over the Internet have wreaked havoc on corporate operations around the world. Disruptions caused by distributed denial of service attacks that were launched via worms, create headlines on a weekly basis. IDCs Enterprise Survey 2005 continues to list worms, viruses and Trojans as the top security threat for enterprises. Financial losses from such attacks could add up to millions of dollars in addition to seriously damaging the business. A number of security product vendors have tried to tackle the problem of propagating worms. To date, none of these solutions has proven effective. DefensePro integrates the first truly proactive and adaptive set of IPS features that is highly effective in eliminating network worm propagation. DefensePro employs Adaptive Smart Dynamic Filters that are both extremely accurate and simple to use. Using sophisticated, advanced statistical analysis, fuzzy logic, and a novel closedfeedback filtering mechanism, DefensePro IPS devices automatically and proactively repel and attack incoming worms before they can cause harm. DefensePro does not use signatures and do not rely on user defined behavior policies/thresholds in order to detect worms. The devices are also adaptive to normal traffic changes, so they are not affected by naturally evolving network behavior. Behind the technology DefensePro is a hardware appliance that is placed in-line with network traffic, typically at the network perimeter or between key network segments. The DefensePro employs the following three automatically synchronized processes to optimize worm prevention: Detection - Real-time discovery of worm propagation. Characterization Classification of the worm propagation profile. Mitigation Activation of Adaptive, Smart, Dynamic Filters that block the worm evolving profile. Detection Worm detection is based on behavioral analysis of user's (source IP) payload (data) distribution across its connections in the network. Statistical parameters are collected per user (source IP address). Parameters per user include: Number of connections to different destination IP and Ports pairs over a period of time Stateful Score for each connection Target port numbers (below and above 1024)

These parameters are used in order to create the user distribution curve, as shown in Figure 1.

33

Figure 1 - User Distribution

Normal distribution is characterized by fewer connections (in regards to destination ports and IP addresses) and higher score per connection as described in the following paragraph. Abnormal distribution is characterized by numerous connections (in regards to ports and IP addresses) and lower score per connection. Connection Scoring Examples TCP Connection In the following example several stages of the TCP connection and the associated scoring are shown.

Figure 2 - TCP Connection Scoring

34

UDP Session

Figure 3 - UDP Scoring

ICMP

Figure 4 - ICMP Scoring

UDP, ICMP and sometimes SYN packets are used in regular network scanners in order to identify and find hosts and services on the network. Using the same scoring system DefensePro is capable to detect and block the regular scanners.

Worm Characterization
One of DefensePros patent-pending technology breakthroughs is its ability to dynamically characterize the ongoing (and potentially mutating) propagation methods used by worms. The technology is based on the innovative implementation of statistical algorithms that characterize worm profiles. Profiles include such information as where the worm originated and which vulnerable applications the worm it is trying to exploit.

Worm Filtering
DefensePros mitigation module is responsible for generating filters that effectively prevents the worm activities and at the same time allows legitimate traffic to go through (even if it was generated from the infected hosts themselves). The mitigation module generates prevention measures according to the worm profile that was generated by the characterization module. These prevention measures block

35

the worm traffic. In any case blocking or rate limiting apply only to traffic that matches the worm spreading profile. Closed-Feedback DefensePro incorporates closed-feedback technology that optimizes the prevention measures against the worm by continuously evaluating the effectiveness of the countermeasures and adjusting them accordingly.

?
Analysis
Intense Worm Activities

?
Analysis
Potential Worm Activities

?
Analysis

Safe Environment

(e,g., source IP -> port 135 (TCP) OR (e.g., source IP -> port 135 (TCP)) port 445 (TCP) )

Initial Prevention Measure

Optimization

Optimization
(e,g., source IP -> port 135 (TCP) OR port 445 (TCP) ) AND ( packet size AND TTL AND, )

Figure 5 - Closed Feedback

The initial blocking rule is the scanning source IP address and the scanned destination port or IP address. The source is being tracked longer for other scanning activities and if they are detected, an additional scanned destination port number or IP address is added. Once the scanning activity is mitigated, the footprint is further optimized using packet characteristics such as TTL, ID and other as described in the following lists. Version 3.10 Footprint Types Packet Characteristics IP Source Address Destination Port Destination IP address TTL Packet Size Max number of Instances 1 1 1 1 1 Logical Operation AND AND AND AND AND

36

Blocking Footprint Example: Vertical scan: IP Source Address AND IP Destination Address(es) AND Total Packet Length (if found) AND Time To Live (TTL) (if found). Horizontal scan: IP Source Address AND Destination Port(s) AND Total Packet Length (if found) AND Time To Live (TTL) (if found). Version 3.20 Footprint Types Packet Characteristics IP Source Address Destination Port Destination IP address TTL Packet Size IP ID (Packet Identification Number) TCP Sequence Number ICMP Message Type Max number of Instances 1 5 5 1 1 1 1 1 Logical Operation AND OR OR AND AND AND AND AND

If more than 5 Destination Ports or Destination IP addresses are found they will not be used in footprint at all. Blocking Footprint Example: Horizontal scan example: Source IP address = 192.168.1.1 AND Destination Port = (135 OR 445 OR 165) AND Packet Size = 100 AND IP ID=1402 AND TCP Seq=102030. Vertical scan example: Source IP address = 192.168.1.1 AND Destination IP = 200.0.0.1 AND Packet Size = 100 AND TTL=50 AND IP ID=1400.

Configuring Worm Propagation and Anti Scanning profiles

Deployment Considerations DefensePro can be installed in the following locations: At the Corporate GW protecting the users and the public servers. At the Corporate LAN - separating user segments and mission critical servers. At the Carrier network - protecting the core or between peers.

For each location a special protection profile was created and tuned for the different requirements of each implementation location.

37

Policy Directions Anti scanning should always be used in network policies that have directions, meaning protecting from source address (could be any) to protected network. Anti-Scanning profiles Each anti-scanning profile suites the location in the network that is described by its name. The profiles have internal configured sensitivity scales that are adapted to the network location, so that you can fine tune it by selecting the sensitivity levels in the same profile.

Figure 6 - Selecting a Profile Type

Figure 7 - FineTuning the Sensitivity

38

Gateway Corporate gateway is installed between the outside world and the corporate user space and public servers.

Figure 8 - GW Installation

When DefensePro is installed as a gateway, we need to assign different sensitivity levels to the different sides of the device due to the probability of actual worm activity passing through the device. Since the device is the default exit point of all outbound traffic, there is higher probability that an outbound scanning activity (internally infected host) goes through the device and is detected. On the other hand the external exposed IP addresses represent a small segment of the available address space and the probability of scanning activity hitting this segment in high repetition is very low. For this reason we need to assign a low sensitivity to the outbound traffic and higher sensitivity to the inbound traffic. Note: The profile is preconfigured to have asymmetrical sensitivity levels as can be seen in the following tables: Gateway Profile Inbound Policy Detection Sensitivity The slowest scan to be detected 1 every 10 Minutes 1 every 1.5 Minutes 1 every 0.05 second (20/sec) 1 every 0.01 second (100/sec) Attack trigger (in case of pure scan)* At least 5 events At least 15 events At least 75 events At least 105 events

High Medium Low (default) Very Low (minor)

39

Gateway Profile Outbound Policy Detection Sensitivity The slowest scan to be detected 1 every 5 seconds 1 every 0.2 second (5/sec) 1 every 2 seconds 1 every 0.05 second (20/sec) Attack trigger (in case of pure scan)* At least 15 events At least 45 events At least 25 events At least 90 events

High Medium Low (default) Very Low (minor)

Note: if the policy does not have a direction, both directions are considered outbound and have the lowest sensitivity values. This may result in misdetection of inbound scanning activities. LAN In LAN installation the device is sitting between two segments of the LAN or between users and mission critical servers and protects one from the other.

Figure 9 - LAN Installation

Since traffic between the two protected segments has to flow through the device, there is only one scale of sensitivity for this profile. The activity seen by the device is very high, so the sensitivity level is inherently lower than for example GW inbound sensitivity.

40

LAN Profile Inbound & Outbound Policy Detection Sensitivity The slowest scan to be detected 1 every 5 seconds 1 every 0.2 second (5/sec) 1 every 2 seconds 1 every 0.05 second (20/sec) Attack trigger (in case of pure scan)* At least 15 events At least 45 events At least 75 events At least 105 events

High Medium Low (default) Very Low (minor)

Carrier In Carrier installation the device is installed between the user segments and the core, or between peering points. There is no significance for directions and the scanning is fairly symmetric. Sensitivity levels are very similar to LAN, but the chances of false positive triggering are slightly lower.

Figure 10 - Carrier Network

Carrier Profile Inbound & Outbound Policy Detection Sensitivity The slowest scan to be detected 1 every 5 seconds Attack trigger (in case of pure scan)* At least 15 events

High

41

Carrier Profile Inbound & Outbound Policy Detection Sensitivity The slowest scan to be detected 1 every 0.2 second (5/sec) 1 every 0.01 second (100/sec) 1 every 0.05 second (20/sec) Attack trigger (in case of pure scan)* At least 45 events At least 90 events At least 105 events

Medium Low (default) Very Low (minor)

Dynamic blocking duration mechanism Upon detection of an attack, the system implements the blocking footprint rule for a pre-defined Initial Blocking Duration (default 10 sec). The blocking period fits into the average scanning rate (i.e., will effectively block slow rate scans as well). There is a parameter called Slow Rate Blocking which, if enabled, allows the system to adapt the blocking interval according to the scan rate.. In a case of attack's consistency, which means that the system detects repeated scanning activities from the same source, the system extends the blocking duration according to a dynamic blocking duration mechanism. This mechanism includes a random factor that sets "unpredictable" blocking duration. The maximum blocking duration that the system can renew for the source of a scan if that source continues to scan the network is 80 seconds. Summary Worms wreak major damage to organizations in the form of lost revenue and damaged reputation. Until now, worms have not been effectively controlled by existing network security solutions. DefensePro offers the most effective and the simplest product today for the prevention of worm propagation. When installing DefensePro Anti-Scanning Protection, it is imperative to find the right profile that suits the installation, later on it is possible to use different sensitivity levels in this profile to fine tune the device to the actual network activity.

42

Appendix B Server Cracking Protection

Abstract Server Cracking Protection profiles defends the applications in your network, protecting against cracking attempts and vulnerability scanners. Application scanning and authentication brute force attempts are usually precursors to more serious exploitation attempts. The attacker is trying to gain access to a restricted part of the application or to find a known vulnerability through the process of sending a list of legitimate looking requests and analyzing the responses. Both, cracks and scanning attempts are characterized by a higher (frequency and quantity) than usual error responses from the application to specific users. Blocking such attempts helps preventing the higher volume and higher severity attacks. Server Cracking Protection profiles provide application level protection that identifies the higher (frequency and quantity) than usual error responses from various applications and blocks the sources that are responsible for these hacking attempts, while allowing legitimate traffic to pass through. The blocking is done using source tracking and fuzzy logic decision engine. Attacks are detected based on frequency and quantity of server based error responses, uniquely identified per protected application. The analysis is done per source IP and protected server. These parameters are sent to the Fuzzy Inference System (FIS) who generates DoA (Degree of attack).

Figure 11 - Server Cracking Protection

43

The Threats Brute Force Cracking attacks being brute force or dictionary attacks are trying to break into an application by guessing user names and passwords from known lists using scripts or available tools. The risk associated with these types of attacks is very clear: once a username and password are obtained, the attacker has a free access to a service, information or even to the actual server. Additional risks are denial of service by triggering built-in protections in the applications, locking out users or consuming system resources during the authentication attempts. Application Vulnerability Scanning Scanning are attacks that try at the application level to find services that are known to be vulnerable or actual vulnerabilities so they could later be exploited by the attacker. The scanners, being automatic or manual, do not send an exploit to the server, but a more legitimate request that only shows the existence of the vulnerability, and as such does not trigger a signature based IPS. In most cases the server is not vulnerable and responds with an error message. SIP Scanning In SIP scanning the attackers aim is slightly different. While it is possible to find vulnerable SIP implementation, the actual gain from SIP scanning is to obtain a list of SIP subscribers and to send them SIP SPAM messages also known as SPIT. An attacker uses scripts to send the SPIT messages to a list of guessed subscriber names and notes the ones that reply. SPIT can cause inconvenience to the subscribers and can disrupt the service if done in high volumes. SIP Brute Force A register brute force is an attempt to gain access to a user account and through it to the service, allowing the attacker to use the service without paying for it, causing revenue loss, reputation loss and increase in bill verification activities. Behind the technology DefensePro is a hardware appliance that is placed in-line with network traffic, typically between the clients and the protected servers. The detection mechanism is based on the analysis of server error code replies. The codes are identified by matching server responses signatures that can be updated in a similar way to the AttackDB. The signatures can be updated to provide additional protection to new applications or improving existing ones. Currently available protections are: Web Authentication Brute Force Web Scans SMTP Brute Force FTP Brute Force POP3 Brute Force SIP Brute Force (UDP & TCP) MySQL Brute Force MSSQL Brute Force

44

SIP Scans HTTP proxy authentication Brute Force. Web authentication that is done at the application level and the HTTP is not detectable by this feature. The errors in this case are sent in the HTML response with no HTTP error code and are undetectable using a signature. The Web Scans protection does not work on web servers that are configured to return HTTP 200 OK instead of HTTP error message. Even if the body of the HTML page says that an error has occurred DefensePro will not be able to detect it without an HTTP error code. While this practice is not recommended by the RFC, it is sometimes used by web server administrators. A future support for such customized error pages will be implemented.

Protection limitations:

Exponential moving average mechanism is responsible for deriving behavioral parameters (frequency and quantity of code replies) per source IP address and protected server. These parameters are further analyzed through Fuzzy Logic Inference System that generates a DoA (degree of attack). The DoA determines the state of each user (source IP address): Attack state: The user (source) is blocked Suspect state: The system continues to follow the user for a predefined duration (suspect monitoring time-out). Normal state: The system continues to follow the user for a pre-defined duration (normal monitoring time-out which is lower than the Suspect state time-out).

Mitigation Once a user (source) has been identified as an attacker, it is blocked, meaning no more connections from this source to the destination IP and port (service) are accepted. In case of attack, DefensePro inserts the source IP to the block list, or extends the blocking duration in case the IP address was already blocked during the same attack lifecycle. When the system detects the attack, the first blocking period is a random value between 10 to 30 seconds. Upon inserting the source IP into block list, the system keeps tracking the user (source) for the duration of the blocking period and additional expiration time (User monitoring interval) that is defined by the sensitivity that is set for the specific attack. If the user (source) keeps attacking the network during the monitoring interval it is blocked again using a new blocking period that is more than twice the last blocking period up to the maximal blocking period, which is 120 seconds.

User Monitoring Intervals:

User State User Monitoring Interval per Profile (sec) High sensitivity 20 40 60 Medium sensitivity 15 30 45 Low sensitivity 10 15 20 Minor sensitivity 5 10 15

Normal state Suspect state Attack state1*

45

In case of user attack state, the user is added to the block list and the monitoring interval is set when the user is released from block. Deployment Considerations When the Server-Cracking Protection will be server based, there will not be the need to define the servers that will be protected by the feature. The administrator will create a network security policy that will include the protected servers in it, by using IP ranges or physical segments and add Server-Cracking Protection to the network security policy. Based on the application running on the protected segment the administrator can choose which type of protection to add to the profile.

Figure 12 - Creating a Server Cracking Protection Profile When adding a signature to the profile the administrator can configure the sensitivity associated with the specific attack on the specific policy.

46

Figure 13 - Sensitivity Settings The sensitivity level defines thresholds for the number and frequency of server side error messages. These messages are tracked to trigger attack detection. High sensitivity means it needs few cracking attempts to trigger the protection, while Minor means it needs very high number of attempts. Default: Medium. There may be cases where you need to tune this value. For example, if you are protecting a non-maintained or non-updated web server it may generate HTTP error code replies at abnormal rate, which may trigger false attack detection. In this case it is recommended to use a less sensitive profile with sensitivity set to Low. Cracking (Brute-force) attempts Triggers: Sensitivity
High Medium Low Minor

Counter Attack trigger

20 40 60 80

Frequency [1/sec] Attack trigger

5 10 15 20

Note: Application scanning and brute-force attempts are usually generated trough multiple L4 connections. If the attack attempts are using the same L4 connection (i.e., TCP or UDP connection) detection sensitivity will be automatically set to a higher value than those that are specified in the above table, thus the number of attempts and their frequency that is needed for attack triggering will be lower. Cracking attempts Triggers (Single L4 connection): Sensitivity
High Medium Low Minor

Counter Attack Trigger

5 10 15 20

Frequency [1/sec] Attack Trigger

1 2 4 6

47

Scans attempts Triggers: Sensitivity High Medium Low Minor Counter Attack trigger 10 30 25 45 Frequency [1/sec] Attack trigger 0.5 1 3 30

User monitoring interval parameters:

User State User Monitoring Interval per Profile (sec) High sensitivity 20 40 60 Medium sensitivity 15 30 45 Low sensitivity 10 15 20 Minor sensitivity 5 10 15

Normal state Suspect state Attack state*

48

Appendix C MPLS RD
Abstract MPLS-VPN also known as L3VPN is a method of creating Virtual Private Networks, providing traffic isolation and differentiation, without substantial overhead. While the network provides many advantages for network administrators and customers alike few problems are discovered. Each of the MPLS-VPN customers may use the same private IP address range for communication, and the MPLS tag is changed randomly. For these reasons neither IP address nor MPLS tag can be used to identify and distinguish MPLS VPN customers and create network security policies per customer. The following paper describes Radware's DefensePro support for MPLS-VPN clients based on VRF information, specifically MPLS RD (route distinguisher) value. About the MPLS-VPN technology MPLS VPN operation In a single provider's network (see figure 14), a router that connects to a customer is called a Provider Edge (PE) router, and the customer's router it connects to is called a Customer Edge (CE) router. Each VPN is associated with one or more VPN routing/forwarding instances (VRFs). A VRF defines the VPN membership of a customer site attached to a PE router. A VRF consists of an IP routing table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included into the routing table. A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs, However, a site can only associate with one (and only one) VRF. A customer site's VRF contains all the routes available to the site from the VPNs of which it is a member. Packet forwarding information is stored in the IP routing table for each VRF. A separate set of routing tables is maintained for each VRF. This table prevents information from being forwarded outside a VPN, and also prevents packets that are outside a VPN from being forwarded to a router within the VPN. A route distinguisher (RD) is an address qualifier used only within a single internet service provider's Multi-Protocol Label Switching (MPLS) network. It is used to uniquely define MPLS VRF and to distinguish the distinct Virtual Private Network (VPN) routes of separate customers who connect to the provider. Within an MPLS network, a PE router needs to be configured to associate each route distinguisher with routes that lead to a particular CE router. The PE router may be configured to associate all routes leading to the same CE router with the same route distinguisher, or it may be configured to associate different routes with different route distinguishers, even if they lead to the same CE router.

49

Figure 14 - VPNs with a Service Provider backbone BGP Distribution of VPN Routing Information A service provider edge (PE) router learns an IP prefix from a customer edge (CE) router through a BGP session with the CE router, or through the routing information protocol (RIP) exchange with the CE router. The IP prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a member of the VPN-IPv4 address family. It serves to uniquely identify the customer address, even if the customer site is using globally non unique private IP addresses. For example, RD is used by PE router to be able to distinguish between the IP address 10.0.0.0 of one customer from the 10.0.0.0 of another customer, the network administrator must add a unique route distinguisher to each. The RD used to generate the VPN-IPv4 prefix is specified by a configuration command associated with the VRF on the PE router. The route distinguisher is an 8-byte field prefixed to the customer's Internet Protocol address (IPv4). The resulting 12-byte field is a unique "VPN-IPv4" address. The 8byte route distinguisher consists of 3 fields (from RFC 4364): Type field (2 bytes) determines the lengths of the other two fields, as well as the semantics of the administrator field. Administrator field typically the 2-byte autonomous system number of the provider. Assigned Number field assigned by the provider. BGP propagates reachable information for VPN-IPv4 prefixes among PE routers by means of the BGP multiprotocol extensions (see RFC 2283, Multiprotocol Extensions for BGP-4) which define support for address families other than IPv4. It does this in a way that ensures the routes for a given VPN are learned only by other members of that VPN, enabling members of the VPN to communicate with each other.

50

Normally the Border Gateway Protocol (BGP) used by the provider's routers only looks at the 4-byte IP address, but the BGP Multiprotocol Extensions allow BGP to view the entire 12-byte VPN-IPv4 address, and carry routes from multiple "address families". If the route distinguisher Administrator subfield and the Assigned Number subfield of a VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is considered to have exactly the same meaning as the corresponding globally unique IPv4 address. In particular, this VPN-IPv4 address and the corresponding globally unique IPv4 address will be considered comparable by BGP. In all other cases, a VPN-IPv4 address and its corresponding globally unique IPv4 address will be considered non-comparable by BGP. A given per-site forwarding table will only have one VPN-IPv4 route for any given IPv4 address prefix. When a packet's destination address is matched against a VPN-IPv4 route, only the IPv4 part is actually matched. MPLS RD mapping into MPLS Tags An MPLS RD (one or more) are associated per VPN, where each RD is mapped to two MPLS Tags: upper tag and lower tag. The actual mapping of MPLS RD differs per destination route. Lets take an example where a VPN consisting of two sites (site-1 and site-2) is assigned to an MPLS RDs of 100:1. The MPLS Tags are assigned per traffic flow. Traffic from site-1 to site-2 will be assigned with upper/lower tags 10/20, while traffic from site-2 to site-1 will be assigned with upper/lower tags 15/40. The administrator configures the MPLS RD values per PE router. The MPLS Tags are assigned dynamically by the routers per established link, and may change when a link is reconnected. The MPLS Tag information is exchanged between the PE routers using several mechanisms: MPLS lower tag information is exchanged using BGP via the multiprotocol extension. MPLS upper tag is exchanged using LDP (the MPLS Label Distribution protocol) or via RSVP.

Cisco Implementation A route distinguisher (RD) creates routing and forwarding tables and specifies the default route-distinguisher for a VPN. The RD is added to the beginning of the customer's IPv4 prefixes to change them into globally unique VPN-IPv4 prefixes. An RD is either ASN-relative, in which case it is composed of an autonomous system number and an arbitrary number, or it is IP-address-relative, in which case it is composed of an IP address and an arbitrary number. You can enter an RD in either of these formats: 16-bit AS number: your 32-bit number. For example, 101:3 32-bit IP address: your 16-bit number. For example, 192.168.122.15:1

Juniper Implementation Each routing instance must have a unique route distinguisher associated with it. The route distinguisher is used to place bounds around a VPN, so that the same IP address prefixes can be used in different VPNs without having them overlap. We recommend that you use a unique route distinguisher for each routing instance that you configure. Although you could use the same route distinguisher on all PE 51

routers for the same VPN, if you use a unique route distinguisher, you can determine the CE router from which a route originated. To configure a route distinguisher, include the route-distinguisher statement: [edit routing-instances] routing-instance-name { route-distinguisher (as-number:number | ip-address:number); } You can configure the statements at the following hierarchy levels: [edit routing-instances routing-instance-name] [edit logical-routers logical-router-name routing-instances routinginstance-name] The route distinguisher is a 6-byte value that you can specify in one of the following formats: as-number:number, where as-number is your assigned AS number (a 2byte value) and number is any 4-byte value. The AS number can be in the range from 1 through 65,535. ip-address:number, where ip-address is an IP address in your assigned prefix range (a 4-byte value) and number is any 2-byte value. The IP address can be in the range from 0 through 4,294,967,295 (232 - 1). Deployment Considerations Where is DefensePro Deployed DefensePro is installed on the link between the PE and P routers. The PE routers add the 2nd MPLS tag to the CE traffic and distributes the RD information to the remote PE routers. Configuration Consideration When creating a policy you can define it per MPLS RD. DefensePro is capable of learning the MPLS RD from the network by listening to the BGP traffic, but the user can create RD tags manually and not wait for the BGP update. When DefensePro is installed in-line, the link will be set down and then up. This will trigger the routers to send BGP and LDP update messages containing the RD values. DefensePro can therefore extract the RD information from these messages. In case DefensePro is installed out-of-path, no link will be interrupted, and the routers will not send BGP/LDP updates. In this case, it is required to manually reset BGP peers on the P and PE routers. In case DefensePro is turned off, the MPLS VRF association information is cleared, and upon each device boot DefensePro has to learn again the MPLS VRF association information. How to use the MPLS RD Once DefensePro is installed and configured, it learns the MPLS RD used in the network (automatically or manually) and the administrator can start configuring network security polices based on the MPLS RD as the customer identifier. Viewing and managing the MPLS RD table.

52

Go to APSolute OS and click on MPLS RD. The following table will be shown.

Figure 15 - Populated MPLS RD Table User can manually add new MPLS RD entries or remove them. It is also possible to clear the whole table or export it to Excel file. Note: After clearing the table and in order to populate it again a full broadcast of the MPLS RD is required. This is usually a costly operation, in network terms, and shouldn't be preformed frequently. Creating a MPLS RD based Policy. It is possible to create a Network Security policy based on MPLS RD information same as using physical ports, VLANS and IP addresses. In order to create a policy using the MPLS RD there is a need to create it and give it meaningful name. Right Click on the VLAN/MPLS RD cell and click Add. The following window will appear, click on the MPLS RD tab.

53

Figure 16 - MPLS RD Objects Table Using several MPLS RD per customer is possible by giving the same, exact name to several values.

Figure 17 - Network Security Policy with MPLS RD Once an MPLS RD is created, it can be used in the policy as a differentiator between traffic. Only traffic matching the MPLS RD values will be inspected by the policy shown above.

54

Limitations Due to the nature of VPN environment where the same address spaces are used for different customers, the support of MPLS RD feature is limited when the device is working in L4 Dest Port (Full L4 is not supported). The following features are not supported when working in L4 Dest Port mode: Anti-Scanning HTTP Mitigator SYN-Protection Server protections Bandwidth Management module

Summary MPLS-VPN networks offer the ability to reuse private address spaces between customers making the implementation easier for network operators. Radware's DefensePro is the first and only IPS that is capable of working in MPLS VPN network, allowing the administrator to create policies per customer based on MPLS RD information.

55

Appendix D - Working in Asymmetric Network

One of DefensePro's strong points is the ability to work in asymmetrical routing networks. DefensePro's ability to work in stateless mode enables it to inspect ingress or egress traffic without the need to see both traffic sides on the same port pair or device. This paper describes each protection and it's adaptation to asymmetrical networks.

Asymmetric Routing Network

In the internet it is impossible to control end-to-end routing and path traversed. Asymmetric routing occurs when the path from node n1 to node n2 is different from the path from n2 to n1 due to path cost calculations that are done at each end.

LNK ACT NO LNK G13 G14 G15 G16 G 17 G18 G19 G20

1000 100 10

G1

G3

G5

G7

G9

G11

G2

G4

G6

G8

G10

G12

APSolute Application Delivery

DefensePro

LNK ACT NO LNK G13 G14 G15 G16 G17 G18 G19 G20

1000 100 10

G1

G3

G5

G7

G9

G11

G2

G4

G6

G8

G10

G12

APSolute Application Delivery

DefensePro

Figure 18 - Asymmetric Routing

Note: The assumption is that the traffic in one direction is traversing the same path at least for the duration of the same connection.

IPS
DefensePro IPS is inspecting packet by packet and as such is suitable to work in an asymmetrical environment. As long as all the incoming or outgoing packets of the same session are seen by DefensePro it is able to detect the protocols and services and apply the correct signatures to inspect the traffic resulting in accurate protection with minimal false positive rate. All the following Intrusion preventions are available: Server based intrusions o o o o o Web Vulnerabilities Mail server intrusions FTP server intrusions SQL server intrusions DNS server intrusions

56

Worms & Viruses Trojans & Backdoors SIP

BDoS
The DefensePro behavior-based DoS protection uses adaptive, self-learning and selfadjusting technology to immediately block unknown, zero-day attacks in seconds. DefensePro Behavioral DoS has several protections that are working in asymmetrical routing networks. DefensePro is able to create a baseline based on the rate parameters and rate invariant parameters of the following protocols and TCP flags: UDP ICMP IGMP TCP SYN TCP SYN+ACK (in version 4.00) TCP FIN

For TCP RST protection please create an additional policy in Report Only mode and monitor it to prevent false positives.

57