<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    How many servers are running on the one machine?<br>
    <br>
    You might need to up the LIMITSTAT and LIMITINFO chains to more than
    10/sec if you have a bunch of servers being handled by that rule.<br>
    <br>
    10/sec is good for about 4 or 5 game servers.<br>
    <br>
    You can see if your limits make sense by looking at "sudo iptables
    -L -v -n" and looking at dropped packets in the LIMITSTAT and
    LIMITINFO chains.&nbsp; If you see some of dropped packets (but are not
    under a 'getstatus' or 'getinfo' attack) then up it from 10 to maybe
    20 or so.<br>
    <br>
    Thanks,<br>
    <br>
    <i>Boyd</i><br>
    <div class="moz-signature"><i><font size="-1">__________________________________<br>
          Boyd G. Gafford Ph.D.<br>
          Manager of Software Development<br>
          Westport Research Associates Inc.<br>
          7001 Blue Ridge Blvd<br>
          Raytown, MO 64133<br>
          (816) 358-8990<br>
          <a class="moz-txt-link-abbreviated" href="mailto:drboyd@westportresearch.com">drboyd@westportresearch.com</a><br>
        </font></i><br>
    </div>
    <br>
    On 03/09/2012 12:09 PM, escapedturkey wrote:
    <blockquote
cite="mid:CALCvV0y_adEd6F9ah2Sf71C2dX2fuh1Y2O5YG7sM54OSgP9QEA@mail.gmail.com"
      type="cite">Seems to have killed qstat status check. <br>
      <br>
      Without ServerArk:<br>
      <br>
      qstat -old -R -P -a2s <a moz-do-not-send="true"
        href="http://208.43.15.2:27015">208.43.15.2:27015</a><br>
      <a moz-do-not-send="true" href="http://208.43.15.2:27015">208.43.15.2:27015</a>
      "EscapedTurkey.com Dallas, TX" map de_dust at (null) 0/32 players
      1 ms<br>
      <br>
      ServerArk running:<br>
      <br>
      qstat -old -R -P -a2s <a moz-do-not-send="true"
        href="http://208.43.15.2:27015">208.43.15.2:27015</a><br>
      <a moz-do-not-send="true" href="http://208.43.15.2:27015">208.43.15.2:27015</a>
      no response<br>
      <br>
      This is what I am using:<br>
      <br>
      # The main logic of ServerArk, all done with /sbin/iptables!<br>
      <br>
      # Version 1.01<br>
      # (C) 2012 Boyd G. Gafford Ph.D. (Usage is under the LGPL)<br>
      # To contact me, simply post on the forum at <a
        moz-do-not-send="true" href="http://elitewarriors.net">elitewarriors.net</a>.<br>
      #<br>
      # Please note these rules ONLY affect UDP packets to the game
      servers, nothing else!<br>
      # This script will protect all Q3-protocol servers on the port
      28960. It protects<br>
      <br>
      # against both 'getstatus' and 'getinfo' attacks, as well as
      'getchallenge' atttacks,<br>
      # even from a UDP flood with random source IPs.<br>
      <br>
      # Add a limit/drop chain for "getstatus" packets that limits it to
      10 a second for all servers.<br>
      # If you are only protecting one server, you can set the number
      from 10 down to 4 (or 2 even).<br>
      <br>
      /sbin/iptables -N LIMITSTAT<br>
      /sbin/iptables -A LIMITSTAT -p udp -m limit --limit 10/sec
      --limit-burst 10 -j ACCEPT<br>
      /sbin/iptables -A LIMITSTAT -p udp -j DROP<br>
      <br>
      <br>
      # Add a limit/drop chain for "getinfo" packets that limits it to
      10 a second for all servers.<br>
      # If you are only protecting one server, you can set the number
      from 10 down to 4 (or 2 even).<br>
      <br>
      /sbin/iptables -N LIMITINFO<br>
      /sbin/iptables -A LIMITINFO -p udp -m limit --limit 10/sec
      --limit-burst 10 -j ACCEPT<br>
      /sbin/iptables -A LIMITINFO -p udp -j DROP<br>
      <br>
      <br>
      # Add a limit/drop chain for "getchallenge" packets that limits it
      to 5 a second for all servers.<br>
      # If you are only protecting one server, you can set the number
      from 5 down to 2. Setting it<br>
      # at 2 means only 2 players could connect to the server per
      second. Set LIMITCONN to the<br>
      # same, as there is one getchallenge/connect packet sequence per
      valid player connection.<br>
      <br>
      /sbin/iptables -N LIMITCHLG<br>
      /sbin/iptables -A LIMITCHLG -p udp -m limit --limit 5/sec
      --limit-burst 5 -j ACCEPT<br>
      /sbin/iptables -A LIMITCHLG -p udp -j DROP<br>
      <br>
      <br>
      # Add a limit/drop chain for "connect" packets that limits it to 5
      a second for all servers.<br>
      # If you are only protecting one server, you can set the number
      from 5 down to 2. Setting it<br>
      # at 2 means only 2 players could connect to the server per
      second. Set LIMITCHLG to the<br>
      # same, as there is one getchallenge/connect packet sequence per
      valid player connection.<br>
      <br>
      /sbin/iptables -N LIMITCONN<br>
      /sbin/iptables -A LIMITCONN -p udp -m limit --limit 5/sec
      --limit-burst 5 -j ACCEPT<br>
      /sbin/iptables -A LIMITCONN -p udp -j DROP<br>
      <br>
      <br>
      # Add a limit chain that prevents more than 70 packets a second
      per player.<br>
      # This is the main logic of ServerArk, but just performed by an
      iptable rule.<br>
      # We allow up to 128 players which is enough for 4 servers full
      (at 32 players each).<br>
      # If you only have one server, you could the size and max to 32.<br>
      # If you have players who have manually set their packet rate up
      to 100, just change the 70 to 100.<br>
      <br>
      /sbin/iptables -N LIMITPLRS<br>
      /sbin/iptables -A LIMITPLRS -p udp -m hashlimit --hashlimit-name
      PLAYERS --hashlimit-above 100/sec --hashlimit-burst 100
      --hashlimit-mode srcip,srcport --hashlimit-htable-size 128
      --hashlimit-htable-max 128 --hashlimit-htable-gcinterval 1000
      --hashlimit-htable-expire 10000 -j DROP<br>
      /sbin/iptables -A LIMITPLRS -p udp -j ACCEPT<br>
      <br>
      <br>
      # Add the rules to pick out the various special packets and send
      them to appropriate limit chains.<br>
      # To protect 5 ports, just specify a range like "--dport
      28960:28964" below.<br>
      <br>
      /sbin/iptables -A INPUT -p udp --dport 27000:30000 -m string
      --string "getstatus" --algo bm --from 32 --to 33 -j LIMITSTAT<br>
      /sbin/iptables -A INPUT -p udp --dport 27000:30000 -m string
      --string "getinfo" --algo bm --from 32 --to 33 -j LIMITINFO<br>
      /sbin/iptables -A INPUT -p udp --dport 27000:30000 -m string
      --string "getchallenge" --algo bm --from 32 --to 33 -j LIMITCHLG<br>
      /sbin/iptables -A INPUT -p udp --dport 27000:30000 -m string
      --string "connect" --algo bm --from 32 --to 33 -j LIMITCONN<br>
      <br>
      <br>
      # Send all other packets (normal player packets) to the limit
      players chain.<br>
      # A port range like "--dport 28960:28964" could also be used here
      as well.<br>
      # /sbin/iptables -A INPUT -p udp --dport 28960 -j LIMITPLRS<br>
      <br>
      <div> /sbin/iptables -A INPUT -p udp --dport 27000:30000 -j
        LIMITPLRS<br>
      </div>
      <div><br>
      </div>
      <div class="gmail_quote">On Fri, Mar 9, 2012 at 11:41 AM, Boyd G.
        Gafford Ph.D. <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:drboyd@westportresearch.com" target="_blank">drboyd@westportresearch.com</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000"> Yeah, if they flood
            "getstatus" and "getinfo", during the attack your server
            will not be visible from the master list.<br>
            <br>
            If they flood "getchallenge", during the attack nobody will
            be able to join your server.<br>
            <br>
            Once the attack ends, then you'll be visible again and
            people can join normally.<br>
            <br>
            Since most of these attacks are from spoofed random IP
            addresses (millions of them), you can't limit per IP, as no
            IP repeats.<br>
            <br>
            This set of rules is about the best I've found short of
            doing a whitelisted server, where you only allow IP's of
            known good players, and block everything else, and then
            people have to join the server with "connect IP:PORT".&nbsp;
            That's fairly inconvenient for most players, so these rules
            are about as good as you can get and still allow usage from
            the master list.<br>
            <br>
            &nbsp; Thanks,<br>
            <font color="#888888"> <br>
              <i>&nbsp; Boyd</i></font>
            <div><br>
              <div><i><font size="-1">__________________________________<br>
                    Boyd G. Gafford Ph.D.<br>
                    Manager of Software Development<br>
                    Westport Research Associates Inc.<br>
                    7001 Blue Ridge Blvd<br>
                    Raytown, MO 64133<br>
                    <a moz-do-not-send="true"
                      href="tel:%28816%29%20358-8990"
                      value="+18163588990" target="_blank">(816)
                      358-8990</a><br>
                    <a moz-do-not-send="true"
                      href="mailto:drboyd@westportresearch.com"
                      target="_blank">drboyd@westportresearch.com</a><br>
                  </font></i><br>
              </div>
              <br>
            </div>
            <div>
              <div> On 03/09/2012 10:00 AM, Ruediger Meier wrote:
                <blockquote type="cite">
                  <pre>On Friday 09 March 2012, Boyd G. Gafford Ph.D. wrote:
</pre>
                  <blockquote type="cite">
                    <pre>Just wanted to share these with the COD group here.  I've been
running these rules for about a week now, and they have been working
wonderfully.  Let me know if you end up using them and how they work
for you.
</pre>
                  </blockquote>
                  <pre>Be aware that now it's easy for a attacker to make your servers 
invisible for others by flooding your limit rules.
Maybe you should rather limit per ip.

cu,
Rudi

</pre>
                  <blockquote type="cite">
                    <pre>#!/bin/bash
# The main logic of ServerArk, all done with iptables!
# Version 1.01
# (C) 2012 Boyd G. Gafford Ph.D. (Usage is under the LGPL)
# To contact me, simply post on the forum at <a moz-do-not-send="true" href="http://elitewarriors.net" target="_blank">elitewarriors.net</a>.
#
# Please note these rules ONLY affect UDP packets to the game
servers, nothing else!
# This script will protect all Q3-protocol servers on the port 28960.
It protects
# against both 'getstatus' and 'getinfo' attacks, as well as
'getchallenge' atttacks,
# even from a UDP flood with random source IPs.

# Add a limit/drop chain for "getstatus" packets that limits it to 10
a second for all servers.
# If you are only protecting one server, you can set the number from
10 down to 4 (or 2 even).
iptables -N LIMITSTAT
iptables -A LIMITSTAT -p udp -m limit --limit 10/sec --limit-burst 10
-j ACCEPT
iptables -A LIMITSTAT -p udp -j DROP

# Add a limit/drop chain for "getinfo" packets that limits it to 10 a
second for all servers.
# If you are only protecting one server, you can set the number from
10 down to 4 (or 2 even).
iptables -N LIMITINFO
iptables -A LIMITINFO -p udp -m limit --limit 10/sec --limit-burst 10
-j ACCEPT
iptables -A LIMITINFO -p udp -j DROP

# Add a limit/drop chain for "getchallenge" packets that limits it to
5 a second for all servers.
# If you are only protecting one server, you can set the number from
5 down to 2.  Setting it
# at 2 means only 2 players could connect to the server per second. 
Set LIMITCONN to the
# same, as there is one getchallenge/connect packet sequence per
valid player connection.
iptables -N LIMITCHLG
iptables -A LIMITCHLG -p udp -m limit --limit 5/sec --limit-burst 5
-j ACCEPT
iptables -A LIMITCHLG -p udp -j DROP

# Add a limit/drop chain for "connect" packets that limits it to 5 a
second for all servers.
# If you are only protecting one server, you can set the number from
5 down to 2.  Setting it
# at 2 means only 2 players could connect to the server per second. 
Set LIMITCHLG to the
# same, as there is one getchallenge/connect packet sequence per
valid player connection.
iptables -N LIMITCONN
iptables -A LIMITCONN -p udp -m limit --limit 5/sec --limit-burst 5
-j ACCEPT
iptables -A LIMITCONN -p udp -j DROP

# Add a limit chain that prevents more than 70 packets a second per
player. # This is the main logic of ServerArk, but just performed by
an iptable rule.
# We allow up to 128 players which is enough for 4 servers full (at
32 players each).
# If you only have one server, you could the size and max to 32.
# If you have players who have manually set their packet rate up to
100, just change the 70 to 100.
iptables -N LIMITPLRS
iptables -A LIMITPLRS -p udp -m hashlimit --hashlimit-name PLAYERS
--hashlimit-above 70/sec --hashlimit-burst 70 --hashlimit-mode
srcip,srcport --hashlimit-htable-size 128 --hashlimit-htable-max 128
--hashlimit-htable-gcinterval 1000 --hashlimit-htable-expire 10000 -j
DROP iptables -A LIMITPLRS -p udp -j ACCEPT

# Add the rules to pick out the various special packets and send them
to appropriate limit chains.
# To protect 5 ports, just specify a range like "--dport 28960:28964"
below. iptables -A INPUT -p udp --dport 28960-m string --string
"getstatus" --algo bm --from 32 --to 33 -j LIMITSTAT
iptables -A INPUT -p udp --dport 28960-m string --string "getinfo"
--algo bm --from 32 --to 33 -j LIMITINFO
iptables -A INPUT -p udp --dport 28960-m string --string
"getchallenge" --algo bm --from 32 --to 33 -j LIMITCHLG
iptables -A INPUT -p udp --dport 28960-m string --string "connect"
--algo bm --from 32 --to 33 -j LIMITCONN

# Send all other packets (normal player packets) to the limit players
chain. # A port range like "--dport 28960:28964" could also be used
here as well. iptables -A INPUT -p udp --dport 28960-j LIMITPLRS
/
/Also, you can do an "iptables -L -v -n" to see what kind of attacks
these rules have blocked.  Here's an example of this command after a
"getchallenge" flood attack from random IPs, on our Dallas server
running on port 29070.

ew@server1:~$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 11368 packets, 1538K bytes)
  pkts bytes target     prot opt in     out     source
destination
  3880  177K LIMITSTAT  udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           udp dpt:29070 STRING match "getstatus" ALGO name
bm FROM 32 TO 33
14036  617K LIMITINFO  udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           udp dpt:29070 STRING match "getinfo" ALGO name bm
FROM 32 TO 33
   37M 1620M LIMITCHLG  udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           udp dpt:29070 STRING match "getchallenge" ALGO
name bm FROM 32 TO 33
    17  4989 LIMITCONN  udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           udp dpt:29070 STRING match "connect" ALGO name bm
FROM 32 TO 33
  237K   17M LIMITPLRS  udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           udp dpt:29070

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 343K packets, 54M bytes)
  pkts bytes target     prot opt in     out     source
destination

Chain LIMITCHLG (1 references)
  pkts bytes target     prot opt in     out     source
destination
40025 1761K ACCEPT     udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           limit: avg 5/sec burst 5
*37M 1618M DROP*       udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>

Chain LIMITCONN (1 references)
  pkts bytes target     prot opt in     out     source
destination
    17  4989 ACCEPT     udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           limit: avg 5/sec burst 5
     0     0 DROP       udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>

Chain LIMITINFO (1 references)
  pkts bytes target     prot opt in     out     source
destination
14036  617K ACCEPT     udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           limit: avg 10/sec burst 10
     0     0 DROP       udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>

Chain LIMITPLRS (1 references)
  pkts bytes target     prot opt in     out     source
destination
  1642  104K DROP       udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           limit: above 70/sec burst 70 mode srcip-srcport
htable-size 128 htable-max 128
  236K   17M ACCEPT     udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>

Chain LIMITSTAT (1 references)
  pkts bytes target     prot opt in     out     source
destination
  3868  177K ACCEPT     udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>           limit: avg 10/sec burst 10
    12   516 DROP       udp  --  *      *       <a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>
<a moz-do-not-send="true" href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>

Notice the bolded packet/byte statistics for the "getchallenge" drop
chain named LIMITCHLG.  A total of 37 million packets dropped.  I was
on the game during this attack, and although the server did lag a bit
from the sheer size of the flood (almost saturating the bandwidth),
nobody lagged out.  Without this rule, the game server deadlocked.

Also notice you can tell how many players have connected to the
server, as the LIMITCONN status shows 17 packets accepted.  So during
this time we had 17 players join the game.

You can also see how many people requested the servers in game (as
well as other services like GameTracker getting info on you), as that
corresponds to the LIMITSTAT and LIMITINFO chains.

Another cool thing you can do is "cat /proc/srv/ipt_hashlimit/PLAYERS
to see the IP addresses of all the players currently connected to the
server(s).  Once a player quits playing, he goes out of this file
automatically after 10 seconds.

I may refine these a bit further, but for now, these seem to be
working well on our VPS.

Thanks,

/Boyd/
</pre>
                  </blockquote>
                  <pre>_______________________________________________
cod mailing list
<a moz-do-not-send="true" href="mailto:cod@icculus.org" target="_blank">cod@icculus.org</a>
<a moz-do-not-send="true" href="http://icculus.org/mailman/listinfo/cod" target="_blank">http://icculus.org/mailman/listinfo/cod</a>

</pre>
                </blockquote>
              </div>
            </div>
          </div>
          <br>
          _______________________________________________<br>
          cod mailing list<br>
          <a moz-do-not-send="true" href="mailto:cod@icculus.org"
            target="_blank">cod@icculus.org</a><br>
          <a moz-do-not-send="true"
            href="http://icculus.org/mailman/listinfo/cod"
            target="_blank">http://icculus.org/mailman/listinfo/cod</a><br>
          <br>
        </blockquote>
      </div>
      <br>
      <br clear="all">
      <br>
      -- <br>
      <div>EscapedTurkey.com Billing and Support<br>
      </div>
      <div><a moz-do-not-send="true"
          href="https://www.escapedturkey.com/helpdesk" target="_blank">https://www.escapedturkey.com/helpdesk</a></div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cod mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cod@icculus.org">cod@icculus.org</a>
<a class="moz-txt-link-freetext" href="http://icculus.org/mailman/listinfo/cod">http://icculus.org/mailman/listinfo/cod</a>
</pre>
    </blockquote>
  </body>
</html>