@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).
Yeah, lowering SYN-ACK retries is the most practical fix here: sysctl -w net.ipv4.tcp_synack_retries=1
Default is 5, which means 5x amplification. Setting it to 1 won't eliminate the problem but cuts the amplification significantly. Legit clients will retry anyway if they miss the first one.
As for rp_filter – it helps if you're a router/ISP, but on a regular VPS the packets already passed through your provider's network, so not much you can do there.
The real solution (BCP38) needs to happen upstream at ISPs who should drop spoofed packets at the source. But we don't live in that perfect world yet.
RareCloud.io — High-Performance VPS in EU / US / JP / HK
Affordable deals • Fast NVMe • Reliable network
@rarecloud said: The real solution (BCP38) needs to happen upstream at ISPs who should drop spoofed packets at the source. But we don't live in that perfect world yet.
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
Yeah, lowering SYN-ACK retries is the most practical fix here:
sysctl -w net.ipv4.tcp_synack_retries=1Default is 5, which means 5x amplification. Setting it to 1 won't eliminate the problem but cuts the amplification significantly. Legit clients will retry anyway if they miss the first one.
As for rp_filter – it helps if you're a router/ISP, but on a regular VPS the packets already passed through your provider's network, so not much you can do there.
The real solution (BCP38) needs to happen upstream at ISPs who should drop spoofed packets at the source. But we don't live in that perfect world yet.
RareCloud.io — High-Performance VPS in EU / US / JP / HK
Affordable deals • Fast NVMe • Reliable network
Do I agree to that.
I mean, no comment on some up-streams........
Host-C | Storage by Design | AS211462
“If it can’t guarantee behavior under load, it doesn’t belong in production.”