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

Transcription

1 SOLUTION GUIDE Radware & CyberGuard Complete Security Solutions offering Load Balancing, High Availability and Bandwidth Management. North America Radware Inc. 575 Corporate Dr Suite 205 Mahwah, NJ Tel Document Version: 0.1 Revision Date: 7 January 2004 International Radware Ltd. 22 Raoul Wallenberg St Tel Aviv 69710, Israel Tel

2 Date 7 January 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 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. FireProof s advanced security features also enable an additional level of network security by blocking many popular network based intrusion attempts or Denial of Service attacks before they ever reach the Firewall, further optimizing the entire solution.

3 Date 7 January 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 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. 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.

4 Date 7 January 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 Where the previous example required the use of a separate FireProof device on each segment, Port Rules enables the ability to deploy a single FireProof among several segments. It is important to note that a complete security solution may utilize some FireProof s deployed with Port Rules, for instance on the internal and DMZ networks, and some FireProof s deployed without, on the external segments for example. FireProof provides an extensive level of flexibility enabling it to meet any customers security and performance needs.

5 Date 7 January 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 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 SynApps Load Balancing module intelligently distributes traffic across network devices, optimizing the utilization of site-wide resources to accelerate application performance and cut operating costs. Employing an extensive array of Load Balancing algorithms to

6 Date 7 January 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, misconfigurations, default installations and port scanning. By continuously monitoring all network traffic at Gigabit speeds, Intrusion Prevention detects and prevents attacks in real time, immediately terminating suspicious sessions to completely safeguarding enterprise operations from hacking. All suspect traffic is monitored and reported, enabling network administrators to take proactive measures against potential intruders.

7 Date 7 January 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 10/100 Fast Ethernet ports only

8 Date 7 January 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 performance, scalable solution enabling complete control over traffic while providing security at multiple levels.

9 Date 7 January 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 press enter. The FireProof will reboot and display the Startup Configuration menu. StartUp Configuration 0. Exit 1. IP address IP subnet mask Port number 1 4. Default router IP address RIP version disable 6. OSPF enable No 7. OSPF area ID 8. NMS IP address 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 on Interface 1. To exit this menu and boot the WSD, use option 0. Login Information When logging in via CLI or Web Based Management, the default username/password is radware/radware.

10 Date 7 January 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. Figure B.1 Traditional FireProof Deployment Firewall Sandwich

11 Date 7 January Configuration The following configuration information pertains to FireProof version Any menu references refer to Web Based Management (WBM). External FireProof 1. Boot FireProof and configure first IP address (public ), 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, /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: and 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 FW1-ext Active FW2-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, 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= , Firewall IP Address= , Virtual NAT Address= Both the Firewall IP and Virtual NAT address should be the same. This entry should be repeated for each firewall in the firewall table. 8. Configure required global options. From WBM, FireProof Global Configuration General. From this menu, dispatch method (i.e. load balancing algorithm) and

12 Date 7 January 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 ). 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 which will map to the Remote VIP configured on the Internal FireProof ( ). On CyberGuard #2, a Static NAT address can be configured as 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 Active Active Active 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 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 network and the internal interfaces will reside on the network.

13 Date 7 January Configure appropriate routes on each firewall. The Default Route should be specified as the interface on the External FireProof ( ). Additionally, a network route should exist for the network utilizing the interface of the Internal FireProof ( ) 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 ), 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), /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: and 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 FW1-int Active FW2-int Active 5. Configure the default route of the FireProof to be one of the firewalls in the Firewall Table, for example. From WBM, Router Routing Table. The route is required to enable the forwarding of load balanced traffic in the

14 Date 7 January 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 ). 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 ( ) was created when the External FireProof was configured. This IP should be placed in the FPHM for each firewall. Sample entries are as follows: Firewall IP Address Check Address Status Active Active Active Active Active 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 All traffic destined to the Internet should be routed through the Internal FireProof. Therefore, hosts on the internal network ( ) should have their default gateways configured to the interface of the Internal FireProof ( ).

15 Date 7 January 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. Figure C.1 FireProof with Port Rules

16 Date 7 January Configuration The following configuration information pertains to FireProof version Any menu references refer to Web Based Management (WBM). FireProof 1. Boot FireProof and configure first IP address (public ) 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, /24 on Interface 1 also. From WBM, Router IP Router Interface Parameters. Add the third and fourth IP addresses, /24 and /24 on Interface 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: and 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:

17 Date 7 January Firewall Address Firewall Name Operational Status FW1-ext Active FW2-ext Active FW1-int Active FW2-int Active 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, 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= , Firewall IP Address= , Virtual NAT Address= 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: Create Static NAT address on the external interface of all firewalls. This address will map to the internal interface address, making it possible to route a health check packet from the FireProof interface on the external network to the internal interface of each firewall. For example, create the address on CyberGuard #1 which will map to that firewalls internal interface ( ). On CyberGuard #2, a Static NAT address can be configured as which also maps to the internal interface address ( ). Again, these

18 Date 7 January 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: Firewall IP Address Check Address Status Active Active Active Active Active Active Active 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 network and the internal interfaces will reside on the network. 2. Configure appropriate routes on each firewall. The Default Route should be specified as the interface on the external interface of the FireProof ( ). Additionally, a network route should exist for the network utilizing the internal interface of the FireProof ( ) 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,

19 Date 7 January 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 All traffic destined to the Internet should be routed through the Internal FireProof. Therefore, hosts on the internal network ( ) should have their default gateways configured to the interface of the Internal FireProof ( ).