HTML SYN-RECV OPEN CONNECTIONS

Why are 78 SYN-RECV connections open on a Raspberry pi Apache web server? Here is an example [not the real IP addresses].

user@pizero:~> ss -aO
Netid  State     Recv-Q   Send-Q    Local Address:Port                  Peer Address:Port
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https       [::ffff:192.168.33.131]:3765
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https       [::ffff:192.168.35.156]:7058
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https        [::ffff:192.168.33.52]:55053
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https        [::ffff:192.168.32.15]:64241
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https        [::ffff:192.168.34.18]:28359
tcp    SYN-RECV  0        0     [::ffff:10.0.1.2]:https       [::ffff:192.168.32.109]:32137

The connections are from different client addresses on a Class B network. The SYN-RECV state means the web server is waiting for the client to complete the network connection. This is a normal 3-way TCP/IP handshake:

1. [Client] SYN ⏵     [Web Server]
2. [Client] ⏴ SYN-ACK [Web Server]
3. [Client] ACK ⏵     [Web Server]

This is an incomplete 2-way TCP/IP handshake resulting in a SYN-RECV connection state. These connections are timed out after 30 seconds.

1. [Client] SYN ⏵     [Web Server]
2, [Client] ⏴ SYN-ACK [Web Server]

It seems unlikely that 80 machines on the same network are sending SYN packets [8 packets/second] at the same time and not completing the handshake. More likely, a single machine is sending SYNs with forged source addresses and no intention of completing the handshake. This looks like a SYN flood attack.

Enabling SYN cookies has no effect. Installed UFW on the server and blocked these networks. Now it's whack-a-mole, blocking networks when they show up.

This could be caused by a misconfigured network. It could also be deliberate. The first rule in any competent ISP network administrator's internet facing router is to deny outbound packets with source addresses that are not from your own network. The second rule is to drop inbound packets when the source IP address is from the internal network. Here are the iptable rules to deny spoofed network addresses.

iptables -N spoofing
iptables -I spoofing -j LOG --log-prefix "Spoofed source IP"
iptables -I spoofing -j DROP

iptables -A INPUT -s 255.0.0.0/8 -j spoofing
iptables -A INPUT -s 0.0.0.8/8 -j spoofing

Here are the UFW rules to block networks sending the spoofed packets. IP addresses have been changed. Currently blocking 26 class B networks.

user@pizero:~> sudo ufw show added
ufw deny from 192.168.0.0/16 comment 'SYN-RECV'
ufw allow 80
ufw allow 443

dave@worldsworstwriter.org 2024-10-06