Re: connlimit modul doesn't works as expected

2018-03-11 Thread Florian Westphal 
Toralf Förster  wrote:
> On 03/10/2018 10:16 PM, Florian Westphal wrote:
> > Toralf Förster  wrote:
> >> At my server (stable hardened Gentoo with vanilla 4.15.7) I do have this 
> >> rule:
> >>
> >> /sbin/iptables -A OUTPUT -p tcp --destination-port 443 --syn --match 
> >> connlimit --connlimit-above 3000 --connlimit-mask 0 --connlimit-daddr 
> >> --match limit --limit 1/second --limit-burst 1 -j LOG --log-prefix "443 
> >> hammered "
> >>
> >> Sometimes (usually after 2-4 days uptime) however this rule fires too 
> >> often - even over hours.
> >>
> >> When I restart the iptable script then the rule stopps to fire. This 
> >> happened few times in a row over the last weeks. So I'm convinced that 
> >> there wasn't an external event related to this behaviour.
> > 
> > You could check via conntrack -L.
> 
> HHm, the output of "conntrack -L" let me wonder if the rule gave the output I 
> wanted to achieve.
> I'd like to get a log entry, if there are more than 3,000 new SYN connections 
> within the last second, not, if there are 3,000 SYN at all.

connlimit keeps state of total connetions.
So if there are 3000 outgoing connections to port 443, and there is one
more, then connlimit will start to match.

AFAIU from your description you should replace connlimit with

-m hashlimit --hashlimit-above 3003/sec --hashlimit-name synhash

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

Re: connlimit modul doesn't works as expected

2018-03-11 Thread Toralf Förster 
On 03/10/2018 10:16 PM, Florian Westphal wrote:
> Toralf Förster  wrote:
>> At my server (stable hardened Gentoo with vanilla 4.15.7) I do have this 
>> rule:
>>
>> /sbin/iptables -A OUTPUT -p tcp --destination-port 443 --syn --match 
>> connlimit --connlimit-above 3000 --connlimit-mask 0 --connlimit-daddr 
>> --match limit --limit 1/second --limit-burst 1 -j LOG --log-prefix "443 
>> hammered "
>>
>> Sometimes (usually after 2-4 days uptime) however this rule fires too often 
>> - even over hours.
>>
>> When I restart the iptable script then the rule stopps to fire. This 
>> happened few times in a row over the last weeks. So I'm convinced that there 
>> wasn't an external event related to this behaviour.
> 
> You could check via conntrack -L.

HHm, the output of "conntrack -L" let me wonder if the rule gave the output I 
wanted to achieve.
I'd like to get a log entry, if there are more than 3,000 new SYN connections 
within the last second, not, if there are 3,000 SYN at all.
So I'm pretty unsure, if the iptables rule is the right one?

-- 
Toralf
PGP C4EACDDE 0076E94E
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: connlimit modul doesn't works as expected

2018-03-11 Thread Toralf Förster 
On 03/10/2018 10:16 PM, Florian Westphal wrote:

> You could check via conntrack -L.

# conntrack -L | wc -l
conntrack v1.4.2 (conntrack-tools): 39698 flow entries have been shown.
39698

Many lines ...

-- 
Toralf
PGP C4EACDDE 0076E94E
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: connlimit modul doesn't works as expected

2018-03-10 Thread Florian Westphal 
Toralf Förster  wrote:
> At my server (stable hardened Gentoo with vanilla 4.15.7) I do have this rule:
> 
> /sbin/iptables -A OUTPUT -p tcp --destination-port 443 --syn --match 
> connlimit --connlimit-above 3000 --connlimit-mask 0 --connlimit-daddr --match 
> limit --limit 1/second --limit-burst 1 -j LOG --log-prefix "443 hammered "
> 
> Sometimes (usually after 2-4 days uptime) however this rule fires too often - 
> even over hours.
> 
> When I restart the iptable script then the rule stopps to fire. This happened 
> few times in a row over the last weeks. So I'm convinced that there wasn't an 
> external event related to this behaviour.

You could check via conntrack -L.
Restarting works because it clears the connlimit state.

> Known issue?

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