rfc: reject use of drop in nat table

rfc: reject use of drop in nat table

[Jan Engelhardt]

This just happened to be within my thoughts. Comments, declinations?

commit 344a4b52b8484460727ed605e042583dbc73ac83
Author: Jan Engelhardt <jengelh@medozas.de>
Date:   Thu Jul 3 19:06:22 2008 +0200

    Reject use of DROP in nat table
    
    Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 iptables.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/iptables.c b/iptables.c
index 41e1836..6e7242d 100644
--- a/iptables.c
+++ b/iptables.c
@@ -1917,6 +1917,12 @@ int do_command(int argc, char *argv[], char **table, iptc_handle_t *handle)
 		invert = FALSE;
 	}
 
+	if (strcmp(*table, "nat") == 0) {
+		if ((policy != NULL && strcmp(policy, "DROP") == 0) ||
+		    (jumpto != NULL && strcmp(jumpto, "DROP") == 0))
+			exit_error(OTHER_PROBLEM, "The nat table is not for filtering");
+	}
+
 	for (matchp = matches; matchp; matchp = matchp->next)
 		if (matchp->match->final_check != NULL)
 			matchp->match->final_check(matchp->match->mflags);

Re: rfc: reject use of drop in nat table

[Patrick McHardy]

Jan Engelhardt wrote:
> 
> This just happened to be within my thoughts. Comments, declinations?

Well, first thought is the usual fear of breaking setups.

But I do agree that this makes sense, we've had a number
of "bugreports" over the years from people how tried to
do filtering in the nat table and didn't realize it only
sees the first packet of a connection.

Not sure - anyone else with an opinion? :)

Re: rfc: reject use of drop in nat table

[Phil Oester]

On Mon, Aug 04, 2008 at 06:57:21PM +0200, Patrick McHardy wrote:
> Well, first thought is the usual fear of breaking setups.

If they are doing this, their setup is _already_ broken.  This
will fix it ;-)

> But I do agree that this makes sense, we've had a number
> of "bugreports" over the years from people how tried to
> do filtering in the nat table and didn't realize it only
> sees the first packet of a connection.
>
> Not sure - anyone else with an opinion? :)

+1

Phil

Re: rfc: reject use of drop in nat table

[Jozsef Kadlecsik]

On Mon, 4 Aug 2008, Patrick McHardy wrote:

> Jan Engelhardt wrote:
> > 
> > This just happened to be within my thoughts. Comments, declinations?
> 
> Well, first thought is the usual fear of breaking setups.
> 
> But I do agree that this makes sense, we've had a number
> of "bugreports" over the years from people how tried to
> do filtering in the nat table and didn't realize it only
> sees the first packet of a connection.
> 
> Not sure - anyone else with an opinion? :)

Instead of the line

+                       exit_error(OTHER_PROBLEM, "The nat table is not for filtering");

the next one would probably be little bit more user friendly:

+                       fprintf(stderr, "The nat table is not for filtering, next iptables release won't support it at all. Fix your setup.\n");

And in the next release it could be changed to 'exit_error'.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: rfc: reject use of drop in nat table

[Patrick McHardy]

Jozsef Kadlecsik wrote:
> On Mon, 4 Aug 2008, Patrick McHardy wrote:
> 
>> Jan Engelhardt wrote:
>>> This just happened to be within my thoughts. Comments, declinations?
>> Well, first thought is the usual fear of breaking setups.
>>
>> But I do agree that this makes sense, we've had a number
>> of "bugreports" over the years from people how tried to
>> do filtering in the nat table and didn't realize it only
>> sees the first packet of a connection.
>>
>> Not sure - anyone else with an opinion? :)
> 
> Instead of the line
> 
> +                       exit_error(OTHER_PROBLEM, "The nat table is not for filtering");
> 
> the next one would probably be little bit more user friendly:
> 
> +                       fprintf(stderr, "The nat table is not for filtering, next iptables release won't support it at all. Fix your setup.\n");
> 
> And in the next release it could be changed to 'exit_error'.

That sounds good, lets do that.

Re: rfc: reject use of drop in nat table

[Jan Engelhardt]

On Monday 2008-08-04 15:08, Patrick McHardy wrote:
>> 
>> Instead of the line
>> 
>> +                       exit_error(OTHER_PROBLEM, "The nat table is not for
>> filtering");
>> 
>> the next one would probably be little bit more user friendly:
>> 
>> +                       fprintf(stderr, "The nat table is not for filtering,
>> next iptables release won't support it at all. Fix your setup.\n");
>> 
>> And in the next release it could be changed to 'exit_error'.
>
> That sounds good, lets do that.
>

commit 4241918dec00067d74cb3c8345efc8dcd08330e9
Author: Jan Engelhardt <jengelh@medozas.de>
Date:   Thu Jul 3 19:06:22 2008 +0200

Reject use of DROP in nat table

Consensus is that we should warn for now.

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 iptables.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/iptables.c b/iptables.c
index 41e1836..6a105f8 100644
--- a/iptables.c
+++ b/iptables.c
@@ -1917,6 +1917,14 @@ int do_command(int argc, char *argv[], char **table, iptc_handle_t *handle)
 		invert = FALSE;
 	}
 
+	if (strcmp(*table, "nat") == 0 &&
+	    ((policy != NULL && strcmp(policy, "DROP") == 0) ||
+	    (jumpto != NULL && strcmp(jumpto, "DROP") == 0)))
+		fprintf(stderr, "\nThe \"nat\" table is not intended for "
+		        "filtering, hence the use of DROP is deprecated and "
+		        "will permanently be disabled in the next iptables "
+		        "release. Please adjust your scripts.\n\n");
+
 	for (matchp = matches; matchp; matchp = matchp->next)
 		if (matchp->match->final_check != NULL)
 			matchp->match->final_check(matchp->match->mflags);

Re: rfc: reject use of drop in nat table

[Patrick McHardy]

Jan Engelhardt wrote:
> Reject use of DROP in nat table
> 
> Consensus is that we should warn for now.

Applied, thanks.