Is it possible to write some sort of firewall rule/s to prevent the heartbleed handshake without disrupting normal SSL connections ?
If maybe the heartbeat data to be returned is bigger then say 200 bytes. There are various snort rules based on this.
Im not so much worried about servers and routers. Im worried about home devices. Everything from consumer routers to NATed security cameras and CCTV DVR’s. Im worried about things that will have direct connection to the web and run encryption. These things might NEVER get patched. There is already active scanning for these devices.
Im also worried about outgoing apps on iDevices and Android. Just because the OS is not vulnerable does NOT mean the app is OK. There are already apps for iDevices which run on the current iOS which ARE vulnerable to reverse heartbleed. The list is certain to grow. Home alarm systems that have web interfaces for user to set the alarm when away. Home automation systems. Even medical devices which allow the doctor to remote monitor have show to be vulnerable.
So I want to block this SSL heartbeat. I wont be able to control patching the consumer devices, most likely they may never be patched. Cable modems, TVs, Bluray players, surround rcvrs. The list is insane.
So I want to stop the traffic, arrest the heartbeat “feature” before it becomes a heart attack.
There must be a way to do this on RouterOS. The example I give above works. Lets see if it can be done on Mikrotik. Lets save users of our networks.