Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#658499: arno-iptables-firewall syntax changes
26 views
Skip to first unread message
Slade, Zac
Feb 24, 2012, 12:40:02 PM2/24/12
to
Arno,
It sounds to me like you made a change to the software that changes the behavior of the NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed "~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of "SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
Correct me if I'm wrong Arno, you seem to indicate in this bug report that the earlier behavior is a bug. If so a note in the CHANGELOG stating that you addressed a parser BUG would be helpful to anyone. I also understand that you probably won't be able to do this for the current upload as amending CHANGELOG entries isn't usually done. Maybe just a note in your upstream CHANGELOG noting the bug fix.
Julia,
Looking at the current form of the firewall.conf that ships with arno in sid I see the following:
# NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
# an internal client through (D)NAT. Note that you can also use these
# variables to forward ports to DMZ hosts.
#
# TCP/UDP form:
# "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
# {SRCIP3,...~}PORT3,...>DESTIP2{~port}"
#
# IP form:
# "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
# {SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
#
# TCP/UDP port forward examples:
# Simple (forward port 80 to internal host 192.168.0.10):
# NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
# Advanced (forward port 20 & 21 to 192.168.0.10 and
# forward from 1.2.3.4 port 81 to 192.168.0.11 port 80:
# NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
#
# IP protocol forward example:
# (forward protocols 47 & 48 to 192.168.0.10)
# NAT_FORWARD_IP="47,48>192.168.0.10"
#
# NOTE 1: {~port} is optional. Use it to redirect a specific port to a
# different port on the internal client.
# NOTE 2: {SRCIPx} is optional. Use it to restrict access for specific source
# (inet) IP addresses.
# (IPv4 Only)
# -----------------------------------------------------------------------------
This does not seem to allow the syntax you were using. Notice the form "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to indicate to me that the ~ in your previous examples is what caused your breakage. Can you confirm that the documentation is correct and that you can set NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
Thank you,
Zac Slade
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
It sounds to me like you made a change to the software that changes the behavior of the NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed "~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of "SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
Correct me if I'm wrong Arno, you seem to indicate in this bug report that the earlier behavior is a bug. If so a note in the CHANGELOG stating that you addressed a parser BUG would be helpful to anyone. I also understand that you probably won't be able to do this for the current upload as amending CHANGELOG entries isn't usually done. Maybe just a note in your upstream CHANGELOG noting the bug fix.
Julia,
Looking at the current form of the firewall.conf that ships with arno in sid I see the following:
# NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
# an internal client through (D)NAT. Note that you can also use these
# variables to forward ports to DMZ hosts.
#
# TCP/UDP form:
# "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
# {SRCIP3,...~}PORT3,...>DESTIP2{~port}"
#
# IP form:
# "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
# {SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
#
# TCP/UDP port forward examples:
# Simple (forward port 80 to internal host 192.168.0.10):
# NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
# Advanced (forward port 20 & 21 to 192.168.0.10 and
# forward from 1.2.3.4 port 81 to 192.168.0.11 port 80:
# NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
#
# IP protocol forward example:
# (forward protocols 47 & 48 to 192.168.0.10)
# NAT_FORWARD_IP="47,48>192.168.0.10"
#
# NOTE 1: {~port} is optional. Use it to redirect a specific port to a
# different port on the internal client.
# NOTE 2: {SRCIPx} is optional. Use it to restrict access for specific source
# (inet) IP addresses.
# (IPv4 Only)
# -----------------------------------------------------------------------------
This does not seem to allow the syntax you were using. Notice the form "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to indicate to me that the ~ in your previous examples is what caused your breakage. Can you confirm that the documentation is correct and that you can set NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
Thank you,
Zac Slade
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Arno van Amersfoort
Feb 24, 2012, 4:40:01 PM2/24/12
to
Dear Zac,
Your assumption is wrong. One can still use the short form
"SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
use(d) the undocumented, no longer working, "~SRC_PORT>INT_IP~INT_PORT"
form. The version that no longer allowed this form, is ALSO the version
that introduced rule sanity checking which IS mentioned in the
CHANGELOG. This means, as I also told Julia, that the firewall does
report that it was unable to parse *ALL* rules properly. It even reports
which rule fails and it certainly doesn´t cause any security issues.
Furthermore it's impossible for us to (regression) test any previously
undocumented/unintended functionality and report it in the CHANGELOG
accordingly.
cheers,
Arno
On 24-2-2012 18:21, Slade, Zac wrote:
> Arno,
> It sounds to me like you made a change to the software that changes the behavior of the NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed "~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of "SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
>
> Correct me if I'm wrong Arno, you seem to indicate in this bug report that the earlier behavior is a bug. If so a note in the CHANGELOG stating that you addressed a parser BUG would be helpful to anyone. I also understand that you probably won't be able to do this for the current upload as amending CHANGELOG entries isn't usually done. Maybe just a note in your upstream CHANGELOG noting the bug fix.
>
> Julia,
> Looking at the current form of the firewall.conf that ships with arno in sid I see the following:
>
> # NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
> # an internal client through (D)NAT. Note that you can also use these
> # variables to forward ports to DMZ hosts.
> #
> # TCP/UDP form:
> # "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
> # {SRCIP3,...~}PORT3,...>DESTIP2{~port}"
> #
> # IP form:
> # "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
> # {SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
> #
> # TCP/UDP port forward examples:
> # Simple (forward port 80 to internal host 192.168.0.10):
> # NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
> # Advanced (forward port 20& 21 to 192.168.0.10 and
Your assumption is wrong. One can still use the short form
"SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
use(d) the undocumented, no longer working, "~SRC_PORT>INT_IP~INT_PORT"
form. The version that no longer allowed this form, is ALSO the version
that introduced rule sanity checking which IS mentioned in the
CHANGELOG. This means, as I also told Julia, that the firewall does
report that it was unable to parse *ALL* rules properly. It even reports
which rule fails and it certainly doesn´t cause any security issues.
Furthermore it's impossible for us to (regression) test any previously
undocumented/unintended functionality and report it in the CHANGELOG
accordingly.
cheers,
Arno
On 24-2-2012 18:21, Slade, Zac wrote:
> Arno,
> It sounds to me like you made a change to the software that changes the behavior of the NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed "~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of "SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
>
> Correct me if I'm wrong Arno, you seem to indicate in this bug report that the earlier behavior is a bug. If so a note in the CHANGELOG stating that you addressed a parser BUG would be helpful to anyone. I also understand that you probably won't be able to do this for the current upload as amending CHANGELOG entries isn't usually done. Maybe just a note in your upstream CHANGELOG noting the bug fix.
>
> Julia,
> Looking at the current form of the firewall.conf that ships with arno in sid I see the following:
>
> # NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
> # an internal client through (D)NAT. Note that you can also use these
> # variables to forward ports to DMZ hosts.
> #
> # TCP/UDP form:
> # "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
> # {SRCIP3,...~}PORT3,...>DESTIP2{~port}"
> #
> # IP form:
> # "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
> # {SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
> #
> # TCP/UDP port forward examples:
> # Simple (forward port 80 to internal host 192.168.0.10):
> # NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
> # forward from 1.2.3.4 port 81 to 192.168.0.11 port 80:
> # NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
> #
> # IP protocol forward example:
> # (forward protocols 47& 48 to 192.168.0.10)
> # NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
> #
> # IP protocol forward example:
Slade, Zac
Feb 24, 2012, 5:20:02 PM2/24/12
to
> -----Original Message-----
> From: Arno van Amersfoort [mailto:arn...@rocky.eld.leidenuniv.nl]
> Sent: Friday, February 24, 2012 3:33 PM
> To: Slade, Zac
> Cc: 658...@bugs.debian.org; julia....@gmail.com; Lonnie Abelbeck
> Subject: Re: arno-iptables-firewall syntax changes
>
> Dear Zac,
>
> Your assumption is wrong. One can still use the short form
> "SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
> use(d) the undocumented, no longer working,
> "~SRC_PORT>INT_IP~INT_PORT"
> form. The version that no longer allowed this form, is ALSO the version that
> introduced rule sanity checking which IS mentioned in the CHANGELOG. This
> means, as I also told Julia, that the firewall does report that it was unable to
> parse *ALL* rules properly. It even reports which rule fails and it certainly
> doesn´t cause any security issues.
My opening paragraph did say that didn't it.... Sorry for that. By the end of the mail I had corrected that:
> From: Arno van Amersfoort [mailto:arn...@rocky.eld.leidenuniv.nl]
> Sent: Friday, February 24, 2012 3:33 PM
> To: Slade, Zac
> Cc: 658...@bugs.debian.org; julia....@gmail.com; Lonnie Abelbeck
> Subject: Re: arno-iptables-firewall syntax changes
>
> Dear Zac,
>
> Your assumption is wrong. One can still use the short form
> "SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
> use(d) the undocumented, no longer working,
> "~SRC_PORT>INT_IP~INT_PORT"
> form. The version that no longer allowed this form, is ALSO the version that
> introduced rule sanity checking which IS mentioned in the CHANGELOG. This
> means, as I also told Julia, that the firewall does report that it was unable to
> parse *ALL* rules properly. It even reports which rule fails and it certainly
> doesn´t cause any security issues.
> > This does not seem to allow the syntax you were using. Notice the form
> "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to
> indicate to me that the ~ in your previous examples is what caused your
> breakage. Can you confirm that the documentation is correct and that you can
> set NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
I never suggested this was a security vulnerability. Clearly it isn't. I think Julia's frustration is that when reloading the firewall rules after the upgrade she gets a broken firewall and a WARNING message. Is there a way to prevent loading of the rules entirely and preserving the original firewall state in the case of a parsing error? Maybe that's reaching a little; I'm just curious if that might be a good path forward to prevent future updates from blowing away currently running firewalls when the administrator is unaware of configuration file changes (even parser fixes)? This will happen again I'm sure(completely by accident). See the history of bash for more examples(and bash upgrades are generally really clean).
> Furthermore it's impossible for us to (regression) test any previously
> undocumented/unintended functionality and report it in the CHANGELOG
> accordingly.
Regards,
Julia Longtin
Feb 24, 2012, 6:30:01 PM2/24/12
to
Re-reading the documentation in firewall.conf, I now understand what the source of my confusion is. the tilde symbol is used as a SUFFIX on the left hand side of the arrow, indicating "what is before me is a IP address", and it is used as a PREFIX in the right hand side of the arrow, indicating "what is after me is a port number." in both cases, it is used to separate an IP from a port. This is certainly confusing behavior, as anyone reading it left-to-right or right-to-left is bound to be confused.
Julia Longtin
Arno van Amersfoort
Feb 25, 2012, 5:20:02 AM2/25/12
to
>
> I never suggested this was a security vulnerability. Clearly it isn't. I think Julia's frustration is that when reloading the firewall rules after the upgrade she gets a broken firewall and a WARNING message. Is there a way to prevent loading of the rules entirely and preserving the original firewall state in the case of a parsing error? Maybe that's reaching a little; I'm just curious if that might be a good path forward to prevent future updates from blowing away currently running firewalls when the administrator is unaware of configuration file changes (even parser fixes)? This will happen again I'm sure(completely by accident). See the history of bash for more examples(and bash upgrades are generally really clean).
Well, you can simply use the "check-conf" argument to test your
> I never suggested this was a security vulnerability. Clearly it isn't. I think Julia's frustration is that when reloading the firewall rules after the upgrade she gets a broken firewall and a WARNING message. Is there a way to prevent loading of the rules entirely and preserving the original firewall state in the case of a parsing error? Maybe that's reaching a little; I'm just curious if that might be a good path forward to prevent future updates from blowing away currently running firewalls when the administrator is unaware of configuration file changes (even parser fixes)? This will happen again I'm sure(completely by accident). See the history of bash for more examples(and bash upgrades are generally really clean).
configuration prior to actually applying it. Having the firewall falling
back to its previous configuration is not possible due to the way it's
implemented....
-arno
Slade, Zac
Feb 27, 2012, 1:30:02 PM2/27/12
to
> Sent: Saturday, February 25, 2012 4:14 AM
> To: Slade, Zac; 658...@bugs.debian.org
> Cc: julia....@gmail.com; Lonnie Abelbeck
> Subject: Re: Bug#658499: arno-iptables-firewall syntax changes
>
> >
> > I never suggested this was a security vulnerability. Clearly it isn't. I think
> Julia's frustration is that when reloading the firewall rules after the upgrade she
> gets a broken firewall and a WARNING message. Is there a way to prevent
> loading of the rules entirely and preserving the original firewall state in the case
> of a parsing error? Maybe that's reaching a little; I'm just curious if that might
> be a good path forward to prevent future updates from blowing away currently
> running firewalls when the administrator is unaware of configuration file
> changes (even parser fixes)? This will happen again I'm sure(completely by
> accident). See the history of bash for more examples(and bash upgrades are
> generally really clean).
>
> Well, you can simply use the "check-conf" argument to test your configuration
> prior to actually applying it. Having the firewall falling back to its previous
> configuration is not possible due to the way it's implemented....
Thank you Arno I'll be adding check-conf to my toolbox!
> To: Slade, Zac; 658...@bugs.debian.org
> Cc: julia....@gmail.com; Lonnie Abelbeck
> Subject: Re: Bug#658499: arno-iptables-firewall syntax changes
>
> >
> > I never suggested this was a security vulnerability. Clearly it isn't. I think
> Julia's frustration is that when reloading the firewall rules after the upgrade she
> gets a broken firewall and a WARNING message. Is there a way to prevent
> loading of the rules entirely and preserving the original firewall state in the case
> of a parsing error? Maybe that's reaching a little; I'm just curious if that might
> be a good path forward to prevent future updates from blowing away currently
> running firewalls when the administrator is unaware of configuration file
> changes (even parser fixes)? This will happen again I'm sure(completely by
> accident). See the history of bash for more examples(and bash upgrades are
> generally really clean).
>
> Well, you can simply use the "check-conf" argument to test your configuration
> prior to actually applying it. Having the firewall falling back to its previous
> configuration is not possible due to the way it's implemented....
I can't speak for Julia, but it appears that you've addressed this bug fully and there is nothing left to gain by keeping it open.
Thank you again,
Zac Slade
0 new messages