Orchestrated Infrastructure Security - Protocol Inspection with AFM
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction 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. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring Protocol Inspection (IPS) with AFM deployed as a Layer 2 solution. It covers the configuration of Protocol Inspection on an F5 BIG-IP running version 16.0.0. Configuration of BIG-IP deployed as AFM can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Protocol Inspection (IPS) with AFM Network Configuration Create an AFM Protocol Inspection Policy Attach Virtual Servers to an AFM Protocol Inspection Policy Protocol Inspection (IPS) with AFM: Network Configuration The BIG-IP will be deployed with VLAN Groups.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. From the F5 Configuration Utility go to Network > VLANs.Click Create on the right. Give it a name, ingress1 in this example.Set the Interface to 5.0.Set Tagging to Untagged then click Add.Interface 5.0 (untagged) should be visible like in the image below.Click Repeat at the bottom to create another VLAN. Note: In this example interface 5.0 will receive decrypted traffic from sslo1. Give it a name, egress1 in this example.Set the Interface to 6.0.Set Tagging to Untagged then click Add.Interface 6.0 (untagged) should be visible like in the image below.Click Finished when done. Note: In this example interface 6.0 will receive decrypted traffic from sslo1. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2.These VLANs should be named in a way that you can differentiate them from the others.Example: ingress2 and egress2 It should look something like this when done: Note: In this example Interface 3.0 and 4.0 are physically connected to sslo2. Click VLAN Groups then Create on the right. Give it a name, vlg1 in this example.Move ingress1 and egress1 from Available to Members.Set the Transparency Mode to Transparent.Check the box to Bridge All Traffic then click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2.This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2.It should look like the image below: For full Layer 2 transparency the following CLI option needs to be enabled: (tmos)# modify sys db connection.vgl2transparent value enable Create an AFM Protocol Inspection Policy You can skip this step if you already have an AFM Protocol Inspection policy created and attached to one or more virtual servers.If not, we’ll cover it briefly.In this example we configured Protocol Inspection with Signatures and Compliance enabled. From Security select Protocol Security > Inspection Profiles > Add > New. Give it a name, IPS in this example.For Services, select the Protocol(s) you want to inspect, HTTP in this example. Optionally check the box to enable automatic updates and click Commit Changes to System. Attach Virtual Servers to an AFM Protocol Inspection Policy Attach the Protocol Inspection Profile to the Virtual Server(s) you wish to protect.From Local Traffic select Virtual Servers.Click the name of the Virtual Server you want to apply the profile to, 10.4.11.52 in this example. Click Security > Policies. Set the Protocol Inspection Profile to Enabled, then select the Profile created previously, IPS in this example.Click Update when done. Repeat this process to attach the IPS Profile to the remaining Virtual Servers. Summary In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups.We also covered how to create an AFM Protocol Inspection policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.
Defending against the Low-Orbit-Ion-Cannon (LOIC)
It’s been a busy week for the security analysts at F5. The SOPA bill has been getting its technical teeth pulled out by the likes of Dan Kaminsky during congressional hearings but passions around the social implications of the bill are running high. On Wednesday, January 18 th , federal agencies from the US and New Zealand moved in on media-distribution site MegaUpload.com, citing unauthorized media distribution as their charge. This was interpreted as the modern-day sinking of the USS Merrimack in this skirmish between SOPA-backers and their opponents. The hactivist group Anonymous, always ready for fight, have rallied around the MegaUpload.com seizures and launched distributed denial-of-service (DDoS) attacks against the United States Department of Justice (www.justice.gov) and Warner Brother’s Universal Music group (www.universalmusic.com). Both sites were down on Wednesday and Thursday. In an insightful tweet, cryptographer Matt Blaze (author of my pseudo random number generator), pointed out the irony of the situation: For the attack distribution, members of Anonymous modified the JavaScript version of their tool, dubbed the Low-Orbit-Ion-Cannon (LOIC), so that not only would it attack the Justice Department, it would do so if a user simply browsed to a page containing the JavaScript itself . This particular version of the LOIC only performs HTTP floods (unlike the Windows client which also does SYN floods and UDP floods). As you can see from this JavaScript version of the LOIC, there is a message that the individual attacker can send in as part of the payload of their attack: in this case, the default message is “Somos legión!” (“We are legion!”). The message is appended to the URI as “msg=Somos%20legión!"” Security vendors can customized their defense solutions to watch for this string and block those connections (or even black-list the originating IPs if they so choose – the LOIC has never bothered to cloak its users). Scanning a URI for specific strings is something that is particularly easy to do with F5’s iRules. With just a few minutes spent on the DevCentral site’s tutorial section, you can create a simple iRule that looks for the default message and then drops the associated connection. However, since Anonymous (or some other group or subgroup) may change the message in the future, the iRule can be enhanced to reference a string class to which one can add more strings should the message change. In the iRule below, we’ve added the original LOIC message that was used during the Wikileaks attacks of 2010, “U dun goofed.” First, create a string class and add additional payload strings as you see it (replaces spaces with %20). ltm data-group anonmsgs { records { Somos%20legi { } U%20dun%20goofed { } } type string } Then create this iRule that references the string class. ltm rule loic_defense_class { when HTTP_REQUEST { if { [class match [HTTP::uri] contains anonmsgs] } { log local0. "2012 attack from [IP::client_addr]:[TCP::client_port]" drop } } } While this particular iRule is written and tested specifically against the JavaScript version of the LOIC, the technique is applicable against any attack that includes a static payload. If your site is being attacked by any such tool using a recognizable payload simply deploy this iRule or a similar one on the BIG-IPs in front of your servers. If you are the victim of a more sophisticated DDoS campaign, perhaps one using synfloods, connfloods and UDP floods there is an existing DevCentral article that details how to tune your BIG-IP for the best defense. The Windows version of LOIC, for example, launches synfloods and UDP floods in addition to its HTTP floods. Happily, the SynCheck feature will kick in automatically on the BIG-IP, but temporarily blocking UDP at the virtual level is something that may require manual configuration if UDP is already being allowed by the application (an atypical configuration for most enterprise and data center applications). Debate around SOPA, PIPA and the new OPEN bill is still ongoing. Though some view the current controversy as a digital media vs. internet freedom, a colleague of mine suggested a more nuanced analysis: “It’s not about internet freedom vs. media piracy, it’s about the shifting terrain of intellectual property rights, and the business models of the major industries involved being put at risk by changing consumer consumption patterns. “F5 Firewall Like No Other - Ruling the Application
“Vive la différence!” I’ve been here in Europe at our Agility Conference in Monte Carlo (the theme: GO BIG) talking with customers and partners about what makes the F5 firewall different. F5’s European Conference at Monte Carlo Bay, Monaco Old School Excel As I made my presentation to a packed room of customers, I noticed that one story really got them nudging each other. We had an early customer of the Advanced Firewall Manager (AFM) module. This customer used to organize their firewall rules in an old-school way – with an Excel spreadsheet. The spreadsheet was 300 pages long! This is how that happens: Imagine a new firewall operator. A bizdev team builds a new application and asks him to open a hole in the firewall for it. He checks, and sees that there is already a working rule for an existing marketing application, so he doesn’t create a new one. Six months later, the bizdev application is retired, and he is asked to remove the firewall rule. By now he has forgotten that he didn’t create a rule for this application and he removes the one that is there. This stops traffic to the original marketing application as well. When the marketing team realizes that they have stopped receiving traffic, they come and yet at him. He quickly learns that it is “safe” to create a firewall rule but “unsafe” to remove one. This is the opposite of good security posture but it is a scenario that many, many, many organizations face today. This explains why so many in the audience were nodding and nudging each other. Ruling the Application The reason that F5’s firewall is different is because we build the application firewall rule into the application itself. It is part of the definition of the application, right there next to the http options, the pool definition and the tcp profile parameters. ltm virtual bizdev1 { ip-protocol tcp pool bizdev_pool profiles { http tcp } fw-rules { reject1020 { action reject log yes source { addresses { 10.128.20.0/24 } } } allow_http { action accept destination { ports { http } } ip-protocol tcp } } } When the application is retired, the associated firewall rules are automatically retired with it. This has three benefits. No accretion of stale rules. While the initial management overhead may be the same for defining the network, over time the active set of firewall rules will remain identical to the active set of applications. Performance. This automatic pruning process will have performance benefits because, as firewall operators should know, the smaller the rule set, the faster the firewall. Application Mobility. As applications moves between datacenters and/or clouds, the firewall rules move with them. This makes application migration easier and less error prone. Changing the Firewall World That’s just one way that F5 is changing the firewall world. There are other benefits associated with this “application-centric firewall policy management." If you want to see them all in one place, check out the white paper: “Replacing Abstract Zones with Real Application Security Policy.”F5 Firewall Like No Other - Bringing Proxy Back
Who doesn’t love a Justin Timberlake reference when talking about security technology? The guy helped bring back the Fedora, which I am pleasantly delighted to see on the heads of hipsters and kids all over the place. In this third and final blog entry on what makes the F5 firewall different from all the others, let’s think about what F5 is bringing back. Starting with the original Firewall Toolkit in the 90’s, the full proxy has been the best, most-flexible firewall solution. By using one connection to the client and a completely separate connection with the server, a full proxy can validate the inbound data before establishing and consuming server resources. For example, a full proxy is much more resilient to a TCP replay attack than a typical FPGA-based firewall. The firewall industry went away from full proxy architecture for two reasons: There were too many protocols to support. Back then it wasn’t just Internet Protocol, it was SNA and IPX, too, and a dozen other protocols we don’t even remember. Each time any of the dozen changed, it required the proxy to change. It was too difficult to maintain all the different proxies. With the much slower CPUs of the 90s, performance became an issue as the Internet exploded and full proxy firewalls were not able to keep up. Eventually firewall vendors had to switch to FPGAs which were not smart enough to be full proxy but could process individual packets faster. F5’s Advanced Firewall Manager (AFM) module is bringing full proxy back as the right security solution. This is possible now for two reasons. 1. The network protocol space has converged around TCP, DNS, SIP, HTTP and SSL. These are also the protocols that F5 specializes in. Everything is converging our way and our customers and analysts know it. 2. F5 has spent over ten years building the world’s fastest full proxy traffic management microkernel for these four protocols. It is multi-processor capable and hardware-assisted. We have millions and millions of lines of custom code and custom hardware devoted specifically to the full proxy for just these popular protocols. All that development is a significant barrier to entry for anyone wanting to do what we do. Even if others come around to our way of thinking, it will take some time before they can start to compete. What? You say you want some proof about the virtues of the full proxy solution for firewalling? Here is a short list of threat vectors that are mitigated just by the virtue of a full proxy firewall: Layer Threat Mitigated? 4 TCP Replay Yes 4 SYN+FIN Floods Yes 4 SYN Floods Yes 5 SSL Replay Yes 5 SSL Empty flood Yes 7 Slowloris Yes 7 HTTP Floods Yes That’s just off the top of our heads. Hopefully you get the picture. If your firewall isn’t full proxy, is it blocking modern threats? Or is it relying on another full proxy device (like an F5 load – balancer) to pick up the slack? The full proxy is back. The fedora is back, too. Interesting times we live in. Connect with David: Connect with F5: Related blogs & articles: F5 Firewall Like No Other – Application-Centric Logging F5 Firewall Like No Other – Ruling the Application Whitepaper: Replacing Abstract Zones with Real Application Security Policy Whitepaper: The New Data Center Firewall ParadigmThe BIG-IP Application Security Manager Part 1: What is the ASM?
tl;dr - BIG-IP Application Security Manager (ASM) is a layer 7 web application firewall (WAF) available on F5's BIG-IP platforms. Introduction This article series was written a while back, but we are re-introducing it as a part of our Security Month on DevCentral. I hope you enjoy all the features of this very powerful module on the BIG-IP! This is the first of a 10-part series on the BIG-IP ASM. This module is a very powerful and effective tool for defending your applications and your peace of mind, but what is it really? And, how do you configure it correctly and efficiently? How can you take advantage of all the features it has to offer? Well, the purpose of this article series is to answer these fundamental questions. So, join me as we dive into this really cool technology called the BIG-IP ASM! The Basics The BIG-IP ASM is a Layer 7 ICSA-certified Web Application Firewall (WAF) that provides application security in traditional, virtual, and private cloud environments. It is built on TMOS...the universal product platform shared by all F5 BIG-IP products. It can run on any of the F5 Application Delivery Platforms...BIG-IP Virtual Edition, BIG-IP 2000 -> 11050, and all the VIPRION blades. It protects your applications from a myriad of network attacks including the OWASP Top 10 most critical web application security risks It is able to adapt to constantly-changing applications in very dynamic network environments It can run standalone or integrated with other modules like BIG-IP LTM, BIG-IP DNS, BIG-IP APM, etc Why A Layer 7 Firewall? Traditional network firewalls (Layer 3-4) do a great job preventing outsiders from accessing internal networks. But, these firewalls offer little to no support in the protection of application layer traffic. As David Holmes points out in his article series on F5 firewalls, threat vectors today are being introduced at all layers of the network. For example, the Slowloris and HTTP Flood attacks are Layer 7 attacks...a traditional network firewall would never stop these attacks. But, nonetheless, your application would still go down if/when it gets hit by one of these. So, it's important to defend your network with more than just a traditional Layer 3-4 firewall. That's where the ASM comes in... Some Key Features The ASM comes pre-loaded with over 2,200 attack signatures. These signatures form the foundation for the intelligence used to allow or block network traffic. If these 2,200+ signatures don't quite do the job for you, never fear...you can also build your own user-defined signatures. And, as we all know, network threats are always changing so the ASM is configured to download updated attack signatures on a regular basis. Also, the ASM offers several different policy building features. Policy building can be difficult and time consuming, especially for sites that have a large number of pages. For example, DevCentral has over 55,000 pages...who wants to hand-write the policy for that?!? No one has that kind of time. Instead, you can let the system automatically build your policy based on what it learns from your application traffic, you can manually build a policy based on what you know about your traffic, or you can use external security scanning tools (WhiteHat Sentinel, QualysGuard, IBM AppScan, Cenzic Hailstorm, etc) to build your policy. In addition, the ASM comes configured with pre-built policies for several popular applications (SharePoint, Exchange, Oracle Portal, Oracle Application, Lotus Domino, etc). Did you know? The BIG-IP ASM was the first WAF to integrate with a scanner. WhiteHat approached all the WAFs and asked about the concept of building a security policy around known vulnerabilities in the apps. All the other WAFs said "no"...F5 said "of course!" and thus began the first WAF-scanner integration. The ASM also utilizes Geolocation and IP address intelligence to allow for more sophisticated and targeted defense measures. You can allow/block users from specific locations around the world, and you can block IP addresses that have built a bad reputation on other sites around the Internet. If they were doing bad things on some other site, why let them access yours? The ASM is also built for Payment Card Industry Data Security Standard (PCI DSS) compliance. In fact, you can generate a real-time PCI compliance report at the click of a button! The ASM also comes loaded with the DataGuard feature that automatically blocks sensitive data (Credit Card numbers, SSN, etc) from being displayed in a browser. In addition to the PCI reports, you can generate on-demand charts and graphs that show just about every detail of traffic statistics that you need. The following screenshot is a representative sample of some real traffic that I pulled off a site that uses the ASM. Pretty powerful stuff! I could go on for days here...and I know you probably want me to, but I'll wrap it up for this first article. I hope you can see the value of the ASM both as a technical solution in the defense of your network and also a critical asset in the long-term strategic vision of your company. So, if you already have an ASM and want to know more about it or if you don't have one yet and want to see what you're missing, come on back for the next article where I will talk about the cool features of policy building. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
Achieving firewall high-availability in Azure with F5
Background Due to the lack of Layer 2 functions (e.g. ARP) in public Cloud provider networks, certain firewall vendors recommend achieving Firewall (FW) high-availability (HA) through the use of load balancing. Take Palo Alto (PA) as an example, this article (High Availability Considerations on AWS and Azure | Palo Alto Networks) seems to suggest that load balancing is the only option, when deploying FW HA in Azure. For inbound HTTPS traffic, it does not make sense to pass that traffic as is to the FW, as the FW can't see it. The way to protect that traffic is using AWAF and AFM. This article focuses on load balancing FW's, achieving HA, and protect inbound non-HTTPS, as well as outbound traffic. - outbound being traffic originated from internal networks (e.g. user browsers) and destined to the Internet Inbound The following diagram depicts a two tier configuration. The VPC is associated with 10.3.0.0/16 CIDR block. For the ease of testing, Client is placed within the VPC, however, it represents users coming from the Internet. Traffic flow is shown as below, 1. Client (20.4) -> vs (20.5) Note: vs is the LB VIP fronting a second LB VIP configured on F5-Outbound 2. LTM sends traffic to the backend (70.5), which is a LB VIP configured on F5-Outbound, frontending resources in Server network To get to the 70.0 subnet, we use a firewall pool, and the LTM selects a firewall from that pool. azureuser@(F5-Inbound)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net route net route to_Server { network 10.3.70.0/24 pool /Common/fw_pool } azureuser@(F5-Inbound)(cfg-sync Standalone)(Active)(/Common)(tmos)# list ltm pool fw_pool ltm pool fw_pool { members { 10.3.30.10:any { address 10.3.30.10 session monitor-enabled state up } 10.3.40.10:any { address 10.3.40.10 session monitor-enabled state up } } monitor custom_PING_mon } 3. For traffic to be routed to either FW (e.g. 30.10 or 40.10), we also need to leverage User Defined Route (UDR), an Azure construct. e.g. udr-fw1-inbound and udr-fw2-inbound shown in the diagram 4. Once traffic arrives at a FW, the FW forwards that traffic to the tier 2 LTM (e.g. F5-Outbound). Again, UDR's must be used, for both outgoing and returning traffic, otherwise Azure will send traffic to the default subnet gateway (e.g. .1 address of each subnet) 5. When traffic (src: 30.245 or 40.245, dst: 70.5) arrives at F5-Outbound. The tier 2 LTM makes a load balancing decision and proxies that traffic to Server. 6. Traffic makes its way back. Routes back to F5-Inbound must be created on the tier 2 LTM. net route to_10.3.30.245 { gw 10.3.50.10 network 10.3.30.245/32 } net route to_10.3.40.245 { gw 10.3.60.10 network 10.3.40.245/32 } This concludes inbound. Outbound For outbound traffic, we will only leverage the tier 2 LTM (e.g. F5-Outbound). Once traffic arrives at the FW's, they get sent to the Internet via Azure default gateway. See diagram below. Traffic flow is shown as below, 1. Traffic originates from Server (70.4) and destines to the Internet (e.g. 1.2.3.4) 2. UDR must be created to route traffic to F5-Outbound 3. Once traffic arrives at the F5, a FW is selected as the next hop. See F5-Outbound config below. net route to_outside { network default pool /Common/fw_pool } ltm pool fw_pool { members { 10.3.50.10:any { address 10.3.50.10 session monitor-enabled state up } 10.3.60.10:any { address 10.3.60.10 session monitor-enabled state up } } monitor gateway_icmp } Again, watch the UDR's (we will need to create a new route and add to the existing UDR route table, as only one UDR is permitted per subnet) 4. Once traffic arrives at the FW, the FW sends it off to the Internet. To do this, SNAT must be enabled on the FW. For Linux, the following works. #FW1 iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 10.3.30.10 #FW2 iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 10.3.40.10 Internal traffic traversing different vnet's also go through the load balanced FW's. FW's routing table will send traffic to the destination, using Azure system default gateway. Notice that SNAT must be enabled. Remarks It's also possible to have Inbound working on a single F5. The FW's will need to SNAT inbound traffic in this case. Diagrams is shown below. Make sure to enable IP forwarding on all interfaces that forwardtraffic. The setting is under Interface, IP Configurations, within the Azure portal. Azure CLI The following CLI completed 95% of this build. az network public-ip create --resource-group cz-lb-fw-in_out_bound --name Client-pub-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name c-ext --vnet-name cz-A1 --subnet f5-front --network-security-group apply-all-nsg --private-ip-address 10.3.20.4 --public-ip-address Client-pub-ip az network public-ip create --resource-group cz-lb-fw-in_out_bound --name F5-Inbound-mgmt-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name f5-mgmt --vnet-name cz-A1 --subnet mgmt --network-security-group apply-all-nsg --private-ip-address 10.3.10.4 --public-ip-address F5-Inbound-mgmt-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name f5-ext --vnet-name cz-A1 --subnet f5-front --network-security-group apply-all-nsg --private-ip-address 10.3.20.245 az network nic create --resource-group cz-lb-fw-in_out_bound --name f51-int --vnet-name cz-A1 --subnet fw1-front --network-security-group apply-all-nsg --private-ip-address 10.3.30.245 az network nic create --resource-group cz-lb-fw-in_out_bound --name f52-int --vnet-name cz-A1 --subnet fw2-front --network-security-group apply-all-nsg --private-ip-address 10.3.40.245 az network nic create --resource-group cz-lb-fw-in_out_bound --name fw1-ext --vnet-name cz-A1 --subnet fw1-front --network-security-group apply-all-nsg --private-ip-address 10.3.30.10 az network nic create --resource-group cz-lb-fw-in_out_bound --name fw2-ext --vnet-name cz-A1 --subnet fw2-front --network-security-group apply-all-nsg --private-ip-address 10.3.40.10 az network nic create --resource-group cz-lb-fw-in_out_bound --name fw1-int --vnet-name cz-A1 --subnet fw1-back --network-security-group apply-all-nsg --private-ip-address 10.3.50.10 az network nic create --resource-group cz-lb-fw-in_out_bound --name fw2-int --vnet-name cz-A1 --subnet fw2-back --network-security-group apply-all-nsg --private-ip-address 10.3.60.10 az network public-ip create --resource-group cz-lb-fw-in_out_bound --name F5-Outbound-mgmt-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name f5o-mgmt --vnet-name cz-A1 --subnet mgmt --network-security-group apply-all-nsg --private-ip-address 10.3.10.5 --public-ip-address F5-Outbound-mgmt-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name f5o1-ext --vnet-name cz-A1 --subnet fw1-back --network-security-group apply-all-nsg --private-ip-address 10.3.50.245 az network nic create --resource-group cz-lb-fw-in_out_bound --name f5o2-ext --vnet-name cz-A1 --subnet fw2-back --network-security-group apply-all-nsg --private-ip-address 10.3.60.245 az network nic create --resource-group cz-lb-fw-in_out_bound --name f5o-int --vnet-name cz-A1 --subnet server-subnet --network-security-group apply-all-nsg --private-ip-address 10.3.70.245 az network public-ip create --resource-group cz-lb-fw-in_out_bound --name Server-pub-ip az network nic create --resource-group cz-lb-fw-in_out_bound --name s-ext --vnet-name cz-A1 --subnet server-subnet --network-security-group apply-all-nsg --private-ip-address 10.3.70.4 --public-ip-address Server-pub-ip # Add nics (only use when missing interfaces) az vm nic add --resource-group cz-lb-fw-in_out_bound --vm-name F5-Inbound --nics f51-int f52-int # FW builds az vm create --image ubuntults --resource-group cz-lb-fw-in_out_bound --name FW1 --admin-username azureuser --authentication-type ssh --size Standard_DS1_v2 --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics fw1-ext fw1-int az vm create --image ubuntults --resource-group cz-lb-fw-in_out_bound --name FW2 --admin-username azureuser --authentication-type ssh --size Standard_DS1_v2 --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics fw2-ext fw2-int #F5 builds az vm image accept-terms --urn f5-networks:f5-big-ip-best:f5-bigip-virtual-edition-best-byol:latest az vm create --image f5-networks:f5-big-ip-best:f5-bigip-virtual-edition-best-byol:latest --resource-group cz-lb-fw-in_out_bound --name "F5-Inbound" --admin-username azureuser --authentication-type ssh --size Standard_DS3_v2_Promo --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics f5-mgmt f5-ext f51-int f52-int az vm create --image f5-networks:f5-big-ip-best:f5-bigip-virtual-edition-best-byol:latest --resource-group cz-lb-fw-in_out_bound --name "F5-Outbound" --admin-username azureuser --authentication-type ssh --size Standard_DS3_v2_Promo --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics f5o-mgmt f5o1-ext f5o2-ext f5o-int #Client and server builds az vm create --image ubuntults --resource-group cz-lb-fw-in_out_bound --name Server --admin-username azureuser --authentication-type ssh --size Standard_DS1_v2 --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics s-ext az vm create --image ubuntults --resource-group cz-lb-fw-in_out_bound --name Client --admin-username azureuser --authentication-type ssh --size Standard_DS1_v2 --ssh-key-value "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtQiakawV5Co...." --nics c-ext # Update nics to enable forwarding az network nic update --resource-group cz-lb-fw-in_out_bound --name fw1-ext --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fw1-int --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fw2-ext --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fw2-int --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fwo1-ext --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fwo2-ext --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fwo1-int --ip-forwarding true az network nic update --resource-group cz-lb-fw-in_out_bound --name fwo2-int --ip-forwarding true # Create route-tables, associate to subnets and create routes az network route-table create --name udr-fw1-inbound --resource-group cz-lb-fw-in_out_bound --location eastus2 az network vnet subnet update --resource-group cz-lb-fw-in_out_bound --vnet-name cz-A1 --name fw1-front --route-table udr-fw1-inbound az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw1-inbound --name fw1_toServer --next-hop-type VirtualAppliance --address-prefix 10.3.70.0/24 --next-hop-ip-address 10.3.30.10 az network route-table create --name udr-fw2-inbound --resource-group cz-lb-fw-in_out_bound --location eastus2 az network vnet subnet update --resource-group cz-lb-fw-in_out_bound --vnet-name cz-A1 --name fw2-front --route-table udr-fw2-inbound az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw2-inbound --name fw2_toServer --next-hop-type VirtualAppliance --address-prefix 10.3.70.0/24 --next-hop-ip-address 10.3.40.10 az network route-table create --name udr-fw1-f5t2 --resource-group cz-lb-fw-in_out_bound --location eastus2 az network vnet subnet update --resource-group cz-lb-fw-in_out_bound --vnet-name cz-A1 --name fw1-back --route-table udr-fw1-f5t2 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw1-f5t2 --name post_fw1_toServer --next-hop-type VirtualAppliance --address-prefix 10.3.70.0/24 --next-hop-ip-address 10.3.50.245 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw1-f5t2 --name server_return_fw1 --next-hop-type VirtualAppliance --address-prefix 10.3.30.245/32 --next-hop-ip-address 10.3.50.10 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw1-f5t2 --name to_outside_fw1 --next-hop-type VirtualAppliance --address-prefix 0.0.0.0/0 --next-hop-ip-address 10.3.50.10 az network route-table create --name udr-fw2-f5t2 --resource-group cz-lb-fw-in_out_bound --location eastus2 az network vnet subnet update --resource-group cz-lb-fw-in_out_bound --vnet-name cz-A1 --name fw2-back --route-table udr-fw2-f5t2 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw2-f5t2 --name post_fw2_toServer --next-hop-type VirtualAppliance --address-prefix 10.3.70.0/24 --next-hop-ip-address 10.3.60.245 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw2-f5t2 --name server_return_fw2 --next-hop-type VirtualAppliance --address-prefix 10.3.40.245/32 --next-hop-ip-address 10.3.60.10 az network route-table route create --resource-group cz-lb-fw-in_out_bound --route-table-name udr-fw2-f5t2 --name to_outside_fw2 --next-hop-type VirtualAppliance --address-prefix 0.0.0.0/0 --next-hop-ip-address 10.3.60.10 Updates: Alternative approaches have also been developed, and can be used to support the following use cases: vnet to vnet traffic be load balanced to FW's - a hub and spoke topology is used where the hub vnet hosts the services (F5's and FW's), and spoke vnets host consumer networks (e.g. DMZ, internal) vnet to Internet traffic be load balanced to FW's - traffic originated from spoke vnets, destined to Internet,traverses the hub vnet, where FW's are load balanced Inbound Intertnet to vnet's traffic be load balanced to FW's - e.g. RDP to internal machines, or application load balancing SNAT is optional for vnet to vnet, as well as inbound Internet traffic - The F5can retain client IP addresses and pass traffic as is to FW's (e.g. No address translation on the F5) Due to variations in requirements and their associated complexities, it's not possible to share all the details here. If you have a particular requirement, please reach out to your Sales team!
F5 Friday: It is now safe to enable File Upload
Web 2.0 is about sharing content – user generated content. How do you enable that kind of collaboration without opening yourself up to the risk of infection? Turns out developers and administrators have a couple options… The goal of many a miscreant is to get files onto your boxen. The second step after that is often remote execution or merely the hopes that someone else will look at/execute the file and spread chaos (and viruses) across your internal network. It’s a malicious intent, to be sure, and makes developing/deploying Web 2.0 applications a risky proposition. After all, Web 2.0 is about collaboration and sharing of content, and if you aren’t allowing the latter it’s hard to enable the former. Most developers know about and have used the ability to upload files of just about any type through a web form. Photos, documents, presentations – these types of content are almost always shared through an application that takes advantage of the ability to upload data via a simple web form. But if you allow users to share legitimate content, it’s a sure bet (more sure even than answering “yes” to the question “Will it rain in Seattle today?”) that miscreants will find and exploit the ability to share content. Needless to say information security professionals are therefore not particularly fond of this particular “feature” and in some organizations it is strictly verboten (that’s forbidden for you non-German speakers). So wouldn’t it be nice if developers could continue to leverage this nifty capability to enable collaboration? Well, all you really need to do is integrate with an anti-virus scanning solution and only accept that content which is deemed safe, right? After all, that’s good enough for e-mail systems and developers should be able to argue that the same should be good enough for web content, too. The bigger problem is in the integration. Luckily, ICAP (Internet Content Adaptation Protocol) is a fairly ready answer to that problem. SOLUTION: INTEGRATE ANTI-VIRUS SCANNING via ICAP The Internet Content Adaptation Protocol (ICAP) is a lightweight HTTP based protocol specified in RFC 3507 designed to off-load specific content to dedicated servers, thereby freeing up resources and standardizing the way in which features are implemented. ICAP is generally used in proxy servers to integrate with third party products like antivirus software, malicious content scanners and URL filters. ICAP in its most basic form is a "lightweight" HTTP based remote procedure call protocol. In other words, ICAP allows its clients to pass HTTP based (HTML) messages (Content) to ICAP servers for adaptation. Adaptation refers to performing the particular value added service (content manipulation) for the associated client request/response. -- Wikipedia, ICAP Now obviously developers can directly take advantage of ICAP and integrate with an anti-virus scanning solution directly. All that’s required is to extract every file in a multi-part request and then send each of them to an AV-scanning service and determine based on the result whether to continue processing or toss those bits into /dev/null. This is assuming, of course, that it can be integrated: packaged applications may not offer the ability and even open-source which ostensibly does may be in a language or use frameworks that require skills the organization simply does not have. Or perhaps the cost over time of constantly modifying the application after every upgrade/patch is just not worth the effort. For applications for which you can add this integration, it should be fairly simple as developers are generally familiar with HTTP and RPC and understand how to use “services” in their applications. Of course this being an F5 Friday post, you can probably guess that I have an alternative (and of course more efficient) solution than integration into the code. An external solution that works for custom as well as packaged applications and requires a lot less long term maintenance – a WAF (Web Application Firewall). BETTER SOLUTION: web application firewall INTEGRATION The latest greatest version (v10.2) of F5 BIG-IP Application Security Manager (ASM) included a little touted feature that makes integration with an ICAP-enabled anti-virus scanning solution take approximately 15.7 seconds to configure (YMMV). Most of that time is likely logging in and navigating to the right place. The rest is typing the information required (server host name, IP address, and port number) and hitting “save”. F5 Application security manager (ASM) v10 includes easy integration with a/v solutions It really is that simple. The configuration is actually an HTTP “class”, which can be thought of as a classification of sorts. In most BIG-IP products a “class” defines a type of traffic closely based on a specific application protocol, like HTTP. It’s quite polymorphic in that defining a custom HTTP class inherits the behavior and attributes of the “parent” HTTP class and your configuration extends that behavior and attributes, and in some cases allows you to override default (parent) behavior. The ICAP integration is derived from an HTTP class, so it can be “assigned” to a virtual server, a URI, a cookie, etc… In most ASM configurations an HTTP class is assigned to a virtual server and therefore it sees all requests sent to that server. In such a configuration ASM sees all traffic and thus every file uploaded in a multipart payload and will automatically extract it and send it via ICAP to the designated anti-virus server where it is scanned. The action taken upon a positive result, i.e. the file contains bad juju, is configurable. ASM can block the request and present an informational page to the user while logging the discovery internally, externally or both. It can forward the request to the web/application server with the virus and log it as well, allowing the developer to determine how best to proceed. ASM can be configured to never allow requests to reach the web/application server that have not been scanned for viruses using the “Guarantee Enforcement” option. When configured, if the anti-virus server is unavailable or doesn’t respond, requests will be blocked. This allows administrators to configure a “fail closed” option that absolutely requires AV scanning before a request can be processed. A STRATEGIC POINT of CONTROL Leveraging a strategic point of control to provide AV scanning integration and apply security policies regarding the quality of content has several benefits over its application-modifying code-based integration cousin: Allows integration of AV scanning in applications for which it is not feasible to modify the application, for whatever reason (third-party, lack of skills, lack of time, long term maintenance after upgrades/patches ) Reduces the resource requirements of web/application servers by offloading the integration process and only forwarding valid uploads to the application. In a cloud-based or other pay-per-use model this reduces costs by eliminating the processing of invalid requests by the application. Aggregates logging/auditing and provides consistency of logs for compliance and reporting, especially to prove “due diligence” in preventing infection. Related Posts All F5 Friday Entries on DevCentral All About ASM
