Re: iptables recent / more than one exception

jdow <jdow@xxxxxxxxxxxxx> · Fri, 04 May 2012 02:37:30 -0700

On 2012/05/04 01:15, Reindl Harald wrote:

Am 04.05.2012 03:10, schrieb jdow:

On 2012/05/03 10:57, Reindl Harald wrote:

Am 03.05.2012 19:46, schrieb Paul W. Frields:

On Thu, May 03, 2012 at 04:21:20PM +0200, Reindl Harald wrote:

iptables -I INPUT -p tcp -i eth0 ! -s $LOCAL_NETWORK -m state --state NEW -m recent --set
iptables -I INPUT -p tcp -i eth0 ! -s $LOCAL_NETWORK -m state --state NEW -m recent --update --seconds 1
--hitcount  75 -j REJECT --reject-with tcp-reset

Even when you use comma-separated addresses (allowed when not using
the '!' operator), iptables actually creates separate rules in
response to the command.  I believe that's what you need to do in this
situation

in theory yes
but practically the reject of this rule would be triggered

a secuity auditor from a customer is whining the he no longer
can make security-scans

Ah, wait a minute. If he cannot make security scans neither can
anybody else. So defacto his job is finished.

this is the naive view :-)

the reality in business-to-business relationships is that
such scans are done with standard software like Nessus
and if this stops the job is not done - if you are
speaking about a big customer with a policy which requires
sec-audits yu can not say "it is done"

a real attacker does not need nessus

he plays around with params manually to find sql-injections
and so on without triggering any rate-control and maybe
even bypassing mod_security or whatever application fierwall

For any exception you place into the rules to allow him to scan you must
think VERY carefully what it's effects will be. You might accidentally
open up the internal network to him leading to a false positive detection
from his security scan.

i know this, that is the reason why i like to exclude him only
from the rate-control as also done with mod_security

So he's not REALLY testing your security profile, is he? He should be
nibbling around the edges, too.

But, then, I note your setting with --recent is not nearly as stringent as
mine. Any given address gets one connection per minute to ssh. That VASTLY
slows down dictionary attacks. Yours is a significant slow down; but, not
so much that somebody could not, as you put it, nibble around the edges to
get in. You have slowed down such attacks, though. That is good.

It would be handy if there was an iptables rule that allowed skipping the
next rule in order if the special rule hit. Alas, I am unaware of such a
trick potential.

{^_^}
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org