I can confirm this as an issue. A couple of days ago, I was hit by this kind of attack with the UDP payload length of 1400. It seems that the attacker is spoofing the IP address of the victim (my.ip.address.here) and send out some query to the gameservers. Then they reply to the spoofed IP address (my.ip.address.here) and therefore they fill up my pipes with large amounts of incoming bandwidth causing denial of service. I don't know if this issue can be resolved in some way, but it would be great if Valve could have a look on what's happening. Sadly, I don't have any info on the payload of these packets. As you can see below, the packets have different destination ports (UDP port 80 and 27015), but that makes no sense as it's still causing denial of service.
-- 00:40:40.684970 IP 80.72.41.210.27228 > my.ip.address.here.80: UDP, length 1400 00:40:40.684975 IP 80.72.41.210.27228 > my.ip.address.here.80: UDP, length 1400 00:40:40.684979 IP 80.72.41.210.27228 > my.ip.address.here.80: UDP, length 300 00:40:40.684986 IP 94.23.245.111.27069 > my.ip.address.here.80: UDP, length 1400 00:40:40.684991 IP 94.23.245.111.27069 > my.ip.address.here.80: UDP, length 250 00:40:40.684994 IP 188.212.105.122.27015 > my.ip.address.here.80: UDP, length 1400 00:40:40.684999 IP 188.212.105.122.27015 > my.ip.address.here.80: UDP, length 611 00:40:40.685002 IP 5.39.44.62.28009 > my.ip.address.here.80: UDP, length 1426 00:40:40.685007 IP 5.39.44.62.28009 > my.ip.address.here.80: UDP, length 276 00:40:40.685838 IP 200.58.100.36.22033 > my.ip.address.here.80: UDP, length 1400 00:40:40.685867 IP 200.58.100.36.22033 > my.ip.address.here.80: UDP, length 611 00:40:40.685871 IP 77.37.144.20.27777 > my.ip.address.here.80: UDP, length 1400 00:40:40.685876 IP 77.37.144.20.27777 > my.ip.address.here.80: UDP, length 320 00:40:40.685892 IP 188.120.236.19.27017 > my.ip.address.here.80: UDP, length 1400 00:40:40.685898 IP 188.120.236.19.27017 > my.ip.address.here.80: UDP, length 594 00:40:40.685901 IP 93.191.11.143.27024 > my.ip.address.here.80: UDP, length 1400 00:40:40.685906 IP 93.191.11.143.27024 > my.ip.address.here.80: UDP, length 420 00:40:40.689231 IP 83.222.115.18.27003 > my.ip.address.here.80: UDP, length 1400 00:40:40.689236 IP 83.222.115.18.27003 > my.ip.address.here.80: UDP, length 350 00:40:40.689245 IP 46.174.48.44.27230 > my.ip.address.here.80: UDP, length 1400 00:40:40.689251 IP 46.174.48.44.27230 > my.ip.address.here.80: UDP, length 605 00:40:40.689274 IP 83.222.97.200.27223 > my.ip.address.here.80: UDP, length 1400 00:40:40.689279 IP 83.222.97.200.27223 > my.ip.address.here.80: UDP, length 376 00:40:40.689297 IP 94.236.237.125.27019 > my.ip.address.here.80: UDP, length 1400 00:40:40.689303 IP 94.236.237.125.27019 > my.ip.address.here.80: UDP, length 318 00:40:40.689307 IP 89.231.6.6.27024 > my.ip.address.here.80: UDP, length 1400 00:40:40.689311 IP 89.231.6.6.27024 > my.ip.address.here.80: UDP, length 1238 00:40:40.689320 IP 217.73.17.23.27018 > my.ip.address.here.80: UDP, length 1400 00:40:40.689324 IP 91.231.140.105.27015 > my.ip.address.here.80: UDP, length 1400 00:40:40.689329 IP 91.231.140.105.27015 > my.ip.address.here.80: UDP, length 332 00:40:40.689332 IP 217.73.17.23.27018 > my.ip.address.here.80: UDP, length 1400 00:40:40.689337 IP 217.73.17.23.27018 > my.ip.address.here.80: UDP, length 179 00:40:40.689345 IP 46.50.235.91.27129 > my.ip.address.here.27015: UDP, length 1400 00:40:40.689351 IP 46.50.235.91.27129 > my.ip.address.here.27015: UDP, length 406 00:40:40.689388 IP 91.204.161.38.27035 > my.ip.address.here.80: UDP, length 1400 00:40:40.689400 IP 91.204.161.38.27035 > my.ip.address.here.80: UDP, length 484 00:40:40.689415 IP 188.212.107.72.27015 > my.ip.address.here.80: UDP, length 1400 00:40:40.689422 IP 188.212.107.72.27015 > my.ip.address.here.80: UDP, length 497 00:40:40.689426 IP 217.26.171.227.27015 > my.ip.address.here.80: UDP, length 1400 00:40:40.689430 IP 217.26.171.227.27015 > my.ip.address.here.80: UDP, length 751 -- By the way, the console of server I'm running at port 27015 is flooded with messages like these (which causes CPU lag): -- NET_GetLong: Split packet from 188.212.107.30:27015 with invalid split size (number 99/ count 18) where size 24436 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 109.163.232.151:27015 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 109.163.232.151:27015 with invalid split size (number 48/ count 18) where size 29440 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 200.43.192.233:27021 with invalid split size (number 118/ count 18) where size 29807 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 80.93.184.193:27015 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 80.93.184.193:27015 with invalid split size (number 118/ count 18) where size 24927 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 193.104.68.46:27021 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 193.104.68.46:27021 with invalid split size (number 95/ count 18) where size 25441 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 64.74.97.104:27015 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 64.74.97.104:27015 with invalid split size (number 101/ count 18) where size 25964 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 85.95.164.36:27019 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 85.95.164.36:27019 with invalid split size (number 114/ count 18) where size 16500 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 147.32.127.225:27018 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 147.32.127.225:27018 with invalid split size (number 109/ count 18) where size 24432 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 91.82.84.189:27060 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 91.82.84.189:27060 with invalid split size (number 115/ count 18) where size 24438 is out of valid range [564 - 1248 ] NET_GetLong: Split packet from 92.62.226.97:27016 with invalid split size (number -1/ count 2) where size -1 is out of valid range [564 - 1248 ] -- Best regards Oskar Levin [email protected] -----Ursprungligt meddelande----- Från: [email protected] [mailto:[email protected]] För LocalStrike | Live your game! Skickat: den 4 augusti 2012 04:50 Till: Half-Life dedicated Linux server mailing list Ämne: [hlds_linux] New 1.6 Exploit very dangerous! i read this from a forum and at this time we have the same situation here! please we need a fix asap! -- I am writing to inform you about a new very dangerous exploit in the HLDS engine. Briefly, the exploit allows the attacker to send packets over every hlds server to a predefined destination. This way all HLDS servers make an unstoppable "botnet" which can attack the destination which is chosen. The attack originally started a month and a half ago in Bulgaria, and since then many big server chains are attacked and still no solution is found. The attack is so strong that even Internet Service Providers say that it harms the connection of their users near the hlds server location. Explaination of the attack: We know that the attack is made through the UDP protocol from hundreds of IPs that are real counter strike 1.6 servers (hlds). It comes from the server port, and almost always hits port 27005. The most common length of the packets is 1400, but there are also less packets with different length. However, there is no point in dropping the packets with this length because the whole international and inbound channels are filled and the server still cannot be reached. Also the HEX of the packets contains a part of the server configuration. I've noticed a packet which HEX prints "You have been banned from this server!". This makes me think that some bot connects to a chosen server and makes the server send a UDP packet to the predefined destination. We've managed to log full information of the attack. I have 15 gigabytes of logs with this attack which are made for only 10 minutes. I will attach a short part of my logs, and some other logs from other server administrators who have experienced the same attack. One of the server administrators says: "I am writing to say that I have received the same attack against my machines and since I work as a system administrator in coorporate hosting company, my machines are colocated in the company's server room, with this I want to say that my resources are a lot bigger than my mate @talibana's and I managed to localize the attack or at least I think so. The flood was directed to UDP port 27005, after a while the enourmous flood managed to fill my international channel and I had to work jointly with our ISP, after I asked them to block port 27005 only 4 ip addresses started to show on my machine, 3 of which were Russian and 1 Greek, which didn't make a lot of traffic or big number of packets, just to say they were "listening" to the final point - my IP address. After I have blocked these IPs from the routing machine (Gateway) the flood totally dissapeared." And also: "We talk about a vurnarability in the Engine, which allows the generation of packets from unauthorized people, which are being sent where the 'bad guy' wants." The above "story" was sent to Valve, with a view of finding a solution to the problem. Since the attack reached its peak we can't just wait, watching our servers getting ruined. I post this topic so that more experienced people can say what they think and to figure out what kind of attack it is together so that a fix could be implemented. You can dowload logs and other things at the end of the post. I will update this post with the most recent information about the attack. A small discovery: A system administrator noticed that HLSW is receiving exactly the same packets, as the flooder sends from other HL1 servers to the "victim". This packet cotains information about the server vars and mod information. We think that this is the same packet which can be send to every server to request the info. (A2S_INFO) The question that appears is how the attacker manages to request this information from the infected servers and forward it to a specified ip adress? What we tried ? We tried to stop the international traffic which "solved" the problem with 1400 length packets, but another flood appeared which attacks the server ports (27015/6/7..): Logs and pics: A very short part of the flood attack (40 mb) - http://www.multiupload.nl/7ECR925FM2 Traffic extreme: http://desmond.imageshack.us/Himg228/scale...amp;res=landing I really hope that here we will find solution! If you have any questions I will tell you what you want. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
