they SYN as many of your ports and IPs, you send SYN-ACK to the spoofed IP destination, the destination knows it didnt SYN you and refuses to ACK the connection.
long TTL keeps the connection open longer, and it builds up to a DDOS for you when your ports are all half open.
depending on the real owner of the spoofed IP, they might blacklist your IP for spraying them with syn-ack.
?? I don't understand the conclusion to block incoming SYNs with TTL > 70... you're blocking all (even valid) connection attempts from users running other OS's that don't choose the default TTL of 64... like Windows, which I think uses 128.
> There will be up to around 100 connections to the web server in the SYN state, all with different IP addresses
Is that an actual problem though? 100 entries in a table is going to use a miniscule amount of RAM, a few kB at most.
And the solution to this (if you have way more than 100) is SYN cookies, which I think the Linux kernel at least will automatically enable when it detects it is under undue load.
6 comments
[ 13.1 ms ] story [ 244 ms ] threadAddress: 66.252.224.242 01000010.11111100.11100000. 11110010
Maybe a long forgotten server with some ancient malware that keeps being moved around...
Mysterious
attacker crafts packets with a forged return IP.
they SYN as many of your ports and IPs, you send SYN-ACK to the spoofed IP destination, the destination knows it didnt SYN you and refuses to ACK the connection.
long TTL keeps the connection open longer, and it builds up to a DDOS for you when your ports are all half open.
depending on the real owner of the spoofed IP, they might blacklist your IP for spraying them with syn-ack.
Is that an actual problem though? 100 entries in a table is going to use a miniscule amount of RAM, a few kB at most.
And the solution to this (if you have way more than 100) is SYN cookies, which I think the Linux kernel at least will automatically enable when it detects it is under undue load.