Re: [hlds_linux] tf2 denial of service - please do something!
How does your ip tables rules look. Like ? Den 8 jan 2011 03.56 skrev Marco Padovan evolutioncr...@gmail.com: Il 08/01/2011 01:01, frostschutz ha scritto: On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote: I suppose those are all spoofed udp packets as they were the last time I checked them :( Only you can tell. (We can't look at the packets you're getting:) Didn't took the time because they were very short spikes... will arrange something in the next days if the thing will continue with this frequency... The problem is that it will take days to analyze the output of half an hour worth of log :D it's difficult to justify these spikes as legit traffic.. 10k spikes are not legit, I was thinking more along the lines of randomly getting 40 instead of just 10-20 packets in one particular second. A spike of 40 could be allowed, a spike of 1 certainly not. ;) check from 23:21 onward http://pastebin.com/jUjzyKY6 Since the DROP stays at 0 for several minutes that looks fine. If it increased like 1-5 packets every other second that would point to a too low limit. You had 3 unlucky queries between 23:00 and 23:01 (legit spike that got dropped), then again nothing for minutes, and then comes the DoS that gets dropped correctly. yeah, I'm sorry for those 3... hope they got lucky retrying a second later ;) I think that's okay. I hope that too... thanks for your precious suggestions :) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
this should do the trick: iptables -N QUERYLIMIT iptables -A QUERYLIMIT -m hashlimit --hashlimit-mode dstport --hashlimit-name srcdsquery --hashlimit 20/s --hashlimit-burst 10 -j ACCEPT iptables -A QUERYLIMIT -j DROP iptables -N QUERY iptables -A QUERY -p udp -m udp -m string --algo bm --hex-string '|54|' -j QUERYLIMIT iptables -A QUERY -p udp -m udp -m string --algo bm --hex-string '|55|' -j QUERYLIMIT iptables -A QUERY -p udp -m udp -m string --algo bm --hex-string '|56|' -j QUERYLIMIT iptables -A QUERY -p udp -m udp -m string --algo bm --hex-string '|57|' -j QUERYLIMIT iptables -I INPUT 15 -p udp --dport 29000:3 -j QUERY Il 08/01/2011 11:07, daniel jokiaho ha scritto: How does your ip tables rules look. Like ? Den 8 jan 2011 03.56 skrev Marco Padovan evolutioncr...@gmail.com mailto:evolutioncr...@gmail.com: Il 08/01/2011 01:01, frostschutz ha scritto: On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote: I suppose those are all spoofed udp packets as they were the last time I checked them :( Only you can tell. (We can't look at the packets you're getting:) Didn't took the time because they were very short spikes... will arrange something in the next days if the thing will continue with this frequency... The problem is that it will take days to analyze the output of half an hour worth of log :D it's difficult to justify these spikes as legit traffic.. 10k spikes are not legit, I was thinking more along the lines of randomly getting 40 instead of just 10-20 packets in one particular second. A spike of 40 could be allowed, a spike of 1 certainly not. ;) check from 23:21 onward http://pastebin.com/jUjzyKY6 Since the DROP stays at 0 for several minutes that looks fine. If it increased like 1-5 packets every other second that would point to a too low limit. You had 3 unlucky queries between 23:00 and 23:01 (legit spike that got dropped), then again nothing for minutes, and then comes the DoS that gets dropped correctly. yeah, I'm sorry for those 3... hope they got lucky retrying a second later ;) I think that's okay. I hope that too... thanks for your precious suggestions :) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
box keeping up :) 50k packets dropped in just 15minutes Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 346357 17999035 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 12 604 DROP all -- * * 0.0.0.0/00.0.0.0/0 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/00.0.0.0/0 another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/00.0.0.0/0 dropped accept ... nobody complained yet... so looks like its holding :) thanks for your suggestions 3 Il 07/01/2011 01:19, frostschutz ha scritto: On Fri, Jan 07, 2011 at 12:36:10AM +0100, Marco Padovan wrote: hashlimit was exactly what I needed! Set it up correctly ... will see tomorrow what will happen :) Great... :) My own box runs without iptables and TF2 servers without mods. No problems so far - I'm not running anything well known (small clan and idle servers) so it seems the DoS is directed to specific servers only... then again I probably wouldn't notice as the clan servers are empty most of the time and the idlers don't complain much. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 If the number of dropped packets keeps rising slowly here, you are probably dropping legitimate queries. Maybe the limit is a bit too low then. Also consider using a larger burst. The burst will allow short, random spikes, but under actual and constant DoS, the limit will still be respected, same as without burst. I'd try limit 20 burst 40 here and see how that goes. You can be generous with burst as it will vanish completely during a DoS attack anyhow (and it will take 40 below-limit seconds to recharge). another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 drop accept is to be expected during a DoS attack. nobody complained yet... so looks like its holding :) Test it yourself - see if you can get a complete server list using the standard steam server browser. If half of your servers are missing there most of the time (while there is NO DoS going on), chances are your limit is too low. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
I thoutgh about that too... but monitoring the situation closely it appear to be cristal clear: http://pastebin.com/asHm8GkW I getting spikes of 50k packets in very short periods (60seconds) I'll try to monitor all my servers in HLSW seeing how much time they are going offline... btw... seeing the spikes were that big I think I can increase the limit a lot... maybe 25 :) Il 07/01/2011 22:22, frostschutz ha scritto: On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 If the number of dropped packets keeps rising slowly here, you are probably dropping legitimate queries. Maybe the limit is a bit too low then. Also consider using a larger burst. The burst will allow short, random spikes, but under actual and constant DoS, the limit will still be respected, same as without burst. I'd try limit 20 burst 40 here and see how that goes. You can be generous with burst as it will vanish completely during a DoS attack anyhow (and it will take 40 below-limit seconds to recharge). another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 drop accept is to be expected during a DoS attack. nobody complained yet... so looks like its holding :) Test it yourself - see if you can get a complete server list using the standard steam server browser. If half of your servers are missing there most of the time (while there is NO DoS going on), chances are your limit is too low. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
No offense, but have you tried to look at where those dos attack comes from? You could block the IP-address of the attacker. /Chris Den 07/01/2011 kl. 22.32 skrev Marco Padovan: I thoutgh about that too... but monitoring the situation closely it appear to be cristal clear: http://pastebin.com/asHm8GkW I getting spikes of 50k packets in very short periods (60seconds) I'll try to monitor all my servers in HLSW seeing how much time they are going offline... btw... seeing the spikes were that big I think I can increase the limit a lot... maybe 25 :) Il 07/01/2011 22:22, frostschutz ha scritto: On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 If the number of dropped packets keeps rising slowly here, you are probably dropping legitimate queries. Maybe the limit is a bit too low then. Also consider using a larger burst. The burst will allow short, random spikes, but under actual and constant DoS, the limit will still be respected, same as without burst. I'd try limit 20 burst 40 here and see how that goes. You can be generous with burst as it will vanish completely during a DoS attack anyhow (and it will take 40 below-limit seconds to recharge). another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 drop accept is to be expected during a DoS attack. nobody complained yet... so looks like its holding :) Test it yourself - see if you can get a complete server list using the standard steam server browser. If half of your servers are missing there most of the time (while there is NO DoS going on), chances are your limit is too low. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
I suppose those are all spoofed udp packets as they were the last time I checked them :( I do not have direct access to the upstream links so I cannot trace them and link them to a specific bw supplier :( just increased the limits but still getting the drop rule hit hard... it's difficult to justify these spikes as legit traffic.. check from 23:21 onward http://pastebin.com/jUjzyKY6 I do not think I'm the only one in this situation as I saw many people discussing these problems recently :/ Il 07/01/2011 23:27, Christoffer Pedersen ha scritto: No offense, but have you tried to look at where those dos attack comes from? You could block the IP-address of the attacker. /Chris Den 07/01/2011 kl. 22.32 skrev Marco Padovan: I thoutgh about that too... but monitoring the situation closely it appear to be cristal clear: http://pastebin.com/asHm8GkW I getting spikes of 50k packets in very short periods (60seconds) I'll try to monitor all my servers in HLSW seeing how much time they are going offline... btw... seeing the spikes were that big I think I can increase the limit a lot... maybe 25 :) Il 07/01/2011 22:22, frostschutz ha scritto: On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 If the number of dropped packets keeps rising slowly here, you are probably dropping legitimate queries. Maybe the limit is a bit too low then. Also consider using a larger burst. The burst will allow short, random spikes, but under actual and constant DoS, the limit will still be respected, same as without burst. I'd try limit 20 burst 40 here and see how that goes. You can be generous with burst as it will vanish completely during a DoS attack anyhow (and it will take 40 below-limit seconds to recharge). another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 drop accept is to be expected during a DoS attack. nobody complained yet... so looks like its holding :) Test it yourself - see if you can get a complete server list using the standard steam server browser. If half of your servers are missing there most of the time (while there is NO DoS going on), chances are your limit is too low. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
You could use iptraf do look after the packets. You can configure it to put all the packet-logs into a file and then take a look at the file. /Chris Den 07/01/2011 kl. 23.50 skrev Marco Padovan: I suppose those are all spoofed udp packets as they were the last time I checked them :( I do not have direct access to the upstream links so I cannot trace them and link them to a specific bw supplier :( just increased the limits but still getting the drop rule hit hard... it's difficult to justify these spikes as legit traffic.. check from 23:21 onward http://pastebin.com/jUjzyKY6 I do not think I'm the only one in this situation as I saw many people discussing these problems recently :/ Il 07/01/2011 23:27, Christoffer Pedersen ha scritto: No offense, but have you tried to look at where those dos attack comes from? You could block the IP-address of the attacker. /Chris Den 07/01/2011 kl. 22.32 skrev Marco Padovan: I thoutgh about that too... but monitoring the situation closely it appear to be cristal clear: http://pastebin.com/asHm8GkW I getting spikes of 50k packets in very short periods (60seconds) I'll try to monitor all my servers in HLSW seeing how much time they are going offline... btw... seeing the spikes were that big I think I can increase the limit a lot... maybe 25 :) Il 07/01/2011 22:22, frostschutz ha scritto: On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: 20 minutes later: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 50483 2675483 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 If the number of dropped packets keeps rising slowly here, you are probably dropping legitimate queries. Maybe the limit is a bit too low then. Also consider using a larger burst. The burst will allow short, random spikes, but under actual and constant DoS, the limit will still be respected, same as without burst. I'd try limit 20 burst 40 here and see how that goes. You can be generous with burst as it will vanish completely during a DoS attack anyhow (and it will take 40 below-limit seconds to recharge). another box of ours that generally suffer a lot of is now reporting: Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 52 16966756 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport 563098 29844034 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 drop accept is to be expected during a DoS attack. nobody complained yet... so looks like its holding :) Test it yourself - see if you can get a complete server list using the standard steam server browser. If half of your servers are missing there most of the time (while there is NO DoS going on), chances are your limit is too low. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote: I suppose those are all spoofed udp packets as they were the last time I checked them :( Only you can tell. (We can't look at the packets you're getting:) it's difficult to justify these spikes as legit traffic.. 10k spikes are not legit, I was thinking more along the lines of randomly getting 40 instead of just 10-20 packets in one particular second. A spike of 40 could be allowed, a spike of 1 certainly not. ;) check from 23:21 onward http://pastebin.com/jUjzyKY6 Since the DROP stays at 0 for several minutes that looks fine. If it increased like 1-5 packets every other second that would point to a too low limit. You had 3 unlucky queries between 23:00 and 23:01 (legit spike that got dropped), then again nothing for minutes, and then comes the DoS that gets dropped correctly. I think that's okay. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Il 08/01/2011 01:01, frostschutz ha scritto: On Fri, Jan 07, 2011 at 11:50:56PM +0100, Marco Padovan wrote: I suppose those are all spoofed udp packets as they were the last time I checked them :( Only you can tell. (We can't look at the packets you're getting:) Didn't took the time because they were very short spikes... will arrange something in the next days if the thing will continue with this frequency... The problem is that it will take days to analyze the output of half an hour worth of log :D it's difficult to justify these spikes as legit traffic.. 10k spikes are not legit, I was thinking more along the lines of randomly getting 40 instead of just 10-20 packets in one particular second. A spike of 40 could be allowed, a spike of 1 certainly not. ;) check from 23:21 onward http://pastebin.com/jUjzyKY6 Since the DROP stays at 0 for several minutes that looks fine. If it increased like 1-5 packets every other second that would point to a too low limit. You had 3 unlucky queries between 23:00 and 23:01 (legit spike that got dropped), then again nothing for minutes, and then comes the DoS that gets dropped correctly. yeah, I'm sorry for those 3... hope they got lucky retrying a second later ;) I think that's okay. I hope that too... thanks for your precious suggestions :) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Ronny and me wrote that blogpost on vanillatf2. During our tests the filter seemed effective and not causing too much CPU usage even when sending multiple megabytes worth of packets per second, so I'm curious why you say it's not going to work for you. It would of course be better if the gameserver itself would use sv_max_queries_sec_global properly. Right now this setting doesn't help against these attacks. On 5 January 2011 23:42, Marco Padovan evolutioncr...@gmail.com wrote: I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
I'm getting high cpu usage because, due to how our system works, we had to filter ALL the ports... even the ports where other gameservers type (call of duty, mumble voice server and all the other) were running... I'm just talking of only 20mbits/sec dataflow... but appear to be enough to put some load on the server that I would prefer to not have... As for now I'm giving a try to: http://code.google.com/p/querycache/ and, on another machine, will try: iptables -I INPUT 10 -p udp -m udp --dport $i -m string --algo bm --hex-string '|54|' --to 33 -m limit --limit 10/s -j ACCEPT as that tag should be only at the beginning of the packet... right? I have yet to understand the exact size of the attack packets... filtering out directly by size would be even better and faster instead of a string comparison Il 06/01/2011 12:02, Arie ha scritto: Ronny and me wrote that blogpost on vanillatf2. During our tests the filter seemed effective and not causing too much CPU usage even when sending multiple megabytes worth of packets per second, so I'm curious why you say it's not going to work for you. It would of course be better if the gameserver itself would use sv_max_queries_sec_global properly. Right now this setting doesn't help against these attacks. On 5 January 2011 23:42, Marco Padovanevolutioncr...@gmail.com wrote: I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
With 1000ports protected and 4 rules for each port on simple testserver (xeon 3430): PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7 root -76 0 000 S 29.5 0.0 204:01.74 sirq-net-rx/0 21 root -76 0 000 S 8.3 0.0 9:02.45 sirq-net-rx/1 15408 *** 20 0 620m 506m 18m S 6.6 6.3 114:34.22 srcds_linux 12249 *** 22 2 363m 291m 3420 R 4.6 3.6 3:35.13 cod4_lnxded 8495 *** 20 0 83864 19m 2104 S 3.6 0.2 545:31.54 hlds_i686 8649 *** 20 0 173m 61m 7416 S 3.0 0.8 516:10.89 srcds_linux 29.5% + 8.3% of cpu usage just to correct an engine defect is too much... currently, on that test box, there are like 10 servers protected... the rest are servers that does not need protection (cod, voice and so on)... and the traffic flow is very very very low! Monitoring eth0...(press CTRL-C to stop) rx: 632 kbit/s 777 p/s tx: 308 kbit/s 220 p/s :( Il 06/01/2011 12:02, Arie ha scritto: Ronny and me wrote that blogpost on vanillatf2. During our tests the filter seemed effective and not causing too much CPU usage even when sending multiple megabytes worth of packets per second, so I'm curious why you say it's not going to work for you. It would of course be better if the gameserver itself would use sv_max_queries_sec_global properly. Right now this setting doesn't help against these attacks. On 5 January 2011 23:42, Marco Padovanevolutioncr...@gmail.com wrote: I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Thu, Jan 06, 2011 at 01:19:32PM +0100, Marco Padovan wrote: With 1000ports protected and 4 rules for each port on simple testserver If you're saying that each packet has to traverse 4000 rules in your setup, then that would explain why it's so slow. Is the port number relevant for the match or why don't make one rule that matches all ports? Can you post an (excerpt) of the rules you're using? Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Thu, Jan 06, 2011 at 01:58:13PM +0100, frostschutz wrote: Can you post an (excerpt) of the rules you're using? Noticed this was posted earlier. Note: This is _untested_, it's been a while since I used iptables. $IPTABLES -N QUERYLIMIT $IPTABLES -A QUERYLIMIT -m limit --limit 20/s -j ACCEPT $IPTABLES -A QUERYLIMIT -j DROP $IPTABLES -N QUERY $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|54|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|55|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|56|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|57|' -j QUERYLIMIT $IPTABLES -A INPUT -p udp --dport 2:3 -j QUERY Something like this should be sufficient to match and limit an entire port range. Packets outside the port range traverse 1 rule, Packets inside the port range traverse 5 rules, Packets that actually match traverse 3-6 rules and fall under a global 20 per second limit. (maybe limit per client if it's DoS but not DDoS) Depending on which of these 54 55 56 57 is the most frequent occurence, they could be reordered too. If there are lots of packets that don't start with , that could be matched first to further reduce the number of rules that packets that won't match have to traverse. However you really should use port ranges that have affected traffic exclusively, no point in forcing other stuff through all that. Just throwing ideas around frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Chain QUERYLIMIT (4 references) pkts bytes target prot opt in out source destination 180990905 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 limit: avg 20/sec burst 5 110 4974 DROP all -- * * 0.0.0.0/00.0.0.0/0 as suspected that appear to keep a single bucket and allowing 20/sec on the whole server... not on every single port :( Il 06/01/2011 14:28, frostschutz ha scritto: On Thu, Jan 06, 2011 at 01:58:13PM +0100, frostschutz wrote: Can you post an (excerpt) of the rules you're using? Noticed this was posted earlier. Note: This is _untested_, it's been a while since I used iptables. $IPTABLES -N QUERYLIMIT $IPTABLES -A QUERYLIMIT -m limit --limit 20/s -j ACCEPT $IPTABLES -A QUERYLIMIT -j DROP $IPTABLES -N QUERY $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|54|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|55|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|56|' -j QUERYLIMIT $IPTABLES -A QUERY -p udp -m udp -m string --algo bm --hex-string '|57|' -j QUERYLIMIT $IPTABLES -A INPUT -p udp --dport 2:3 -j QUERY Something like this should be sufficient to match and limit an entire port range. Packets outside the port range traverse 1 rule, Packets inside the port range traverse 5 rules, Packets that actually match traverse 3-6 rules and fall under a global 20 per second limit. (maybe limit per client if it's DoS but not DDoS) Depending on which of these 54 55 56 57 is the most frequent occurence, they could be reordered too. If there are lots of packets that don't start with , that could be matched first to further reduce the number of rules that packets that won't match have to traverse. However you really should use port ranges that have affected traffic exclusively, no point in forcing other stuff through all that. Just throwing ideas around frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Thu, Jan 06, 2011 at 04:16:23PM +0100, Marco Padovan wrote: as suspected that appear to keep a single bucket and allowing 20/sec on the whole server... not on every single port :( Yes, it's a single bucket. Does it really have to be per server? I'd just use a sane value for limit and a large burst here (1000), so short spikes will work but continuous DoS won't. After all even if just one gameserver gets DoSed, in the end it's the whole server that has to cope with the network and CPU. And as long as there is no DoS it will work normally, even with just one bucket. Of course you could still add a separate bucket for each port in the querylimit chain (no need for a drop rule for each port, just put a single drop rule at the end). But if you do that you'll likely run into performance problems again. So I think single bucket is preferable. Also consider combining this with fail2ban or similar, so you can block IPs who are spamming you completely. This will ease load both on your server, and the bucket. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
My guess is the person that is doing the attack is on this reading the little discussion. :p Sent from my iPhone 4 On Jan 6, 2011, at 7:47 AM, frostschutz frostsch...@metamorpher.de wrote: On Thu, Jan 06, 2011 at 04:16:23PM +0100, Marco Padovan wrote: as suspected that appear to keep a single bucket and allowing 20/sec on the whole server... not on every single port :( Yes, it's a single bucket. Does it really have to be per server? I'd just use a sane value for limit and a large burst here (1000), so short spikes will work but continuous DoS won't. After all even if just one gameserver gets DoSed, in the end it's the whole server that has to cope with the network and CPU. And as long as there is no DoS it will work normally, even with just one bucket. Of course you could still add a separate bucket for each port in the querylimit chain (no need for a drop rule for each port, just put a single drop rule at the end). But if you do that you'll likely run into performance problems again. So I think single bucket is preferable. Also consider combining this with fail2ban or similar, so you can block IPs who are spamming you completely. This will ease load both on your server, and the bucket. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Ok will see what will happen this evening... Fail2ban cannot help due to spoofed ips. The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p Il giorno 06/gen/2011 16.50, frostschutz frostsch...@metamorpher.de ha scritto: On Thu, Jan 06, 2011 at 04:16:23PM +0100, Marco Padovan wrote: as suspected that appear to keep a single bucket and allowing 20/sec on the whole server... not on every single port :( Yes, it's a single bucket. Does it really have to be per server? I'd just use a sane value for limit and a large burst here (1000), so short spikes will work but continuous DoS won't. After all even if just one gameserver gets DoSed, in the end it's the whole server that has to cope with the network and CPU. And as long as there is no DoS it will work normally, even with just one bucket. Of course you could still add a separate bucket for each port in the querylimit chain (no need for a drop rule for each port, just put a single drop rule at the end). But if you do that you'll likely run into performance problems again. So I think single bucket is preferable. Also consider combining this with fail2ban or similar, so you can block IPs who are spamming you completely. This will ease load both on your server, and the bucket. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
It seems you have never heard of: sv_max_queries_sec sv_max_queries_sec_global sv_max_queries_window I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Thu, Jan 06, 2011 at 06:14:01PM +0100, Ronny Schedel wrote: It seems you have never heard of: sv_max_queries_sec sv_max_queries_sec_global sv_max_queries_window Those do not work properly. Just so you know. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote: The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p So I came across this in the iptables man page... hashlimit This patch adds a new match called 'hashlimit'. The idea is to have something like 'limit', but either per destination-ip or per (destip,destport) tuple. It gives you the ability to express '1000 packets per second for every host in 192.168.0.0/16' '100 packets per second for every service of 192.168.1.1' with a single iptables rule. So you can use hashlimit for a 20 pps for each port solution, still with just a single rule. iptables -m hashlimit --hashlimit 20/s --hashlimit-mode destip-destport (might also need --hashlimit-htable-size/max/, not sure...) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Nice! Will give it a try if it's already part of the kernel I use :) Thank you Il giorno 06/gen/2011 18.43, frostschutz frostsch...@metamorpher.de ha scritto: On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote: The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p So I came across this in the iptables man page... hashlimit This patch adds a new match called 'hashlimit'. The idea is to have something like 'limit', but either per destination-ip or per (destip,destport) tuple. It gives you the ability to express '1000 packets per second for every host in 192.168.0.0/16' '100 packets per second for every service of 192.168.1.1' with a single iptables rule. So you can use hashlimit for a 20 pps for each port solution, still with just a single rule. iptables -m hashlimit --hashlimit 20/s --hashlimit-mode destip-destport (might also need --hashlimit-htable-size/max/, not sure...) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Hello. Now one unfortunate fact about DoS attacks is that they are designed to interrupt service. The main reason why they work so well is because UDP packets can be spoofed. Thus you are unable to identify a IP to ban as the IPs reported will not be the real source of the packet. Almost a year ago I suffered a 30Mbit/sec DoS attack on a CS:S server. (Everyone who knows my name can probably guess why someone would want to attack me.) Given the nature of the attack and the fact that my game server was empty I just firewalled off the port they were attacking (save bandwidth). While Query Cache can help you server show that its up, in the end if someone has enough bandwidth they can take your server down. While VALVe can probably make a better query mechanism they won't be able to fix this problem. Since this problem is actually a problem with the way the internet is designed. The main problem lies in the UDP protocol. Since no handshakes are required (since UDP is stateless) its easy to spoof the source IP with just a Linux box (or a modded Windows). The only true solution when your getting DoS'd is for your ISP (host) to find the source of the attack through tickets to up-stream providers. However, most ISPs will not bother to trace the origin of the attack (due to the fact that most come from zombie machines). On Thu, Jan 6, 2011 at 11:53 AM, Marco Padovan evolutioncr...@gmail.com wrote: Nice! Will give it a try if it's already part of the kernel I use :) Thank you Il giorno 06/gen/2011 18.43, frostschutz frostsch...@metamorpher.de ha scritto: On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote: The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p So I came across this in the iptables man page... hashlimit This patch adds a new match called 'hashlimit'. The idea is to have something like 'limit', but either per destination-ip or per (destip,destport) tuple. It gives you the ability to express '1000 packets per second for every host in 192.168.0.0/16' '100 packets per second for every service of 192.168.1.1' with a single iptables rule. So you can use hashlimit for a 20 pps for each port solution, still with just a single rule. iptables -m hashlimit --hashlimit 20/s --hashlimit-mode destip-destport (might also need --hashlimit-htable-size/max/, not sure...) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
While true, it is somewhat different in matters of actual possession of resources to blow a connection out of the sky with 40x155mbit hacked boxes and able to take down 5-6 different gameservers with your crappy 512kbit dsl-line from home due to improper handling of packets. -TheG On Thu, Jan 6, 2011 at 10:37 PM, Kigen theki...@gmail.com wrote: Hello. Now one unfortunate fact about DoS attacks is that they are designed to interrupt service. The main reason why they work so well is because UDP packets can be spoofed. Thus you are unable to identify a IP to ban as the IPs reported will not be the real source of the packet. Almost a year ago I suffered a 30Mbit/sec DoS attack on a CS:S server. (Everyone who knows my name can probably guess why someone would want to attack me.) Given the nature of the attack and the fact that my game server was empty I just firewalled off the port they were attacking (save bandwidth). While Query Cache can help you server show that its up, in the end if someone has enough bandwidth they can take your server down. While VALVe can probably make a better query mechanism they won't be able to fix this problem. Since this problem is actually a problem with the way the internet is designed. The main problem lies in the UDP protocol. Since no handshakes are required (since UDP is stateless) its easy to spoof the source IP with just a Linux box (or a modded Windows). The only true solution when your getting DoS'd is for your ISP (host) to find the source of the attack through tickets to up-stream providers. However, most ISPs will not bother to trace the origin of the attack (due to the fact that most come from zombie machines). On Thu, Jan 6, 2011 at 11:53 AM, Marco Padovan evolutioncr...@gmail.com wrote: Nice! Will give it a try if it's already part of the kernel I use :) Thank you Il giorno 06/gen/2011 18.43, frostschutz frostsch...@metamorpher.de ha scritto: On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote: The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p So I came across this in the iptables man page... hashlimit This patch adds a new match called 'hashlimit'. The idea is to have something like 'limit', but either per destination-ip or per (destip,destport) tuple. It gives you the ability to express '1000 packets per second for every host in 192.168.0.0/16' '100 packets per second for every service of 192.168.1.1' with a single iptables rule. So you can use hashlimit for a 20 pps for each port solution, still with just a single rule. iptables -m hashlimit --hashlimit 20/s --hashlimit-mode destip-destport (might also need --hashlimit-htable-size/max/, not sure...) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
I agree... this is not a matter of bandwidth but it has to do with improper packet handling of a small amount of traffic... Il giorno 06/gen/2011 22.52, Björn Rohlén bjorn.roh...@gmail.com ha scritto: ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
hashlimit was exactly what I needed! Set it up correctly ... will see tomorrow what will happen :) Il 06/01/2011 18:40, frostschutz ha scritto: On Thu, Jan 06, 2011 at 05:28:43PM +0100, Marco Padovan wrote: The single bucket is problematic due to how we manage the gameservers, will update the status this evening :p So I came across this in the iptables man page... hashlimit This patch adds a new match called 'hashlimit'. The idea is to have something like 'limit', but either per destination-ip or per (destip,destport) tuple. It gives you the ability to express '1000 packets per second for every host in 192.168.0.0/16' '100 packets per second for every service of 192.168.1.1' with a single iptables rule. So you can use hashlimit for a 20 pps for each port solution, still with just a single rule. iptables -m hashlimit --hashlimit 20/s --hashlimit-mode destip-destport (might also need --hashlimit-htable-size/max/, not sure...) Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
On Fri, Jan 07, 2011 at 12:36:10AM +0100, Marco Padovan wrote: hashlimit was exactly what I needed! Set it up correctly ... will see tomorrow what will happen :) Great... :) My own box runs without iptables and TF2 servers without mods. No problems so far - I'm not running anything well known (small clan and idle servers) so it seems the DoS is directed to specific servers only... then again I probably wouldn't notice as the clan servers are empty most of the time and the idlers don't complain much. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
There were bots spoofing their IPs doing the stupid packet length attack (The one that you can preform with ease on Dialup). I stopped checking my kern.log files a while ago as none of the IPs matched up with any players. The fix for this is simple, install DAF, or filter the port with IPTables. However, if they're using some of the newer, more fun tools. You're forced to use IPTables to filter the traffic since SRCDS cannot handle it for some asinine reason. You can also install ServerSecure2, however it creates visibility issues (even under non-attack cases). This should have been fixed over two years ago, but it's still an issue today. Hopefully it's nothing like the Rcon crash where it took the ETF2L Servers to go down :/ Kyle. On Thu, Jan 6, 2011 at 4:19 PM, frostschutz frostsch...@metamorpher.de wrote: On Fri, Jan 07, 2011 at 12:36:10AM +0100, Marco Padovan wrote: hashlimit was exactly what I needed! Set it up correctly ... will see tomorrow what will happen :) Great... :) My own box runs without iptables and TF2 servers without mods. No problems so far - I'm not running anything well known (small clan and idle servers) so it seems the DoS is directed to specific servers only... then again I probably wouldn't notice as the clan servers are empty most of the time and the idlers don't complain much. Regards frostschutz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
I'm curious, what do you mean when you say that the iptables solution cannot be handled properly on your busy servers? Do the string checks create a lot of overhead and slow things down? I have not experienced any attacks, but I agree that this is something that needs to be solved in the engine. A cvar to limit the number of queries per second would be great. - Dave - Original Message - From: Marco Padovan evolutioncr...@gmail.com Date: Wednesday, January 5, 2011 5:42 pm Subject: [hlds_linux] tf2 denial of service - please do something! To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] tf2 denial of service - please do something!
Normally, the packets that are send in other byte sizes, because srcds can't handle those bytesizes (i think). All the DoS-attacks i had used the packet size of either 24 or 46. I solved this by blocking this byte size on the port (27015). I haven't had any DoS'es since. Regards. Chris Sendt fra min iPhone 4 Den 05/01/2011 kl. 23.42 skrev Marco Padovan evolutioncr...@gmail.com: I'm hosting many tf2 servers and lately we are getting a lot of denial of services... basically we got our machservers spammed with query requests till the point they time out (the machine is running properly, it's just the gameserver slowly dieing) an effective way to stop this kind of behaviour is: http://www.vanillatf2.org/2011/01/fighting-dos-attacks/ but that cannot be handled properly on boxes as busy as ours... basically with just little effort anybody is able to take down a single gameserver spamming it with query requests :( What can we do to stop that? Is there a decent plugin/official fix to get rid of this problem instead of doing packet inspection via iptables on boxes handling 1+ packets/second? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
