IPTables limits?

[Andrew Kelly]

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". 
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.

Andy

> > I have installed fail2ban, which blacklists for a shorter amount of
> > time, I suspect under the theory that ssh attacks are almost random, and
> > will pass.
> 
> Yeah, it works.  Mine has minimal impact on the rulesets, but either
> is fine.
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer                      ricks at nerd.com -
> - AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
> -                                                                    -
> -              Death is nature's way of dropping carrier             -
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe