Instantly share code, notes, and snippets.

Embed
What would you like to do?
Drop successful SSLv3 connections using IPtables
# Matching 'SSL SERVER HELLO' packets using IPtables
# Using some connection tracking to make sure not
# to match randomly in the middle of some huge SSL
# session.
iptables --insert INPUT -p tcp --sport 443 \
-m connbytes --connbytes-mode bytes --connbytes-dir both --connbytes 0:500 \
-m state --state ESTABLISHED \
-m length --length 46:375 \
-m u32 --u32 "\
0>>22&0x3C@ 12>>26&0x3C@ 0&0xFFFFFF00=0x16030000 && \
0>>22&0x3C@ 12>>26&0x3C@ 4&0x00FF0000=0x00020000 && \
0>>22&0x3C@ 12>>26&0x3C@ 8&0x00FFFF00=0x00030000" \
-j LOG --log-prefix "SSLv3 Server Hello Handshake"
# Results in log messages such as:
#SSLv3 Server Hello Handshake
@gertvdijk

This comment has been minimized.

gertvdijk commented Oct 16, 2014

Taking the first 500 bytes of the connection is a good performance boost 👍
However, in mitigating POODLE, it was shown that the attacker is downgrading the secure connection from TLSv1+ to SSLv3. Does it require to set up a new TCP connection (and thus resetting the counter) for a client to downgrade in protocols? If not, then you'll probably be missing out on the actual SSLv3 handshake caused by the downgrade attack and only catching the 'regular' SSLv3 handshakes.

@lhaagsma

This comment has been minimized.

Owner

lhaagsma commented Oct 16, 2014

"However, in mitigating POODLE, it was shown that the attacker is downgrading the secure connection from TLSv1+ to SSLv3. Does it require to set up a new TCP connection (and thus resetting the counter) for a client to downgrade in protocols?"

I believe that this is required yes. But as I have not seen PCAP data of this part of the attack in progress I cannot be 100% sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment