1

I'm running a service at a given port (let's say 1234). From time to time it's not reachable. When I check dmesg I see:

TCP: Possible SYN flooding on port 1234. Sending cookies. Check SNMP counters

net.ipv4.tcp_max_syn_backlog is set to 1024

When I check netstat I see:

tcp 0 0 exampledomainname.com:5008 ip190-5-138-234.i:56772 SYN_RECV
tcp 0 0 exampledomainname.com:5008 ip190-5-138-234.i:56771 SYN_RECV
tcp 0 0 exampledomainname.com:1234 216.218.222.14:18687 SYN_RECV
tcp 0 0 exampledomainname.com:1234 185.234.218.50:59848 SYN_RECV
tcp 0 0 exampledomainname.com:1234 tor-exit.r2.apx.p:45992 SYN_RECV
tcp 0 0 exampledomainname.com:1234 tor-exit1.signal.:42747 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:29545 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:19883 SYN_RECV
tcp 0 0 exampledomainname.com:1234 5.188.86.30:53106 SYN_RECV
tcp 0 0 exampledomainname.com:1234 lh28409.voxility.:59899 SYN_RECV
tcp 0 0 exampledomainname.com:1234 tor-exit1.signal.:40048 SYN_RECV
tcp 0 0 exampledomainname.com:1234 62.176.4.10:48546 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:52326 SYN_RECV
tcp 0 0 exampledomainname.com:1234 sunfire-cape.gate:44592 SYN_RECV
tcp 0 0 exampledomainname.com:1234 sunfire-cape.gate:44590 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chomsky.torserver:45374 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:60156 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:47522 SYN_RECV
tcp 0 0 exampledomainname.com:1234 tor-exit.r2.apx.p:38568 SYN_RECV
tcp 0 0 exampledomainname.com:1234 chulak.enn.lu:34309 SYN_RECV
tcp 0 0 exampledomainname.com:1234 185.100.86.128:35623 SYN_RECV
tcp 0 0 exampledomainname.com:1234 tor-exit1.signal.:42921 ...

around 30 of these SYN_RECV connections. If my assumption is correct it seems to be a pretty sophisticated bot-net which goes through Tor network.

What can I do against such an attack? Any help would be highly appreciated.

user994612
  • 35
  • 5

2 Answers2

0

There are numerous possible methods for mounting an effective defence against DDOS attacks. Most involve analysis of network traffic, but a distinction is made between profiles of 'known' attacks/techniques that the defence software will be able to match against, novel attacks that cause irregular activity, and profiles of healthy activity.

It goes without saying that an effective defence would depend upon the tools you have available and the systems you are using. Perhaps this video could give you some ideas.

https://www.youtube.com/watch?v=AqY3UxXyQTY

Leo Naylor
  • 13
  • 2
  • thank you for your answer.. unfortunately I'm on a VPS with root access without possibility to 'buy in and install' more hardware. – user994612 Jan 22 '18 at 21:52
0

You may want to implement SYNPROXY iptables rules, which would perform the 3WHS before adding a conntrack entry, the one it is saturating when you are under synflood attack.

I personnaly tested and can confirm it does work. This is an explanation from the Red Hat developper who pushed SYNPROXY in the linux kernel : https://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/#more-273

From the article :

sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack
iptables -A INPUT -i $DEV -p tcp -m tcp –dport $PORT -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m state --state INVALID -j DROP
sysctl -w net/ipv4/tcp_timestamps=1

Note that if you need to use NAT, there are some changes to do because of NAT using conntrack and SYNPROXY blocking conntrack on first packets.

If you need it, I've some scripts somewhere where I solved the issue (it just would take some time to find them).

Edit : basically, you'd need to move nat of tcp flows from -t nat -A PREROUTING to -t nat -A OUTPUT

setenforce 1
  • 186
  • 3
  • Sadly, this is not a correct solution for me. I have set it up as described. Used 'eth0' instead of $DEV. DDoS can still take me out. – user994612 Jan 28 '18 at 14:58