<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    Thank you, I assumed it was these iptables problem, because i had
    never before these problems. With less strict do you mean these
    line:<br>
    <br>
    iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
    --hashlimit-name getstatus --hashlimit-above 2/second -j QUERY-BLOCK<br>
    <br>
    to rise up these value (2 second)? Or maybe some other too?<br>
    <br>
    Thank you<br>
    <br>
    <pre class="moz-signature" cols="72">Andrej

+386 31 247 707
<a class="moz-txt-link-abbreviated" href="mailto:aparovel@gmail.com">aparovel@gmail.com</a></pre>
    <br>
    On 28.1.2012 20:52, B.M. Schiltmans wrote:
    <blockquote cite="mid:4F2451E5.8020003@planet.nl" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      If you're using hlsw as rcon-tool, then yes I noticed that too.<br>
      Since hlsw is querying your server at quite a high rate, your
      filters start dropping traffic. Ergo, no query-result and no rcon.<br>
      When you shut hlsw down, your filters relax and you can connect
      again.<br>
      Not sure if the query-interval is settable in hlsw, but you could
      always try setting your filters a little less strict.<br>
      <br>
      Hope that helps.<br>
      <br>
      Grtz<br>
      Bram<br>
      <br>
      On 28-1-2012 20:35, Andrej Parovel wrote:
      <blockquote cite="mid:4F244E0C.2010300@gmail.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        Hello,<br>
        <br>
        Did maybe anybody notice or have the problem when applying
        iptables script witch is in the reply, that you can't then
        connect on RCON and also I can't reach my servers over HSLSW,
        but you can connect on the server and it is actualy running ok.<br>
        Just rcon connecting problems and HSLW reaching.<br>
        <br>
        Thank you.<br>
        <br>
        <pre class="moz-signature" cols="72">Andrej

+386 31 247 707
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:aparovel@gmail.com">aparovel@gmail.com</a></pre>
        <br>
        On 21.1.2012 1:51, John wrote:
        <blockquote cite="mid:4F1A0C13.9080503@nuclearfallout.net"
          type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          On 1/20/2012 3:27 PM, Marco Padovan wrote:
          <blockquote cite="mid:4F19F85D.3050405@evcz.tk" type="cite"><font
              size="-1"><font face="Verdana">I was referring to dynamic
                filtering using -m recent<br>
                <br>
                [not] to manually adding IPs O.o</font></font></blockquote>
          <br>
          Marco's right about this. The most effective way to prevent
          effects from these attacks on Linux is to use a combination of
          the "string", "hashlimit", and "recent" modules. Done right,
          the solution is mostly automatic, so you shouldn't need to
          manually add IPs.<br>
          <br>
          These commands, for instance, would block external IPs that
          send queries at a rate of 2/second or higher:<br>
          <br>
          # add a host to the banlist and then drop the packet.<br>
          iptables -N QUERY-BLOCK<br>
          iptables -A QUERY-BLOCK -m recent --set --name blocked-hosts
          -j DROP<br>
          <br>
          # is this a query packet? if so, block commonly attacked ports
          outright, <br>
          # then see if it's a known attacking IP, then see if it is
          sending at a high<br>
          # rate and should be added to the list of known attacking IPs.<br>
          iptables -N QUERY-CHECK<br>
          iptables -A QUERY-CHECK -p udp -m string ! --string
          "getstatus" --algo bm --from 32 --to 41 -j RETURN<br>
          iptables -A QUERY-CHECK -p udp --sport 0:1025 -j DROP<br>
          iptables -A QUERY-CHECK -p udp --sport 3074 -j DROP<br>
          iptables -A QUERY-CHECK -p udp --sport 7777 -j DROP<br>
          iptables -A QUERY-CHECK -p udp --sport 27015:27100 -j DROP<br>
          iptables -A QUERY-CHECK -p udp --sport 25200 -j DROP<br>
          iptables -A QUERY-CHECK -p udp --sport 25565 -j DROP<br>
          # is it already blocked? continue blocking it and update the
          counter so it<br>
          # gets blocked for at least another 30 seconds.<br>
          iptables -A QUERY-CHECK -m recent --update --name
          blocked-hosts --seconds 30 --hitcount 1 -j DROP<br>
          # check to see if it exceeds our rate threshold,<br>
          # and add it to the list if it does.<br>
          iptables -A QUERY-CHECK -m hashlimit --hashlimit-mode srcip
          --hashlimit-name getstatus --hashlimit-above 2/second -j
          QUERY-BLOCK<br>
          <br>
          # look at all the packets going to q3/cod*/et/etc servers<br>
          iptables -A INPUT -p udp --dport 27960:29000 -j QUERY-CHECK<br>
          <br>
          The "recent" module makes it possible to block up to 100 IPs
          at once with this method (any attackers beyond this would only
          be rate-limited). That number can be raised when the module is
          loaded, but I haven't seen 100 attacks happening at once yet
          (typically it's maybe 5-20 at once). You can see blocked hosts
          later by looking at /proc/net/xt_recent/blocked-hosts.<br>
          <br>
          (If you don't have "recent", you could get away without it --
          just be aware that some of the packets will get through,
          increasing load on the game server. Without "hashlimit", you'd
          still see an advantage from the port checks, but you'd need to
          manually block IPs that are being hit on other ports. Without
          "string", you'd similarly be down to just port checks, and
          need to take out the other rules.)<br>
          <br>
          -John<br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
cod mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:cod@icculus.org">cod@icculus.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://icculus.org/mailman/listinfo/cod">http://icculus.org/mailman/listinfo/cod</a>
</pre>
        </blockquote>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
cod mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:cod@icculus.org">cod@icculus.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://icculus.org/mailman/listinfo/cod">http://icculus.org/mailman/listinfo/cod</a>
</pre>
      </blockquote>
      <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>