Orchestrated Infrastructure Security - Getting Started
Note: The Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here. Introduction A typical daisy-chained security stack is difficult to manage and make changes. All devices in the chain are physically wired to each other in a serial arrangement. Each device performs SSL decryption and re-encryption when needed. All devices in the chain need to have similar performance capabilities. All devices in the chain need to be properly configured to route traffic to their neighboring devices, and likely will need to be manually configured to trust SSL certificates used by neighboring devices for decryption and re-encryption. Failure of any device in the security chain brings the entire chain down. Capacity cannot be increased simply by adding another like-device (i.e. a NGFW) to the chain. Capacity can only be increased by replacing a single device with a higher capacity device. Removing or adding a device to the chain is problematic. For one, the entire security stack will need to be unavailable while removing or adding a device. Proper routing between devices must be maintained or the whole chain will not pass traffic. Certificate trust and other factors may need to be addressed as well. High availability is also problematic. The only way to ensure high availability is to create another daisy-chain, identical to the first. This chain needs to wait in standby mode until the primary chain fails or is taken down, and then the standby chain can take over for the primary. Managing a single daisy chain security stack is not easy. Managing two for high availability is significantly more complicated and overly expensive. Some security devices are deployed differently and cannot operate together in the security stack. Those devices would need their own separate deployment from the devices in the daisy chain, further complicating the configuration. As an example, it’s not an uncommon security practice to employ network TAP devices, explicit proxies, ICAP servers as well as Layer2/3 devices. All of these devices cannot be configured to properly route traffic in a daisy chain. SSL Orchestrator solves almost all of these challenges, and enables you to have a nimble security solution capable of adapting to almost any type of threat. High Level Network Topology The network topology used for this setup is below. BIG-IP-11 and 12 are deployed in Layer 2 mode. The Advanced WAF and AFM devices will also be deployed in Layer 2 and will be physically wired to the SSL Orchestrators. This is a high availability environment where there is one Active BIG-IP and one ready on Standby. The Port Objects (511 & 512) allow traffic to flow through either BIG-IP, in case of a failure. The applications being protected are represented by the Ubuntu servers connected to the South switch. BIG-IP Network Topology A zoomed in view of the BIG-IP devices is below. This shows the physical connectivity and the specific interfaces used by SSL Orchestrator, Advanced WAF and AFM devices. Summary This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - L2 Mode Deployment
Introduction This article shows you how to deploy SSL Orchestrator in Layer 2 (L2) mode This article is divided into the following high level sections: Network Topology Requirements Best Practices Known Limitations Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Network Topology The diagram below is a representation of the actual lab network where SSL Orchestrator was deployed and tested. Before SSL Orchestrator After SSL Orchestrator All routing configuration is static routing – no dynamic routing protocols is implemented in this design. Dynamic Routing was not considered for this article series. Example Port Object/Channel and MLAG configuration from North Switch1: interface Port-Channel511 switchport trunk allowed vlan 511 switchport mode trunk mlag 511 interface Port-Channel512 switchport trunk allowed vlan 511 switchport mode trunk mlag 512 mlag configuration domain-id mlag1 heartbeat-interval 2500 local-interface Vlan4094 peer-address 172.16.0.2 peer-link Port-Channel10 reload-delay 150 Requirements BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 NGWF Version: Details are beyond the scope of this discussion – note that NGWF is configured with vWire and performs its inspection as a transparent L2 device. Adv. WAF: Details are beyond the scope of this discussion – for this implementation, the Advanced WAF module is running on a separate BIG-IP platform. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here in GitLab. Demo videos are available for both Inbound and Outbound use cases: Outbound Traffic Inspection Inbound Traffic Inspection Best Practices for SSL Orchestrator Deployment BIG-IP Recommendations The following provides salient recommendations, these and others are discussed in detail in the SSL Orchestrator Document. AutoMap AutoMap is a secure network address translation (SNAT) described in Knowledge article K7336. AutoMap should not be used where possible in BIG-IP SSL Orchestrator deployments. Please refer to K7820 for SNAT uses and best practices. With BIG-IP configurations (SSLO or other modules), whenever a large number of connections are going to require SNAT, you want to make sure that SNAT pools are used to avoid port collisions (running out of ephemeral ports to initiate the connection). Debug Logging Traffic through BIG-IP SSL Orchestrator will transit through different services as defined in the service chain. Enabling debug will generate logs as traffic traverses the different services – this can be very verbose and generate large amounts of traffic. It is recommended to leverage debug logging for troubleshooting only. Security Recommendations The following recommendations can also be found in the SSL Orchestrator Document. SSL Orchestrator and Service Proximity SSL Orchestrator is almost never first in an enterprise architecture, so other security devices (proxies, firewalls, IPSs, sandboxes, etc.) are already deployed. If you ask any network and/or security admin, 99% of the time they have no interest in moving those security devices or re-architecting anything else when SSL Orchestrator is introduced. However, remember that the traffic being sent to and from the security devices is unencrypted, so sending traffic across an existing enterprise network to some security device is also sending passwords, credit card numbers, and other protected data (HIPAA, PCI, etc.), across an uncontrolled span of network where any connected device can see it in clear text. It is therefore brutally important that customers understand this, and that they do move those security devices to networks that are behind and protected by SSL Orchestrator. In a perfect situation, no traffic should be able to reach these security devices except through SSL Orchestrator. As frightening as the possibility of a data exposure is, there are going to be customers that ignore the warnings. You should therefore do your best to convey this security best practice to customers as their trusted advisor. This is the reason for the “Auto-Manage” field in the configuration for the services. It creates non- overlapping, internal, non-routable address spaces for each service and encourages customers to protect them. If disabling this, and changing the inline service IP spaces, take care to protect these. Known Limitations It is recommended to consult with the Knowledge Article K00805840 for current known issues and workarounds. Strictness Underlying the BIG-IP SSL Orchestrator is the BIG-IP TMOS infrastructure. The BIG-IP SSL Orchestrator provides a guided configuration front-end to configure TMOS to build the services, and different policies to make the solution work as designed. If the administrator were to dive deeper in the low-level configuration of the device after building a topology, the configuration would contain BIG-IP configuration items – refer to Appendix C for sample configuration for a simple SSL Orchestrator configuration. The notion of strictness is introduced to “lock” the configured items in such a manner as to prevent the administrator to be able to modify the underlying object without using the SSL Orchestrator interface. Any attempt to modify an object that is strictly managed will result in an error message as shown below: Gossip For BIG-IP SSL Orchestrator deployed in redundant pairs, BIG-IP should be in manual/full sync mode (Device Management>>Device Group). For more information related to BIG-IP high availability (HA) configuration, refer to the user guide. The traditional synchronization mechanism is augmented with “gossip” for the SSL Orchestrator. This synchronization mechanism is independent from typical LTM config sync. For the version of BIG-IP SSL Orchestrator used for this deployment, ”gossip” config sync is two-way automatic. "gossip" uses REST API calls for the SSL Orchestrator related part of the config sync. If a change is made to one device in the pair, it is automatically propagated to the other device. This differs from the traditional BIG-IP sync behavior. SSL Orchestrator config needs to be re-deployed if a STANDALONE environment is changed to an HA environment. Also, you need to make sure VLAN configuration is the same on both the box for successful re-deployment. Summary This article should be a good starting point for planning your initial SSL Orchestrator deployment. The network topology and architecture was explained with the help of diagrams. We also went over the software requirements, best practices and known limitations. Next Steps Click Next to proceed to the next article in the series.
