TCP 4 way handshake or TCP Split Handshake Attack

TCP 4 way handshake or TCP Split Handshake Attack

[Fatih USTA]

Hello,
I am trying to protect my network from the tcp split handshake attack! 
(4-way handshake rejection or 3-way handshake enforcement).
I tested the sample code. (link below) And passed the firewall(iptables).
I can't find any solution on the internet for Linux.
Any advice?

Link1: 
https://tech.labs.oliverwyman.com/blog/2016/11/07/4-way-tcp-handshake-and-firewalls/
Link2: https://gist.github.com/anonymous/142ebe785dbb146dafaa7ff59d8a9da8
Link3: https://nmap.org/misc/split-handshake.pdf


Thank you.

Re: TCP 4 way handshake or TCP Split Handshake Attack

[Florian Westphal]

Fatih USTA <fatihusta86@gmail.com> wrote:
> Hello,
> I am trying to protect my network from the tcp split handshake attack!
> (4-way handshake rejection or 3-way handshake enforcement).
> I tested the sample code. (link below) And passed the firewall(iptables).

Why wouldn't it?  Its valid tcp, your ruleset allows connections to happen
and there is a socket expecting a connection.

> I can't find any solution on the internet for Linux.

nft add rule filter forward tcp flags & (syn | ack) == syn ct direction reply counter drop

But why would you want to disallow this behaviour?

> Link1: https://tech.labs.oliverwyman.com/blog/2016/11/07/4-way-tcp-handshake-and-firewalls/

This is simultaneous connect, at least thats what can be seen in the
tcpdump, syns cross on wire, both ends send syn/ack.  WHy do you
consider this an "attack"?

Re: TCP 4 way handshake or TCP Split Handshake Attack

[Fatih USTA]

Fatih USTA

On 24.01.2020 19:24, Florian Westphal wrote:
> Fatih USTA <fatihusta86@gmail.com> wrote:
>> Hello,
>> I am trying to protect my network from the tcp split handshake attack!
>> (4-way handshake rejection or 3-way handshake enforcement).
>> I tested the sample code. (link below) And passed the firewall(iptables).
> Why wouldn't it?  Its valid tcp, your ruleset allows connections to happen
> and there is a socket expecting a connection.

Actually there isn't real open socket(sample code) on the clients. Only 
sending and receiving packet. There is no listen port on the system. (If 
I understand correctly)
>> I can't find any solution on the internet for Linux.
> nft add rule filter forward tcp flags & (syn | ack) == syn ct direction reply counter drop

fw1

-A FORWARD -p tcp -m tcp --tcp-flags SYN,ACK SYN -m conntrack --ctdir 
REPLY -j LOG --log-prefix "SPLIT FWD " --log-level 6
-A FORWARD -p tcp -m tcp --tcp-flags SYN,ACK SYN -m conntrack --ctdir 
REPLY -j DROP

kernel: : [3074700.968937] SPLIT FWD IN=eth12 OUT=eth11 
MAC=8a:15:53:25:4e:94:72:43:c2:9f:07:cb:08:00 SRC=172.16.2.2 
DST=10.0.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=61 ID=206 DF PROTO=TCP 
SPT=5555 DPT=5555 WINDOW=29200 RES=0x00 SYN URGP=0


I wrote this rule on fw1, but not dropped. Is this rule correct?
Here is the test topology.
host1 <> fw1 <> router <> fw2 <> host2

host1=10.0.0.2
fw1= 10.0.0.1
fw1= 172.16.1.2(MASQ)
router=172.16.1.1
router=172.16.2.1
fw2= 172.16.2.2 (MASQ)
fw2=10.0.1.1
host2=10.0.1.2

host1 command
./tcp-4way.py 172.16.2.2 5555 hello
host2 command
./tcp-4way.py 172.16.1.2 5555 world

host1 result
connected to 172.16.2.2:5555
received message: [world]

host2 result
connected to 172.16.1.2:5555
received message: [hello]

> But why would you want to disallow this behaviour?

There isn't defined port forwarding to clients on the iptables. Clients 
sends packets to "remote Real IP" address. I think this is security 
issue. isn't?
>> Link1: https://tech.labs.oliverwyman.com/blog/2016/11/07/4-way-tcp-handshake-and-firewalls/
> This is simultaneous connect, at least thats what can be seen in the
> tcpdump, syns cross on wire, both ends send syn/ack.  WHy do you
> consider this an "attack"?
I know this is RFC defined feature.
Some one says attack some one says issue.
This issue reported by the nss labs. Global firewall vendors patched 
their software.

What's your comments for this report?
https://www.nsslabs.com/press/2011/5/10/network-firewall-vendors-address-tcp-split-handshake-issues-found-by-nss-labs/

Other links.
https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10476&cat=SECURITY_PRODUCTS&actp=LIST
https://www.hackmageddon.com/2011/04/17/tcp-split-handshake-attack-explained/
https://www.secplicity.org/2011/04/15/what-is-the-tcp-split-handshake-attack-and-does-it-affect-me/

Re: TCP 4 way handshake or TCP Split Handshake Attack

[Florian Westphal]

Fatih USTA <fatihusta86@gmail.com> wrote:
> On Fri, Jan 24, 2020, 19:24 Florian Westphal <fw@strlen.de> wrote:
> 
> > Fatih USTA <fatihusta86@gmail.com> wrote:
> > > Hello,
> > > I am trying to protect my network from the tcp split handshake attack!
> > > (4-way handshake rejection or 3-way handshake enforcement).
> > > I tested the sample code. (link below) And passed the firewall(iptables).
> >
> > Why wouldn't it?  Its valid tcp, your ruleset allows connections to happen
> > and there is a socket expecting a connection.
> >
> 
> Actually there isn't real open socket(sample code) on the clients. Only
> sending and receiving packet. There is no listen port on the system. (If I
> understand correctly)

Are you referring to the sample code?
I did not look at it before.  The example code illustrates simulatenous
connect.  There are two sockets that connect to one another, crossing
syns.

If some doesn't want this for whatever reason you need to filter/drop pure
syn in reply direction.

This also disables/prevents connection re-use with client/server reversal.

(I.e., a connects to b, a closes, b starts to close, then immediately
 connects to a using exaclty same connection quadruple).

> > > I can't find any solution on the internet for Linux.
> >
> > nft add rule filter forward tcp flags & (syn | ack) == syn ct direction
> > reply counter drop
> >
> Is there iptables sample?

-p tcp --syn -m conntrack --ctdir REPLY -j DROP

or something like that.

> > But why would you want to disallow this behaviour?
>
> There isn't defined port forwarding to clients on the iptables.

That 'port forwarding' is created at the very moment the SYN packet has
passed through snat/masquerade rule.  This is what nf_nat does -- dynamic
port forwarding.  Otherwise, incoming replies would not get passed to
the client that initiated the request, i.e. you would need
manual/stateless snat rule.

> Clients
> sends packets to remote "Real IP" address behind the firewall. I think this
> is security issue.

A asked to connect to B.
At exactly the same time B asked to connect to A.

Both syn packets pass though a NAT gateway.
Both NAT gateways have a matching state with reverse translation info.

The fact that the reply packet has only 'syn bit' set rather
than the normal 'syn/ack' makes no difference, in both cases
packet should have its NAT reversed and passed to the client.

> This issue reported by the nss labs. Global firewall vendors patched their
> software.
> 
> What's your comments for this report?
> 
> https://www.nsslabs.com/press/2011/5/10/network-firewall-vendors-address-tcp-split-handshake-issues-found-by-nss-labs/

I found no technical rationale why there is a problem.

> https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10476&cat=SECURITY_PRODUCTS&actp=LIST

"In reality, in such similar circumstances, NSS test have shown that
some network security devices, with the sole firewall function enabled,
get confused and behaves in a stateless manner."

conntrack doesn't misbehave, connection is tracked normally.

I suspect that this is about some ids/ips or network logging tools that
might not detect connection establishement when reply to syn is another
syn instead of syn/ack.

In any case, I see no wrong/unsafe behaviour from nf_conntrack.