[ANNOUNCE] Release of iptables-1.4.3.2

[ANNOUNCE] Release of iptables-1.4.3.2

[Pablo Neira Ayuso]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

The netfilter coreteam presents:

     iptables version 1.4.3.2

the iptables release for the 2.6.29 kernel. This version includes
accumulated bugfixes for the previous release from Jan Engelhardt and
Peter Volkov. Check the Changelog file for more details.

Remember that iptables >= 1.4.3 starts enforcing the deprecation of NAT
filtering that was added in 1.4.2-rc1, filtering rules in the NAT tables
will cause an error instead of a warning from now on. Please make sure
your rulesets are update appropriately.

Version 1.4.3.2 can be obtained from:

http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
git://git.netfilter.org/iptables.git

On behalf of the Netfilter Core Team.
Happy firewalling!

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers


[-- Attachment #2: changes-iptables-1.4.3.2.txt --]
[-- Type: text/plain, Size: 693 bytes --]

Jan Engelhardt (12):
      libxt_tcpmss: fix an inversion while parsing --mss
      iptables-multi: support "iptables-static" as a callable name
      libxtables: reorder .version member
      build: do not run ldconfig for DESTDIR installations
      build: add configure option to disable ip6tables
      build: add configure option to disable ipv4 iptables
      libxtables: provide IPv6 zero address variable
      iptables: print negation extrapositioned
      Merge commit 'v1.4.3'
      Merge branch 'plus'
      CLASSIFY: document non-standard interpretation behavior
      libxt_conntrack: properly output negation symbol

Pablo Neira Ayuso (1):
      build: bump version to 1.4.3.2

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Dennis J.]

On 04/06/2009 01:38 PM, Pablo Neira Ayuso wrote:
> The netfilter coreteam presents:
>
>       iptables version 1.4.3.2
>
> the iptables release for the 2.6.29 kernel. This version includes
> accumulated bugfixes for the previous release from Jan Engelhardt and
> Peter Volkov. Check the Changelog file for more details.
>
> Remember that iptables>= 1.4.3 starts enforcing the deprecation of NAT
> filtering that was added in 1.4.2-rc1, filtering rules in the NAT tables
> will cause an error instead of a warning from now on. Please make sure
> your rulesets are update appropriately.

What does "deprecation of NAT filtering" entail exactly? I checked the 
release notes for 1.4.2-rc1 but couldn't find any reference to that and I 
wasn't lucky searching the devel mailinglist either.

Regards,
   Dennis

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Eray Aslan]

On 06.04.2009 17:18, Dennis J. wrote:
> What does "deprecation of NAT filtering" entail exactly?

# /sbin/iptables -V
iptables v1.4.2
# /sbin/iptables -t nat -A OUTPUT -p tcp --dport 10000 -j DROP

The "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.

# /sbin/iptables -L -nvx -t nat
[...]
Chain OUTPUT (policy ACCEPT 45827 packets, 3301166 bytes)
    pkts      bytes target     prot opt in     out     source
    destination
       0        0 DROP       tcp  --  *      *       0.0.0.0/0
  0.0.0.0/0           tcp dpt:10000
#

versus

# /sbin/iptables -V
iptables v1.4.3.1
# /sbin/iptables -t nat -A OUTPUT -p tcp --dport 10000 -j DROP
iptables v1.4.3.1:
The "nat" table is not intended for filtering, the use of DROP is
therefore inhibited.


Try `iptables -h' or 'iptables --help' for more information.
# /sbin/iptables -L -nvx -t nat
[...]
Chain OUTPUT (policy ACCEPT 5115 packets, 415189 bytes)
    pkts      bytes target     prot opt in     out     source
    destination
#

Do not filter in the nat table and you will be fine.

-- 
Eray

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Mart Frauenlob]

Eray Aslan wrote:
> On 06.04.2009 17:18, Dennis J. wrote:
>   
>> What does "deprecation of NAT filtering" entail exactly?
>>     
>
> # /sbin/iptables -V
> iptables v1.4.2
> # /sbin/iptables -t nat -A OUTPUT -p tcp --dport 10000 -j DROP
>
> The "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.
>
> # /sbin/iptables -L -nvx -t nat
> [...]
> Chain OUTPUT (policy ACCEPT 45827 packets, 3301166 bytes)
>     pkts      bytes target     prot opt in     out     source
>     destination
>        0        0 DROP       tcp  --  *      *       0.0.0.0/0
>   0.0.0.0/0           tcp dpt:10000
> #
>
> versus
>
> # /sbin/iptables -V
> iptables v1.4.3.1
> # /sbin/iptables -t nat -A OUTPUT -p tcp --dport 10000 -j DROP
> iptables v1.4.3.1:
> The "nat" table is not intended for filtering, the use of DROP is
> therefore inhibited.
>
>
> Try `iptables -h' or 'iptables --help' for more information.
> # /sbin/iptables -L -nvx -t nat
> [...]
> Chain OUTPUT (policy ACCEPT 5115 packets, 415189 bytes)
>     pkts      bytes target     prot opt in     out     source
>     destination
> #
>
> Do not filter in the nat table and you will be fine.
>
>   
Hello,

what about the 'policy' in the 'nat' table? Will it allow 'DROP'?

what about the other non 'filter' tables?
Will it be possible to 'DROP' in the mangle table? Or set it's policy to 
'DROP'?
Isn't dropping in the mangle table almost the same thing as doing that 
in the nat table?
At least it violates the concept of filtering in the filter table.

What if someone uses 'DROP' rules and policy in the 'raw' table?
Especially setting a drop policy there turns the concept upside down.
I've been reading some advices to do 'blacklisting' in the raw table, 
which does sound quite reasonable to me, as the raw table is the first 
to be process, thus speeding up the processing.
Though the raw table has been introduces to allow 'NOTRACK'. So, the 
concept violation makes sense here?
But again, a 'DROP' policy? Needed?

I must say I've always been wondering why the other tables (formerly 
just mangle and nat) would have the DROP policy available, and why they 
allow dropping rules, although the iptables concept says to do filtering 
in the filter table.
I've seen quite some people (mostly unexperienced) mess up their box 
with that, most of them ending up asking for public help.
It seems misleading to me, to make that options available.

Thanks for any information you want to share with me.

Thanks to the developers spending their time and energy.

Greets

Mart

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Eray Aslan]

On 09.04.2009 11:31, Mart Frauenlob wrote:
> what about the 'policy' in the 'nat' table? Will it allow 'DROP'?

# /sbin/iptables -V
iptables v1.4.3.1
# /sbin/iptables -t nat -P OUTPUT DROP
iptables v1.4.3.1:
The "nat" table is not intended for filtering, the use of DROP is
therefore inhibited.


Try `iptables -h' or 'iptables --help' for more information.
# echo $?
2
# /sbin/iptables -t nat -L|grep OUTPUT
Chain OUTPUT (policy ACCEPT)

> what about the other non 'filter' tables?
> Will it be possible to 'DROP' in the mangle table? Or set it's policy to
> 'DROP'?

Yes

> Isn't dropping in the mangle table almost the same thing as doing that
> in the nat table?

No.  Not all packets in a connection traverse the nat table.

> At least it violates the concept of filtering in the filter table.

Yes.  Correct place to filter in in the filter table.  But if you insist
on doing the "wrong" thing, who is to interfere?

[...]
> I've seen quite some people (mostly unexperienced) mess up their box
> with that, most of them ending up asking for public help.
> It seems misleading to me, to make that options available.

Well, software does not grow on trees.  Someone has to write it but is
it really worth the effort to ban filtering in mangle et al?  Filtering
in the nat table was especially wrong because it didnot give the
expected result and I suppose that is reason for the patch/revized
behaviour.

-- 
Eray

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Payam Chychi]

Hey Guys,

Any thoughts or ideas on when a fix for the -m limit function will be
made/released?

Thanks
Payam


On Thu, Apr 9, 2009 at 6:27 AM, Eray Aslan <erayaslan@gmail.com> wrote:
> On 09.04.2009 11:31, Mart Frauenlob wrote:
>> what about the 'policy' in the 'nat' table? Will it allow 'DROP'?
>
> # /sbin/iptables -V
> iptables v1.4.3.1
> # /sbin/iptables -t nat -P OUTPUT DROP
> iptables v1.4.3.1:
> The "nat" table is not intended for filtering, the use of DROP is
> therefore inhibited.
>
>
> Try `iptables -h' or 'iptables --help' for more information.
> # echo $?
> 2
> # /sbin/iptables -t nat -L|grep OUTPUT
> Chain OUTPUT (policy ACCEPT)
>
>> what about the other non 'filter' tables?
>> Will it be possible to 'DROP' in the mangle table? Or set it's policy to
>> 'DROP'?
>
> Yes
>
>> Isn't dropping in the mangle table almost the same thing as doing that
>> in the nat table?
>
> No.  Not all packets in a connection traverse the nat table.
>
>> At least it violates the concept of filtering in the filter table.
>
> Yes.  Correct place to filter in in the filter table.  But if you insist
> on doing the "wrong" thing, who is to interfere?
>
> [...]
>> I've seen quite some people (mostly unexperienced) mess up their box
>> with that, most of them ending up asking for public help.
>> It seems misleading to me, to make that options available.
>
> Well, software does not grow on trees.  Someone has to write it but is
> it really worth the effort to ban filtering in mangle et al?  Filtering
> in the nat table was especially wrong because it didnot give the
> expected result and I suppose that is reason for the patch/revized
> behaviour.
>
> --
> Eray
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Payam Tarverdyan Chychi
Network Security Specialist / Network Engineer

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Vincent Bernat]

OoO En  ce début  d'après-midi ensoleillé du  jeudi 09 avril  2009, vers
15:27, Eray Aslan <erayaslan@gmail.com> disait :

>> At least it violates the concept of filtering in the filter table.

> Yes.  Correct place to filter in in the filter table.  But if you insist
> on doing the "wrong" thing, who is to interfere?

Well, it  depends what  "wrong" is. When  dropping in filter  table, you
leave an entry in  the conntrack. If you try to drop  to avoid some kind
of DOS, this  is an unwanted effect. When you drop  in PREROUTING in the
nat table, there is no entry in the conntrack. This is really convenient
with matches like "hashlimit".

This loss of functionality should be better explained. Maybe this is the
prelude of some simplification in Netfilter?
-- 
Choose a data representation that makes the program simple.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Eray Aslan]

On 09.04.2009 11:31, Mart Frauenlob wrote:
> what about the 'policy' in the 'nat' table? Will it allow 'DROP'?

# /sbin/iptables -V
iptables v1.4.3.1
# /sbin/iptables -t nat -P OUTPUT DROP
iptables v1.4.3.1:
The "nat" table is not intended for filtering, the use of DROP is
therefore inhibited.


Try `iptables -h' or 'iptables --help' for more information.
# echo $?
2
# /sbin/iptables -t nat -L|grep OUTPUT
Chain OUTPUT (policy ACCEPT)

> what about the other non 'filter' tables?
> Will it be possible to 'DROP' in the mangle table? Or set it's policy to
> 'DROP'?

Yes

> Isn't dropping in the mangle table almost the same thing as doing that
> in the nat table?

No.  Not all packets in a connection traverse the nat table.

> At least it violates the concept of filtering in the filter table.

Yes.  Correct place to filter in in the filter table.  But if you insist
on doing the "wrong" thing, who is to interfere?

[...]
> I've seen quite some people (mostly unexperienced) mess up their box
> with that, most of them ending up asking for public help.
> It seems misleading to me, to make that options available.

Well, software does not grow on trees.  Someone has to write it but is
it really worth the effort to ban filtering in mangle et al?  Filtering
in the nat table was especially wrong because it didnot give the
expected result and I suppose that is reason for the patch/revized
behaviour.

-- 
Eray

Re: [ANNOUNCE] Release of iptables-1.4.3.2

[Mart Frauenlob]

Eray Aslan wrote:
> On 09.04.2009 11:31, Mart Frauenlob wrote:
>   
>> what about the 'policy' in the 'nat' table? Will it allow 'DROP'?
>>     
>
> # /sbin/iptables -V
> iptables v1.4.3.1
> # /sbin/iptables -t nat -P OUTPUT DROP
> iptables v1.4.3.1:
> The "nat" table is not intended for filtering, the use of DROP is
> therefore inhibited.
>
>
> Try `iptables -h' or 'iptables --help' for more information.
> # echo $?
> 2
> # /sbin/iptables -t nat -L|grep OUTPUT
> Chain OUTPUT (policy ACCEPT)
>
>   
>> what about the other non 'filter' tables?
>> Will it be possible to 'DROP' in the mangle table? Or set it's policy to
>> 'DROP'?
>>     
>
> Yes
>
>   
>> Isn't dropping in the mangle table almost the same thing as doing that
>> in the nat table?
>>     
>
> No.  Not all packets in a connection traverse the nat table.
>   
Yes I know...

>> At least it violates the concept of filtering in the filter table.
>>     
>
> Yes.  Correct place to filter in in the filter table.  But if you insist
> on doing the "wrong" thing, who is to interfere?
>
>   
The programmer...
It's not me insisting in doing the wrong thing. I know these things.
I write this, because of all the people who do not.
And this lack of knowledge must be the reason why filtering in the nat 
table was prohibited.
Because people were doing the wrong thing, because they do not know 
better...

So now we have:

- filter table - DROP allowed and right - DROP policy = good
- mangle table - DROP allowed but wrong - DROP policy = bad
- nat table - DROP prohibited and wrong - DROP policy = prohibited
- raw table - DROP allowed and right for avoiding conntrack - DROP 
policy = bad?

That is a little chaotic...

More continuous would be IMHO:

- filter table - DROP allowed and right - DROP policy = good
- mangle table - DROP  prohibited - DROP policy = prohibited
- nat table - DROP prohibited - DROP policy = prohibited
- raw table - DROP allowed and right for avoiding conntrack - DROP 
policy = prohibited

> [...]
>   
>> I've seen quite some people (mostly unexperienced) mess up their box
>> with that, most of them ending up asking for public help.
>> It seems misleading to me, to make that options available.
>>     
>
> Well, software does not grow on trees.  Someone has to write it but is
> it really worth the effort to ban filtering in mangle et al?  Filtering
> in the nat table was especially wrong because it didnot give the
> expected result and I suppose that is reason for the patch/revized
> behaviour.
>   
Again, why allow, what is considered wrong?
If you know what you are doing, filtering in the nat table will do what 
you want, because you know about the special behaviour.
Only the lack of knowledge makes things go wrong.
And that is the point. If you know iptables, you do your filtering in 
the filter table, or in the raw table (to avoid conntrack for some 
blacklist kind of stuff).
If you don't, it happens... You may start setting mangle, raw policies 
to DROP, filter in mangle table, do weird stuff, an experienced user 
would (most likely) never do.

Is it really worth the hassle for approx. hundreds of people every year 
falling into those pitfalls?
Many end up here or on similar places, needs effort for anyone involved.
Iptables is installed on like any linux box out there, and there's  
always a lot of people trying to write their own ruleset.
Many of them are unexperienced. Therefor the concept should be clear, 
continuous and error messages should be understandable.
Preventing the user from doing nonsense. It's about the security, not 
some trivial thing...

Well, just thoughts about my favorite software... :)

btw: if I could (write C), I'd become a software tree... :-;


Good day

Mart

The death of policy (WAS -> Re: [ANNOUNCE] Release of iptables-1.4.3.2)

[Gáspár Lajos]

Mart Frauenlob írta:
> More continuous would be IMHO:
>
> - filter table - DROP allowed and right - DROP policy = good
> - mangle table - DROP  prohibited - DROP policy = prohibited
> - nat table - DROP prohibited - DROP policy = prohibited
> - raw table - DROP allowed and right for avoiding conntrack - DROP 
> policy = prohibited
If I follow you then I would say that we do not need any policy in 
mangle, nat, raw table...
Just simply accept any packet..
> Again, why allow, what is considered wrong?
> If you know what you are doing, filtering in the nat table will do 
> what you want, because you know about the special behaviour.
> Only the lack of knowledge makes things go wrong.
(nod)
> And that is the point. If you know iptables, you do your filtering in 
> the filter table, or in the raw table (to avoid conntrack for some 
> blacklist kind of stuff).
Maybe we could delete that conntrack entry if we drop a packet in the 
filter table...

> Many of them are unexperienced. Therefor the concept should be clear, 
> continuous and error messages should be understandable.
(nod)
> Preventing the user from doing nonsense. It's about the security, not 
> some trivial thing...
(nod)(nod)
>
> Well, just thoughts about my favorite software... :)
>
lol

One more thing...
If there is no policy in the tables (except filter) then the ACCEPT 
target is (MAYBE) useless in those tables...

Swifty