[YouHack]

Also @Ghazal, as an addition, I've seen a weird spanish server last saturday in sacnr monitor, it had 999/20 players ( Hosted by Ultra-H ) and was the first server in their list, and it was redirecting to another server which i don't remember its name.

[Peek]

Quote:

Originally Posted by Ghazal I've witnessed another attack from a guy who joined my server, said that it will be closed and advertised his own spanish server. After fire walling his ip and his server ip, his attack stopped. This might have nothing to do with the thread, but firewall the ips just in case. 81.40.48.119 142.44.134.4

I found a good protection against this type of attack:
https://sampforum.blast.hk/showthread.php?tid=169530
https://sampforum.blast.hk/showthread.php?tid=301568

Dude that's just someone spamming in your chat, chill...

[Ghazal]

Quote:

Originally Posted by Peek I found a good protection against this type of attack: https://sampforum.blast.hk/showthread.php?tid=169530 https://sampforum.blast.hk/showthread.php?tid=301568 Dude that's just someone spamming in your chat, chill...

He DDoSed the server, lol. Of course my server has an anti spam system and have administrators.

[rt-2]

Quote:

Originally Posted by adri1 Recopilation (i am not the author of those scripts) https://pastebin.com/raw/gWUq8hg1 https://pastebin.com/raw/jsp610qg https://github.com/SergiooES/sv-spoof-protection http://ubi.livs.pl/samp/samp_prot_ver1.zip https://github.com/Edresson/SAMP-Fir...er/Firewall.sh

I would like to compile this for windows but Imm not too familiar with C++ and I'm missing libraries, notably the netinet and phtread.h.

Thank you,
rt-2

[Ubi]

Please don't combine regular volumetric DDoS attacks with connection flood (cookie) and query flood in this thread.

Quote:

Originally Posted by Crystallize Me neither

It's up to you. I understand your fears.

Quote:

Originally Posted by Battlezone Could you at least hand the source code to a beta tester from the team so that he can check it and compile it at least for us?

I don't think they will do anything like that, but if someone from beta team is ready to recompile it, then I can provide him source. This plugin is very simple, but it affects internal SA-MP code. I don't want to ruin Kalcor's work by removing his limit and publishing source to everyone.. This can lead to massive attack bounces and self-ddoses.

Quote:

Originally Posted by rt-2 I would like to compile this for windows but Imm not too familiar with C++ and I'm missing libraries, notably the netinet and phtread.h.

This code is not for windows. You can't just "recompile" it. It should be ported first.

===================
As promised. I've finished Windows version. Again.. Please read README.txt.
http://ubi.livs.pl/samp/samp_prot_ver2.zip
Tested on:
Linux Debian 8 - SAMP 0.3.7-R2-1
Windows 10 Pro 64bit - SAMP 0.3.7-R2-1-1
//edit: Source: http://ubi.livs.pl/samp/samp_prot_ver2_s.zip

Enjoy. That's all.

[Ubi]

Virustotal as a confirmation: https://www.virustotal.com/#/file-an...UwMzkzNzc1OA==

[PrettyDiamond]

samp prot_ver2.zip doesnt works for me

Код:

[18:58:49] [connection] incoming connection: 67.36.39.152:45965 id: 6
[18:58:49] Warning: Minimum time between new connections (1000) exceeded for 117.43.172.74:30203. Ignoring the request.
[18:58:50] [connection] incoming connection: 73.119.219.154:32285 id: 7
[18:58:50] Warning: Minimum time between new connections (1000) exceeded for 94.249.233.247:23832. Ignoring the request.
[18:58:51] [connection] incoming connection: 167.107.4.227:61198 id: 8
[18:58:51] Warning: Minimum time between new connections (1000) exceeded for 62.241.143.163:57645. Ignoring the request.
[18:58:52] [connection] incoming connection: 179.55.127.184:27254 id: 9
[18:58:52] Warning: Minimum time between new connections (1000) exceeded for 85.102.239.40:26600. Ignoring the request.
[18:58:53] [connection] incoming connection: 134.14.174.72:27315 id: 0
[18:58:53] Warning: Minimum time between new connections (1000) exceeded for 82.136.220.242:47582. Ignoring the request.
[18:58:54] [connection] incoming connection: 141.188.131.68:21533 id: 1
[18:58:54] Warning: Minimum time between new connections (1000) exceeded for 122.206.54.60:63874. Ignoring the request.
[18:58:55] [connection] incoming connection: 59.139.49.176:50103 id: 2
[18:58:55] Warning: Minimum time between new connections (1000) exceeded for 12.106.137.89:37923. Ignoring the request.
[18:58:56] [connection] incoming connection: 128.15.1.168:43139 id: 3
[18:58:56] Warning: Minimum time between new connections (1000) exceeded for 176.124.92.145:17402. Ignoring the request.
[18:58:57] [connection] incoming connection: 64.81.5.60:42177 id: 4
[18:58:57] Warning: Minimum time between new connections (1000) exceeded for 188.169.169.115:45445. Ignoring the request.
[18:58:58] [connection] incoming connection: 46.216.188.150:55501 id: 5
[18:58:58] Warning: Minimum time between new connections (1000) exceeded for 188.238.41.89:44054. Ignoring the request.
[18:58:59] [connection] incoming connection: 14.162.152.71:30380 id: 6
[18:58:59] Warning: Minimum time between new connections (1000) exceeded for 16.67.8.231:20419. Ignoring the request.
[18:59:00] [connection] incoming connection: 207.21.101.129:49789 id: 7
[18:59:00] Warning: Minimum time between new connections (1000) exceeded for 205.203.177.20:8207. Ignoring the request.
[18:59:01] [connection] incoming connection: 174.102.107.206:10211 id: 8
[18:59:01] Warning: Minimum time between new connections (1000) exceeded for 72.10.226.181:6757. Ignoring the request.
[18:59:02] [connection] incoming connection: 87.215.141.127:39132 id: 9
[18:59:02] Warning: Minimum time between new connections (1000) exceeded for 190.107.123.238:5405. Ignoring the request.
[18:59:03] [connection] incoming connection: 71.155.28.51:38960 id: 0
[18:59:03] Warning: Minimum time between new connections (1000) exceeded for 166.89.59.153:15422. Ignoring the request.
[18:59:04] [connection] incoming connection: 81.233.241.60:53071 id: 1
[18:59:04] Warning: Minimum time between new connections (1000) exceeded for 76.79.67.230:9816. Ignoring the request.
[18:59:05] [connection] incoming connection: 159.199.148.224:102 id: 2
[18:59:05] Warning: Minimum time between new connections (1000) exceeded for 24.107.57.172:27083. Ignoring the request.
[18:59:06] [connection] incoming connection: 72.21.172.28:37489 id: 3
[18:59:06] Warning: Minimum time between new connections (1000) exceeded for 200.175.63.209:59501. Ignoring the request.
[18:59:07] [connection] incoming connection: 140.134.250.216:54066 id: 4
[18:59:07] Warning: Minimum time between new connections (1000) exceeded for 95.110.184.120:19855. Ignoring the request.
[18:59:08] [connection] incoming connection: 170.91.7.108:51967 id: 5
[18:59:08] Warning: Minimum time between new connections (1000) exceeded for 144.253.186.179:9336. Ignoring the request.
[18:59:09] [connection] incoming connection: 54.242.245.34:43377 id: 6
[18:59:09] Warning: Minimum time between new connections (1000) exceeded for 142.100.245.203:10219. Ignoring the request.
[18:59:10] [connection] incoming connection: 83.203.185.76:7124 id: 7
[18:59:10] Warning: Minimum time between new connections (1000) exceeded for 196.39.104.91:47262. Ignoring the request.
[18:59:11] [connection] incoming connection: 201.76.237.174:42558 id: 8
[18:59:11] Warning: Minimum time between new connections (1000) exceeded for 123.132.128.234:9879. Ignoring the request.
[18:59:12] [connection] incoming connection: 212.136.21.29:49769 id: 9
[18:59:12] Warning: Minimum time between new connections (1000) exceeded for 112.170.85.11:34112. Ignoring the request.
[18:59:13] [connection] incoming connection: 113.22.13.76:43630 id: 0
[18:59:13] Warning: Minimum time between new connections (1000) exceeded for 111.28.250.87:3272. Ignoring the request.
[18:59:14] [connection] incoming connection: 5.15.127.150:22936 id: 1
[18:59:14] Warning: Minimum time between new connections (1000) exceeded for 165.225.14.227:42270. Ignoring the request.
[18:59:15] [connection] incoming connection: 58.120.41.174:6961 id: 2
[18:59:15] Warning: Minimum time between new connections (1000) exceeded for 55.210.228.0:39949. Ignoring the request.

right now tested it

[Ubi]

Show me your config (server.cfg) file (without passwords ofc).

//edit: You probably disabled "concookies". Please enable it.

[Sew_Sumi]

Well, I suppose that took the spam out of the sails of those who were egging for an update... xD

[AMBEROUS]

yeah fix it

[adri1]

Quote:

Originally Posted by AMBEROUS yeah fix it

He basically said there's nothing to do...

[Paulice]

Quote:

Originally Posted by adri1 He basically said there's nothing to do...

Fight dirty or come out clean by cooperating with your provider, there's what you can do!

[denNorske]

Quote:

Originally Posted by Kalcor It may work slightly better for the hosted/internet list if the server name was cached, but I've always assumed most players are just firing up the server browser and connecting to a server in their favorites list, which is already cached locally. It's only new players looking for a server that are loading up the lists. When you open the server browser, the only connections it makes is to query the servers in your favorites list. It doesn't rely on sa-mp.com. Increasing the centralisation by caching lots of information on sa-mp.com actually makes it more vulnerable to attack. If all the data were centralised, if sa-mp.com closed at some point, the client wouldn't work anymore - which I don't think anyone wants.

Good point, but some sort of an adaptive way of doing this would be nice. Alternatives to the current method (which seems to be not working well at the moment) would at some point be necessary to get the functionality back on track

[fr0stG]

Quote:

Originally Posted by Kalcor It may work slightly better for the hosted/internet list if the server name was cached, but I've always assumed most players are just firing up the server browser and connecting to a server in their favorites list, which is already cached locally. It's only new players looking for a server that are loading up the lists. When you open the server browser, the only connections it makes is to query the servers in your favorites list. It doesn't rely on sa-mp.com. Increasing the centralisation by caching lots of information on sa-mp.com actually makes it more vulnerable to attack. If all the data were centralised, if sa-mp.com closed at some point, the client wouldn't work anymore - which I don't think anyone wants.

While I know this would be a consierable amount of work, maybe it's the only good way of mitigation..

Can you convert querying servers to use TCP instead of UDP to address spoofing issues? Or perhaps offer both as a fail-over if one is unresponsive/performing slowly? Here's a diagram showing what I mean, you could easily use Unix sockets to transfer data between the udp daemon and tcp query listener. (although would be different for Windows servers)



I know TCP can still be abused, but it can't be spoofed (assuming the attacker can't guess sequence numbers, which is near impossible), there's stuff like SYN attacks (halfopen), but those are easily mitigated by firewalls and SYN cookies. But there's advantages and disadvantages to using TCP and UDP. TCP is a more stateful protocol, so it's affected more by restrictive firewalls/NAT traversal. It might still be the only good choice to mitigate this.

I won't lecture you more since based on your post history, you're familiar with networking concepts. It's just an idea.

[wallee]

Quote:

Originally Posted by Kalcor It may work slightly better for the hosted/internet list if the server name was cached, but I've always assumed most players are just firing up the server browser and connecting to a server in their favorites list, which is already cached locally. It's only new players looking for a server that are loading up the lists. When you open the server browser, the only connections it makes is to query the servers in your favorites list. It doesn't rely on sa-mp.com. Increasing the centralisation by caching lots of information on sa-mp.com actually makes it more vulnerable to attack. If all the data were centralised, if sa-mp.com closed at some point, the client wouldn't work anymore - which I don't think anyone wants.

It sucks when somebody buys hosted tab and then his server doesn't show up there so if it's possible hosted tab should be "centralized" and other lists should stay the way they are.

[Kalcor]

Quote:

Originally Posted by fr0stG Can you convert querying servers to use TCP instead of UDP to address spoofing issues?

SYN cookies are not normally enabled and it requires kernel level access to enable them. I don't know that most sa-mp servers owners have root access. I've been concerned we'd just be replacing one type of flood for TCP SYN flood. A lot of the attackers aren't using spoofing but have actual botnets to flood with.

I could add SYN cookies to UDP, it's just that the end result is the same, just the returned packets are smaller.

There are some nice aspects to the fact that you can query a server in a single connectionless packet, especially from SA-MP's point of view when it has to query a whole bunch of servers for the internet/hosted list.

We'll see though. I think it's safe to disable the flood protection on the smaller query packets, which would make the attack less effective. But like I said, nothing I add to the server code can magically stop IP spoofing and packet floods.

[Ubi]

Quote:

Originally Posted by Kalcor You can disable it if you want but I wouldn't recommend it. That limit is there for a reason. The SA-MP server is answering those query requests which means the spoofed IPs are going to recieve traffic from your server when they never requested it. If your server sends packets to too many different IPs, eventually you'll get an abuse complaint. [...]

I know it and that's why I'm warning about it in README and posts here. Disabling the limit makes filtering such attacks easier, but server shouldn't be left without any firewall on-top (there's a risk of bouncing attack/self-ddos as you said). This attack is quite small, so there's only little traffic outgoing and that's why disabling limit works. Anyway it shouldn't be left as is.

You can add some kind of cookie system inside query mechanism, but it's still not ideal (as you said).

Quote:

Originally Posted by Kalcor I think it's safe to disable the flood protection on the smaller query packets, which would make the attack less effective. But like I said, nothing I add to the server code can magically stop IP spoofing and packet floods.

And that's what my plugin exactly does. Anyway config option should be added internally (like in source games etc.).

[fr0stG]

Quote:

Originally Posted by Kalcor SYN cookies are not normally enabled and it requires kernel level access to enable them. I don't know that most sa-mp servers owners have root access. I've been concerned we'd just be replacing one type of flood for TCP SYN flood. A lot of the attackers aren't using spoofing but have actual botnets to flood with. I could add SYN cookies to UDP, it's just that the end result is the same, just the returned packets are smaller. There are some nice aspects to the fact that you can query a server in a single connectionless packet, especially from SA-MP's point of view when it has to query a whole bunch of servers for the internet/hosted list. We'll see though. I think it's safe to disable the flood protection on the smaller query packets, which would make the attack less effective. But like I said, nothing I add to the server code can magically stop IP spoofing and packet floods.

I believe CentOS 6.x+ started enabling SYN cookies by default. This is a fresh CentOS 7 minimal install and it has it on already:

PHP код:

[root@ce5 sysctl.d]# sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1 


Not sure about other distros like Ubuntu, they'll probably have it disabled still.

And yes, you're right, since it's a kernel parameter, you'd need root access to enable it. Even if the user doesn't have root access (e.g non-virtualized KVM/Xen) then they could just ask their host to enable it for them. But the cases where it would not be enabled already is rare. Most hosts would enable SYN cookies by default since shared servers are more likely to be attacked.

I know there's other headaches that come with enabling SYN cookies and using TCP (like tuning the backlog, conntracking, and other junk) but at the end of the day it's still possible to mitigate via a firewall since you've got a legiitmate IP to block instead of spoofed nonsense.

Also another reason why removing the querylimit is a bad idea: like Kalcor stated, it sends traffic to hosts that never requested it. This could allow someone to create a small-scale UDP reflection attack using your SA-MP server. This technique has been used in the past to great effect with DNS amplification/reflection attacks (although DNS responses are MUCH larger than SA-MP server responses)

[Ubi]

Quote:

Originally Posted by fr0stG [...]Also another reason why removing the querylimit is a bad idea: like Kalcor stated, it sends traffic to hosts that never requested it. This could allow someone to create a small-scale UDP reflection attack using your SA-MP server. This technique has been used in the past to great effect with DNS amplification/reflection attacks (although DNS responses are MUCH larger than SA-MP server responses)

That's why I removed limit only for "i" and "p" requests which are relatively small. But this is still dangerous in some cases.

[silenthill]

The attack is forged and the attacker makes a request for each query [i, r, c, p] and a cookie connection revenue
by RDM: https://sampforum.blast.hk/showthread.php?tid=639963