From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 405D921F1FB for ; Wed, 9 Apr 2014 08:18:25 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9103634wiv.7 for ; Wed, 09 Apr 2014 08:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=9pX3GZRAgbUe7fa/KBuE1NlomucnRdEk3IJ9mFSOZOM=; b=vGmhm1khNGNVDbfsLu8bNNhR0pvbNI495wsYh2lzJCUUKGAD/yq4fM+iL0IIbSZXcq tQQaRVVHC032aa0G6xxzWHCUsWCASm2h5R04iPlMS2erw37vRNX3609RCEZOXaSdbRy+ fy7RmdxT0f/cCTjmCfSROFctzy+oCn4n6M71lEBsB80MAHKSrnN28AcPdaPkIAGvsUR7 IDkSsx6za2+SGzZVyCyoI1VDkuwvZEiaVFEmCMNlCTG5vD04fNeI8Qxzze+zihEo6hpb St76WsDQ6bawSQ/MXyFgzrdmsxYTzOrIsn5cdTAlDX8yLHhCp/ZrOUPb9ykesBcvz1PI 8psw== MIME-Version: 1.0 X-Received: by 10.180.188.169 with SMTP id gb9mr10573593wic.17.1397056703108; Wed, 09 Apr 2014 08:18:23 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Wed, 9 Apr 2014 08:18:23 -0700 (PDT) In-Reply-To: <53453B13.8000705@ecsc.co.uk> References: <53453B13.8000705@ecsc.co.uk> Date: Wed, 9 Apr 2014 08:18:23 -0700 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] Fwd: [uknof] CVE-2014-0160 mitigation using iptables X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:18:25 -0000 It is not clear if this could be used to protect things inside the firewall (switching to a forward rather than input table), nor if it could be used with ipv6. ---------- Forwarded message ---------- From: Fabien Bourdaire Date: Wed, Apr 9, 2014 at 5:20 AM Subject: [uknof] CVE-2014-0160 mitigation using iptables To: uknof@lists.uknof.org.uk 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=3D0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=3D0x18030000:0x1803FFFF" -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] =3D=3D 18' $ tshark -i interface port 443 -R 'ssl.record.content_type =3D=3D 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 -- ECSC Ltd - http://www.ecsc.co.uk --=20 Dave T=E4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article