Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Getting DDoS on OVH network from spoofed IPs
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Getting DDoS on OVH network from spoofed IPs

o_be_oneo_be_one Member
edited August 2020 in Help

Hey community,

i'm not that into networks (meaning i'm quite noob with that :D) but i've tried to understand attacks i had on a game server. I'm hosted at OVH and most bad traffic is mitigated, but some are not since they look legit to OVH (or they use a trick to not go into VAC like someone told me). Since it's not a big traffic, i can handle it on server side. The game is TeeWorlds (ddnet.tw exactly).

This attaks comes from spoofed IPs, so it's not possible to clear the traffic related to attacking ip... I wanted to filter packets content so i can throttle or rate limit or whatever but sounds like it will not help at all. A friend talks about XDP but can't use in VPS (kvm) and also not sure it would help any further.

So, what's your advices? I've ordered an i3d.net dedicated just to try another network than OVH and also to try this renown provider in gaming industry and also to be able to try XDP.

This is a part of the spoofed ip addresses (first column is number of occurences of the same ip):
4 116.202.33.203 4 116.202.21.67 4 116.202.197.229 4 109.94.163.80 4 109.94.163.73 4 109.94.163.223 4 109.94.163.214 4 109.94.162.59 4 109.94.162.241 4 109.94.161.90 4 109.94.161.199 4 109.94.161.162 4 109.94.161.136 4 109.94.160.59 4 109.91.88.36 4 109.91.82.190 4 109.91.196.58 4 109.90.61.145 4 109.90.226.80 4 109.90.148.114 4 109.85.99.186 4 109.85.214.171 4 109.85.189.219 4 109.84.174.253 4 109.84.161.183 4 109.84.127.7 4 109.75.99.82 4 109.75.99.70 4 109.75.99.50 4 109.75.92.234 4 109.75.91.202 4 109.75.88.58 4 109.75.87.135 4 109.75.85.220 4 109.75.84.138 4 109.75.83.74 4 109.75.29.80 4 109.75.27.14 4 109.75.24.155 4 109.75.223.107 4 109.75.221.104 4 109.75.220.24 4 109.75.218.187 4 109.75.218.135 4 109.75.216.74 4 109.75.214.221

This is the content of packets (all is random, just fstd and gie3 are not):
23:35:09.479501 IP 192.129.45.186.30482 > X.X.X.X.8303: UDP, length 15 E..+k.....gn..-.....w. o..D...........fstdE 23:35:09.479647 IP 192.109.206.146.48141 > X.X.X.X.8303: UDP, length 15 E..+k.....(..m........ o....xe........gie3. 23:35:09.479744 IP 192.109.206.146.48141 > X.X.X.X.8303: UDP, length 15 E..+k.....(..m........ o..;...........fstdi 23:35:09.479776 IP 192.109.206.146.48141 > X.X.X.X.8303: UDP, length 15 E..+k.....(..m........ o..*.xe4H......gie3. 23:35:09.479825 IP 188.138.65.222.52713 > X.X.X.X.8303: UDP, length 15 E..+MT........A....... o..0.xe........gie3. 23:35:09.479824 IP 192.109.206.146.48141 > X.X.X.X.8303: UDP, length 15 E..+k.....(..m........ o..............fstd. 23:35:09.479882 IP 188.138.65.222.52713 > X.X.X.X.8303: UDP, length 15 E..+MV........A....... o.............fstd.
23:35:09.479942 IP 188.138.65.222.52713 > X.X.X.X.8303: UDP, length 15
E..+MW........A....... o..h.xe........gie3.
`

Thanks a lot for your help!

Comments

  • stefemanstefeman Member
    edited August 2020

    post tcpdump if possible. (file that can be opened with wireshark).

    if it passes OVH, you need to block it manually. Either via default policy or hex string rule or xdp.

    or if u want the easy solution, pick something like x4b remote protection.

  • @stefeman said:
    post tcpdump if possible. (file that can be opened with wireshark).

    if it passes OVH, you need to block it manually. Either via default policy or hex string rule or xdp.

    or if u want the easy solution, pick something like x4b remote protection.

    Well it's already tcpdump parts i've put as "code" (so you have packet contents and spoofed ips example), and since it spoofed your answer is not relevant here i think ^^. Also blocking ips or string will not help as well. I think it's more about if is there a way to block spoofed ips but it's something on OVH network side i guess. Maybe some people had this experience in the past and found a solution to share.

  • SplitIceSplitIce Member, Host Rep

    If you are interested we provide remote mitigation services. No need to order a new server (although you will want to order a new, clean IP from OVH).

  • stefemanstefeman Member
    edited August 2020

    @o_be_one said:

    @stefeman said:
    post tcpdump if possible. (file that can be opened with wireshark).

    if it passes OVH, you need to block it manually. Either via default policy or hex string rule or xdp.

    or if u want the easy solution, pick something like x4b remote protection.

    Well it's already tcpdump parts i've put as "code" (so you have packet contents and spoofed ips example)

    What you shared is worthless compared to full tcpdump file of the attack.

    It looks like "UDPBypass" from "qbot" which is literally this.

    https://pastebin.com/raw/1zcHksMR

    and since it spoofed your answer is not relevant here i think ^^.
    Also blocking ips or string will not help as well.

    How is would be not relevant? You can still block it with default policy or based on hex. and its even easier if they hit random destination ports rather than a single open one which you need.

    I think it's more about if is there a way to block spoofed ips but it's something on OVH network side i guess. Maybe some people had this experience in the past and found a solution to share.

    As long as there are hosts like Creanova and Host-unlimited, that do not follow bcp38 this cancer exists.

    As for how to block this specific attack. Well, you shared very little packet info of the overall attack, but I assume its mostly random data hitting random ports mostly, so go by this.

    iptables -P input DROP; iptables -P FORWARD DROP; iptables -P OUTPUT ACCEPT;

    Then simply accept the service ports you actually need manually such as SSH and gameserver ports and clientports.

    At the end you should have 5-25 ports out of 65k ports open, so when that same attack happens 99% of it will be just dropped rather than hitting service ports.

    If they target a specific open port after that same attack fails to bring the services down, you can apply A2S rules, enable SYN Proxy, and block hex values, and even enable interrupt coalescing to save some CPU power as you do that stuff.

    Maybe you should just outsource that stuff to remote-ddos providers if you think its impossible though.

    if its UDP 8303 and you run Teeworlds server, ideal situation would be measuring what normal traffic length looks like with tcpdump and only allow that range.

    Thanked by 1o_be_one
  • hzrhzr Member

    @o_be_one said: Well it's already tcpdump parts i've put as "code" (so you have packet contents and spoofed ips example), and since it spoofed your answer is not relevant here i think ^^. Also blocking ips or string will not help as well. I think it's more about if is there a way to block spoofed ips but it's something on OVH network side i guess. Maybe some people had this experience in the past and found a solution to share.

    The ascii-converted version (with lots of ..... for nonprintable characters) is pretty much a complete loss of packet contents, btw.

    Thanked by 1o_be_one
  • @stefeman said: At the end you should have 5-25 ports out of 65k ports open, so when that same attack happens 99% of it will be just dropped rather than hitting service ports.

    Only tcp 22 and udp 8303 are open (OVH firewall side). All attacks comes from random ips and ports (each one does 4 requests only) and goes to server_ip:8303.
    Packets contain random strings, only it ends everytime by fstd or gie3, which are used by TeeWorlds for server info queries iirc. Packets length are always the same (and i already filter some). Thanks a lot for taking time to offer a complete answer.

    @SplitIce said:
    If you are interested we provide remote mitigation services. No need to order a new server (although you will want to order a new, clean IP from OVH).

    Unfortunately out of budget (non profit stuff)

  • jbuggiejbuggie Member
    edited August 2020

    Sound like you are getting UDP flood attack...a type of DOS. There isn't much that you could do at the network level on your server since they are crafted to be valid server queries. The appropriate solution must be at the application level: the server needs to identify valid requests and silently drop all others without normal ICMP response.
    With a big enough pipe though, the attacker can overwhelm any defense on a single server.

    Thanked by 1o_be_one
Sign In or Register to comment.