Weird Attack

[-XTC-]

A few days ago i recorded a small attack that looked something similar to this. ( failed to take down the server though :dance: )

0000  45 00 00 97 06 2a 40 00  6f 11 a2 fa 4e 04 4a ee   E....*@. o...N.J.
0010  4a 5b 7e e4 69 7d 69 87  00 83 00 00 fe ff ff ff   J[~.i}i. ........
0020  53 52 6f 75 72 63 65 20  45 6e 67 69 6e 65 20 51   SRource  Engine Q
0030  75 65 72 79 00 ff ff ff  ff 11 73 6f 75 72 63 65   uery.... ..source
0040  20 45 6e 67 69 6e 65 20  51 75 65 72 79 00 ff ff    Engine  Query...
0050  ff ff 54 53 6f 75 72 63  65 20 45 6e 67 69 6e 65   ..TSourc e Engine
0060  20 51 75 65 72 79 00 ff  ff 53 52 6f 75 72 63 65    Query.. .SRource
0070  20 45 6e 67 69 6e 65 20  51 75 65 72 79 00 ff ff    Engine  Query...
0080  ff ff 72 43 6f 75 72 63  65 20 45 6e 67 69 6e 65   ..rCourc e Engine
0090  20 51 75 65 72 79 00                                Query.

There was this and 2 other variant packets being spammed with small changes between each.
TTLs were all random, unique IPs with every packet, source port was always 27005 but that doesn't help since a majority of players connect from that port.
I'm not a fan of filtering by contents but that appeared necessary for this. If you host with a service that can filter by contents, i used the string "SRource Engine Query" since that was at the beginning of every packet.
If you run out of options I'd recommend hosting with NFO under a VDS, or VPS if that suits your needs. Their host system allows you to setup firewall rules as explained in an earlier post that will block this attack.

[rokrox]

[QUOTE=Hergs;39870530]We've tried blocking the IP's, but they keep changing. We even switched our own IP but this keeps happening :/. There doesn't seem to be a fix yet.[/QUOTE]

I said before the attack is reflected, it's abusing outdated servers.

[QUOTE=-XTC-;39876083]A few days ago i recorded a small attack that looked something similar to this. ( failed to take down the server though :dance: )

0000  45 00 00 97 06 2a 40 00  6f 11 a2 fa 4e 04 4a ee   E....*@. o...N.J.
0010  4a 5b 7e e4 69 7d 69 87  00 83 00 00 fe ff ff ff   J[~.i}i. ........
0020  53 52 6f 75 72 63 65 20  45 6e 67 69 6e 65 20 51   SRource  Engine Q
0030  75 65 72 79 00 ff ff ff  ff 11 73 6f 75 72 63 65   uery.... ..source
0040  20 45 6e 67 69 6e 65 20  51 75 65 72 79 00 ff ff    Engine  Query...
0050  ff ff 54 53 6f 75 72 63  65 20 45 6e 67 69 6e 65   ..TSourc e Engine
0060  20 51 75 65 72 79 00 ff  ff 53 52 6f 75 72 63 65    Query.. .SRource
0070  20 45 6e 67 69 6e 65 20  51 75 65 72 79 00 ff ff    Engine  Query...
0080  ff ff 72 43 6f 75 72 63  65 20 45 6e 67 69 6e 65   ..rCourc e Engine
0090  20 51 75 65 72 79 00                                Query.

There was this and 2 other variant packets being spammed with small changes between each.
TTLs were all random, unique IPs with every packet, source port was always 27005 but that doesn't help since a majority of players connect from that port.
I'm not a fan of filtering by contents but that appeared necessary for this. If you host with a service that can filter by contents, i used the string "SRource Engine Query" since that was at the beginning of every packet.
If you run out of options I'd recommend hosting with NFO under a VDS, or VPS if that suits your needs. Their host system allows you to setup firewall rules as explained in an earlier post that will block this attack.[/QUOTE]

It's a standard source query, if you block it players won't be able to query the server. You can rate limit it, but that's still not a great solution.

Has anyone actually tried the fix I posted? Set [b]net_splitpacket_maxrate[/b] to 1048576, that's the maximum. Srcds should handle all the invalid packets then. You can see from the results posted that the common values are like 8000. I've been running the maximum since this attack was common like a year ago, and I haven't had an issue with any of this.

[-XTC-]

My mistake. If you're using the default net_splitpacket_maxrate then your max udp packet size will be 2520, so you can drop anything with a length between 2521-65535

[Pantho]

[QUOTE=rokrox;39898482]I said before the attack is reflected, it's abusing outdated servers.

It's a standard source query, if you block it players won't be able to query the server. You can rate limit it, but that's still not a great solution.

Has anyone actually tried the fix I posted? Set [b]net_splitpacket_maxrate[/b] to 1048576, that's the maximum. Srcds should handle all the invalid packets then. You can see from the results posted that the common values are like 8000. I've been running the maximum since this attack was common like a year ago, and I haven't had an issue with any of this.[/QUOTE]

SRCDS sucks at handling packets though, it's still going to crash when flooded.

[TheDivinity]

My bullshit fix, and I am not saying it's going to work.

Half of the attack seems to be the console spam, right?

Reason I think that is I remember when I was getting hit by Devnull, I had the bright idea of turning net_showudp 1 on, and the console froze up, then forcefully restarted, which was dumb on my part.

Couldn't you block the net_getlong spam with enginespew, then only feel the affects of the network attack itself, which is a very low PPS, so it shouldn't affect you that much.

That was just my shit idea, never got to test it out, because I haven't been attacked in a long while by this sort of attack.

Also, think EngineSpew comes with Python's EPOE, if you are looking for it.

Edit:

hook.Remove("EngineSpew", "DRP_Console")

hook.Add("Think", "SHITBALLS", function()
	for i = 1, 50000, 1 do
		print("Net_GetLong SPAM")
	end
end)

timer.Simple(10, function()
	require("enginespew")
	
	hook.Add("EngineSpew", "DRP_Console", function()
		return false
	end)
end)

Shitty test, but I have no other way of testing.

Download Link: [url]http://TheD3vine.net/EngineSpew.zip[/url]

Thanks, Python.

This along with messing with net_ ConVars should atleast subside its effectiveness.

[hemirox]

[QUOTE=rokrox;39898482]I said before the attack is reflected, it's abusing outdated servers.

It's a standard source query, if you block it players won't be able to query the server. You can rate limit it, but that's still not a great solution.

Has anyone actually tried the fix I posted? Set [B]net_splitpacket_maxrate[/B] to 1048576, that's the maximum. Srcds should handle all the invalid packets then. You can see from the results posted that the common values are like 8000. I've been running the maximum since this attack was common like a year ago, and I haven't had an issue with any of this.[/QUOTE]

The original attack in the OP was with the default setting (15000) so 8000 shouldn't have bothered it. Since then I've tried setting it to the max, with no change.

I read up on dumpcap and started capturing packets. I just had an attack about 5:30pm Central. I managed to capture the packets. Heres the packet capture (openable in wireshark), I filtered out all the other traffic so all the packets should be from the attack. If anybody wants to check it out, be my guest.

[URL="https://dl.dropbox.com/u/1493617/newattack.pcapng"]Click[/URL]

[-XTC-]

This is the attack i mentioned in my first reply.

0000  00 16 3e 89 ce 58 fe ff  ff ff ff ff 08 00 45 00   ..>..X.. ......E.
0010  00 cc 00 01 00 00 78 11  78 eb 69 ea 9d a3 4a 5b   ......x. x.i...J[
0020  77 4c dc 4b 69 87 00 b8  55 a9 fe ff ff ff ff 87   wL.Ki... U.......
0030  06 6f 75 72 69 69 65 20  45 6e 62 69 6e 65 24 51   .ouriie  Enbine$Q
0040  76 66 73 78 00 43 ff ff  ff ff 85 16 6f 74 79 63   vfsx.C.. ....otyc
0050  65 20 45 6e 64 69 6e 69  21 51 76 66 73 78 00 ef   e Endini !Qvfsx..
0060  ff ff ff 18 33 6f 75 72  63 65 20 45 6e 67 69 6e   ....3our ce Engin
0070  65 29 52 75 65 72 77 00  ff ff ff ff 11 73 6f 75   e)Ruerw. .....sou
0080  72 63 65 20 45 6e 67 69  6e 65 20 51 75 65 72 79   rce Engi ne Query
0090  00 ff ff ff ff 54 53 6f  75 72 63 65 20 45 6e 67   .....TSo urce Eng
00a0  69 6e 65 20 51 75 65 72  79 00 ff ff 53 52 6f 75   ine Quer y...SRou
00b0  72 63 65 20 45 6e 67 69  6e 65 20 51 75 65 72 79   rce Engi ne Query
00c0  00 ff ff ff ff 72 43 6f  75 72 63 65 20 45 6e 67   .....rCo urce Eng
00d0  69 6e 65 20 51 75 65 72  79 00                     ine Quer y.      

Notice how "SRource Engine Query" is present.

Your server is hosted through NFO, they can probably filter these packets for you if you can't do it yourself.

[rokrox]

[QUOTE=-XTC-;39904829]This is the attack i mentioned in my first reply.

0000  00 16 3e 89 ce 58 fe ff  ff ff ff ff 08 00 45 00   ..>..X.. ......E.
0010  00 cc 00 01 00 00 78 11  78 eb 69 ea 9d a3 4a 5b   ......x. x.i...J[
0020  77 4c dc 4b 69 87 00 b8  55 a9 fe ff ff ff ff 87   wL.Ki... U.......
0030  06 6f 75 72 69 69 65 20  45 6e 62 69 6e 65 24 51   .ouriie  Enbine$Q
0040  76 66 73 78 00 43 ff ff  ff ff 85 16 6f 74 79 63   vfsx.C.. ....otyc
0050  65 20 45 6e 64 69 6e 69  21 51 76 66 73 78 00 ef   e Endini !Qvfsx..
0060  ff ff ff 18 33 6f 75 72  63 65 20 45 6e 67 69 6e   ....3our ce Engin
0070  65 29 52 75 65 72 77 00  ff ff ff ff 11 73 6f 75   e)Ruerw. .....sou
0080  72 63 65 20 45 6e 67 69  6e 65 20 51 75 65 72 79   rce Engi ne Query
0090  00 ff ff ff ff 54 53 6f  75 72 63 65 20 45 6e 67   .....TSo urce Eng
00a0  69 6e 65 20 51 75 65 72  79 00 ff ff 53 52 6f 75   ine Quer y...SRou
00b0  72 63 65 20 45 6e 67 69  6e 65 20 51 75 65 72 79   rce Engi ne Query
00c0  00 ff ff ff ff 72 43 6f  75 72 63 65 20 45 6e 67   .....rCo urce Eng
00d0  69 6e 65 20 51 75 65 72  79 00                     ine Quer y.      

Notice how "SRource Engine Query" is present.

Your server is hosted through NFO, they can probably filter these packets for you if you can't do it yourself.[/QUOTE]

There is no difference from these packets and normal source queries, if you filter the packets you're going to stop normal users from viewing your server as online. You can rate limit the packets, but that's not a solution. (Which I stated before.)

[hemirox]

Been talking to John (CEO of NFOServers), here was his response.

[quote]We have seen many such attacks against customers recently; it is a new attack vector that they are using which takes advantage of a vulnerability in the engine (a vulnerability in Garrysmod, and likely other OB games). I have added many filters to our routers to stop attacks that I've already seen, but they keep changing their attack vector slightly to compensate.[/quote]

Kinda odd that I've never experienced it before the last GMod update (update 159).

[rokrox]

[QUOTE=hemirox;39905555]Been talking to John (CEO of NFOServers), here was his response.

Kinda odd that I've never experienced it before the last GMod update (update 159).[/QUOTE]

The attack isn't new, it's been around for a while now.

[url]https://forums.alliedmods.net/showthread.php?t=192484[/url]
[url]http://facepunch.com/showthread.php?t=1232724[/url]

Dates back to August 10, 2012.

edit: But the method does seem to have changed, as the servers listed in the screenshots do not resolve to game servers. (not on standard ports anyway.)

[-XTC-]

[QUOTE=rokrox;39905450]There is no difference from these packets and normal source queries, if you filter the packets you're going to stop normal users from viewing your server as online. You can rate limit the packets, but that's not a solution. (Which I stated before.)[/QUOTE]

If you filter packets containing "SRource Engine Query" then you'll block the attack for a while. All the attacks i have received contain this string. I'm currently blocking this string without any issues.
If you filtered out "Source Engine Query" (notice the second R not present in Source) then yes, that would drop all queries to your server and make your server invisible.

[rokrox]

[QUOTE=-XTC-;39905769]If you filter packets containing "SRource Engine Query" then you'll block the attack for a while. All the attacks i have received contain this string. I'm currently blocking this string without any issues.
If you filtered out "Source Engine Query" (notice the second R not present in Source) then yes, that would drop all queries to your server and make your server invisible.[/QUOTE]

I didn't catch the R. But that would just be a matter of time until they change the string. Something like Divinity's fix seems to be a more stable approach, since the network traffic isn't what's taking the server offline but rather the console spam. (so it appears.)

[-XTC-]

In my experience it doesn't take much udp flooding to crash srcds, no matter what the contents is. The string would work for now until they read this thread or realize their attack is being dropped.
All of the attacks I have received only last a few seconds, so if you rate limit these packets your server would only be invisible for a short period.

[Pantho]

[QUOTE=Pantho;39864640]I thought they where just flooding fake queries? By which I mean if it's done properly there isn't a way to distinguish from real queries.[/QUOTE]

Why did the majority mark this as disagree, idiots.

NFO do have preset rules to block this ship. As do another host I know of but I forget the name :s. Anyway a few decent ones have rules in place to block or limit these popular attacks.

[rokrox]

[QUOTE=Pantho;40236444]Why did the majority mark this as disagree, idiots.

NFO do have preset rules to block this ship. As do another host I know of but I forget the name :s. Anyway a few decent ones have rules in place to block or limit these popular attacks.[/QUOTE]

You can block these with firewall rules without NFO either way, it's not like the line is being saturated.

[Pantho]

[QUOTE=rokrox;40248809]You can block these with firewall rules without NFO either way, it's not like the line is being saturated.[/QUOTE]

Didn't notice there was 4 weeks before the post, woops.

But yea, you can in linux anyway. Not sure how you'd block this on a windows server OS without buying some silly priced software.

[TheDivinity]

As stated in another post, ServerSecure is another solution.

[rokrox]

[QUOTE=Pantho;40249027]Didn't notice there was 4 weeks before the post, woops.

But yea, you can in linux anyway. Not sure how you'd block this on a windows server OS without buying some silly priced software.[/QUOTE]

[url]http://en.wikipedia.org/wiki/IPCop[/url] or [url]http://www.pfsense.org/[/url] would be viable solutions for windows.

[QUOTE=TheDivinity;40249042]As stated in another post, ServerSecure is another solution.[/QUOTE]

And plugins.