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. Security is a cat and mouse game, and people will always invent new ways to bypass security measures. Nevertheless, I believe OVS could be an important part of the security defense line against such attempts. It would add some great value for its customers, and could be a nice illustration of how community-driven SDN helps organizations face new security challenges Regards, Jeroen van Bemmel, Alcatel-Lucent / Nuage Networks
check_heartbleed.patch
Description: check_heartbleed.patch
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
