http://www.securityfocus.com/archive/1/531779/30/0/threaded
> Date: Wed, 9 Apr 2014 11:35:26 -0500 > From: [email protected] > To: [email protected] > Subject: Re: [NTSysADM] Heartbleed vulnerability > > On Wed, 9 Apr 2014, Richard Stovall wrote: > > > Please to be explaining or providing links. It would be great to know how > > to do this. > > this was on the bugtraq list this morning.. I haven't had a chance to test > yet today... > > > > From: Fabien Bourdaire <[email protected]> > To: [email protected] > Subject: CVE-2014-0160 mitigation using iptables > > > Following up on the CVE-2014-0160 vulnerability, heartbleed. We've > created some iptables rules to block all heartbeat queries using the > very powerful u32 module. > > The rules allow you to mitigate systems that can't yet be patched by > blocking ALL the heartbeat handshakes. We also like the capability to > log external scanners :) > > The rules have been specifically created for HTTPS traffic and may be > adapted for other protocols; SMTPS/IMAPS/... > > # Log rules > iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ > "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" > > # Block rules > iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ > "52=0x18030000:0x1803FFFF" -j DROP > > # Wireshark rules > $ tshark -i interface port 443 -R 'frame[68:1] == 18' > $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' > > > We believe that this should only be used as a temporary fix to decrease > the exposure window. The log rule should allow you to test the firewall > rules before being used in production. It goes without saying that if > you have any suggested improvements to these rules we would be grateful > if you could share them with the security community. > > Clearly, use of these rules is at your own risk ;) > > > ECSC SOC Team Researchers: > Adam Shore > Alex Innes > Fabien Bourdaire > > > >
