From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Irwin L." <biatche@gmail.com>
Cc: netfilter@vger.kernel.org
Subject: Re: nftables: drop ssh brute force with ip block
Date: Thu, 23 Jun 2016 13:01:32 +0200 [thread overview]
Message-ID: <20160623110132.GB2149@salvia> (raw)
In-Reply-To: <576BC023.4040001@gmail.com>
On Thu, Jun 23, 2016 at 06:55:31PM +0800, Irwin L. wrote:
> On 2016-06-23 18:48, Pablo Neira Ayuso wrote:
> >On Thu, Jun 23, 2016 at 06:39:46PM +0800, Irwin L. wrote:
> >>I currently use:
> >>tcp dport {22222,40022,42222} ct state new counter flow table bruteforce {
> >>ip saddr limit rate 3/minute } counter accept comment "limit bruteforce"
> >>
> >>Is this ok?
> >Looks good to me. I would probably check for ct state new in first
> >place, given that this only matches the first packet a new TCP
> >connections. It will save you the tcp dport set lookup.
> >
> >Note that you can even limit this per port, ie.
> >
> > ct state new tcp dport {22222,40022,42222} counter \
> > flow table bruteforce { ip saddr . tcp dport limit rate 3/minute } \
> > counter accept comment "limit bruteforce"
> >
> >using the 'ip saddr . tcp dport' concatenation. But I guess you want
> >globally ban anyone spamming you to those ports anyway.
> >
> >>I wanted to ban spamming ips altogether, but I've since learned that this is
> >>the job of 'fail2ban'
>
> >fail2ban is nice to have to simplify this administrative hassle, but I
> >think it is still using iptables (it's been a while a I didn't look at
> >that code), we can do much better now with nft to resolve this problem.
>
> By that do you mean "counter ct state new" instead of "counter flow table" ?
>
> Thing is with this method, it only limits, I wonder if nft can blacklist the
> ip for 1 day or even 1 week with the option of manually removing blacklisted
> ips manually.
>
I mean, instead of:
tcp dport {22222,40022,42222} ct state new counter
use this:
ct state new tcp dport {22222,40022,42222} counter
so just place the 'ct state new' check in first place, as most packets
will not go further in the rule evaluation, given that the rule
evaluation happens from left to right. If one of the statements
evaluates false, we stop evaluating and look at the next rule.
prev parent reply other threads:[~2016-06-23 11:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-19 18:24 nftables: drop ssh brute force with ip block Irwin L.
2016-06-23 10:34 ` Pablo Neira Ayuso
2016-06-23 10:39 ` Irwin L.
2016-06-23 10:48 ` Pablo Neira Ayuso
2016-06-23 10:55 ` Irwin L.
2016-06-23 11:01 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160623110132.GB2149@salvia \
--to=pablo@netfilter.org \
--cc=biatche@gmail.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox