* Possibly dangerous interpretation of address/prefix pair in -s option
[not found] <mail.629a20b0.7e37.7f80bf761b5d8a04@storage.wm.amazon.com>
@ 2022-06-03 14:54 ` Stefan Riha
2022-06-03 15:21 ` Reindl Harald
2022-06-03 17:30 ` Kamil Jońca
[not found] ` <010201812a366a81-2f2bc7f3-e142-4807-9742-bfa7b19dd468-000000@eu-west-1.amazonses.com>
1 sibling, 2 replies; 30+ messages in thread
From: Stefan Riha @ 2022-06-03 14:54 UTC (permalink / raw)
To: netfilter
Hi,
I'm a beginner and noticed than when I do e.g.
iptables -A INPUT ... -s 10.0.0.2/24 ...
this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the entire network. I think it would be more beginner-proof if iptables would interpret this as incorrect input and error. Or at least, interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input, and that input is automatically re-interpretet (which in itself is unsafe, I would think), then at least interpret it in the way that is more restrictive (i.e. single IP instead of subnet). Otherwise I like iptables a lot, thanks for all the great work!
Regards, Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 14:54 ` Possibly dangerous interpretation of address/prefix pair in -s option Stefan Riha
@ 2022-06-03 15:21 ` Reindl Harald
2022-06-08 10:38 ` Chris Hall
2022-06-03 17:30 ` Kamil Jońca
1 sibling, 1 reply; 30+ messages in thread
From: Reindl Harald @ 2022-06-03 15:21 UTC (permalink / raw)
To: Stefan Riha, netfilter
Am 03.06.22 um 16:54 schrieb Stefan Riha:
> I'm a beginner and noticed than when I do e.g.
>
> iptables -A INPUT ... -s 10.0.0.2/24 ...
>
> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the entire network. I think it would be more beginner-proof if iptables would interpret this as incorrect input and error. Or at least, interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input, and that input is automatically re-interpretet (which in itself is unsafe, I would think), then at least interpret it in the way that is more restrictive (i.e. single IP instead of subnet). Otherwise I like iptables a lot, thanks for all the great work!
sorry - garbage in - garbage out
that's how netmasks are working
you are supposed to review your inputs and the final ruleset and the
decimal way of writing ip's is completly different to the internal way
of the tcp stack
ipcalc 10.0.0.2/24
Address: 10.0.0.2
Network: 10.0.0.0/24
Netmask: 255.255.255.0 = 24
Broadcast: 10.0.0.255
Address space: Private Use
HostMin: 10.0.0.1
HostMax: 10.0.0.254
Hosts/Net: 254
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
[not found] ` <mail.629a3f4f.4e0b.2e3e82745c98ed1d@storage.wm.amazon.com>
@ 2022-06-03 17:05 ` Stefan Riha
2022-06-03 17:28 ` Alex Buie
0 siblings, 1 reply; 30+ messages in thread
From: Stefan Riha @ 2022-06-03 17:05 UTC (permalink / raw)
To: netfilter; +Cc: h.reindl
Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
>> how do you expect your calculator "error out" when you type "1+3" but
meant "1+2"?
I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
10.0.0.0/24 (that's what iptables assumed I meant)
or
10.0.0.2/32 (or equivalently 10.0.0.2)
The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
In [3]: 3)4
python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
Thanks again for your patience!
-----Original message-----
From: Reindl Harald
Sent: Friday, June 3 2022, 6:42 pm
To: Stefan Riha
Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
Am 03.06.22 um 18:36 schrieb Stefan Riha:
> But it assumed that when I put in 10.0.0.2/24
you braindead moron IT CALCULATED
10.0.0.2/24 is for a computer similar to "1+2" for a human
> I actually meant 10.0.0.0/24
then write it
> That's possibly dangerous
operate a firewall as beginner is in generall dangerous
> because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
then write it
> As you said, it can't smell what I meant when I supplied an incorrect
> input. So the right thing would be to error, and not do anything.
how do you expect your calculator "error out" when you type "1+3" but
meant "1+2"?
> Instead it re-interprets my incorrect input
FUCK IT - it DID NOT interprete - IT IT A CALCULATION
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 17:05 ` Stefan Riha
@ 2022-06-03 17:28 ` Alex Buie
2022-06-03 17:30 ` Alex Buie
0 siblings, 1 reply; 30+ messages in thread
From: Alex Buie @ 2022-06-03 17:28 UTC (permalink / raw)
To: Stefan Riha; +Cc: netfilter, h.reindl
Underneath, it's all just binary math.
Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
their binary representation.
EG:
10.0.0.0: 00001010.00000000.00000000.00000000
10.0.0.2: 00001010.00000000.00000000.00000010
Then you are providing a bitmask (the /24 or /32 part) to tell the
kernel which parts of the address should be checked for matching.
/24: 11111111.11111111.11111111.00000000
/32: 11111111.11111111.11111111.111111111
The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
make sure the first 24 bits match 10.0.0.2".
1- 10.0.0.50: 00001010.00000000.00000000.00110010
2- /24: 11111111.11111111.11111111.00000000
---------------------------------------------------------------
XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
1- 10.0.0.2: 00001010.00000000.00000000.00000010
2- /24: 11111111.11111111.11111111.00000000
---------------------------------------------------------------
XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
Result 1 == Result 2, so the source match passes.
This is functionally equivalent to telling the kernel "allow all of
10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
There is no reinterpretation going on - the rule is simply being
processed exactly as you added it, and the behavior you suggest would
be introducing reinterpretation.
Hopefully that helps :)
Alex
On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net> wrote:
>
> Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
>
> >> how do you expect your calculator "error out" when you type "1+3" but
> meant "1+2"?
>
> I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
>
> 10.0.0.0/24 (that's what iptables assumed I meant)
>
> or
>
> 10.0.0.2/32 (or equivalently 10.0.0.2)
>
> The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
>
> In [3]: 3)4
>
> python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
>
> Thanks again for your patience!
>
> -----Original message-----
> From: Reindl Harald
> Sent: Friday, June 3 2022, 6:42 pm
> To: Stefan Riha
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
>
> Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > But it assumed that when I put in 10.0.0.2/24
>
> you braindead moron IT CALCULATED
>
> 10.0.0.2/24 is for a computer similar to "1+2" for a human
>
> > I actually meant 10.0.0.0/24
>
> then write it
>
> > That's possibly dangerous
>
> operate a firewall as beginner is in generall dangerous
>
> > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
>
> then write it
>
> > As you said, it can't smell what I meant when I supplied an incorrect
> > input. So the right thing would be to error, and not do anything.
>
> how do you expect your calculator "error out" when you type "1+3" but
> meant "1+2"?
>
> > Instead it re-interprets my incorrect input
>
> FUCK IT - it DID NOT interprete - IT IT A CALCULATION
>
>
>
--
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com
Join the conversation!
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 14:54 ` Possibly dangerous interpretation of address/prefix pair in -s option Stefan Riha
2022-06-03 15:21 ` Reindl Harald
@ 2022-06-03 17:30 ` Kamil Jońca
1 sibling, 0 replies; 30+ messages in thread
From: Kamil Jońca @ 2022-06-03 17:30 UTC (permalink / raw)
To: netfilter
Stefan Riha <stefan@sriha.net> writes:
> Hi,
>
> I'm a beginner and noticed than when I do e.g.
>
> iptables -A INPUT ... -s 10.0.0.2/24 ...
>
> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the
> entire network. I think it would be more beginner-proof if iptables
> would interpret this as incorrect input and error. Or at least,
I am afraid that you will not find allies here.
Interpreting this as bitmask notation is quite long tradition, and I am
afrait that noone wants to put extra code here,
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 17:28 ` Alex Buie
@ 2022-06-03 17:30 ` Alex Buie
[not found] ` <mail.629a519e.0cd7.3039eb4576cddb5d@storage.wm.amazon.com>
0 siblings, 1 reply; 30+ messages in thread
From: Alex Buie @ 2022-06-03 17:30 UTC (permalink / raw)
To: Stefan Riha; +Cc: netfilter, h.reindl
Whoops - just noticed, XOR should be AND in my message. My apologies!
On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com> wrote:
>
> Underneath, it's all just binary math.
> Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> their binary representation.
>
> EG:
> 10.0.0.0: 00001010.00000000.00000000.00000000
> 10.0.0.2: 00001010.00000000.00000000.00000010
>
> Then you are providing a bitmask (the /24 or /32 part) to tell the
> kernel which parts of the address should be checked for matching.
>
> /24: 11111111.11111111.11111111.00000000
> /32: 11111111.11111111.11111111.111111111
>
> The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> make sure the first 24 bits match 10.0.0.2".
>
> 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> 2- /24: 11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
>
> 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> 2- /24: 11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
>
> Result 1 == Result 2, so the source match passes.
>
> This is functionally equivalent to telling the kernel "allow all of
> 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
>
> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.
>
> Hopefully that helps :)
>
> Alex
>
>
> On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net> wrote:
> >
> > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> >
> > >> how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> >
> > 10.0.0.0/24 (that's what iptables assumed I meant)
> >
> > or
> >
> > 10.0.0.2/32 (or equivalently 10.0.0.2)
> >
> > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> >
> > In [3]: 3)4
> >
> > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> >
> > Thanks again for your patience!
> >
> > -----Original message-----
> > From: Reindl Harald
> > Sent: Friday, June 3 2022, 6:42 pm
> > To: Stefan Riha
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > But it assumed that when I put in 10.0.0.2/24
> >
> > you braindead moron IT CALCULATED
> >
> > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> >
> > > I actually meant 10.0.0.0/24
> >
> > then write it
> >
> > > That's possibly dangerous
> >
> > operate a firewall as beginner is in generall dangerous
> >
> > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> >
> > then write it
> >
> > > As you said, it can't smell what I meant when I supplied an incorrect
> > > input. So the right thing would be to error, and not do anything.
> >
> > how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > > Instead it re-interprets my incorrect input
> >
> > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> >
> >
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com
>
>
>
> Join the conversation!
--
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com
Join the conversation!
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
[not found] ` <mail.629a519e.0cd7.3039eb4576cddb5d@storage.wm.amazon.com>
@ 2022-06-03 18:23 ` Stefan Riha
2022-06-03 21:40 ` Jozsef Kadlecsik
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Stefan Riha @ 2022-06-03 18:23 UTC (permalink / raw)
To: Alex Buie; +Cc: netfilter, h.reindl
>> Whoops - just noticed, XOR should be AND in my message. My apologies!
No problem:) Thanks for taking the time and answer so comprehensively!
> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.
Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says:
>> For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255.
So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.
I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.
Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?
[1] https://en.wikipedia.org/wiki/IP_address
-----Original message-----
From: Alex Buie
Sent: Friday, June 3 2022, 7:30 pm
To: Stefan Riha
Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
Whoops - just noticed, XOR should be AND in my message. My apologies!
On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com <mailto:alex.buie@datto.com>> wrote:
>
> Underneath, it's all just binary math.
> Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> their binary representation.
>
> EG:
> 10.0.0.0: 00001010.00000000.00000000.00000000
> 10.0.0.2: 00001010.00000000.00000000.00000010
>
> Then you are providing a bitmask (the /24 or /32 part) to tell the
> kernel which parts of the address should be checked for matching.
>
> /24: 11111111.11111111.11111111.00000000
> /32: 11111111.11111111.11111111.111111111
>
> The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> make sure the first 24 bits match 10.0.0.2".
>
> 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> 2- /24: 11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
>
> 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> 2- /24: 11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
>
> Result 1 == Result 2, so the source match passes.
>
> This is functionally equivalent to telling the kernel "allow all of
> 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
>
> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.
>
> Hopefully that helps :)
>
> Alex
>
>
> On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net <mailto:stefan@sriha.net>> wrote:
> >
> > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> >
> > >> how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> >
> > 10.0.0.0/24 (that's what iptables assumed I meant)
> >
> > or
> >
> > 10.0.0.2/32 (or equivalently 10.0.0.2)
> >
> > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> >
> > In [3]: 3)4
> >
> > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> >
> > Thanks again for your patience!
> >
> > -----Original message-----
> > From: Reindl Harald
> > Sent: Friday, June 3 2022, 6:42 pm
> > To: Stefan Riha
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > But it assumed that when I put in 10.0.0.2/24
> >
> > you braindead moron IT CALCULATED
> >
> > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> >
> > > I actually meant 10.0.0.0/24
> >
> > then write it
> >
> > > That's possibly dangerous
> >
> > operate a firewall as beginner is in generall dangerous
> >
> > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> >
> > then write it
> >
> > > As you said, it can't smell what I meant when I supplied an incorrect
> > > input. So the right thing would be to error, and not do anything.
> >
> > how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > > Instead it re-interprets my incorrect input
> >
> > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> >
> >
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com <http://www.datto.com>
>
>
>
> Join the conversation!
--
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com <http://www.datto.com>
Join the conversation!
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 18:23 ` Stefan Riha
@ 2022-06-03 21:40 ` Jozsef Kadlecsik
[not found] ` <mail.629aff89.73ff.3ae87c7606a48613@storage.wm.amazon.com>
2022-06-03 23:37 ` Timothy Ham
2022-06-09 14:21 ` Gordon Fisher
2 siblings, 1 reply; 30+ messages in thread
From: Jozsef Kadlecsik @ 2022-06-03 21:40 UTC (permalink / raw)
To: Stefan Riha; +Cc: Alex Buie, netfilter, h.reindl
On Fri, 3 Jun 2022, Stefan Riha wrote:
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
>
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24
> differently? For example systemd-networkd interprets 10.0.0.2/24 as a
> single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense
> to me, because why would one specify the .2 at the end, if one meant the
> subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet
> itself. In the Wikipedia article about Ip addresses [1] it says:
That is a different context: in systemd-networkd you want to express a
single IP address *and* a netmask in one go, so the syntax is interpreted
that way. The wikipedia article explains it also.
However the -s/-d options of iptables are interpreted as
source/destination IP addresses/networks. Read the manpage: "Address can
be either a network name, a network IP address (with /mask), or a plain IP
address". The input is interpreted accordingly, therefore 10.0.0.2/24 is
equal to 10.0.0.0/24.
If you want to specify a single IP address, then either use 10.0.0.2/32 or
simply 10.0.0.2.
Best regards,
Jozsef
> -----Original message-----
> From: Alex Buie
> Sent: Friday, June 3 2022, 7:30 pm
> To: Stefan Riha
> Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
>
> Whoops - just noticed, XOR should be AND in my message. My apologies!
>
> On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com <mailto:alex.buie@datto.com>> wrote:
> >
> > Underneath, it's all just binary math.
> > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > their binary representation.
> >
> > EG:
> > 10.0.0.0: 00001010.00000000.00000000.00000000
> > 10.0.0.2: 00001010.00000000.00000000.00000010
> >
> > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > kernel which parts of the address should be checked for matching.
> >
> > /24: 11111111.11111111.11111111.00000000
> > /32: 11111111.11111111.11111111.111111111
> >
> > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > make sure the first 24 bits match 10.0.0.2".
> >
> > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
> >
> > 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
> >
> > Result 1 == Result 2, so the source match passes.
> >
> > This is functionally equivalent to telling the kernel "allow all of
> > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> >
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
> >
> > Hopefully that helps :)
> >
> > Alex
> >
> >
> > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net <mailto:stefan@sriha.net>> wrote:
> > >
> > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > >
> > > >> how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > >
> > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > >
> > > or
> > >
> > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > >
> > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > >
> > > In [3]: 3)4
> > >
> > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > >
> > > Thanks again for your patience!
> > >
> > > -----Original message-----
> > > From: Reindl Harald
> > > Sent: Friday, June 3 2022, 6:42 pm
> > > To: Stefan Riha
> > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > >
> > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > > But it assumed that when I put in 10.0.0.2/24
> > >
> > > you braindead moron IT CALCULATED
> > >
> > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > >
> > > > I actually meant 10.0.0.0/24
> > >
> > > then write it
> > >
> > > > That's possibly dangerous
> > >
> > > operate a firewall as beginner is in generall dangerous
> > >
> > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > >
> > > then write it
> > >
> > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > input. So the right thing would be to error, and not do anything.
> > >
> > > how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > > Instead it re-interprets my incorrect input
> > >
> > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> > >
> > >
> > >
> >
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com <http://www.datto.com>
> >
> >
> >
> > Join the conversation!
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com <http://www.datto.com>
>
> Join the conversation!
>
>
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 18:23 ` Stefan Riha
2022-06-03 21:40 ` Jozsef Kadlecsik
@ 2022-06-03 23:37 ` Timothy Ham
2022-06-04 5:29 ` pigi
2022-06-09 14:21 ` Gordon Fisher
2 siblings, 1 reply; 30+ messages in thread
From: Timothy Ham @ 2022-06-03 23:37 UTC (permalink / raw)
Cc: netfilter
Here is an example network that wouldn't work with your proposed "syntax error":
10.0.0.1/25
IP Address: 10.0.0.1
Network Address: 10.0.0.1
Usable Host IP Range: 10.0.0.1 - 10.0.0.126
Broadcast Address: 10.0.0.127
10.0.0.129/25
IP Address: 10.0.0.129
Network Address: 10.0.0.129
Usable Host IP Range: 10.0.0.129 - 10.0.0.254
Broadcast Address: 10.0.0.255
This is a bit convoluted, but are perfectly valid subnets. And in order to specify them, the current behavior is needed.
Cheers,
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, June 3rd, 2022 at 11:23 AM, Stefan Riha <stefan@sriha.net> wrote:
> > > Whoops - just noticed, XOR should be AND in my message. My apologies!
>
>
> No problem:) Thanks for taking the time and answer so comprehensively!
>
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
>
>
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says:
>
> > > For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255.
>
>
> So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.
>
> I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.
>
> Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?
>
>
> [1] https://en.wikipedia.org/wiki/IP_address
>
> -----Original message-----
> From: Alex Buie
> Sent: Friday, June 3 2022, 7:30 pm
> To: Stefan Riha
> Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
>
> Whoops - just noticed, XOR should be AND in my message. My apologies!
>
> On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com mailto:alex.buie@datto.com> wrote:
>
> > Underneath, it's all just binary math.
> > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > their binary representation.
> >
> > EG:
> > 10.0.0.0: 00001010.00000000.00000000.00000000
> > 10.0.0.2: 00001010.00000000.00000000.00000010
> >
> > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > kernel which parts of the address should be checked for matching.
> >
> > /24: 11111111.11111111.11111111.00000000
> > /32: 11111111.11111111.11111111.111111111
> >
> > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > make sure the first 24 bits match 10.0.0.2".
> >
> > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
> >
> > 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
> >
> > Result 1 == Result 2, so the source match passes.
> >
> > This is functionally equivalent to telling the kernel "allow all of
> > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> >
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
> >
> > Hopefully that helps :)
> >
> > Alex
> >
> > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net mailto:stefan@sriha.net> wrote:
> >
> > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > >
> > > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > > meant "1+2"?
> > >
> > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > >
> > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > >
> > > or
> > >
> > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > >
> > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > >
> > > In [3]: 3)4
> > >
> > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > >
> > > Thanks again for your patience!
> > >
> > > -----Original message-----
> > > From: Reindl Harald
> > > Sent: Friday, June 3 2022, 6:42 pm
> > > To: Stefan Riha
> > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > >
> > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > >
> > > > But it assumed that when I put in 10.0.0.2/24
> > >
> > > you braindead moron IT CALCULATED
> > >
> > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > >
> > > > I actually meant 10.0.0.0/24
> > >
> > > then write it
> > >
> > > > That's possibly dangerous
> > >
> > > operate a firewall as beginner is in generall dangerous
> > >
> > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > >
> > > then write it
> > >
> > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > input. So the right thing would be to error, and not do anything.
> > >
> > > how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > > Instead it re-interprets my incorrect input
> > >
> > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com http://www.datto.com
> >
> > Join the conversation!
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com http://www.datto.com
>
>
> Join the conversation!
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 23:37 ` Timothy Ham
@ 2022-06-04 5:29 ` pigi
0 siblings, 0 replies; 30+ messages in thread
From: pigi @ 2022-06-04 5:29 UTC (permalink / raw)
To: netfilter
I think you are wrong:
10.0.0.1/25
IP Address: 10.0.0.1
Network Address: 10.0.0.0 <====== It's "0", not "1"
Usable Host IP Range: 10.0.0.1 - 10.0.0.126
Broadcast Address: 10.0.0.127
10.0.0.129/25
IP Address: 10.0.0.129
Network Address: 10.0.0.128 <===== It's "128" not "129"
Usable Host IP Range: 10.0.0.129 - 10.0.0.254
Broadcast Address: 10.0.0.255
In iptables notation, 10.0.0.1/25 should sound as "syntax error" ( and so should 10.0.0.129/25)
Just my 2 cents.
Pigi
On Saturday, June 4, 2022 1:37:57 AM CEST Timothy Ham wrote:
> Here is an example network that wouldn't work with your proposed "syntax error":
>
> 10.0.0.1/25
> IP Address: 10.0.0.1
> Network Address: 10.0.0.1
> Usable Host IP Range: 10.0.0.1 - 10.0.0.126
> Broadcast Address: 10.0.0.127
>
> 10.0.0.129/25
> IP Address: 10.0.0.129
> Network Address: 10.0.0.129
> Usable Host IP Range: 10.0.0.129 - 10.0.0.254
> Broadcast Address: 10.0.0.255
>
> This is a bit convoluted, but are perfectly valid subnets. And in order to specify them, the current behavior is needed.
>
> Cheers,
>
>
> Sent with Proton Mail secure email.
> ------- Original Message -------
> On Friday, June 3rd, 2022 at 11:23 AM, Stefan Riha <stefan@sriha.net> wrote:
>
>
> > > > Whoops - just noticed, XOR should be AND in my message. My apologies!
> >
> >
> > No problem:) Thanks for taking the time and answer so comprehensively!
> >
> > > There is no reinterpretation going on - the rule is simply being
> > > processed exactly as you added it, and the behavior you suggest would
> > > be introducing reinterpretation.
> >
> >
> > Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says:
> >
> > > > For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255.
> >
> >
> > So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.
> >
> > I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.
> >
> > Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?
> >
> >
> > [1] https://en.wikipedia.org/wiki/IP_address
> >
> > -----Original message-----
> > From: Alex Buie
> > Sent: Friday, June 3 2022, 7:30 pm
> > To: Stefan Riha
> > Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Whoops - just noticed, XOR should be AND in my message. My apologies!
> >
> > On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com mailto:alex.buie@datto.com> wrote:
> >
> > > Underneath, it's all just binary math.
> > > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > > their binary representation.
> > >
> > > EG:
> > > 10.0.0.0: 00001010.00000000.00000000.00000000
> > > 10.0.0.2: 00001010.00000000.00000000.00000010
> > >
> > > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > > kernel which parts of the address should be checked for matching.
> > >
> > > /24: 11111111.11111111.11111111.00000000
> > > /32: 11111111.11111111.11111111.111111111
> > >
> > > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > > make sure the first 24 bits match 10.0.0.2".
> > >
> > > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > > 2- /24: 11111111.11111111.11111111.00000000
> > > ---------------------------------------------------------------
> > > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
> > >
> > > 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> > > 2- /24: 11111111.11111111.11111111.00000000
> > > ---------------------------------------------------------------
> > > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
> > >
> > > Result 1 == Result 2, so the source match passes.
> > >
> > > This is functionally equivalent to telling the kernel "allow all of
> > > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> > >
> > > There is no reinterpretation going on - the rule is simply being
> > > processed exactly as you added it, and the behavior you suggest would
> > > be introducing reinterpretation.
> > >
> > > Hopefully that helps :)
> > >
> > > Alex
> > >
> > > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net mailto:stefan@sriha.net> wrote:
> > >
> > > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > > >
> > > > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > > > meant "1+2"?
> > > >
> > > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > > >
> > > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > > >
> > > > or
> > > >
> > > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > > >
> > > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > > >
> > > > In [3]: 3)4
> > > >
> > > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > > >
> > > > Thanks again for your patience!
> > > >
> > > > -----Original message-----
> > > > From: Reindl Harald
> > > > Sent: Friday, June 3 2022, 6:42 pm
> > > > To: Stefan Riha
> > > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > > >
> > > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > >
> > > > > But it assumed that when I put in 10.0.0.2/24
> > > >
> > > > you braindead moron IT CALCULATED
> > > >
> > > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > > >
> > > > > I actually meant 10.0.0.0/24
> > > >
> > > > then write it
> > > >
> > > > > That's possibly dangerous
> > > >
> > > > operate a firewall as beginner is in generall dangerous
> > > >
> > > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > > >
> > > > then write it
> > > >
> > > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > > input. So the right thing would be to error, and not do anything.
> > > >
> > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > meant "1+2"?
> > > >
> > > > > Instead it re-interprets my incorrect input
> > > >
> > > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> > >
> > > --
> > > Alex Buie
> > > Senior Networking Software Engineer
> > > Datto, Inc.
> > > 475-288-4550 (o)
> > > 585-653-8779 (c)
> > > www.datto.com http://www.datto.com
> > >
> > > Join the conversation!
> >
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com http://www.datto.com
> >
> >
> > Join the conversation!
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
[not found] ` <mail.629aff89.73ff.3ae87c7606a48613@storage.wm.amazon.com>
@ 2022-06-04 6:45 ` Stefan Riha
2022-06-04 11:34 ` Jozsef Kadlecsik
2022-06-04 12:32 ` Reindl Harald
0 siblings, 2 replies; 30+ messages in thread
From: Stefan Riha @ 2022-06-04 6:45 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Alex Buie, netfilter, h.reindl
>> Read the manpage: "Address can
be either a network name, a network IP address (with /mask), or a plain IP
address".
The manpage states that the input can be either of three:
1) a network name
2) network IP address (with /mask) (i.e. 10.0.0.0/24 in the example)
3) a plain IP address (i.e. 10.0.0.2 or equivalently 10.0.0.2/32 in the example)
and the input 10.0.0.2/24 is neither of those three (it's a contextually inappropriate combination of 2 and 3). It therefore should be rejected, but instead it is reinterpreted to be of type 2), i.e. a network IP address (with /mask). What do you think?
My point is, I think this re-interpretation dangerous. I think the appropriate behaviour would be to error on incorrect/ambiguous input.
>> The input is interpreted accordingly, therefore 10.0.0.2/24 is
equal to 10.0.0.0/24.
But would you agree that if the input isn't of the 3 three types explicitly allowed in the manpage, it should be rejected? The word "either" in the manpage gives the impression that the three options are mutually exclusive, and not a contextually inappropriate mixture.
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-04 6:45 ` Stefan Riha
@ 2022-06-04 11:34 ` Jozsef Kadlecsik
2022-06-04 12:32 ` Reindl Harald
1 sibling, 0 replies; 30+ messages in thread
From: Jozsef Kadlecsik @ 2022-06-04 11:34 UTC (permalink / raw)
To: Stefan Riha; +Cc: Alex Buie, netfilter, h.reindl
On Sat, 4 Jun 2022, Stefan Riha wrote:
> >> Read the manpage: "Address can
> be either a network name, a network IP address (with /mask), or a plain IP
> address".
>
> The manpage states that the input can be either of three:
>
> 1) a network name
> 2) network IP address (with /mask) (i.e. 10.0.0.0/24 in the example)
> 3) a plain IP address (i.e. 10.0.0.2 or equivalently 10.0.0.2/32 in the
> example)
>
> and the input 10.0.0.2/24 is neither of those three (it's a contextually
> inappropriate combination of 2 and 3). It therefore should be rejected,
> but instead it is reinterpreted to be of type 2), i.e. a network IP
> address (with /mask). What do you think?
>
> My point is, I think this re-interpretation dangerous. I think the
> appropriate behaviour would be to error on incorrect/ambiguous input.
>
> >> The input is interpreted accordingly, therefore 10.0.0.2/24 is
> equal to 10.0.0.0/24.
>
> But would you agree that if the input isn't of the 3 three types
> explicitly allowed in the manpage, it should be rejected? The word
> "either" in the manpage gives the impression that the three options are
> mutually exclusive, and not a contextually inappropriate mixture.
The second form is interpreted as a network IP address and mask. The input
is normalized by default, so if the IP address is not the network IP
address, that is automatically converted to it.
You may say that it's not appropriate, dangerous, incorrect. But that is
how the system works for decades. Nothing can be changed about it, because
it could break configurations which rely on this behaviour.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-04 6:45 ` Stefan Riha
2022-06-04 11:34 ` Jozsef Kadlecsik
@ 2022-06-04 12:32 ` Reindl Harald
2022-06-04 13:06 ` Jozsef Kadlecsik
1 sibling, 1 reply; 30+ messages in thread
From: Reindl Harald @ 2022-06-04 12:32 UTC (permalink / raw)
To: Stefan Riha, Jozsef Kadlecsik; +Cc: Alex Buie, netfilter
Am 04.06.22 um 08:45 schrieb Stefan Riha:
> My point is, I think this re-interpretation dangerous
and my point is when you come up with "I'm a beginner" you should fro
the sake of go dlisten what people explain and stop using the word
"interpretation"
binary math != interpretation
damned stop wasting peoples time
your way of communication makes me sick and tired
it won't be changed - live with it or just hire somebody who can but het
rid of the idea that you are coming out of the blue after 30 years
changing the world
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-04 12:32 ` Reindl Harald
@ 2022-06-04 13:06 ` Jozsef Kadlecsik
2022-06-04 13:11 ` Reindl Harald
[not found] ` <mail.629b6720.3649.7e2693125cedf4ea@storage.wm.amazon.com>
0 siblings, 2 replies; 30+ messages in thread
From: Jozsef Kadlecsik @ 2022-06-04 13:06 UTC (permalink / raw)
To: Reindl Harald; +Cc: Stefan Riha, Alex Buie, netfilter
On Sat, 4 Jun 2022, Reindl Harald wrote:
> Am 04.06.22 um 08:45 schrieb Stefan Riha:
> > My point is, I think this re-interpretation dangerous
> and my point is when you come up with "I'm a beginner" you should fro
> the sake of go dlisten what people explain and stop using the word
> "interpretation"
>
> binary math != interpretation
> damned stop wasting peoples time
> your way of communication makes me sick and tired
>
> it won't be changed - live with it or just hire somebody who can but het
> rid of the idea that you are coming out of the blue after 30 years
> changing the world
There's no need to be hostile, everyone was a newcomer once. It seems
people can come to wrong conclusions due to the syntax which is used at
different systems with different internal meanings. The feature cannot of
course be changed, but maybe it'd worth to update the documentation.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-04 13:06 ` Jozsef Kadlecsik
@ 2022-06-04 13:11 ` Reindl Harald
[not found] ` <mail.629b6720.3649.7e2693125cedf4ea@storage.wm.amazon.com>
1 sibling, 0 replies; 30+ messages in thread
From: Reindl Harald @ 2022-06-04 13:11 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Stefan Riha, Alex Buie, netfilter
Am 04.06.22 um 15:06 schrieb Jozsef Kadlecsik:
> On Sat, 4 Jun 2022, Reindl Harald wrote:
>
>> Am 04.06.22 um 08:45 schrieb Stefan Riha:
>>> My point is, I think this re-interpretation dangerous
>> and my point is when you come up with "I'm a beginner" you should fro
>> the sake of go dlisten what people explain and stop using the word
>> "interpretation"
>>
>> binary math != interpretation
>> damned stop wasting peoples time
>> your way of communication makes me sick and tired
>>
>> it won't be changed - live with it or just hire somebody who can but het
>> rid of the idea that you are coming out of the blue after 30 years
>> changing the world
>
> There's no need to be hostile, everyone was a newcomer once. It seems
> people can come to wrong conclusions due to the syntax which is used at
> different systems with different internal meanings. The feature cannot of
> course be changed, but maybe it'd worth to update the documentation.
the point was if you are a newcomer lisyten what people are telling you
and when 5 different people on an doff list telling you it's not
"interpretation" stop repeating yourself again and again
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
[not found] ` <mail.629b6720.3649.7e2693125cedf4ea@storage.wm.amazon.com>
@ 2022-06-04 14:07 ` Stefan Riha
2022-06-08 13:56 ` Jozsef Kadlecsik
0 siblings, 1 reply; 30+ messages in thread
From: Stefan Riha @ 2022-06-04 14:07 UTC (permalink / raw)
To: Jozsef Kadlecsik, Reindl Harald; +Cc: Alex Buie, netfilter
>> It seems people can come to wrong conclusions due to the syntax which is used at
different systems with different internal meanings. The feature cannot of
course be changed, but maybe it'd worth to update the documentation.
I see, are you thinking of adding something like this to the manpage:
-s --source address[/mask][,...]
Source specification. Address can be either a network name, a hostname, a network IP address (with /mask), or a plain IP address. It can also be a plain IP address with /mask, in which case the mask will be applied to the plain IP address to compute the associated network IP address. Note that in the latter case, the plain IP address is automatically reinterpreted (i.e. modified or re-calculated) by the system as a network IP address.
I think this would at least raise attention to a beginner to be cautious. Also, I used the terms "modified" and "re-calculated" as synonyms for "reinterpreted". I get the impression this would be more agreeable to some users?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 15:21 ` Reindl Harald
@ 2022-06-08 10:38 ` Chris Hall
2022-06-08 11:21 ` Florian Westphal
` (4 more replies)
0 siblings, 5 replies; 30+ messages in thread
From: Chris Hall @ 2022-06-08 10:38 UTC (permalink / raw)
To: netfilter; +Cc: Reindl Harald
> Am 03.06.22 um 16:54 schrieb Stefan Riha:
>> I'm a beginner and noticed than when I do e.g.
>>
>> iptables -A INPUT ... -s 10.0.0.2/24 ...
>>
>> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the
>> entire network. I think it would be more beginner-proof if iptables
>> would interpret this as incorrect input and error. Or at least,
>> interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input,
>> and that input is automatically re-interpretet (which in itself is
>> unsafe, I would think), then at least interpret it in the way that is
>> more restrictive (i.e. single IP instead of subnet). Otherwise I like
>> iptables a lot, thanks for all the great work!
The iptables(8) Linux manual page says:
[!] -s, --source address[/mask][,...]
Source specification. Address can be either a network
name, a hostname, a network IP address (with /mask), or a
plain IP address. ....
For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
network address for a /24 network.
I agree: the parser should detect invalid input and reject it. I can
see no good reason for being sloppy here.
On 03/06/2022 16:21, Reindl Harald wrote:
> sorry - garbage in - garbage out
> that's how netmasks are working
Except that in this case the iptables command parser could trivially
have detected the 'garbage in' and rejected it instead of generating
'garbage out'.
It can be argued that it is too late to fix the parser, on the basis
that this could stop existing configurations from working. But that
doesn't mean that the parser is not broken.
> you are supposed to review your inputs and the final ruleset
Sure, but it takes quite careful reading of the man page to discover
that 10.0.0.2/24 is undefined. Worse yet, iptables then does something
undefined (AFAICS) :-(
Once you are thoroughly used to how something works, it's easy to become
convinced that what it does is *obvious* and *right*. Sometimes it
takes someone with a different perspective to see the problem.
The emperor is suffering a wardrobe malfunction.
Chris
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 10:38 ` Chris Hall
@ 2022-06-08 11:21 ` Florian Westphal
2022-06-09 17:52 ` Chris Hall
2022-06-08 11:34 ` matt
` (3 subsequent siblings)
4 siblings, 1 reply; 30+ messages in thread
From: Florian Westphal @ 2022-06-08 11:21 UTC (permalink / raw)
To: Chris Hall; +Cc: netfilter, Reindl Harald
Chris Hall <netfilter@gmch.uk> wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
>
> I agree: the parser should detect invalid input and reject it. I can see no
> good reason for being sloppy here.
It breaks current behaviour; we cannot change this 20 years later.
Its as simple as that.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 10:38 ` Chris Hall
2022-06-08 11:21 ` Florian Westphal
@ 2022-06-08 11:34 ` matt
2022-06-08 11:37 ` Matt
` (2 subsequent siblings)
4 siblings, 0 replies; 30+ messages in thread
From: matt @ 2022-06-08 11:34 UTC (permalink / raw)
To: Chris Hall; +Cc: netfilter, Reindl Harald
On 2022-06-08 11:38, Chris Hall wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
>
> I agree: the parser should detect invalid input and reject it. I can
> see no good reason for being sloppy here.
>
If someone uses 10.0.0.2/24 but meant 10.0.0.2/32, then just omit the
/24 or /32 - it's not required.
'-s 10.0.0.2' works fine
Thinking of all the iptables firewall scripts that could be in use right
now, and would be affected by a change that stops accepting
'10.0.0.2/24' as acceptable, and the disruption that would cause,
expecting it to be changed is unreasonable.
If you mean to write a rule for a single IP address then just use that
single IP address, don't use a subnet suffix. Get into that habit
instead.
Matt
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 10:38 ` Chris Hall
2022-06-08 11:21 ` Florian Westphal
2022-06-08 11:34 ` matt
@ 2022-06-08 11:37 ` Matt
2022-06-08 12:59 ` Reindl Harald
2022-06-08 13:30 ` Benny Lyne Amorsen
4 siblings, 0 replies; 30+ messages in thread
From: Matt @ 2022-06-08 11:37 UTC (permalink / raw)
To: netfilter
On 2022-06-08 11:38, Chris Hall wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
>
> I agree: the parser should detect invalid input and reject it. I can
> see no good reason for being sloppy here.
If someone uses 10.0.0.2/24 but meant 10.0.0.2/32, then just omit the
/24 or /32 - it's not required.
'-s 10.0.0.2' works fine
Thinking of all the iptables firewall scripts that could be in use right
now, and would be affected by a change that stops accepting
'10.0.0.2/24' as acceptable, and the disruption that would cause,
expecting it to be changed is unreasonable.
If you mean to write a rule for a single IP address then just use that
single IP address, don't use a subnet suffix. Get into that habit
instead.
Matt
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 10:38 ` Chris Hall
` (2 preceding siblings ...)
2022-06-08 11:37 ` Matt
@ 2022-06-08 12:59 ` Reindl Harald
2022-06-08 13:30 ` Benny Lyne Amorsen
4 siblings, 0 replies; 30+ messages in thread
From: Reindl Harald @ 2022-06-08 12:59 UTC (permalink / raw)
To: Chris Hall, netfilter
Am 08.06.22 um 12:38 schrieb Chris Hall:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
>
> I agree: the parser should detect invalid input and reject it. I can
> see no good reason for being sloppy here
there is nothing to parse or interprete
/24 clearly says only the first 3 octets are the relevant
again: it's a calculation
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 10:38 ` Chris Hall
` (3 preceding siblings ...)
2022-06-08 12:59 ` Reindl Harald
@ 2022-06-08 13:30 ` Benny Lyne Amorsen
4 siblings, 0 replies; 30+ messages in thread
From: Benny Lyne Amorsen @ 2022-06-08 13:30 UTC (permalink / raw)
To: netfilter
Chris Hall <netfilter@gmch.uk> writes:
> The emperor is suffering a wardrobe malfunction.
Reindl Harald has worked tirelessly for more than a decade to get
himself banned from as many open source-related mailing lists as
possible.
/Benny
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-04 14:07 ` Stefan Riha
@ 2022-06-08 13:56 ` Jozsef Kadlecsik
[not found] ` <mail.62a0b35b.5c1c.42faef732ab2e9b5@storage.wm.amazon.com>
0 siblings, 1 reply; 30+ messages in thread
From: Jozsef Kadlecsik @ 2022-06-08 13:56 UTC (permalink / raw)
To: Stefan Riha; +Cc: Reindl Harald, Alex Buie, netfilter
On Sat, 4 Jun 2022, Stefan Riha wrote:
> >> It seems people can come to wrong conclusions due to the syntax which is used at
> different systems with different internal meanings. The feature cannot of
> course be changed, but maybe it'd worth to update the documentation.
>
> I see, are you thinking of adding something like this to the manpage:
>
> -s --source address[/mask][,...]
> Source specification. Address can be either a network name, a hostname,
> a network IP address (with /mask), or a plain IP address. It can also be
> a plain IP address with /mask, in which case the mask will be applied to
> the plain IP address to compute the associated network IP address. Note
> that in the latter case, the plain IP address is automatically
> reinterpreted (i.e. modified or re-calculated) by the system as a
> network IP address.
The mask is unconditionally applied to the IP address. Please note, we
support non-continuous netmasks too. So something like this describes
better how the input is handled:
-s, --source address[/mask][,...]
Source specification. Address can be either a network name, a hostname, a
network IP address (with /mask), or a plain IP address. Hostnames will be
resolved once only, before the rule is submitted to the kernel. Please
note that specifying any name to be resolved with a remote query such as
DNS is a really bad idea. The mask can be either an ipv4 network mask
(for iptables) or a plain number, specifying the number of 1's at the
left side of the network mask. Thus, an iptables mask of 24 is
equivalent to 255.255.255.0. When specified, the mask always applied to
the network IP address part before processing the rule. ...
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: Possibly dangerous interpretation of address/prefix pair in -s option
[not found] ` <mail.62a0b35b.5c1c.42faef732ab2e9b5@storage.wm.amazon.com>
@ 2022-06-08 14:34 ` Stefan Riha
2022-06-09 20:28 ` Gordon Fisher
0 siblings, 1 reply; 30+ messages in thread
From: Stefan Riha @ 2022-06-08 14:34 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Reindl Harald, Alex Buie, netfilter
> The mask is unconditionally applied to the IP address.
Yes. Note again that it is unconditionally applied by other programs too, yet they do not discard the full ip address. When I use 10.0.0.2/24 in the "Address=" keywork of a systemd-networkd configuration, then the the mask is used to compute a prefix route (which is automatically added if not otherwise declared). Yet the full Ip address is kept, and assigned to the nic. My point is that I (as a beginner) would have thought iptables is "smart enough" to figure out that when I submit 10.0.0.2/24 instead of 10.0.0.0/24, then I actually mean 10.0.0.2, and that the additional information that 10.0.0.2 is part of a network 10.0.0.0/24 would be discarded.
> Please note, we support non-continuous netmasks too.
Interesting, I didn't know and had to look up what that is.
> When specified, the mask always applied to the network IP address part before processing the rule.
How about
> When specified, the mask is always applied to the IP address before processing the rule, and the masked-out part of the IP address is subsequently ignored (or "discarded" instead of "ignored").
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-03 18:23 ` Stefan Riha
2022-06-03 21:40 ` Jozsef Kadlecsik
2022-06-03 23:37 ` Timothy Ham
@ 2022-06-09 14:21 ` Gordon Fisher
2 siblings, 0 replies; 30+ messages in thread
From: Gordon Fisher @ 2022-06-09 14:21 UTC (permalink / raw)
Cc: netfilter
On 6/3/2022 11:23 AM, Stefan Riha wrote:
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24
> differently? For example systemd-networkd interprets 10.0.0.2/24 as a
> single Ip address in the subnet 10.0.0.0/24. Which makes a lot of
> sense to me, because why would one specify the .2 at the end, if one
> meant the subnet?
I would say that it depends on context; that is, what the parameter is
supposed to be. Is it meant to specify single address, a network, or either?
In the your systemd-networkd example, IIRC, that is supposed to be a
single IP address, and `10.0.0.2/24` is a short hand for entering
`10.0.0.2` and `255.255.255.0` for a network interface.
Another example that comes to mind where context matters, is the older
`route` command (that predates `ip route`), which has `-host` and `-net`
arguments for `route add` commands, that tell the program whether to
interpret the address part as a network based on the mask given, or as a
single host (where the mask can be omitted.)
`ip route` on the other hand just goes by the mask given similar to `-s`
and `-d` in `iptables`, where it really just does as it is told: check
this address according to the given mask. And like `iptables`, assumes
/32 if no mask is given.
--
gordonfish
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 11:21 ` Florian Westphal
@ 2022-06-09 17:52 ` Chris Hall
2022-06-09 18:38 ` Reindl Harald
2022-06-09 19:23 ` Jozsef Kadlecsik
0 siblings, 2 replies; 30+ messages in thread
From: Chris Hall @ 2022-06-09 17:52 UTC (permalink / raw)
To: netfilter; +Cc: Florian Westphal
On 08/06/2022 12:21, Florian Westphal wrote:
> Chris Hall <netfilter@gmch.uk> wrote:
>> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
>> network address for a /24 network.
>>
>> I agree: the parser should detect invalid input and reject it. I can see no
>> good reason for being sloppy here.
Perhaps that should have been "...no good reason for _having_been_
sloppy...".
> It breaks current behaviour; we cannot change this 20 years later.
> Its as simple as that.
You snipped the bit where I said:
>> It can be argued that it is too late to fix the parser, on the basis
>> that this could stop existing configurations from working. But that
>> doesn't mean that the parser is not broken.
I am hoping that it is agreed that it is a mistake for the parser to
silently accept unspecified input and proceed to so something
unspecified with it.
Accepting that "breaking current behaviour" is a cardinal sin, the
(obvious) alternative to fixing the code is to (retrospectively) fix the
specification and amend the man page to reflect that.
Given that (eg) "-s 10.0.0.2/24" is at best ambiguous, and at worst
nonsense: would a warning message "break current behaviour" ?
Anyway: "20 years later" suggests that this is not a big problem. I am
not trying to argue that it is.
Finally: given what the man page says, my principal issue was with the
(repeated) insistence (elsewhere) that what iptables does is both
*correct* and *obvious*, and that a "newbie" suggesting otherwise should
listen to their "elders and betters" and kindly "go away".
Chris
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-09 17:52 ` Chris Hall
@ 2022-06-09 18:38 ` Reindl Harald
2022-06-09 19:21 ` Joshua Moore
2022-06-09 19:23 ` Jozsef Kadlecsik
1 sibling, 1 reply; 30+ messages in thread
From: Reindl Harald @ 2022-06-09 18:38 UTC (permalink / raw)
To: Chris Hall, netfilter; +Cc: Florian Westphal
Am 09.06.22 um 19:52 schrieb Chris Hall:
> I am hoping that it is agreed that it is a mistake for the parser to
> silently accept unspecified input
it is *not* unspecified input
with /24 you *clearly* say "only use the first 3 octets of the address"
when you use a netmask you are supposed to know what it does and if not
just don't specify it - the address alone would have had the assumed result
it's dead simple and there is nothing to agree
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-09 18:38 ` Reindl Harald
@ 2022-06-09 19:21 ` Joshua Moore
0 siblings, 0 replies; 30+ messages in thread
From: Joshua Moore @ 2022-06-09 19:21 UTC (permalink / raw)
To: Reindl Harald; +Cc: Chris Hall, netfilter, Florian Westphal
Agreed as a user that netmask == more specific filtering. No netmask == use the /32 host as presented.
> On Jun 9, 2022, at 12:11 PM, Reindl Harald <h.reindl@thelounge.net> wrote:
>
> 
>
>> Am 09.06.22 um 19:52 schrieb Chris Hall:
>> I am hoping that it is agreed that it is a mistake for the parser to silently accept unspecified input
>
> it is *not* unspecified input
>
> with /24 you *clearly* say "only use the first 3 octets of the address"
>
> when you use a netmask you are supposed to know what it does and if not just don't specify it - the address alone would have had the assumed result
>
> it's dead simple and there is nothing to agree
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-09 17:52 ` Chris Hall
2022-06-09 18:38 ` Reindl Harald
@ 2022-06-09 19:23 ` Jozsef Kadlecsik
1 sibling, 0 replies; 30+ messages in thread
From: Jozsef Kadlecsik @ 2022-06-09 19:23 UTC (permalink / raw)
To: Chris Hall; +Cc: netfilter, Florian Westphal
On Thu, 9 Jun 2022, Chris Hall wrote:
> On 08/06/2022 12:21, Florian Westphal wrote:
> > Chris Hall <netfilter@gmch.uk> wrote:
> > > For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> > > network address for a /24 network.
> > >
> > > I agree: the parser should detect invalid input and reject it. I can see
> > > no good reason for being sloppy here.
>
> Perhaps that should have been "...no good reason for _having_been_ sloppy...".
I don't agree. If it have been sloppy, it had been fixed at the very
beginning. The "firewall" guys originally were "networking" guys and it
was never a question what 10.0.0.2/24 could mean: apply the mask
unconditionally.
> I am hoping that it is agreed that it is a mistake for the parser to
> silently accept unspecified input and proceed to so something
> unspecified with it.
Nothing is unspecified. If you mean the manpage could be improved, yes, it
seems so.
> Accepting that "breaking current behaviour" is a cardinal sin, the (obvious)
> alternative to fixing the code is to (retrospectively) fix the specification
> and amend the man page to reflect that.
>
> Given that (eg) "-s 10.0.0.2/24" is at best ambiguous, and at worst nonsense:
> would a warning message "break current behaviour" ?
Sorry, I don't understand: if it's a warning, then the wording is
misleading, which current behaviour does break? If it's an error, then
that is unacceptable as it could really break scripts, without easily
realise for the operators what happened: firewall scripts run at the very
beginning at the boot and normally nobody watches the console (if exists).
> Anyway: "20 years later" suggests that this is not a big problem. I am not
> trying to argue that it is.
>
> Finally: given what the man page says, my principal issue was with the
> (repeated) insistence (elsewhere) that what iptables does is both
> *correct* and *obvious*, and that a "newbie" suggesting otherwise should
> listen to their "elders and betters" and kindly "go away".
I agree, unfriendly tones do not help at all to understand newcomers
problems.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Possibly dangerous interpretation of address/prefix pair in -s option
2022-06-08 14:34 ` Stefan Riha
@ 2022-06-09 20:28 ` Gordon Fisher
0 siblings, 0 replies; 30+ messages in thread
From: Gordon Fisher @ 2022-06-09 20:28 UTC (permalink / raw)
To: netfilter
On 6/8/2022 7:34 AM, Stefan Riha wrote:
>> The mask is unconditionally applied to the IP address.
> Yes. Note again that it is unconditionally applied by other programs too, yet they do not discard the full ip address. When I use 10.0.0.2/24 in the "Address=" keywork of a systemd-networkd configuration, then the the mask is used to compute a prefix route (which is automatically added if not otherwise declared). Yet the full Ip address is kept, and assigned to the nic.
This is a different context and meaning than the usage in `iptables`.
In `systemd-networkd`, that is a host address field, not a network
address field, and that specifying a length, a la 10.0.0.2/24, is short
hand for configuring IP address 10.0.0.2 with a mask 255.255.255.0 as
this is for configuring an address on a network interface, which
normally requires an IP address and a mask pair.
Where as in `iptables`, an address supplied to -d or -s is is a network
address field that defaults to /32 when no length is specified, which is
a single address.
It makes all the difference if the field if is a network field or an
single address field.
--
gordonfish
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-06-09 20:28 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mail.629a20b0.7e37.7f80bf761b5d8a04@storage.wm.amazon.com>
2022-06-03 14:54 ` Possibly dangerous interpretation of address/prefix pair in -s option Stefan Riha
2022-06-03 15:21 ` Reindl Harald
2022-06-08 10:38 ` Chris Hall
2022-06-08 11:21 ` Florian Westphal
2022-06-09 17:52 ` Chris Hall
2022-06-09 18:38 ` Reindl Harald
2022-06-09 19:21 ` Joshua Moore
2022-06-09 19:23 ` Jozsef Kadlecsik
2022-06-08 11:34 ` matt
2022-06-08 11:37 ` Matt
2022-06-08 12:59 ` Reindl Harald
2022-06-08 13:30 ` Benny Lyne Amorsen
2022-06-03 17:30 ` Kamil Jońca
[not found] ` <010201812a366a81-2f2bc7f3-e142-4807-9742-bfa7b19dd468-000000@eu-west-1.amazonses.com>
[not found] ` <e2ba2738-2eff-3e97-a389-77abd17664dd@thelounge.net>
[not found] ` <mail.629a2dfb.57ab.496a0a414c9495b2@storage.wm.amazon.com>
[not found] ` <010201812a43a0d9-c4953858-f0e1-48db-a7a3-420d53a11cd7-000000@eu-west-1.amazonses.com>
[not found] ` <df64386a-5daf-6f97-3d37-b0c9b7c25537@thelounge.net>
[not found] ` <mail.629a3289.7fbb.1b2912350cfc7c1b@storage.wm.amazon.com>
[not found] ` <010201812a556c50-7856ee86-1a5a-4135-8acf-869a930d54c8-000000@eu-west-1.amazonses.com>
[not found] ` <768e4d99-0c50-01af-4434-20378c06a3cf@thelounge.net>
[not found] ` <mail.629a35d7.2a64.4a0b184f3a85fa1c@storage.wm.amazon.com>
[not found] ` <010201812a625427-9b51500d-3126-4b6f-95d0-d71702c349a7-000000@eu-west-1.amazonses.com>
[not found] ` <b6945516-3120-24f0-9990-294f1653c9a4@thelounge.net>
[not found] ` <mail.629a388a.7bba.0e9843742ea45568@storage.wm.amazon.com>
[not found] ` <010201812a6ce183-1a849304-791a-4874-9668-23f871060bac-000000@eu-west-1.amazonses.com>
[not found] ` <06924b12-8664-1e96-2a0b-d3711bbb67d7@thelounge.net>
[not found] ` <mail.629a3f4f.4e0b.2e3e82745c98ed1d@storage.wm.amazon.com>
2022-06-03 17:05 ` Stefan Riha
2022-06-03 17:28 ` Alex Buie
2022-06-03 17:30 ` Alex Buie
[not found] ` <mail.629a519e.0cd7.3039eb4576cddb5d@storage.wm.amazon.com>
2022-06-03 18:23 ` Stefan Riha
2022-06-03 21:40 ` Jozsef Kadlecsik
[not found] ` <mail.629aff89.73ff.3ae87c7606a48613@storage.wm.amazon.com>
2022-06-04 6:45 ` Stefan Riha
2022-06-04 11:34 ` Jozsef Kadlecsik
2022-06-04 12:32 ` Reindl Harald
2022-06-04 13:06 ` Jozsef Kadlecsik
2022-06-04 13:11 ` Reindl Harald
[not found] ` <mail.629b6720.3649.7e2693125cedf4ea@storage.wm.amazon.com>
2022-06-04 14:07 ` Stefan Riha
2022-06-08 13:56 ` Jozsef Kadlecsik
[not found] ` <mail.62a0b35b.5c1c.42faef732ab2e9b5@storage.wm.amazon.com>
2022-06-08 14:34 ` Stefan Riha
2022-06-09 20:28 ` Gordon Fisher
2022-06-03 23:37 ` Timothy Ham
2022-06-04 5:29 ` pigi
2022-06-09 14:21 ` Gordon Fisher
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.