Re: [hlds_linux] Overflow attack to Source servers
Thanks for the information, I wasn't aware of that. I guess iptables is out of the question, then. On 06/15/2012 02:37 PM, Asher Baker wrote: Commands are just packaged into the regular game packets, you couldn't filter them out specifically with a firewall without it processing the whole packet. String matching also wouldn't work as the data is bit (rather than byte) aligned. Sent from my iPhone On 15 Jun 2012, at 17:49, David Parker wrote: I should clarify... Using an iptables rule like that assumes that the status request packets are always the same size, and they are a different size than the normal game data packets. You can also do string matching within packets using iptables (if you have the appropriate modules installed), but on a game server, that would probably add so much processing overhead it's not even worth it. - Dave On 06/15/2012 12:40 PM, David Parker wrote: I guess one way Valve could solve this would be to change the way "status" works on the client. They could have the server send server-state information to the clients at some interval, like once per second, or perhaps each time something changes (player joins or leaves, map changes, etc.) and then have the "status" command on the client just read its most recent data. That would prevent status requests from hitting the server at all. It adds some overhead compared to the real-time request/reply method, but it eliminates the need to process each status request that comes in. Or, if the incoming "status" packets are always the same size, you could also use iptables to rate-limit them (just replace N with the packet size in bytes): iptables -A INPUT -p udp -m length --length N -m limit --limit 3/s -j ACCEPT (Note: I didn't test this iptables rule, I just slapped it together as a demonstration) - Dave On 06/14/2012 03:06 PM, Alvaro Gutierrez Lorenzo wrote: I don't think it's still a popular attack, since it is only useful when you can't ban in an effective way the attacker (e. g. Free-to-Play scheme). I dont think it's a widely known attack, on my case it was just a single person who was attacking all our servers, as we verified comparing IPs. What I would suggest you to do is to have SMAC (Sourcemod anti-cheat) command monitor plugin running, and from time to time (or everytime find there are lag issues) check this plugin's logs (called cmd_[date].log, under the Sourcemod's log directory) to see if someone is attacking you by this means. It's easy to spot even without actually opening the log file, a usual day log will not grow over 1MB while when you have been attacked the log will easily reach 300Mb (I've seen>3Gb log files on my server because of this). Inside it looks like thousands of lines stating "[date]: Console<0> executes: status" during a single second. If you ever spot this attack, then you could take this measure to stop it. Meanwhile, I would not take much care, since it's easy and quick to solve (thanks to the people on this mailing list, thank you all again ;) ). El 14/06/2012 20:46, doc escribió: Kind of a scary thread, I do a lot of terrible data collection on my own server/website using the "status" command and I'd hate to have to alias it to nothing to avoid problems like this. Is this something I assume is important enough to look into? On Wed, Jun 13, 2012 at 5:40 AM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: It worked perfectly! Simple attack, simple solution. Never thought of this ways, now it seems so obvious XD I made plugins and searched for the most strange ways of solving it, yet it was "single-line" simple ^^ Well, it disables status, but that's a minimal sacrifice (SMAC provides a secure alternative also, so there's no problem at all). I will spread this through the servers I know: each and every one is victim of this issue, that makes over a dozen grateful servers& communities, many thanks ^^ I've checked this happens without any mods, so some official attention on this would be the perfect happy ending, but this workaround solves the problem so everything fine! El 13/06/2012 4:04, 1nsane escribió: While not a good solution at all. Have you tried aliasing status to nothing? "alias status" This will obviously disable the status command entirely. But perhaps it won't kill the server then? On Tue, Jun 12, 2012 at 7:49 PM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com>wrote: Sorry for the "double mail", I just though that if the fix for that removed the cooldown time for status, there would be no protection over this command, making possible this attack. Invalid Protocol mentionned this protection on an earlier mail. Is it a silly idea? I've never experienced such cooldown protection, that would explain why. El 13/06/2012 1:31, Joe Brown escribió: This was used (and may still be) in hacks as a way to stop admins from using the status command to see your STEAMID in the client console. Spamming it
Re: [hlds_linux] Overflow attack to Source servers
Commands are just packaged into the regular game packets, you couldn't filter them out specifically with a firewall without it processing the whole packet. String matching also wouldn't work as the data is bit (rather than byte) aligned. Sent from my iPhone On 15 Jun 2012, at 17:49, David Parker wrote: > I should clarify... Using an iptables rule like that assumes that the status > request packets are always the same size, and they are a different size than > the normal game data packets. You can also do string matching within packets > using iptables (if you have the appropriate modules installed), but on a game > server, that would probably add so much processing overhead it's not even > worth it. > >- Dave > > On 06/15/2012 12:40 PM, David Parker wrote: >> I guess one way Valve could solve this would be to change the way "status" >> works on the client. They could have the server send server-state >> information to the clients at some interval, like once per second, or >> perhaps each time something changes (player joins or leaves, map changes, >> etc.) and then have the "status" command on the client just read its most >> recent data. That would prevent status requests from hitting the server at >> all. It adds some overhead compared to the real-time request/reply method, >> but it eliminates the need to process each status request that comes in. >> >> Or, if the incoming "status" packets are always the same size, you could >> also use iptables to rate-limit them (just replace N with the packet size in >> bytes): >> >> iptables -A INPUT -p udp -m length --length N -m limit --limit 3/s -j ACCEPT >> >> (Note: I didn't test this iptables rule, I just slapped it together as a >> demonstration) >> >>- Dave >> >> On 06/14/2012 03:06 PM, Alvaro Gutierrez Lorenzo wrote: >>> I don't think it's still a popular attack, since it is only useful when you >>> can't ban in an effective way the attacker (e. g. Free-to-Play scheme). I >>> dont think it's a widely known attack, on my case it was just a single >>> person who was attacking all our servers, as we verified comparing IPs. >>> >>> What I would suggest you to do is to have SMAC (Sourcemod anti-cheat) >>> command monitor plugin running, and from time to time (or everytime find >>> there are lag issues) check this plugin's logs (called cmd_[date].log, >>> under the Sourcemod's log directory) to see if someone is attacking you by >>> this means. It's easy to spot even without actually opening the log file, a >>> usual day log will not grow over 1MB while when you have been attacked the >>> log will easily reach 300Mb (I've seen >3Gb log files on my server because >>> of this). Inside it looks like thousands of lines stating >>> "[date]: Console<0> executes: status" during a single >>> second. >>> >>> If you ever spot this attack, then you could take this measure to stop it. >>> Meanwhile, I would not take much care, since it's easy and quick to solve >>> (thanks to the people on this mailing list, thank you all again ;) ). >>> >>> El 14/06/2012 20:46, doc escribió: Kind of a scary thread, I do a lot of terrible data collection on my own server/website using the "status" command and I'd hate to have to alias it to nothing to avoid problems like this. Is this something I assume is important enough to look into? On Wed, Jun 13, 2012 at 5:40 AM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: > It worked perfectly! Simple attack, simple solution. > Never thought of this ways, now it seems so obvious XD > I made plugins and searched for the most strange ways of solving it, yet > it was "single-line" simple ^^ > > Well, it disables status, but that's a minimal sacrifice (SMAC provides a > secure alternative also, so there's no problem at all). > I will spread this through the servers I know: each and every one is > victim of this issue, that makes over a dozen grateful servers& > communities, many thanks ^^ > > I've checked this happens without any mods, so some official attention on > this would be the perfect happy ending, but this workaround solves the > problem so everything fine! > > El 13/06/2012 4:04, 1nsane escribió: > > While not a good solution at all. Have you tried aliasing status to >> nothing? >> >> "alias status" >> >> This will obviously disable the status command entirely. But perhaps it >> won't kill the server then? >> >> On Tue, Jun 12, 2012 at 7:49 PM, Alvaro Gutierrez Lorenzo< >> rugnor.maj...@gmail.com> wrote: >> >> Sorry for the "double mail", I just though that if the fix for that >>> removed the cooldown time for status, there would be no protection over >>> this command, making possible this attack. >>> Invalid Protocol mentionned this protection on an earlier mail. >>> >>> Is it a silly idea? I've never e
Re: [hlds_linux] Overflow attack to Source servers
I should clarify... Using an iptables rule like that assumes that the status request packets are always the same size, and they are a different size than the normal game data packets. You can also do string matching within packets using iptables (if you have the appropriate modules installed), but on a game server, that would probably add so much processing overhead it's not even worth it. - Dave On 06/15/2012 12:40 PM, David Parker wrote: I guess one way Valve could solve this would be to change the way "status" works on the client. They could have the server send server-state information to the clients at some interval, like once per second, or perhaps each time something changes (player joins or leaves, map changes, etc.) and then have the "status" command on the client just read its most recent data. That would prevent status requests from hitting the server at all. It adds some overhead compared to the real-time request/reply method, but it eliminates the need to process each status request that comes in. Or, if the incoming "status" packets are always the same size, you could also use iptables to rate-limit them (just replace N with the packet size in bytes): iptables -A INPUT -p udp -m length --length N -m limit --limit 3/s -j ACCEPT (Note: I didn't test this iptables rule, I just slapped it together as a demonstration) - Dave On 06/14/2012 03:06 PM, Alvaro Gutierrez Lorenzo wrote: I don't think it's still a popular attack, since it is only useful when you can't ban in an effective way the attacker (e. g. Free-to-Play scheme). I dont think it's a widely known attack, on my case it was just a single person who was attacking all our servers, as we verified comparing IPs. What I would suggest you to do is to have SMAC (Sourcemod anti-cheat) command monitor plugin running, and from time to time (or everytime find there are lag issues) check this plugin's logs (called cmd_[date].log, under the Sourcemod's log directory) to see if someone is attacking you by this means. It's easy to spot even without actually opening the log file, a usual day log will not grow over 1MB while when you have been attacked the log will easily reach 300Mb (I've seen >3Gb log files on my server because of this). Inside it looks like thousands of lines stating "[date]: Console<0> executes: status" during a single second. If you ever spot this attack, then you could take this measure to stop it. Meanwhile, I would not take much care, since it's easy and quick to solve (thanks to the people on this mailing list, thank you all again ;) ). El 14/06/2012 20:46, doc escribió: Kind of a scary thread, I do a lot of terrible data collection on my own server/website using the "status" command and I'd hate to have to alias it to nothing to avoid problems like this. Is this something I assume is important enough to look into? On Wed, Jun 13, 2012 at 5:40 AM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: It worked perfectly! Simple attack, simple solution. Never thought of this ways, now it seems so obvious XD I made plugins and searched for the most strange ways of solving it, yet it was "single-line" simple ^^ Well, it disables status, but that's a minimal sacrifice (SMAC provides a secure alternative also, so there's no problem at all). I will spread this through the servers I know: each and every one is victim of this issue, that makes over a dozen grateful servers& communities, many thanks ^^ I've checked this happens without any mods, so some official attention on this would be the perfect happy ending, but this workaround solves the problem so everything fine! El 13/06/2012 4:04, 1nsane escribió: While not a good solution at all. Have you tried aliasing status to nothing? "alias status" This will obviously disable the status command entirely. But perhaps it won't kill the server then? On Tue, Jun 12, 2012 at 7:49 PM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: Sorry for the "double mail", I just though that if the fix for that removed the cooldown time for status, there would be no protection over this command, making possible this attack. Invalid Protocol mentionned this protection on an earlier mail. Is it a silly idea? I've never experienced such cooldown protection, that would explain why. El 13/06/2012 1:31, Joe Brown escribió: This was used (and may still be) in hacks as a way to stop admins from using the status command to see your STEAMID in the client console. Spamming it like that blocked all clients connected to the server from being able to use the status command, preventing or extending the time it takes to ban someone. Correct me if I'm wrong but I thought the was fixed in an update. Date: Wed, 13 Jun 2012 01:23:23 +0200 From: rugnor.maj...@gmail.com To: hlds_linux@list.valvesoftware.com> Subject: Re: [hlds_linux] Overflow attack to Source servers That's a critical detail I fo
Re: [hlds_linux] Overflow attack to Source servers
I guess one way Valve could solve this would be to change the way "status" works on the client. They could have the server send server-state information to the clients at some interval, like once per second, or perhaps each time something changes (player joins or leaves, map changes, etc.) and then have the "status" command on the client just read its most recent data. That would prevent status requests from hitting the server at all. It adds some overhead compared to the real-time request/reply method, but it eliminates the need to process each status request that comes in. Or, if the incoming "status" packets are always the same size, you could also use iptables to rate-limit them (just replace N with the packet size in bytes): iptables -A INPUT -p udp -m length --length N -m limit --limit 3/s -j ACCEPT (Note: I didn't test this iptables rule, I just slapped it together as a demonstration) - Dave On 06/14/2012 03:06 PM, Alvaro Gutierrez Lorenzo wrote: I don't think it's still a popular attack, since it is only useful when you can't ban in an effective way the attacker (e. g. Free-to-Play scheme). I dont think it's a widely known attack, on my case it was just a single person who was attacking all our servers, as we verified comparing IPs. What I would suggest you to do is to have SMAC (Sourcemod anti-cheat) command monitor plugin running, and from time to time (or everytime find there are lag issues) check this plugin's logs (called cmd_[date].log, under the Sourcemod's log directory) to see if someone is attacking you by this means. It's easy to spot even without actually opening the log file, a usual day log will not grow over 1MB while when you have been attacked the log will easily reach 300Mb (I've seen >3Gb log files on my server because of this). Inside it looks like thousands of lines stating "[date]: Console<0> executes: status" during a single second. If you ever spot this attack, then you could take this measure to stop it. Meanwhile, I would not take much care, since it's easy and quick to solve (thanks to the people on this mailing list, thank you all again ;) ). El 14/06/2012 20:46, doc escribió: Kind of a scary thread, I do a lot of terrible data collection on my own server/website using the "status" command and I'd hate to have to alias it to nothing to avoid problems like this. Is this something I assume is important enough to look into? On Wed, Jun 13, 2012 at 5:40 AM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: It worked perfectly! Simple attack, simple solution. Never thought of this ways, now it seems so obvious XD I made plugins and searched for the most strange ways of solving it, yet it was "single-line" simple ^^ Well, it disables status, but that's a minimal sacrifice (SMAC provides a secure alternative also, so there's no problem at all). I will spread this through the servers I know: each and every one is victim of this issue, that makes over a dozen grateful servers& communities, many thanks ^^ I've checked this happens without any mods, so some official attention on this would be the perfect happy ending, but this workaround solves the problem so everything fine! El 13/06/2012 4:04, 1nsane escribió: While not a good solution at all. Have you tried aliasing status to nothing? "alias status" This will obviously disable the status command entirely. But perhaps it won't kill the server then? On Tue, Jun 12, 2012 at 7:49 PM, Alvaro Gutierrez Lorenzo< rugnor.maj...@gmail.com> wrote: Sorry for the "double mail", I just though that if the fix for that removed the cooldown time for status, there would be no protection over this command, making possible this attack. Invalid Protocol mentionned this protection on an earlier mail. Is it a silly idea? I've never experienced such cooldown protection, that would explain why. El 13/06/2012 1:31, Joe Brown escribió: This was used (and may still be) in hacks as a way to stop admins from using the status command to see your STEAMID in the client console. Spamming it like that blocked all clients connected to the server from being able to use the status command, preventing or extending the time it takes to ban someone. Correct me if I'm wrong but I thought the was fixed in an update. Date: Wed, 13 Jun 2012 01:23:23 +0200 From: rugnor.maj...@gmail.com To: hlds_linux@list.valvesoftware.com> Subject: Re: [hlds_linux] Overflow attack to Source servers That's a critical detail I forgot to mention, so sorry: RCON is port closed, so every attempt to access RCON gives a "Time Out". I'm totally sure it's "status", here I paste an excerpt from the SMAC log, made just by the same plugin you suggest: Sat Mar 31 14:56:34 2012: Console<0>executes: status Sat Mar 31 14:56:34 2012: Console<0>executes: status Sat Mar 31 14:56:34 2012: Console<0>executes: status Sat Mar 31 14:56:34 2012: Console<0>executes: status Sat Mar
