Re: iptables recent / more than one exception

Reindl Harald <h.reindl@xxxxxxxxxxxxx> · Fri, 04 May 2012 10:15:05 +0200


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