Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2011-10-22 at 10:43 +0200, Azerty Ytreza wrote:
> I use these rules by the past for limit number of connections during
> some seconds and block connections if they are too many attempt.
> 
> Old rules which work very well :
> ***************************************
> iptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state NEW -m
> recent --set
> iptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state NEW -m
> recent --update --seconds 60 --hitcount 10 -j DROP
> #ptables -A INPUT -i eth1 -p tcp --dport 443 -m state --state
> NEW,ESTABLISHED -j ACCEPT
> ***************************************
> 
> I have adapted this rules for a FORWARD rules and doesn't work :

What exactly are you trying to achieve? If you're changing to a FORWARD
rule then I assume that you are trying to adapt your rules in order to
block connections destined for a remote server, rather than the local
host?

> ***************************************
> iptables -A INPUT -i eth1 -p udp -m udp --dport 443 -m state --state
> NEW -m recent --set
> iptables -A INPUT -i eth1 -p udp -m udp --dport 443 -m recent --update
> --seconds 60 --hitcount 10 -j DROP

Do you really mean UDP?

> iptables -A FORWARD -i eth1 -p udp -m udp --dport 443 -m state --state
> NEW,ESTABLISHED -j ACCEPT

You've got a mixture of INPUT and FORWARD. Is that what you want?
Remember that packets will never transverse both the INPUT and FORWARD
chains.

> iptables -t nat -A PREROUTING -i eth1 -p udp -m udp --dport 443 -j
> DNAT --to-destination 192.168.1.2:443
> ***************************************
> 
> Someone can explain me why these rules doesn't block request when
> hitcount is reached ?
> I have try other method and put "hitcount" on the FORWARD rules
> directly but it's not work, I have an error from iptables which
> doesn't accept "--set" on a FORWARD request. I doesn't remember error
> but it's probably not the good method.
> 


--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux