on 16-May-2011 10:39
There’s been a lot of commentary on the previous post (SSL Renegotiation DOS – an iRule Countermeasure). Here are some of the updates and corrections.
This means that the attack is less theoretical than the previous post made it sound.
The iRule has received some scrutiny as well. Jason Rahm had crafted a neat little algorithm that made interesting use of random numbers (as a lookup key) and tables (to keep a sliding window). With an eye toward optimizing both CPU usage and per-flow memory, here is a version of the iRule that:
Thanks again go out to the DevCentral community, not only for helping with this iRule, but also for spreading the word (DevCentral Podast) about SSL attacks and our ability to very quickly deploy countermeasures like these.
when RULE_INIT {
set static::maxquery 5
set static::mseconds 60000
}
when CLIENT_ACCEPTED {
set ssl_hs_reqs 0
}
when CLIENTSSL_HANDSHAKE {
incr ssl_hs_reqs
after $static::mseconds { if {$ssl_hs_reqs > 0} {incr ssl_hs_reqs -1} }
if { $ssl_hs_reqs > $static::maxquery } {
after 5000
log "Handshake attack detected, dropping [IP::client_addr]:[TCP::client_port]"
drop
}
}
Links:
We began analyzing this today, for we suddenly began to get these messages in the GUI, constantly from the orginal version of the rule...
Mon Oct 14 13:05:15 CDT 2013 err LTM tmm[11044] 01220001 TCL error: /Common/irule_SSLRenegotiationDOSCountermeasure - can't read "flow": no such variable while executing "table delete -subtable reqrate:$flow -all"
Mon Oct 14 13:05:17 CDT 2013 err LTM tmm1[11044] 01220001 TCL error: /Common/irule_SSLRenegotiationDOSCountermeasure - no serverside connection established (line 1) invoked from within "IP::server_addr"