F5 Infosec Israel 2013 Application Centric Security

Editor's Notes

• #3: Source: IBM X-Force 2011 Trend and Risk Report March 2012{NOTE TO SPEAKER: The key points to get across on this slide really are around the fact -- and this can be conveyed and leveraged in multiple different ways. What I like to articulate here is really that if you look at the attack types, you know, major attack types that exist here are application type attacks and web attacks. In addition to that, you can see here that the key thing is every single one of these customers in themselves had a firewall, and it was most likely a next generation firewall. And the reality of the situation is once again due to the fact that they leverage a piece of technology that was not designed to protect their data center, the resulting effect was that they weren't protected and they were exploited. And it's important that the individual conveying the slide, if you're talking to a partner, that you can articulate that you do not want your customers to be one of the next large bubbles or bubbles that exist on this eye chart. Or if you happen to be a customer the last thing that you want is the company that you're working for or protecting to be on this eye chart.}
• #9: F5 is the global leader in Application Delivery Networking, and continues to be a solid provider and customer ally as we continue to grow and expand the entire ADC market.
• #11: This PPT representation complies with Gartner’s Copyright & Policy as of Nov-08-12. Although the slide may be modified for style & visual consistency, no element should be added, deleted or hidden without contacting r.curran@f5.com
• #14:  So one of F5's key differentiators and value-add with regard to security is the fact that we provide it on a full proxy architecture. And the value of a full proxy architecture for those who are not familiar can be analogous to the role that an escrow agent or an escrow officer might play in a real estate transaction. The reason for the escrow officer is to protect the buyer from the seller and the seller from the buyer by acting as an independent third party or a neutral third party to protect the buyer and the seller. And the role of this officer is also to inspect all elements of the transaction before allowing the transaction to be completed, safely and securely. And much in the same way F5's full proxy security looks and examines all elements within the OSI stack, because we are located at strategic points in the network and we are by nature inspecting that traffic, it allows us to understand what's happening and take action on that traffic, from an application perspective, from a session perspective and from a network session perspective, all throughout the stack. {NOTE TO SPEAKER: F5 Mitigation Technologies:Application: BIG-IP ASM:Positive and negative policy reinforcement, iRules, full proxy for HTTP, server performance anomaly detectionSession: BIG-IP LTM and GTM: high scale performance, DNS Express, SSL termination, iRules, SSL renegotiation validationNetwork: BIG-IP LTM: SynCheck, default-deny posture, high-capacity connection table, full proxy traffic visibility, rate-limiting, strict TCP forwarding. Network layer bullets:L4 Stateful firewall – including TCP checksum checks, fragmentation and reassemblyDDoS mitigationSession layer:SSL inspectionSSL DDoS attacksApplication Layer:OWASP top 10Application content scrubbing (S -> C)}
• #15: Because we are located in strategic points of the network, and because we do take a full proxy approach, performance is absolutely critical, because you can imagine all of the traffic traveling through this point being inspected. It must be done at very, very high rates of speed. Because F5 combines purpose-built software with purpose-built hardware, we're able to achieve and add multiple services on our intelligent services platform with minimal performance degradation, and we're able to do these at scale much higher, at a scale much higher than can be traditionally done with existing security solutions.
• #19: One of the additional functions of the ADF solution is the ability to secure DNS infrastructure. The Application Delivery Firewall with the BIG-IP GTM and DNSSEC module achieves this in a couple of ways. One of the problems or one of the weaknesses of traditional DNS infrastructure is the fact that most DNS infrastructure doesn't have the scale that's necessary to deal with large scale potential attacks in the form of DNS floods or DNS -- in terms of DNS floods. And a typical DNS server might be able to handle say 65,000 concurrent queries. If you start to overwhelm that DNS server, what ends up happening is that an attacker can start to maliciously inject responses for DNS queries. This can result in a number of things such as cache poisoning, DNS spoofing, and generally what it results in is problems for the end website. And it has a real follow-on effect to the brand integrity.  Think about it this way. If you're trying to reach a particular website like www.bank.com, and bank.com is undergoing a DNS attack, if the correct -- is undergoing a DNS denial of service attack, if the correct IP address is not returned and instead it's redirected to a malicious site, that is a real -- that bears a real problem for bank.com's brand and their integrity. Now, our Application Delivery Firewall solves this problem in a couple of ways. The first and foremost is just the sheer scale and ability to handle up to 10 million concurrent queries. So we have this massive scale of DNS -- being able to be a DNS server. The other thing that the ADF can do is also sign DNS queries. This is DNS SEC. What this means is that responses to DNS queries are cryptographically signed so they can't be spoofed. This is a particularly interesting use case for certain federal agencies who have to comply with DNS SEC requirements.
• #21: Traditional firewalls are often incapable of looking into SSL traffic. And what this means is that attacks could be embedded within SSL, either in the form of malforms, payloads, or in the case of certain types of denial of service attacks such as slowloris or slowpost. Those attacks could be embedded within encrypted channels. And if the firewall is not looking into the encrypted channel, then those attacks are passed directly to the server, which could then basically fall over. And it's important to note that it's not the case that firewalls can't look into SSL traffic. In fact, today, many if not most of them do have that ability. But the limiting factor is their scale. And most existing firewalls today have a significant performance penalty when they enable SSL inspection, which means that most administrators end up not enabling this. And so in reality what ends up happening is that most firewalls that are deployed end up passing through SSL encrypted traffic. By contrast, the F5 Application Delivery Firewall has a really high performing SSL inspection, and what that means is that as a full proxy and as a full SSL proxy the ADF will be able to decrypt the incoming SSL connections, inspect them for any possible threats, and then forward them on to the application servers. So we're able to block any malicious packets that would be going through. This has a secondary effect, and that's what we call SSL offload, and namely that since we're using the F5 ADF to do the SSL decryption, then we can pass the unencrypted traffic to the application server, which significantly reduces the load on the app servers.
• #22: If a client connection attempts to renegotiate more than five times in any 60 second period, that client connection is silently dropped.By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack.  There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.The tool itself is about 700 lines of readable C code. Actually, it looks better than your typical hack-tool so I have to give “The Hacker’s Choice” props on their craftmanship. The attack tool ramps up to 400 open connections and attempts to do as many renegotiations on each connection as it can. On my dedicated test client, it comes out to 800 handshakes per second (or 2 per connection per second).Moment of IronyWhen you first run the tool against your BIG-IP virtual server, it might say “Server does not support SSL Renegotiation.” That’s because everyone, including F5, is still recovering from last year’s SSL renegotiation vulnerability and by default our recent versions disable SSL renegotiation. So in order to do any testing at all, you have to re-enable renegotiation. But this also means that by default, virtual servers (on 10.x) are already not vulnerable unless they’ve explicitly re-enabled renegotiation. The irony is that the last critical SSL vulnerability provides some protection against this new SSL vulnerability. The iRule CountermeasureEnter DevCentral. After setting up the attack lab, we asked Jason Rahm (blog) for his assistance. He put together a beautiful little iRule that elegantly defeats the attack. Its premise is simple:If a client connection attempts to renegotiate more than five times in any 60 second period, that client connection is silently dropped.By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack. There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.The iRulewhen RULE_INIT { set static::maxquery 5 set static::seconds 60 } when CLIENT_ACCEPTED { set rand [expr { int(10000000 * rand()) }] } when CLIENTSSL_HANDSHAKE { set reqno [table incr "reqs$rand"] table set -subtable "reqrate:$rand" $reqno "ignored" indefinite $static::seconds if { [table keys -count -subtable "reqrate:$rand"] > $static::maxquery } { after 5000 drop } } when CLIENT_CLOSED { table delete reqs$rand table delete –subtable reqrate:$rand –all } With the iRule in place, you can see its effect within a few seconds of the test restarting.Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err Handshakes 2000 [0.00 h/s], 400 Conn, 0 Err Handshakes 2000 [0.00 h/s], 400 Conn, 0 ErrThe 400 connections each get their five renegotiations and then the iRule waits five seconds (to ack any outstanding client data) before silently dropping the connection. The attack tool believes the connection is still open, so it stalls. Note that the test had to be restarted, because the iRule doesn’t apply to existing connections when it’s attached to a virtual server. Take that into account if you are already under attack.Its understandable if you are thinking “that’s the coolest 20-line iRule I’ve ever seen, I wish I understood it better.” Jason also provided a visual workflow to elucidate its mechanics.iRule DDOS countermeasure workflowConclusionAt a meeting earlier this year here in Seattle we were talking about the previous Renegotiation flaw. The question was posed “What is the next vulnerability that we’re all going to slap our foreheads about?” This particular attack falls into that category. Its a simple attack against a known property of the protocol. Fortunately, BIG-IP can leverage its hardware-offload or use countermeasures like this iRule to counter the attack. There are two take-aways here: first, even long-established and reviewed protocols like SSL/TLS can be used against you and second, iRules are pretty sweet!And thanks again, to Jason Rahm for his invaluable assistance!
• #23: Use this slide with new customers