SOLUTION GUIDE. Radware & CyberGuard Complete Security Solutions offering Load Balancing, High Availability and Bandwidth Management.

(1)

North America

Radware Inc. 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 8600

www.radware.com

SOLUTION GUIDE

Radware & CyberGuard

Complete Security Solutions offering Load Balancing,

High Availability and Bandwidth Management.

Document Version: 0.1

(2)

Solution Guide - Radware / CyberGuard

Date 7 January 2004

- 2 -

Introduction

FireProof activates all enterprise security tools while accelerating defense performance to gigabit speeds, to completely safeguard mission critical resources and make sure your site is really secure. FireProof guarantees the full availability, redundancy and highest operation of FireWalls, Virtual Private Networks and Intrusion Detection Tools, while extending real-time Intrusion Prevention and DoS Protection to prevent malicious signature attacks and debilitating network service denials.

Combining Multi-gigabit Speed Security Application Switching with SynApps application aware services including Health Monitoring, Load Balancing, Bandwidth Management, Intrusion Prevention and DoS Protection, FireProof optimizes the operation of any

combined security architecture, for fault tolerant, high throughput and scaleable defense.

Security and Functionality

CyberGuard Corporation (NASDAQ: CGFW) is the leading technology provider of network security solutions that provides advanced intrusion prevention solutions that protect the critical information assets of Global 2000 companies and governments worldwide. CyberGuard offers a broad line of scalable high performance firewall/VPN appliances, sophisticated security processors and accelerator products for the SSL and IPsec markets, and industry-leading embedded Linux and Linux security solutions. CyberGuard firewall/VPN appliances have been designed and developed with the utmost attention to detail, functionality, user friendliness and a corporate passion for providing the most secure firewall/VPN solutions available. CyberGuard’s firewall technology has earned all the industry's major awards and certifications including the world's most rigorous IT security evaluation – the internationally accepted Common Criteria Evaluation Assurance Level 4+. For more information, please visit

www.cyberguard.com.

Solution Highlights:

• Application gateway proxy firewall security

• Robust scalability and performance options with the industries leading Application Switch technology allows firewall farms to grow to 100 firewalls. • Comprehensive firewall failure detection

• Solution provides optimum mix of security features and traffic management control

• FireProof provides a complete suite of Bandwidth Management/Quality of Service features that enable additional control.

(3)

Solution Guide - Radware / CyberGuard

-

3 -

Solutions

The FireProof offers several methods of implementation designed to meet the needs of newly installed networks or existing networks looking to achieve the benefits of traffic management.

Traditional Deployment

Figure 1 presents a simple solution commonly referred to as a “Firewall Sandwich.” The FireProof is deployed on each segment of the CyberGuard firewall farm. The FireProof provides both outbound and inbound load balancing while ensuring complete and immediate failover for firewalls incapable of forwarding traffic.

Figure 1 – Traditional FireProof Deployment

(4)

Solution Guide - Radware / CyberGuard

-

4 -

FireProof with Port Rules

Utilizing the Port Rules feature, the FireProof can be logically segmented into multiple “virtual” load balancers enabling customers to implement a more cost effective load balancing solution. In this example, a FireProof is deployed using a single interface on each segment of the firewalls.

Figure 2 – FireProof Deployment with Port Rules

(5)

Solution Guide - Radware / CyberGuard

-

5 -

Solution Redundancy

FireProof solutions are designed to optimize traffic forwarding and reduce single points of failure within a security environment. Because Radware’s main goal is the 100% availability of mission critical security devices, the FireProof also supports redundant deployment. A backup FireProof can be deployed in the network to provide immediate and seamless failover for the primary FireProof. A backup unit is always recommended as it further alleviates the FireProof as a single point of failure, and makes maintenance chores, such as software and configuration changes, easier to manage as no downtime will be required.

SynApps

Radware’s SynApps architecture provides a comprehensive set of application aware services to guarantee the full operation of all mission critical applications throughout the network.

Advanced Health Monitoring

FireProof ensures the full availability and fault tolerance of firewalls, load balancing and dynamically distributing traffic among firewalls to guarantee continuous and uncompromised access control. Optimizing all clients and loads across firewalls, FireProof offers full scalability and effective service growth across CyberGuard Premier Firewalls and VPNs.

Advanced Health monitoring module continuously checks the health of all network resources detecting failures in real time and automatically redirects traffic to the highest performing resources to guarantee full application availability and fault tolerant operations.

Advance Health Monitoring and traffic redirection enables comprehensive monitoring of resources - from the testing of discrete physical devices including servers, firewalls, VPN gateways, IDS, anti-virus gateways, cache and routers, through the sampling of multiple devices, to content checks across network layers 4-7 - checking resource health across the entire transaction path.

The Health Monitoring module extends predefined health checks including: HTTP, HTTPS, FTP, RADIUS, RTSP, while enabling the configuration of customized checks by device, transaction path and content to monitor the health.

Load Balancing

(6)

Solution Guide - Radware / CyberGuard

-

6 -

dispatch traffic including cyclic distribution, least users, least packets and least bytes, SynApps Load Balancing enables maximum utilization of IT infrastructure capacities across farms, local and global sites. By attaining high resource utilization, Load Balancing enables seamless service scaling, while reducing additional resource deployment requirements for economical service growth.

Bandwidth Management

Bandwidth Management module extends comprehensive control over bandwidth resource allocation, to prioritize all network traffic and guarantee service levels for mission critical applications. Bandwidth management policies enable the classification of traffic by user, applications, and service pricing models for the configuration and full enforcement of premium services, and differentiating application performance by business requirements, while regulating site-wide bandwidth consumption and costs.

Application Security

SynApps Intrusion Prevention module automatically secures applications network resources from over 1000 malicious attack signatures and viruses including as Code Red, Nimda, Buffer Over Flow (BOF), exploits and vulnerabilities, Trojans, mis-configurations, default installations and port scanning.

(7)

Solution Guide - Radware / CyberGuard

-

7 -

Application Switch

Radware has pioneered the traffic management market with the first Application Switch. Radware’s industry leading technology platform is available in three levels to meet the needs of any company’s performance and infrastructure requirements.

Application Switch III

• 1 – 10 Gigabit Ethernet port (Gbic required) • 7 – 1 Gigabit Ethernet port (SFP - Gbics required) • 16 – 10/100 Fast Ethernet ports

• Compact 1U Size

Application Switch II

• 5 – 1 Gigabit Ethernet port (Gbics required) • 16 – 10/100 Fast Ethernet ports

• Compact 1U Size or

• 7 – 1 Gigabit Ethernet ports only (Gbics required)

Application Switch I

• 2 – 1 Gigabit Ethernet ports • 8 – 10/100 Fast Ethernet ports • Compact 1U Size

or

• 2 – 1 Gigabit Ethernet ports only or

(8)

Solution Guide - Radware / CyberGuard

-

8 -

FireProof Management

The following management methods are available. • SNMP – using Radware Configware Insite GUI • Web Based Management (HTTP)

• Secure Web Based Management (HTTPS) • Telnet

• SSH • ASCII

Configware Insite

Configware Insite provides a visual environment to simply add, link and configure your enterprise wide defense architecture

Conclusion

Radware and CyberGuard provide a single, comprehensive solution that addresses the needs of security conscious customers. Radware and CyberGuard offer a high

(9)

Solution Guide - Radware / CyberGuard

-

9 -

Appendix A – General FireProof Installation Information

ASCII Terminal Setup

For ASCII terminal communication, the FireProof utilizes a “straight” DB-9 connection. The default terminal settings are: 19,200, 8 bits, No Parity, 1 stop bits, and no Flow Control

Factory Defaults

Out of the box, the FireProof should have no configuration. If this is the case, the Startup Configuration menu, depicted below, will be presented upon boot-up. If however, the FireProof does have an existing configuration and you wish to start from scratch, simply reboot the unit and interrupt the boot process when prompted. Enter ‘q’ press enter, then enter ‘@’ press enter. The FireProof will reboot and display the Startup Configuration menu.

StartUp Configuration 0. Exit

1. IP address 10.1.1.1 2. IP subnet mask 255.255.255.0 3. Port number 1

4. Default router IP address 10.1.1.254 5. RIP version disable 6. OSPF enable No 7. OSPF area ID

8. NMS IP address 0.0.0.0 9. Community name public 10. Configuration file name

11. Username radware 12. Password ******* 13. Web access No 14. Secure web access Yes 15. Telnet access No 16. SSH access Yes

From the Startup Configuration, the first IP Address, Subnet Mask, Port/Interface, Default Route, and optional management methods are selected. Within this example, the “public” IP address has been configured as 10.1.1.1 on Interface 1. To exit this menu and boot the WSD, use option ‘0’.

Login Information

(10)

Solution Guide - Radware / CyberGuard

- 10 -

Appendix B – FireProof Solution Configuration

In this example, the FireProof is deployed using a single interface residing on two IP networks. This is typically referred to as a “one-arm” or “lollipop” configuration. The internal and external interfaces of the CyberGuard firewalls are configured on intermediary IP networks separate from the actual LAN and Public networks. This configuration provides the benefit of total segregation from the internal and public

networks while also simplifying routing. The configuration presented is only an example. Deploying the FireProof with two interfaces or one interface on the existing networks is acceptable. Additional installation notes are found in the Radware FireProof User Guide.

(11)

Solution Guide - Radware / CyberGuard

-

1 1 -

Configuration

The following configuration information pertains to FireProof version 2.61.06. Any menu references refer to Web Based Management (WBM).

External FireProof

1. Boot FireProof and configure first IP address (public – 10.1.1.1), subnet mask, default route, and management methods. It is recommended that Web Based Management be enabled, as that method will be used heavily in this document. 2. Once rebooted and connected to the network, connect using a standard web

browser.

3. Add the second IP address, 172.16.2.1/24 on Interface 1. From WBM, Router Æ IP Router Æ Interface Parameters.

4. If not configured in step 1, configure the default gateway of the FireProof to be the next hope ISP router. From WBM, Router Æ Routing Table.

5. Configure CyberGuard firewalls in Firewall Table. From WBM, FireProof Æ Firewalls Æ Firewall table. The IP addresses should be the external interfaces of each of the firewalls: 172.16.2.10 and 172.16.2.20. A name is also required for each firewall before the setting will be accepted by the FireProof. A sample Firewall Table will look as follows:

Firewall Address Firewall Name Operational Status

172.16.2.10 FW1-ext Active

6. Configure a Virtual IP (VIP) address to be used by the FireProof to aggregate outbound NAT addresses from each firewall while also enabling inbound connections (i.e. VPN) to be load balanced across the firewalls. From WBM, FireProof Æ Virtual IP Æ Virtual IP Table. Configure an IP address on the public network. In this example, 10.1.1.2 can be used. Please note, this IP address must not be in use by any other device on the network.

7. Map firewall IP addresses to the VIP created in step 6. From WBM, FireProof Æ Mapped IP Table. Typically the CyberGuard firewalls use the external IP

address for outbound NAT. It is necessary then to define this address in the Mapped IP Table. The entry should read: VIP Address=10.1.1.2, Firewall IP Address=172.16.2.10, Virtual NAT Address=172.16.2.10. Both the Firewall IP and Virtual NAT address should be the same. This entry should be repeated for each firewall in the firewall table.

(12)

Solution Guide - Radware / CyberGuard

- 1 2 -

client aging time can be modified. It is important that “Translate Outbound Traffic to Virtual Address” be enabled since NAT will be utilized in this configuration. 9. Configure Remote Virtual IP for health checking. From WBM, FireProof Æ

Remote Virtual IP Table. Configure an IP on the external network of the firewalls (i.e. 172.16.2.100). This IP will be used by the Internal FireProof to verify proper connectivity through each of the firewalls.

10. Configure Full Path Health Monitoring (FPHM). From WBM, FireProof Æ

Firewalls Æ Full Path Health Monitor Table. By default, the FireProof is checking the health of the configured firewall address defined in the Firewall Table. To ensure that each firewall is completely operational, Full Path Health Monitoring is configured by specifying additional IP addresses to ping and verify connectivity. Because NAT is enabled on the CyberGuard firewalls, health checking traffic cannot be directly routed to internal interfaces or devices behind each firewall. Instead, additional Static NAT addresses will have to be configured on the firewalls to allow inbound health checking traffic through each firewall. For instance, a Static NAT address will be configured on CyberGuard #1 as 172.16.2.50 which will map to the Remote VIP configured on the Internal FireProof (172.16.1.100). On CyberGuard #2, a Static NAT address can be configured as 172.16.2.51 which also maps to the Remote VIP configured on the Internal FireProof.

Next, the FPHM table will be updated on the External FireProof as follows:

Firewall IP Address Check Address Status

172.16.2.10 172.16.2.10 Active

172.16.2.10 172.16.2.50 Active

172.16.2.20 172.16.2.20 Active

172.16.2.20 172.16.2.51 Active

Notice that each firewall has a check address for the external interfaces as well as a check address for the Static NAT address configured on each firewall which maps to the Remote VIP on the Internal FireProof. If any check fails for either firewall, the firewall will be placed in “NonInService” mode, meaning no traffic will be forwarded to it until it resumes successful health checking. This ensures that the FireProof will only send traffic through firewalls that can successfully forward traffic.

CyberGuard Firewalls

(13)

Solution Guide - Radware / CyberGuard

- 1 3 -

2. Configure appropriate routes on each firewall. The Default Route should be specified as the interface on the External FireProof (172.16.2.1). Additionally, a network route should exist for the 192.168.1.0 network utilizing the interface of the Internal FireProof (172.16.1.1) as the next hop route to this network. These routes will ensure the proper flow of traffic through the solution.

3. Configure required security policies.

4. Configure NAT for outbound traffic. As mentioned in step 7 of the preceding section, outbound NAT is typically performed using the firewalls external IP address. If this will not be the case, and a separate NAT address is used, simply change the “Virtual NAT Address” from step 8 to the new address configured for NAT on each firewall. Remember, since each firewall is independently managed, each must use a different IP address for NAT, even if the security policies are identical.

5. Configure Static NAT addresses for Full Path Health Monitoring as described in step 10 of the External FireProof section. There should be at least one address per firewall which maps to the Remote VIP address configured on the Internal FireProof (see step 6 in the following section).

Internal FireProof

1. Boot FireProof and configure first IP address (ex. 172.16.1.1), subnet mask, and management methods. It is recommended that Web Based Management be enabled, as that method will be used heavily in this document.

2. Once rebooted and connected to the network, connect using a standard web browser.

3. Add the second IP address (LAN network), 192.168.1.0/24 on Interface 1. From WBM, Router Æ IP Router Æ Interface Parameters.

4. Configure CyberGuard firewalls in Firewall Table. From WBM, FireProof Æ Firewalls Æ Firewall table. The IP addresses should be the internal interfaces of each of the firewalls: 172.16.1.10 and 172.16.1.20. A name is also required for each firewall before the setting will be accepted by the FireProof. A sample Firewall Table will look as follows:

172.16.1.10 FW1-int Active

(14)

Solution Guide - Radware / CyberGuard

- 1 4 -

correct direction. Only one firewall is defined for the route, however, even if that firewall fails, routing will still work properly.

6. Configure Remote Virtual IP for health checking. From WBM, FireProof Æ Remote Virtual IP Table. Configure an IP on the internal network of the firewalls (i.e. 172.16.1.100). This IP will be used by the External FireProof to verify proper connectivity through each of the firewalls.

7. Configure Full Path Health Monitoring (FPHM). From WBM, FireProof Æ

Firewalls Æ Full Path Health Monitor Table. By default, the FireProof is checking the health of the configured firewall address defined in the Firewall Table. To ensure that each firewall is completely operational, Full Path Health Monitoring is configured by specifying additional IP addresses to ping and verify connectivity. For instance, the external IP address of each firewall should be configured, the DMZ interface address(es) if applicable. Also, a Remote Virtual IP

(172.16.2.100) was created when the External FireProof was configured. This IP should be placed in the FPHM for each firewall. Sample entries are as follows:

172.16.1.10 172.16.1.10 Active 172.16.1.10 172.16.2.10 Active 172.16.1.10 172.16.2.100 Active 172.16.1.20 172.16.1.20 Active 172.16.1.20 172.16.2.20 Active 172.16.1.20 172.16.2.100 Active

Notice that each firewall has a check address for the internal and external interfaces as well as a check address for the Remote VIP on the External FireProof.

DMZ Network

Many security solutions include one or more additional firewall segments, often referred to as Demilitarized Zones (DMZ). For each additional segment, the above solution will require a FireProof be deployed. The same configuration concepts should be applied. If deploying separate FireProof devices on each segment is not possible, using the Port Rules feature of the FireProof may be a more cost-effective means of deployment. Appendix C covers this implementation in detail.

LAN Users

(15)

Solution Guide - Radware / CyberGuard

- 1 5 -

Appendix C – FireProof with Port Rules Solution Configuration

Utilizing the Port Rules feature, the FireProof can be logically segmented into multiple “virtual” load balancers enabling customers to implement a more cost effective load balancing solution. In this example, a FireProof is deployed using a single interface on each segment of the firewalls.

The configuration outlined in this example is similar to setup in Appendix B, except that port rules will be configured. Many of the configuration steps previously outlined apply directly to this configuration. More importantly, implementing Port Rules is completely independent of the firewalls being load balanced, so no additional configuration is required. While Port Rules is discussed utilizing only one interface per firewall segment, it is possible to use two. For further information and any additional installation notes, please refer to the Radware FireProof User Guide.

(16)

Solution Guide - Radware / CyberGuard

- 1 6 -

Configuration

The following configuration information pertains to FireProof version 2.61.06. Any menu references refer to Web Based Management (WBM).

FireProof

1. Boot FireProof and configure first IP address (public – 10.1.1.1) and subnet mask on Interface 1. Also configure the default route, and management methods. It is recommended that Web Based Management be enabled, as that method will be used heavily in this document.

2. Once rebooted and connected to the network, connect using a standard web browser.

3. Add the second IP address, 172.16.2.1/24 on Interface 1 also. From WBM, Router Æ IP Router Æ Interface Parameters. Add the third and fourth IP addresses, 172.16.1.1/24 and 192.168.1.1/24 on Interface 2.

4. If not configured in step 1, configure the default gateway of the FireProof to be the next hope ISP router. From WBM, Router Æ Routing Table.

5. Configure Port Rules. This step must be completed from the ASCII terminal CLI. For this example, the following command should be used once logged in:

FireProof#fp port-rules set 1 1 rules set

FireProof#fp port-rules set 2 2 rules set

These port rules dictate that traffic entering Interface 1 can only be forwarded via a firewall on Interface 1, and traffic entering Interface 2 can only be forwarded via a firewall on Interface 2. The Port Rules feature enables the ability to utilize the FireProof on multiple firewall segments while alleviating the possibility of traffic routing directly between ports through the FireProof. All traffic must traverse the firewalls.

6. Configure CyberGuard firewalls in Firewall Table. From WBM, FireProof Æ Firewalls Æ Firewall table. Since the FireProof will be configured to perform the operations of two separate FireProof devices, the Firewall table will now include 4 entries instead of only two. The IP addresses should be the external interfaces of each of the firewalls: 172.16.2.10 and 172.16.2.20. A name is also required for each firewall before the setting will be accepted by the FireProof.

(17)

Solution Guide - Radware / CyberGuard

- 1 7 -

7. Configure a Virtual IP (VIP) address to be used by the FireProof to aggregate outbound NAT addresses from each firewall while also enabling inbound connections (i.e. VPN) to be load balanced across the firewalls. From WBM, FireProof Æ Virtual IP Æ Virtual IP Table. Configure an IP address on the public network. In this example, 10.1.1.2 can be used. Please note, this IP address must not be in use by any other device on the network.

8. Map firewall IP addresses to the VIP created in step 7. From WBM, FireProof Æ Mapped IP Table. Typically the CyberGuard firewalls use the external IP

address for outbound NAT. It is necessary then to define this address in the Mapped IP Table. The entry should read: VIP Address=10.1.1.2, Firewall IP Address=172.16.2.10, Virtual NAT Address=172.16.2.10. Both the Firewall IP and Virtual NAT address should be the same. This entry should be repeated for each firewall in the firewall table.

9. Configure required global options. From WBM, FireProof Æ Global Configuration Æ General. From this menu, dispatch method (i.e. load balancing algorithm) and client aging time can be modified. It is important that “Translate Outbound Traffic to Virtual Address” be enabled since NAT will be utilized in this configuration. 10. Configure Full Path Health Monitoring (FPHM). From WBM, FireProof Æ

Firewalls Æ Full Path Health Monitor Table. By default, the FireProof is checking the health of the configured firewall address defined in the Firewall Table. To ensure that each firewall is completely operational, Full Path Health Monitoring is configured by specifying additional IP addresses to ping and verify connectivity. Because NAT is enabled on the CyberGuard firewalls, health checking traffic cannot be directly routed to internal interfaces or devices behind each firewall. Instead, additional Static NAT addresses will have to be configured on the firewalls to allow inbound health checking traffic through each firewall. Also, because Port Rules is in use, the Remote VIP feature of the FireProof cannot be used either. To address full path health monitoring, the following steps should be followed:

(18)

Solution Guide - Radware / CyberGuard

- 1 8 -

addresses enable the ability of the external interface of the FireProof to perform health checks “through” each of the firewalls to verify connectivity.

Since traffic routes correctly from the internal networks to the external networks, no additional Static NAT addresses are required on the firewalls for health checking purposes.

Next, the FPHM table will be updated on the External FireProof as follows:

172.16.1.10 172.16.1.10 Active 172.16.1.10 172.16.2.10 Active 172.16.1.20 172.16.1.20 Active 172.16.1.20 172.16.2.20 Active 172.16.2.10 172.16.2.10 Active 172.16.2.10 172.16.2.50 Active 172.16.2.20 172.16.2.20 Active 172.16.2.20 172.16.2.51 Active

Notice that each firewall has a check address for the external interfaces as well as a check address for the Static NAT address configured on each firewall which maps to the respective internal interface. If any check fails for either firewall, the firewall will be placed in “NonInService” mode, meaning no traffic will be

forwarded to it until it resumes successful health checking. This ensures that the FireProof will only send traffic through firewalls that can successfully forward traffic.

CyberGuard Firewalls

1. Configure each firewall with the correct external and internal addresses. Using Figure A.1 as a guide, the external interfaces will reside on the 172.16.2.0 network and the internal interfaces will reside on the 172.16.1.0 network. 2. Configure appropriate routes on each firewall. The Default Route should be

specified as the interface on the external interface of the FireProof (172.16.2.1). Additionally, a network route should exist for the 192.168.1.0 network utilizing the internal interface of the FireProof (172.16.1.1) as the next hop route to this network. These routes will ensure the proper flow of traffic through the solution. 3. Configure required security policies.

(19)

Solution Guide - Radware / CyberGuard

- 1 9 -

each must use a different IP address for NAT, even if the security policies are identical.

5. Configure Static NAT addresses for Full Path Health Monitoring as described in step 10 of the FireProof section. There should be at least one address per firewall which maps to the each firewalls respective internal interface address.

DMZ Network

Many security solutions include one or more additional firewall segments, often referred to as Demilitarized Zones (DMZ). For each additional segment, the above solution will require at lease one additional port from the FireProof be deployed. The same configuration concepts should be applied.

LAN Users