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 :-)
Attachment:
signature.asc
Description: OpenPGP digital signature
-- 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
