Spider & F5 Round Table - Application Centric Security

Editor's Notes

• #7:  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)}
• #8: 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.
• #18: Unable to secure disperse web appsNo virtual WAF option for private cloud apps Replication of production environment complicated and cost-prohibitiveNeed to block app requests from countries or regions due to compliance restrictionsLimiting app. access based on location is a good practice to quickly reduce the attack sourcesScanner scans applications to identify vulnerabilities and directly configures BIG-IP ASM policies to implement a virtual patch that blocks web app attacksBIG-IP ASM is now importing vulnerabilities – not patches – (in v11), it effectively becomes a Vulnerability Management Tool along with being WAF.  Obviously, the net effect is enabling very rapid response, particularly in the instance where you're waiting for the third-party vendor to patch the vulnerability.
• #19: 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!