iptables recent / more than one exception

[Reindl Harald]

Am 05.05.2012 02:31, schrieb jdow:
>>> I don't know nessus. I am guessing that "-n 1000" part means 1000 trials
>>> and it's running as fast as it can go. The idea is to test up to your
>>> DDOS limit, wait 2 seconds, repeat. Can the test be hacked to keep your
>>> system at its limit but not over its limit?
>>
>> no idea, even if it would not help becasue a company
>> only doing certified secsancs will never change them
>> especially if your customer is their customer....
>>
>> but i found a solution!
>>
>> with "--remove" you can remove the given IP from the iptables-list
>> before the REJECT action is triggered and this way add as much
>> networks / addresses you need
>>
>>
>> $IPTABLES -I INPUT -p tcp -i eth0 ! -s $LAN_RANGE -m state --state NEW -m recent --set
>> $IPTABLES -I INPUT -p tcp -i eth0 -s $SECURITY_SCAN -m state --state NEW -m recent --remove
>> $IPTABLES -I INPUT -p tcp -i eth0 ! -s $LAN_RANGE -m state --state NEW -m recent --update --seconds 1 --hitcount 75
>> -j REJECT --reject-with tcp-reset
>> $IPTABLES -I INPUT -p tcp -i eth0 ! -s $LAN_RANGE -m state --state NEW -m recent --update --seconds 1 --hitcount 75
>> -m limit --limit 60/h -j LOG --log-prefix "Rate-Control: "
> 
> As long as that does not break other iptables based protections it's a
> good enough solution. I presume you did audit the iptables setup for that
> possibility.

yes it is fine because it only affects "recent" rules with
"name: DEFAULT" and they are all on top of other rules

there are two others rejecting every connection for two seconds
after trying any port before interesting ones or typically
not public services to make portscans as hard as possible

/sbin/iptables --list --numeric --verbose | grep -v LOG | grep recent

   75  4800 REJECT     tcp  --  eth0   *      !LAN          0.0.0.0/0            state NEW recent: UPDATE seconds:
1 hit_count: 75 name: DEFAULT side: source reject-with tcp-reset
64455 3866K            tcp  --  eth0   *       SECSAN       0.0.0.0/0            state NEW recent: REMOVE name:
DEFAULT side: source
 157K 9125K            tcp  --  eth0   *      !LAN          0.0.0.0/0            state NEW recent: SET name:
DEFAULT side: source
    0     0 REJECT     tcp  --  !lo    *      !LAN          0.0.0.0/0            recent: CHECK seconds: 2 name:
portscan1 side: source reject-with tcp-reset
    0     0            tcp  --  !lo    *      !LAN          0.0.0.0/0            recent: REMOVE name: portscan1
side: source
    0     0 REJECT     tcp  --  !lo    *      !LAN          0.0.0.0/0            multiport dports
19,24,52,79,109,142,442,464,548,586,631,992,994,3305 tcp recent: SET name: portscan1 side: source reject-with tcp-reset
  578 28816 REJECT     tcp  --  !lo    *      !LAN          0.0.0.0/0            recent: CHECK seconds: 2 name:
portscan2 side: source reject-with tcp-reset
   25  1280            tcp  --  !lo    *      !LAN          0.0.0.0/0            recent: REMOVE name: portscan2
side: source
  338 16864 REJECT     tcp  --  !lo    *      !LAN          0.0.0.0/0            multiport dports
23,137,138,139,445,3389,5900 tcp recent: SET name: portscan2 side: source reject-with tcp-reset

> (As an aside the scan company should learn to adapt as more and more
> customers learn this trick and deploy it.)

i fear we are the first ones with such iptables rules and
good mod_security implementation (also had to whitelist)
they saw :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120505/40e9b0af/attachment.sig>