On Thu, May 1, 2014 at 9:04 AM, VAN BEMMEL, Jeroen (Jeroen) <[email protected]> wrote: > Hi, > > > > A recently discovered bug in OpenSSL – a.k.a. the “Heartbleed” bug – has > raised security concerns in many IT organizations. Even though the issue > itself was easily patched, there are many vulnerable servers out there, and > some of these may never get patched. It is expected that Heartbleed will > remain a security concern for many years to come. > > > > There are several ways to mitigate Heartbleed vulnerabilities. Besides > patching or reconfiguring servers, enterprises need additional solutions for > preventing critical information to leak, for those cases where systems > cannot be patched/reconfigured. Several IDS/DPI vendors have published > packet filter expressions to match potential heartbleed packets ( see e.g. > http://www.riverbed.com/blogs/Retroactively-detecting-a-prior-Heartbleed-exploitation-from-stored-packets-using-a-BPF-expression.html > ) > > > > Attached is a (very rough) patch against the latest git tree, to add a > “check_heartbleed” action to OVS. It’s main purpose is to stimulate a > discussion on whether this could be something to add to OpenVSwitch; it is > untested and clearly requires major refactoring before it could be added. > > > > Basically, the way it would work is as follows: SSH Heartbeat response > packets start with a type code ( 0x18 ), two bytes for the SSL version ( > major = 0x3, minor = 0x00-0x03 ) followed by payload bytes. A sample packet > trace can be found at > http://blog.didierstevens.com/2014/04/09/heartbleed-packet-capture/ . The > ‘check_heartbleed’ action would silently drop heartbeat response packets > with a payload larger than a given maximum ( and presumably raise an alarm / > create a log entry ) > > > > This basic feature could be enhanced in several ways. I believe a typical > server would send a couple of response packets ( until the TCP window runs > out ), so besides dropping the first trigger packet we should probably also > send a RST to the server, and create a flow rule to drop all subsequent > response packets for the connection. Moreover, sophisticated attackers could > probably try to use a small TCP MSS value or advertise a small window, such > that the server responses would remain below the threshold. An additional > action to check SYN packets for abnormally low MSS, and small client > advertised window values could potentially help avoid this.
I think another way to rephrase this paragraph is that to do this properly, you need a TCP stack. Adding tons of actions to check for various specific attacks is really unpalatable, so I don't think a piecemeal approach is really tenable. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
