Cannot add ip6 elements to a named set

Cannot add ip6 elements to a named set

[Matt]

Dear nft team,
with ip4 i can create my set and add elements no problem, sample:

table ip filter_v4 {
    set my_drop {
      type ipv4_addr;
      flags timeout
    }
  ...
  ...
}
Then adding a element to it, works all good:
# nft add set filter_v4 my_drop \{type ipv4_addr \; flags timeout \; 
elements=\{192.168.1.1 timeout 60s\} \;\}


But I would like to do the same with ip6:

table ip6 filter_v6 {
    set my_drop {
      type ipv6_addr;
      flags timeout
    }
  ...
  ...
}

However, doing the same with ipv6 doesn't work for me:
#nft add set filter_v6 my_drop \{type ipv6_addr \; flags timeout \; 
elements=\{fda5:2c8a:af4c:a95e::64 timeout 60s\} \;\}

Returns
Error: Could not process rule: No such file or directory
add set filter_v6 my_drop {type ipv6_addr ; flags timeout ; 
elements={fda5:2c8a:af4c:a95e::64 timeout 60s} ;}
         ^^^^^^^^^


Any idea whats wrong?
Thx
Matt

Re: Cannot add ip6 elements to a named set

[Florian Westphal]

Matt <matt-nft@mailtower.de> wrote:
> However, doing the same with ipv6 doesn't work for me:
> #nft add set filter_v6 my_drop \{type ipv6_addr \; flags timeout \;
> elements=\{fda5:2c8a:af4c:a95e::64 timeout 60s\} \;\}

Try:
nft add set ip6 filter_v6 ...

minor change recommendation for https://wiki.nftables.org

[Matt]

Dear nft team,
may i recommend a small change on the nft wiki on the page "Sets" ?
instead of
% nft add set filter saddrs {type ipv4_addr \; size 2 \;}

add the proto (valid ip or ip6)
% nft add set ip filter saddrs {type ipv4_addr \; size 2 \;}


because that had lead me into the below question

Cheers
Matt



On 2019-10-04 16:58, Florian Westphal wrote:
> Matt <matt-nft@mailtower.de> wrote:
>> However, doing the same with ipv6 doesn't work for me:
>> #nft add set filter_v6 my_drop \{type ipv6_addr \; flags timeout \;
>> elements=\{fda5:2c8a:af4c:a95e::64 timeout 60s\} \;\}
> 
> Try:
> nft add set ip6 filter_v6 ...

One more application available for nftables

[Matt]

Dear Forum,
I'd like to announce a new application which runs on nftables, I've 
named it "fail2nft".

The application takes care about unwanted ssh (and other)  logins.

If you are interested, then please see: 
https://coolscript.org/index.php/Fail2nft

Thanks for assistance.
Matt

Re: One more application available for nftables

[Trent W. Buck]

Matt <matt-nft@mailtower.de> writes:

> I'd like to announce a new application which runs on nftables,
> I've named it "fail2nft".
> https://coolscript.org/index.php/Fail2nft

Here's my quick review as a non-expert bystander.
(This is a critique of the code, NOT the author!)

That page needs a section "why choose fail2nft over existing products?" :-)

 * sshguard is lex/yacc (C) that reads logs journal/syslog/NCSA
   and runs a helper script to add/remove block rules.
   Adding new match rules requires a recompile.
   It blocks everything by default (on Debian, via nftables).

   https://bitbucket.org/sshguard/sshguard/src/master/src/fw/sshg-fw-nft-sets.sh

   It's about 2KLOC (slightly bigger than fail2nft).

 * fail2ban is python and uses regular expressions to look for attacks.
   It's configured via a huge mess of .ini files.
   It blocks nothing (except SSH?) by default (on Debian, via xtables).

   https://github.com/fail2ban/fail2ban/blob/0.11/config/action.d/nftables.conf

   It's about 17KLOC (much bigger than fail2nft).

perlcritic (a.k.a. "use criticism;") was very unhappy about
https://coolscript.org/download/fail2nft-installer.pl and
https://coolscript.org/download/fail2nft.tar.gz:usr/local/fail2nft/fail2nft.pl

I recommend fixing pretty much everything perlcritic complains about.
(note that by default, it only emits "high severity" complaints.)

I recommend making fail2nft's git (or whatever VCS) repo publicly
visible, and having versioned release tarballs
(fail2nft-0.9.tar.gz, not fail2nft.tar.gz).


The persistence across reboots via sqlite is interesting.


I haven't nitpicked your
usr/local/fail2nft/install/usr/sbin/nftinit-*.nft in detail.
The overall style looks reasonable.

I suggest explicitly putting "fail2nft" in your table/chain names, and
running them at "priority filter - 5" or so (i.e. before the default
"priority filter").  At that point, your fail2nft table can do nothing
but drop attacker sets, and all the normal rules can live somewhere else.
(See the sshguard link above for an example.)

I know your index.php says it's not for routers yet, but I *strongly*
recommend you hook into INPUT *and* FORWARD, where currently you only
hook into INPUT.  This will handle the easy 80% of routers in only a
couple of extra lines.

I see you're matching vsftpd.  I very very strongly recommend
you... encourage your end users to switch from FTP to SFTP.  :-)
(Many (most?) Windows FTP clients can do SFTP these days.)

Re: One more application available for nftables

[Alessandro Vesely]

On Mon 18/Nov/2019 03:43:32 +0100 Trent W. Buck wrote:
> That page needs a section "why choose fail2nft over existing products?" :-)
> 
>  * sshguard is lex/yacc (C) that reads logs journal/syslog/NCSA
>    and runs a helper script to add/remove block rules.
>    Adding new match rules requires a recompile.
>    It blocks everything by default (on Debian, via nftables).
> 
>    https://bitbucket.org/sshguard/sshguard/src/master/src/fw/sshg-fw-nft-sets.sh
> 
>    It's about 2KLOC (slightly bigger than fail2nft).
> 
>  * fail2ban is python and uses regular expressions to look for attacks.
>    It's configured via a huge mess of .ini files.
>    It blocks nothing (except SSH?) by default (on Debian, via xtables).
> 
>    https://github.com/fail2ban/fail2ban/blob/0.11/config/action.d/nftables.conf
> 
>    It's about 17KLOC (much bigger than fail2nft).

* ipqbdb is C with PCRE to read a piped log file,
  requires custom setup of regexes and iptables -j NFQUEUE --queue-num N,
  the queue filtering daemon(s) can mark or drop based on Berkeley DB.

  https://savannah.nongnu.org/projects/ipqbdb/

  Less than 10KLOC, including utilities to manage the database.


Best
Ale

Re: One more application available for nftables

[zrm]

On 11/17/19 21:43, Trent W. Buck wrote:

> I see you're matching vsftpd.  I very very strongly recommend
> you... encourage your end users to switch from FTP to SFTP.  :-)
> (Many (most?) Windows FTP clients can do SFTP these days.)
> 

It's always fun to see the systems people and the network people argue 
over this.

Everybody should obviously discontinue using plaintext FTP, but FTPS 
(i.e. FTP over TLS) is a thing that exists, and is generally a much 
smaller configuration change for an existing FTP service than switching 
to SFTP (i.e. the SFTP subsystem of the SSH protocol).

Using SFTP also admits a lot of protocol features that you Do Not Want 
if all you're after is file transfers. Configure it a bit wrong and your 
users get a shell, the ability to forward ports from the public address 
of your SFTP server to their client, the ability to forward ports from 
their client to whatever internal hosts they want on the same internal 
network as your SFTP server, a VPN, X11 forwarding etc.

By contrast, the disadvantage of FTPS is that it uses separate control 
and data connections, and because it's encrypted, the firewall can't 
snoop the control connection to see which ports it will use for the data 
connection. So the only way to really make it work is to allow clients 
to make outgoing connections to arbitrary unprivileged ports. Then you 
have to convince the client's network administrator to allow that.

But the alternative is to allow outgoing connections to the SSH port. 
Which, because it's opaque and supports port forwarding and VPN and so 
on, effectively allows the same thing anyway.

Re: One more application available for nftables

[Trent W. Buck]

zrm <zrm@trustiosity.com> writes:

> On 11/17/19 21:43, Trent W. Buck wrote:
>
>> I see you're matching vsftpd.  I very very strongly recommend
>> you... encourage your end users to switch from FTP to SFTP.  :-)
>> (Many (most?) Windows FTP clients can do SFTP these days.)
>>
>
> It's always fun to see the systems people and the network people argue
> over this.
>
> Everybody should obviously discontinue using plaintext FTP, but FTPS
> (i.e. FTP over TLS) is a thing that exists, and is generally a much
> smaller configuration change for an existing FTP service than
> switching to SFTP (i.e. the SFTP subsystem of the SSH protocol).
>
> Using SFTP also admits a lot of protocol features that you Do Not Want
> if all you're after is file transfers. Configure it a bit wrong and
> your users get a shell, the ability to forward ports from the public
> address of your SFTP server to their client, the ability to forward
> ports from their client to whatever internal hosts they want on the
> same internal network as your SFTP server, a VPN, X11 forwarding etc.
>
> By contrast, the disadvantage of FTPS is that it uses separate control
> and data connections, and because it's encrypted, the firewall can't
> snoop the control connection to see which ports it will use for the
> data connection. So the only way to really make it work is to allow
> clients to make outgoing connections to arbitrary unprivileged
> ports. Then you have to convince the client's network administrator to
> allow that.
>
> But the alternative is to allow outgoing connections to the SSH
> port. Which, because it's opaque and supports port forwarding and VPN
> and so on, effectively allows the same thing anyway.

This is an excellent analysis, thank you.

Obviously I have personal Opinionsâ„¢ about FTPS vs SFTP, but
I think we can agree that plaintext FTP is worse than EITHER. :-)

Some tangential comments:

  * (for me) ssh is already there for system administration, and
    "grant more access to existing service" can be an easier sell than
    "deploy another service".

  * tinyssh and dropbear use OpenSSH's sftp driver,
    so there's a monoculture risk there.  (Not sure about GNU ssh.)

  * OpenSSH with "internal-sftp" can chroot without needing anything
    inside the chroot (but chroot(2) isn't a security feature).

  * OpenSSH authorized_keys now has "restrict" keyword (block all
    features).  This means you no longer need to go back and update the
    blocked feature list every time you upgrade SSH.  No equivalent in
    sshd_config (yet) AFAICT.

  * SFTP is _still_ only a draft RFC, whereas
    FTPS is a full standards-track RFC.

  * As a wild alternative, you could do plain rsync --daemon, and
    auth/encrypt at l2/l3 with a wireguard/openvpn/ipsec peer link :-)