Re: nft newbie

[Erwan David]

Le 12/07/2022 à 22:00, Marco a écrit :

Am Tue, 12 Jul 2022 21:17:40 +0200
schrieb :


That looks like a sensible strategy to me.


It isn't at all, completely blocking incoming ICMP is a very stupid
idea.

ICMP is used for control messages, e.g. for Path MTU discovery.
The only IMCP message that can be blocked is echo request or echo
reply, everything else creates problems like nasty timeouts to certain
sites.
You can block incoming echo requests and let all others through it.




I did not speak of blocking ICMP, I refered to the ICMP (host not 
reachable, network not reachable or administratively prohibited that the 
firewall itself emits in cas of a Reject.

Re: nft newbie

[tomas]

On Tue, Jul 12, 2022 at 08:00:42PM +, Marco wrote:
> Am Tue, 12 Jul 2022 21:17:40 +0200
> schrieb :
> 
> > That looks like a sensible strategy to me.
> 
> It isn't at all, completely blocking incoming ICMP is a very stupid
> idea.

I didn't get that "blocking incoming ICMP" part. Just the "DROP instead
of REJECT" part. Blame it on missing incoming coffee.

If it was there, I agree with you: especially blocking the incoming
"fragmentation required" ICMP will cause you lots of grief [1] if you
are behind something with a smaller MTU (cf. path MTU discovery, the
next Wikipedia shop in your quarters carries that).

Cheers

[1] I've seen symptoms like: you ssh into a box, everything seems fine,
   until you do the first `ls -al'. Then the connection hangs. You start
   to believe in ghosts until you understand the underlying mechanism.
-- 
t


signature.asc
Description: PGP signature

Re: nft newbie

[Marco]

Am Tue, 12 Jul 2022 21:17:40 +0200
schrieb :

> That looks like a sensible strategy to me.

It isn't at all, completely blocking incoming ICMP is a very stupid
idea.

ICMP is used for control messages, e.g. for Path MTU discovery.
The only IMCP message that can be blocked is echo request or echo
reply, everything else creates problems like nasty timeouts to certain
sites.
You can block incoming echo requests and let all others through it.

Re: nft newbie

[tomas]

On Tue, Jul 12, 2022 at 07:13:06PM +0200, Erwan David wrote:

[...]

> It depends on your settings. Personnally on a router I tend to Reject if the
> ICMP goes to the internal network, drop if it would be sent outside. That
> avoids some weird timeouts in the internal network (put your own definition
> of internal)

That looks like a sensible strategy to me.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: nft newbie

[Erwan David]

Le 12/07/2022 à 17:27, Henning Follmann a écrit :

On Tue, Jul 12, 2022 at 11:31:11AM +0100, mick crane wrote:

On 2022-07-12 10:33, Gareth Evans wrote:

On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies

In most cases it's a best practice to configure all chains with
_policy drop_ and then add rules for the traffic that you want to
allow

All the nftables and PF howtos I have found take this approach.

Why is it best practice?  Is there any security advantage over
rejection?


I think it is just that 'reject' tells the remote system there is something
listening.
mick



Oh quite contraire!
It literally tells you that there is nothing. And that is the problem.
This way your system can be part of an attack onto someone else.
Because your system creates a message which then is sent to the
address in the src address. And that can be a forged address.
This way you reflect messages to someone else.

In a nice world, where everybody plays by the rules reject would be the
proper thing. Here in reality drop is the better choice.



It depends on your settings. Personnally on a router I tend to Reject if 
the ICMP goes to the internal network, drop if it would be sent outside. 
That avoids some weird timeouts in the internal network (put your own 
definition of internal)

Re: nft newbie

[Henning Follmann]

On Tue, Jul 12, 2022 at 06:16:12PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2022 at 11:27:41AM -0400, Henning Follmann wrote:
> > On Tue, Jul 12, 2022 at 11:31:11AM +0100, mick crane wrote:
> > > On 2022-07-12 10:33, Gareth Evans wrote:
> > > > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies
> > > 
> > > > > In most cases it's a best practice to configure all chains with
> > > > > _policy drop_ and then add rules for the traffic that you want to
> > > > > allow
> > > > 
> > > > All the nftables and PF howtos I have found take this approach.
> > > > 
> > > > Why is it best practice?  Is there any security advantage over
> > > > rejection?
> > > > 
> > > I think it is just that 'reject' tells the remote system there is 
> > > something
> > > listening.
> > > mick
> > > 
> > 
> > 
> > Oh quite contraire!
> > It literally tells you that there is nothing. And that is the problem.
> > This way your system can be part of an attack onto someone else.
> > Because your system creates a message which then is sent to the
> > address in the src address. And that can be a forged address.
> > This way you reflect messages to someone else.
> 
> I was thinking of amplification too. But now you owe us at least
> a hint on how you can use a RST to do amplification.
> 

I think amplification actually needs a service running. This wont
work with just a firewall blocking any traffic.

> So far the factor is 1, which doesn't win you much, does it?

It changes the address where it's coming from. You can hide and
bypass any measures to thwart an attack.


> 
> > In a nice world, where everybody plays by the rules reject would be the
> > proper thing. Here in reality drop is the better choice.
> 
> C'mon, show us the code ;-)

Well, it is very simple. If you drop a package, anyone stares into a black
hole. If you have a misconfigured program you basically get nothing.
If any server would respond you would at least get an error back that
something is not working right. Also if we are talking tcp the program just
assumes the package is lost and will resend it. That is just undesirable.
And it increases actually the load on the misconfigured target.

-H



-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: nft newbie

[tomas]

On Tue, Jul 12, 2022 at 11:27:41AM -0400, Henning Follmann wrote:
> On Tue, Jul 12, 2022 at 11:31:11AM +0100, mick crane wrote:
> > On 2022-07-12 10:33, Gareth Evans wrote:
> > > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies
> > 
> > > > In most cases it's a best practice to configure all chains with
> > > > _policy drop_ and then add rules for the traffic that you want to
> > > > allow
> > > 
> > > All the nftables and PF howtos I have found take this approach.
> > > 
> > > Why is it best practice?  Is there any security advantage over
> > > rejection?
> > > 
> > I think it is just that 'reject' tells the remote system there is something
> > listening.
> > mick
> > 
> 
> 
> Oh quite contraire!
> It literally tells you that there is nothing. And that is the problem.
> This way your system can be part of an attack onto someone else.
> Because your system creates a message which then is sent to the
> address in the src address. And that can be a forged address.
> This way you reflect messages to someone else.

I was thinking of amplification too. But now you owe us at least
a hint on how you can use a RST to do amplification.

So far the factor is 1, which doesn't win you much, does it?

> In a nice world, where everybody plays by the rules reject would be the
> proper thing. Here in reality drop is the better choice.

C'mon, show us the code ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: nft newbie

[tomas]

On Tue, Jul 12, 2022 at 10:09:46AM -0400, gene heskett wrote:
> On 7/12/22 05:36, Gareth Evans wrote:
> > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
> > wrote:
> [...]
> > Why is it best practice?  Is there any security advantage over rejection?
> > 
> > Thanks,
> > Gareth
> > 
> Absolutely. reject sends a msg back to the hacker that there is a machine
> at that address.
> drop sends nothing back so he'll go looking for an easier target

All generalizations suck.

It depends strongly on what you expect on the other side. For a
firewall/router with one side exposed to the internet and with
well-defined services, drop seems (mostly) appropriate.

If you're running a publically accessible web server on that,
"they" already know you're there, so drop is of limited use
(reject is arguably "slightly" worse, dunno).

But the total opposite can be true. I've seen a datacenter isolating
their database server from the web application server with an NAT
firewall, and those umm... experts had the default policy to "drop".

What happened was, that when the entry in the NAT table expired,
because of inactivity, the application server took HALF AN HOUR
to notice that the connection was gone. It sat there twiddling
its thumbs (which isn't that bad), its about-thirty-users couldn't
do anything (which /is/ bad, esp. if it's a newspaper and those
people are the writers and the deadline is coming).

The data center wouldn't change its setup. The application provider
used a too-old Perl version where you couldn't call setsockopts to
set the keepalive option. And I couldn't get my boss's boss to
YELL at both of them because he was too... far up in the hierarchy
to understand a bit of that mess. OTOH, that company would have
deserved to go under in flames for its incompetence. Alas, it
didn't.

So yes, it depends.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: nft newbie

[Henning Follmann]

On Tue, Jul 12, 2022 at 11:31:11AM +0100, mick crane wrote:
> On 2022-07-12 10:33, Gareth Evans wrote:
> > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies
> 
> > > In most cases it's a best practice to configure all chains with
> > > _policy drop_ and then add rules for the traffic that you want to
> > > allow
> > 
> > All the nftables and PF howtos I have found take this approach.
> > 
> > Why is it best practice?  Is there any security advantage over
> > rejection?
> > 
> I think it is just that 'reject' tells the remote system there is something
> listening.
> mick
> 


Oh quite contraire!
It literally tells you that there is nothing. And that is the problem.
This way your system can be part of an attack onto someone else.
Because your system creates a message which then is sent to the
address in the src address. And that can be a forged address.
This way you reflect messages to someone else.

In a nice world, where everybody plays by the rules reject would be the
proper thing. Here in reality drop is the better choice.


-H
-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: nft newbie

[Nicolas George]

Stefan Monnier (12022-07-12):
> Except that if you contact an IP address where there's no machine, you
> may get a "no route to host" error (from the router that finds out
> there's no machine at that address), whereas if that machine DROPs, then
> you'll get no message, thus indicating that there *is* something there :-)

And if the cracker are mediocre, it does not change a thing because your
system is already safe from them. But if they are competent, they
probably have other means to know you are there, and the absence of
response will tell them you probably apply advice blindly. And if the
incoming packets are not hostile, dropping silently breaks the proper
diagnostic mechanisms that would have made them stop, causing useless
load on your connection.

I can go on and on and on.

Unless somebody produces a study that tries to quantify the risk and
cost of each solution, I will consider "DROP not REJECT" cargo cult.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: nft newbie

[gene heskett]

On 7/12/22 05:36, Gareth Evans wrote:

On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
wrote:

[...]

Why is it best practice?  Is there any security advantage over rejection?

Thanks,
Gareth


Absolutely. reject sends a msg back to the hacker that there is a machine
at that address.
drop sends nothing back so he'll go looking for an easier target

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: nft newbie

[Maximiliano Estudies]

El mar, 12 jul 2022 a las 14:13, Anssi Saari () escribió:
>
> "Gareth Evans"  writes:
>
> > On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
> > wrote:
> >
> >> drop and reject are not equivalent.
> >
> > Fair enough
> >
> > [...]
> >> In most cases it's a best practice to configure all chains with
> >> _policy drop_ and then add rules for the traffic that you want to
> >> allow
> >
> > All the nftables and PF howtos I have found take this approach.
> >
> > Why is it best practice?  Is there any security advantage over rejection?
>
> Not really, to me using DROP is a simplistic view not based in reality.
>
> https://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> covers the pros and cons reasonably with this conclusion:
>
> "DROP offers no effective barrier to hostile forces but can dramatically
> slow down applications run by legitimate users. DROP should not normally
> be used."
>

nft only allows for two possible default policies, DROP or ACCEPT,
thus it isn't possible to configure a chain with default REJECT. Thus
my suggestion to configure default drop (just in case) and a
"catch-all" reject at the bottom of the chain.

Re: nft newbie

[Anssi Saari]

"Gareth Evans"  writes:

> On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
> wrote:
>
>> drop and reject are not equivalent.
>
> Fair enough
>
> [...]
>> In most cases it's a best practice to configure all chains with
>> _policy drop_ and then add rules for the traffic that you want to
>> allow 
>
> All the nftables and PF howtos I have found take this approach.
>
> Why is it best practice?  Is there any security advantage over rejection?  

Not really, to me using DROP is a simplistic view not based in reality.

https://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
covers the pros and cons reasonably with this conclusion:

"DROP offers no effective barrier to hostile forces but can dramatically
slow down applications run by legitimate users. DROP should not normally
be used."

Re: nft newbie

[fxkl47BF]

On Tue, 12 Jul 2022, Gareth Evans wrote:

> On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
> wrote:
>
>> drop and reject are not equivalent.
>
> Fair enough
>
> [...]
>> In most cases it's a best practice to configure all chains with
>> _policy drop_ and then add rules for the traffic that you want to
>> allow
>
> All the nftables and PF howtos I have found take this approach.
>
> Why is it best practice?  Is there any security advantage over rejection?

Scammers send out emails to every possible address
If someone happens to respond, "Bugger off", they know they have a good address
If your systems sends a reject notice you're telling someone they have a good 
address
I was taught to drop everything and only open what is necessary

Re: nft newbie

[Gareth Evans]

> On 12 Jul 2022, at 11:31, mick crane  wrote:
> On 2022-07-12 10:33, Gareth Evans wrote:
>> On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies
> 
>>> In most cases it's a best practice to configure all chains with
>>> _policy drop_ and then add rules for the traffic that you want to
>>> allow
>> All the nftables and PF howtos I have found take this approach.
>> Why is it best practice?  Is there any security advantage over rejection?
> I think it is just that 'reject' tells the remote system there is something 
> listening.
> mick
> 
Oh yes (!), thanks.  A few other points (from a quick web search) here

https://www.coresentinel.com/reject-versus-drop/

including potential for REJECT to facilitate DDoS on asymmetric links - so it 
surprises me again (perhaps this time sensibly?) as the firewalld default.

Incidentally (I mainly have Gene in mind) it might be worth pointing out that 
nftables has individual and mass conversion commands for iptables 
rules/rulesets - perhaps useful if you're in a rush or just to see equivalence

https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

Best wishes
Gareth

Re: nft newbie

[mick crane]

On 2022-07-12 10:33, Gareth Evans wrote:

On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies



In most cases it's a best practice to configure all chains with
_policy drop_ and then add rules for the traffic that you want to
allow


All the nftables and PF howtos I have found take this approach.

Why is it best practice?  Is there any security advantage over 
rejection?


I think it is just that 'reject' tells the remote system there is 
something listening.

mick

Re: nft newbie

[Gareth Evans]

On Tue 12 Jul 2022, at 10:19, Maximiliano Estudies  
wrote:

> drop and reject are not equivalent.

Fair enough

[...]
> In most cases it's a best practice to configure all chains with
> _policy drop_ and then add rules for the traffic that you want to
> allow 

All the nftables and PF howtos I have found take this approach.

Why is it best practice?  Is there any security advantage over rejection?  

Thanks,
Gareth

Re: nft newbie

[Maximiliano Estudies]

drop and reject are not equivalent.
with _reject with icmpx_ you get an icmp response when trying to
access a system and get blocked by the firewall.
with _policy drop_ packets that are not allowed just get silently
dropped and don't give any feedback to the source.

In most cases it's a best practice to configure all chains with
_policy drop_ and then add rules for the traffic that you want to
allow (there are some exceptions but for normal workstations I would
always start with policy drop). For machines that are not exposed to
the internet I also like to configure a reject at the bottom of all
chains, it helps a lot when debugging networking problems to know if
you are getting blocked by the firewall

El mar, 12 jul 2022 a las 1:27, Gareth Evans () escribió:
>
> On Sun 10 Jul 2022, at 06:25, Gareth Evans  wrote:
>
> > Thanks Roger, that also suggests "policy drop" in its nftables examples.
>
> As someone on firewalld-users kindly pointed out, there is
>
> > table inet firewalld {
> > chain filter_INPUT {
> [...]
> > reject with icmpx admin-prohibited   <--- catch-all reject
> > }
>
> which seems equivalent to ufw's qualified "policy drop".
>
> Panic over.
> G
>


-- 
Maximiliano Estudies
VDT Referat Beschallung
+49 176 36784771
omslo.com
maxiestudies.com

Re: nft newbie

[Gareth Evans]

On Sun 10 Jul 2022, at 06:25, Gareth Evans  wrote:

> Thanks Roger, that also suggests "policy drop" in its nftables examples.

As someone on firewalld-users kindly pointed out, there is

> table inet firewalld {
> chain filter_INPUT {
[...]
> reject with icmpx admin-prohibited   <--- catch-all reject
> }

which seems equivalent to ufw's qualified "policy drop".

Panic over.
G

Re: nft newbie

[Gareth Evans]

On Sat  9 Jul 2022, at 10:05, Roger Price  wrote:
> On Sat, 9 Jul 2022, Gareth Evans wrote:
>
>> Also for any good nft/netfilter overview articles etc.
>
> Have you seen "Mastering Linux Security and Hardening", 2nd Edition, Donald 
> A. 
> Tevault, chapter 4.  Suitable for those of us who read this newbie thread.
>
> Roger

Thanks Roger, that also suggests "policy drop" in its nftables examples.

I've just noticed the nftables wiki mentions an nftables users mailing list, 

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

which might be useful too.

Thanks,
Gareth

Re: nft newbie

[Roger Price]

On Sat, 9 Jul 2022, Gareth Evans wrote:


Also for any good nft/netfilter overview articles etc.


Have you seen "Mastering Linux Security and Hardening", 2nd Edition, Donald A. 
Tevault, chapter 4.  Suitable for those of us who read this newbie thread.


Roger

Re: nft newbie

[Gareth Evans]

On Sat  9 Jul 2022, at 07:17, Gareth Evans  wrote:
[...]
> If there is no drop by default, why add "policy accept" for 
> related/established as it does?  Doesn't this happen anyway?

I suppose this probably modifies behaviour for otherwise closed ports (which 
would make sense for a firewall!) but I can't find much of a high-level 
overview in documentation - man nft, wiki.

I would still be grateful for thoughts from experienced nft users if any issues 
seem to arise from the lack of qualified "policy drop" in input.  Also for any 
good nft/netfilter overview articles etc.

Thanks,
Gareth

Re: nft newbie

[Gareth Evans]

Having found ufw suited my needs I have only dabbled with firewalld / 
firewall-config / firewall-applet over the years.

Having noticed the recommendation for firewalld on the debian wiki re nftables 

https://wiki.debian.org/nftables#Use_firewalld

I installed it and had a look at the default ruleset with

$ sudo nft list ruleset

If, as I understand, nftables default policy is accept, 

"NOTE: If no policy is explicitly selected, the default policy accept will be 
used."
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains

firewalld doesn't seem to "drop all input unless allowed" by default, as ufw's 
ruleset with only port 22 opened suggests it does.

If there is no drop by default, why add "policy accept" for related/established 
as it does?  Doesn't this happen anyway?

Isn't this less secure, as it seems?

The nftables wiki suggests "policy drop" for input, but the examples are rather 
restrictive.

https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_workstation

https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

nmap from another machine confirms only port 22 is open via firewalld (which is 
the default) but is default acceptance in other respects a security risk?

I haven't included rulesets but happy to provide if wanted.

Thanks,
Gareth

Re: nft newbie

[gene heskett]

On 7/7/22 10:13, Tom Browder wrote:

On Wed, Jul 6, 2022 at 7:17 PM Will Mengarini  wrote:

* gene heskett  [22-07/06=We 18:50 -0400]:

[...] iptables is out of support, replaced I
guess with nft.  [...] whats the command to [...]

The nft is too complicated. UFW works great and is so easy.

-Tom

.
People said that about iptables too, but once you understood how it 
worked, you could block all
of a given outfits possible bot addresses with one /8 or /16, in one 
case a /24. If that denies
one of their legit customers too, I usually told them to fuss at their 
isp as it was not respecting
my robots.txt. Now we've a new name in bots we'll have to train. Look at 
your access logs, it'll

stick out like a sore thumb.

But now I need to create another robots.txt. The worst part of that is 
the stubborn ones will scan
for subdirs that don't have a robots.txt and will bypass the www/root so 
you need a robots.txt in

every dir. That ability I blame on apache2.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: nft newbie

[Tom Browder]

On Wed, Jul 6, 2022 at 7:17 PM Will Mengarini  wrote:
>
> * gene heskett  [22-07/06=We 18:50 -0400]:
> > [...] iptables is out of support, replaced I
> > guess with nft.  [...] whats the command to [...]

The nft is too complicated. UFW works great and is so easy.

-Tom

Re: nft newbie

[Greg Wooledge]

On Thu, Jul 07, 2022 at 10:45:00AM +0200, Erwan David wrote:
> Le 07/07/2022 à 10:11, Roger Price a écrit :
> > Newbie 3: The configuration file begins with the Bash shebang
> > #!/usr/sbin/nft -f but the Debian 11 man page for nftables says
> > 
> >    -f, --file filename Read input from filename. If filename is -, read
> > from stdin.
> > 
> > and doesn't mention omitting the filename.  I'm guessing that -f with no
> > file name means "read from the remainder of this file".  Is this
> > correct?
> 
> It's very old for me (I began unix in 1990)  but in my understanding when a
> file begins wth a shebang the line after the shebang is completed with the
> path to the file and the full line is then executed, thus You'll end with a
> command line of /usr/sbin/nft -f /etc/nftables.conf

That's correct.  That's how shebangs work.

If you take a typical shell script, which begins with #!/bin/sh, and
you execute that, you'll end up with the kernel running a command such
as

  /bin/sh ./myscript

for you.  Likewise, a perl script will end up executing something like

  /usr/bin/perl /usr/bin/perlscript

and so on.  You are allowed to have one (1) argument word after the
interpreter name on a shebang line.  In the case of your nft script,
that option happens to be -f.  This will also be required for awk
scripts (with a shebang of #!/usr/bin/awk -f) and so on.

Re: nft newbie

[Erwan David]

Le 07/07/2022 à 10:11, Roger Price a écrit :


I looked at the workstation example, but it doesn't even allow access 
via ssh. On my Debian 11 box I found 
/usr/share/doc/nftables/examples/workstation.nft which does show how to 
allow incoming ssh, http and https traffic.


Newbie 1: Is it normal for nftables configuration files to be 
executable?  As a newcomer, I expected something more "traditional", ie 
a file containing only key words and data values.


Yes it is. If you look at the first line you see it is a script to be 
evaluated by /usr/sbin/nft



Newbie 2: Command ls -l /etc/nftables.conf reports

    -rwxr-xr-x 1 root root 228 Jan 17  2021 /etc/nftables.conf*

This looks as if anyone can read and execute this file.  I tried as a 
simple user and got the error message


    /etc/nftables.conf:3:1-14: Error: Could not process rule: Operation 
not permitted

    flush ruleset
    ^^

Is execution not permitted for non-root/non-file owner ?


nft configuration is indeed possible only for root.

Newbie 3: The configuration file begins with the Bash shebang 
#!/usr/sbin/nft -f but the Debian 11 man page for nftables says


   -f, --file filename Read input from filename. If filename is -, read 
from stdin.


and doesn't mention omitting the filename.  I'm guessing that -f with no 
file name means "read from the remainder of this file".  Is this correct?


It's very old for me (I began unix in 1990)  but in my understanding 
when a file begins wth a shebang the line after the shebang is completed 
with the path to the file and the full line is then executed, thus 
You'll end with a command line of /usr/sbin/nft -f /etc/nftables.conf

Re: nft newbie

[Roger Price]

On Wed, 6 Jul 2022, Will Mengarini wrote:

* gene heskett  [22-07/06=We 18:50 -0400]:

The man page while quite voluminus is as
usual mostly bereft of useful examples.



has various examples.


May I continue this thread by asking more newbie questions?

I looked at the workstation example, but it doesn't even allow access via ssh. 
On my Debian 11 box I found /usr/share/doc/nftables/examples/workstation.nft 
which does show how to allow incoming ssh, http and https traffic.


Newbie 1: Is it normal for nftables configuration files to be executable?  As a 
newcomer, I expected something more "traditional", ie a file containing only key 
words and data values.


Newbie 2: Command ls -l /etc/nftables.conf reports

   -rwxr-xr-x 1 root root 228 Jan 17  2021 /etc/nftables.conf*

This looks as if anyone can read and execute this file.  I tried as a simple 
user and got the error message


   /etc/nftables.conf:3:1-14: Error: Could not process rule: Operation not 
permitted
   flush ruleset
   ^^

Is execution not permitted for non-root/non-file owner ?

Newbie 3: The configuration file begins with the Bash shebang #!/usr/sbin/nft -f 
but the Debian 11 man page for nftables says


  -f, --file filename Read input from filename. If filename is -, read from 
stdin.

and doesn't mention omitting the filename.  I'm guessing that -f with no file 
name means "read from the remainder of this file".  Is this correct?


My apologies for asking such trivial stuff.
Roger


 is an
HTML version of the man page, which is easier to navigate, at least.

 
may also be helpful.

Re: nft newbie

[gene heskett]

On 7/6/22 20:20, Will Mengarini wrote:

* gene heskett  [22-07/06=We 18:50 -0400]:

[...] iptables is out of support, replaced I
guess with nft.  [...] whats the command to [...]

The man page while quite voluminus is as
usual mostly bereft of useful examples.


has various examples.

 is an
HTML version of the man page, which is easier to navigate, at least.


 may also be helpful.

.

All bookmarked, thank you very much, Will.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: nft newbie

[Will Mengarini]

* gene heskett  [22-07/06=We 18:50 -0400]:
> [...] iptables is out of support, replaced I
> guess with nft.  [...] whats the command to [...]
>
> The man page while quite voluminus is as
> usual mostly bereft of useful examples.


has various examples.

 is an
HTML version of the man page, which is easier to navigate, at least.


 may also be helpful.

Re: nft newbie

[Christian Britz]

Am 07.07.22 um 00:50 schrieb gene heskett:

> I was just locked up by what may have been a ransomware attack by a link 
> from pocket,
> part of firefox's default screen. I did a power down, and had quite a 

I doubt that. This would be such a security desaster for FireFox that it
would have been published on all major news sites by now.

-- 
http://www.cb-fraggle.de