Re: IPTables limits?

Rick Stevens <ricks@xxxxxxxx> · Wed, 22 Oct 2008 11:30:19 -0700

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@xxxxxxxx -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-  Memory is the second thing to go, but I can't remember the first! -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@xxxxxxxxxx
Subject: unsubscribe