On 2012/05/04 23:42, Reindl Harald wrote:
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 :-)
It feels REALLY good when you can stay on top of the other professionals,
right? Hopefully that also is keeping you ahead of the malicious creeps.
Congratulations.
{^_^}
--
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
