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 somethin g!
1000 ports? you say below 10 servers are protected, if it has sourcetv too thats in total 20 ports x4 = 80 ports.. I only protect the ports that need protecting by only selecting the ports of the source servers. Dont know your setup further though, but here it seems running ok. On Thu, 06 Jan 2011 13:19:32 +0100, Marco Padovan evolutioncr...@gmail.com wrote: 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 ___ 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
