is there any way to specify here more than one source-address (the usual comma seperated way does not work in this context) a complete ACCEPT before is no solution because it would bypass any selective ACCEPT-rule 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

Am 03.05.2012 19:46, schrieb Paul W. Frields: > On Thu, May 03, 2012 at 04:21:20PM +0200, Reindl Harald wrote: >> is there any way to specify here more than one source-address >> (the usual comma seperated way does not work in this context) >> >> a complete ACCEPT before is no solution because it would bypass >> any selective ACCEPT-rule >> >> 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 and it will get hard to arue that we can not whitelist him in this case :-(

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

Am 04.05.2012 11:37, schrieb jdow: > 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. my sshd has a sepearte rule the intention of this rule is not to block it is a rate-control against DOS attacks since we had "Anonymous" with a distributed DOS attack last week i can say it works damned good - after replacing a burned down router :-) clearly you can not stand the whole DDOS from some thousand source IPs but it gives you enough time to filter them for a DROP rule - without this ratecontrol you could not operate on the machine before the DDOS it was limited to 100 connections/ip/second which results in "ab -c 50 -n 50000 http://host-on-machine/" raise CPU load up to 100% for a short time, go down to 50% and changing between this both states (sorry baout bad english) with 75 instead of 100 evebn a "ab -c 4 -n 1000" is completly broken from outside the own network because "apache benchmark" thinks the host is dead after 83 connections and stops due too many errors - well, i guess exactly that is the problem for Nessus/OpenVAS and such software from outside now they triggered it all time before with portscans but only not notice

Am 05.05.2012 00:31, schrieb jdow: >> with 75 instead of 100 evebn a "ab -c 4 -n 1000" is completly >> broken from outside the own network because "apache benchmark" >> thinks the host is dead after 83 connections and stops due too >> many errors - well, i guess exactly that is the problem for >> Nessus/OpenVAS and such software from outside now >> >> they triggered it all time before with portscans but only >> not notice > > What happens with something like this (PDL sorta kinda)? > > while( 1 ) > { > "ab -c 4 -n 50" > Sleep( 2 ) > } > > 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, evenif 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: "

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 :-)