IPTables limits?

[Rick Stevens]

Andrew Kelly wrote:
> On Tue, 2008-10-21 at 11:12 -0700, Rick Stevens wrote:
>> Karl Pearson wrote:
>>> On Tue, October 21, 2008 11:16 am, Rick Stevens wrote:
>>>> Karl Pearson wrote:
>>>>> I'm curious if there's a limit on how many iptables entries it takes
>>>>> to
>>>>> hammer a system. Okay, a better question: When am I running the risk
>>>>> of
>>>>> messing up my IP traffic if I add DROP entries in the INPUT rule of
>>>>> iptables?
>>>> You do ask the damndest questions, Karl!  :-)
>>>>
>>>> I've never seen a document that describes any rule limits.  It is a
>>>> kernel module, so one must assume there is some limit.  It may be that
>>>> a spelunking sesion through the source might answer that.
>>>>
>>>> I've got lots of drop entries on my rules and haven't had any issues,
>>>> but I'm always guided by the concept that the more rules a packet must
>>>> traverse, the slower the connection will be at startup.  Therefore I
>>>> order my rules carefully putting the more generic rules at the top of
>>>> the list and the more specific ones at the bottom.  That may not work
>>>> for you...every network is a little different (for example, we blacklist
>>>> entire /8 networks in some cases because of DOS or hack attacks from
>>>> those countries).
>>> I'd love a list of those IPs and how you inserted the rule.
>> Oh, man, I'd have to go through our firewall configs to dig up the
>> addresses involved.  As far as the rule insertion, it's pretty much
>> a standard iptables insert, but we add a "--syn" for TCP and just
>> simply block UDP.  These are interim...eventually we migrate these
>> rules out to our Foundry or Cisco routers and remove them from the
>> individual servers.
>>
>>>                                                               I also
>>> wonder about DROP vs REJECT. I know the difference, but what's the
>>> theory behind using one over the other? I have thought it is about them
>>> knowing the IP is there vs just a hang. But, I'm wondering if the DROP
>>> (hang) causes me any headaches in IP traffic limiting? I know, another
>>> annoying question.
>> We use DROP.  If we're under attack or someone's probing, why let them
>> know they found a machine?  If anything, a DROP is easier on the system
>> than a REJECT since all the system does is drop the connection...it
>> doesn't send anything back.  And if the prober/attacker's connection
>> hangs at his end, good!  Screw them in the first place.  Attackers
>> and probers deserve absolutely no consideration in any way and should
>> be prosecuted in the same manner as someone trying to break into my home
>> or office.
>>
>>> All my DROPs are in the first rule, so they are immediately acted on, or
>>> in this case, DROPped.
>>>
>>> I used to use sshblack, but the way the logfiles are written now make it
>>> ineffective for inbound, however I wrote my own blacklist scripts which
>>> I use with it, so it does do aging checks, which for DDNS is okay, I
>>> think.
>> For SSH issues, I have a standard ruleset.  Here it is from the
>> /etc/sysconfig/iptables file:
>>
>> # This rejects ssh attempts more than twice in 180 seconds...
>> # First, mark attempts as part of the "sshattack" group...
>> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
>> # Optional: Include this line if you want to log these attacks...
>> #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck 
>> --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: "
>> # Finally, reject the connection if more than one attempt is made in 180 
>> seconds...
>> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck 
>> --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset
>>
>> So, you only get to try to SSH once every 3 minutes.  You can tweak the
>> "--hitcount" value and "--seconds" value to customize it for your use.
>> It foils most of the script kiddies out there.
> 
> Unfortunately, it also foils legitimate accesses often enough. This is a
> very effective set up, but it comes with the caveat that "connection
> requests" are counted, and not "connection requests from IP address
> such-and-such".

No, it tracks the source IP.  Two attempts from the same source IP
trigger the lockout.

> When I'm at work and need to access one of my boxes, no problem. I have
> an accept rule for my LAN immediately in front of the gauntlet. But when
> I'm at home and need to do something for whatever reason, I'm coming in
> on a dynamic IP addy and almost always hit the wall because the scripts
> have been there before me. It's not a show-stopper, but it gets annoying
> having to first take a detour to a quieter box that is covered under the
> ACCEPT rule.

That works, but again, the ipt_recent module tracks source IPs.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks at nerd.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-  Memory is the second thing to go, but I can't remember the first! -
----------------------------------------------------------------------