@AuroraZero said:
Yeah most modern kernels have this on by default.
sysctl -w net.ipv4.tcp_syncookies=1
Prevent half open connections not a real fix but helps to not waste resources.
The real fix is this:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Drop invalid packets that do not make sense in the context of a real connection.
Sorry for the formatting on mobile and doing 100 things at one time I apologise.
See, only experienced guys do 100 things at once, todlers get stuck at 98.
So, may I step in and help, so you can advance to 101 things to do at once ? :
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
I would do this:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -j DROP
@AuroraZero said:
Yeah most modern kernels have this on by default.
sysctl -w net.ipv4.tcp_syncookies=1
Prevent half open connections not a real fix but helps to not waste resources.
The real fix is this:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Drop invalid packets that do not make sense in the context of a real connection.
Sorry for the formatting on mobile and doing 100 things at one time I apologise.
Don't think that actually helps. Maybe I wasn't entirely clear about what I am worried about. Not so much worried about the resource consumption on my own server, but about the server being used in the attack to amplify the (spoofed) traffic (by a factor of 5 - i.e. for each spoofed SYN packet, the server sends 5 SYN-ACK packets).
Comments
Yeah most modern kernels have this on by default.
sysctl -w net.ipv4.tcp_syncookies=1
Prevent half open connections not a real fix but helps to not waste resources.
The real fix is this:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Drop invalid packets that do not make sense in the context of a real connection.
Sorry for the formatting on mobile and doing 100 things at one time I apologise.
See, only experienced guys do 100 things at once, todlers get stuck at 98.
So, may I step in and help, so you can advance to 101 things to do at once ?
:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
I would do this:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -j DROP
Host-C | Storage by Design | AS211462
“If it can’t guarantee behavior under load, it doesn’t belong in production.”
Don't think that actually helps. Maybe I wasn't entirely clear about what I am worried about. Not so much worried about the resource consumption on my own server, but about the server being used in the attack to amplify the (spoofed) traffic (by a factor of 5 - i.e. for each spoofed SYN packet, the server sends 5 SYN-ACK packets).
My mistake
Strict rp filters
Lower synak retries
Optional rate limit your synack
The only thing you can do is to disable SYN-ACK retransmission, i.e. by changing
net.ipv4.tcp_synack_retriesto0Check our KVM VPS plans in 🇵🇱 Warsaw, Poland and 🇸🇪 Stockholm, Sweden