Closed storm37000 closed 3 years ago
Thanks for the heads up. As it is, serversecure might not be able to extract the SteamIDs, but they seem easy to notice (most are obviously bad).
right now all the usernames are just empty strings, that can be blocked but it is extremely likely they can spoof those to random values.
I've checked this ULX GB addon and it seems to use the CheckPassword
hook, that's where that message is printed from. Following the trail back, it seems all this connection initialization stuff comes from a C2S_CONNECT
packet. Knowing this, I should now be able to extract SteamID and name. I could try replicating the Steam auth step so they are validated before it goes through all the Lua hooks but no promises.
Also, are you sure they're spoofed IP addresses? There seems to be a challenge before being able to start the connection. Can you provide some examples of these addresses?
I created a rate limit in that hook that worked back when the attack was much less advanced, when it only used 1 or 2 steam accounts. Each one was a different IP that was never repeated as far as i saw.
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
Client "unnamed" connected (24.160.196.83:39165).
Dropped unnamed from server ()
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
Client "unnamed" connected (214.253.174.103:21250).
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: dd SteamID 404310e0
S3: Duplicate client connection: UserID: dd SteamID 404310e0
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: dd SteamID 404310e0
S3: Duplicate client connection: UserID: dd SteamID 404310e0
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: dd SteamID 404310e0
S3: Duplicate client connection: UserID: dd SteamID 404310e0
Dropped unnamed from server ()
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
Client "unnamed" connected (220.134.224.115:31318).
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: de SteamID 404310e0
S3: Duplicate client connection: UserID: de SteamID 404310e0
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: de SteamID 404310e0
S3: Duplicate client connection: UserID: de SteamID 404310e0
[ULX GB] AUTHING PLAYER: WITH SteamID: STEAM_0:0:539068528
S3: Duplicate client connection: UserID: de SteamID 404310e0
S3: Duplicate client connection: UserID: de SteamID 404310e0
220.1.120.243:34808: password failed.
77.224.148.53:44091: password failed.
4.210.143.150:41882: password failed.
187.147.176.245:32998: password failed.
116.152.159.52:8663: password failed.
162.16.93.226:9065: password failed.
85.112.146.51:35152: password failed.
124.218.135.61:56724: password failed.
199.92.151.142:42598: password failed.
64.146.247.34:46686: password failed.
32.101.254.52:36784: password failed.
210.25.144.169:35230: password failed.
68.77.27.49:1380: password failed.
89.140.52.155:60633: password failed.
80.213.83.138:8147: password failed.
134.248.124.213:32317: password failed.
205.196.184.28:7084: password failed.
218.125.100.150:19582: password failed.
218.206.200.220:47094: password failed.
114.164.172.118:27720: password failed.
...
Only a very small portion of it Looked like it happened while that "unnamed" client was in the process of connecting, as it stopped when they finally timed out.
Thanks to help from @willox, I've got a better view of what's actually going on. They are "bypassing" the challenge and I now know how to improve it.
Created another release candidate for 1.5.37. This one uses a non-VALVe PRNG, hopefully seeded by a CSPRNG.
Seems to have stopped the attacks as ive watched it mitigate it with my own eyes.
Seems to be resolved.
New layer 7 ddos attack against the core srcds with join packets using spoofed IP addresses, steamids, and usernames. Many of the steamids are invalid and not real accounts. If this could be checked here and rejected that would likely fix the issue. Keeping it from getting to the lua hooks is important as that is where the actual disruptive lag occurs because of the rate.