ip6tables icmp conntracking on 2.6.18 vs 2.6.24

ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

Hi,

I have two IPv6 hosts and while one can ping other hosts fine, the
other cannot. I use the simplest ip6tables configuration on both:

  -P INPUT DROP
  -P FORWARD DROP
  -P OUTPUT ACCEPT

  -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A INPUT -j LOG --log-prefix "[INPUT6]: "

On a Debian sid host with 2.6.24, this works fine and my ping6
packets get answered.

On the host running Debian etch with 2.6.18, the ping6's leave, are
answered, but the firewall then catches them:

  [INPUT6]: IN=eth2 OUT=
  MAC=00:16:3e:46:5a:86:00:0e:d6:b8:dc:1b:86:dd SRC=
  2001:41e0:ff00:003b:0000:0000:0000:0001
  DST=2001:1620:2004:0000:0000:0000:0000:0002 LEN=104 TC=0 HOPLIM
  IT=48 FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=48901 SEQ=1

I cannot really reboot the 2.6.18 machine to install the backported
2.6.24 on it right now, and I'd first like to know if the kernel is
actually the culprit.

Are you aware of this issue having been fixed between then and now?

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"all women become like their mothers. that is their tragedy. no man
 does. that's his."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Petr Pisar]

On 2008-04-02, martin f krafft <madduck@madduck.net> wrote:
>
> I have two IPv6 hosts and while one can ping other hosts fine, the
> other cannot. I use the simplest ip6tables configuration on both:
>
>   -P INPUT DROP
>   -P FORWARD DROP
>   -P OUTPUT ACCEPT
>
>   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>   -A INPUT -j LOG --log-prefix "[INPUT6]: "
>
> On a Debian sid host with 2.6.24, this works fine and my ping6
> packets get answered.
>
> On the host running Debian etch with 2.6.18, the ping6's leave, are
> answered, but the firewall then catches them:
>
ICMPv6 is used for neighborhood discovery (similar to ARP in IPv4).
Therefore droping all new packets is bad idea because it will drop ND
requestes from other link local stations.

-- Petr

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Jan Engelhardt]

On Wednesday 2008-04-02 23:44, Petr Pisar wrote:
>> I have two IPv6 hosts and while one can ping other hosts fine, the
>> other cannot. I use the simplest ip6tables configuration on both:
>>
>>   -P INPUT DROP
>>   -P FORWARD DROP
>>   -P OUTPUT ACCEPT
>>
>>   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>>   -A INPUT -j LOG --log-prefix "[INPUT6]: "
>>
>> On a Debian sid host with 2.6.24, this works fine and my ping6
>> packets get answered.
>>
>> On the host running Debian etch with 2.6.18, the ping6's leave, are
>> answered, but the firewall then catches them:
>>
> ICMPv6 is used for neighborhood discovery (similar to ARP in IPv4).
> Therefore droping all new packets is bad idea because it will drop ND
> requestes from other link local stations.

Even so, it should not be INVALID but NEW.

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Petr Pisar <petr.pisar@atlas.cz> [2008.04.02.2344 +0200]:
> ICMPv6 is used for neighborhood discovery (similar to ARP in IPv4).
> Therefore droping all new packets is bad idea because it will drop ND
> requestes from other link local stations.

This is just a test-case, really. I am aware that I need to open the
filter for more ICMP types. But in this case, it's all about
echo-reply not being treated as RELATED...



also sprach Jan Engelhardt <jengelh@computergmbh.de> [2008.04.02.2357 +0200]:
> Even so, it should not be INVALID but NEW.

Right, except RELATED in this case... but I understand your reply
was to Petr.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"durch frauen werden die höhepunkte des lebens bereichert
 und die tiefpunkte vermehrt."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach martin f krafft <madduck@madduck.net> [2008.04.02.2326 +0200]:
>   -P INPUT DROP
>   -P FORWARD DROP
>   -P OUTPUT ACCEPT
> 
>   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>   -A INPUT -j LOG --log-prefix "[INPUT6]: "

This seems to apply to all kinds of connections. If I make an
outgoing SSH connection, the SYN,ACK packet from the peer is
logged and dropped instead of accepted.

Is IPv6 connection tracking on 2.6.18 just broken?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"sailing is, after all, a kind of grace, a kind of magic."
                                                        -- phil berman
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg]

Hello,

martin f krafft a écrit :
> 
> Is IPv6 connection tracking on 2.6.18 just broken?

Are you using a 2.6.18 kernel image from Debian etch or a custom one ?

IPv6 conntrack requires the (now not so) new nf_conntrack, but in kernel 
versions older than 2.6.20 nf_conntrack did not support IPv4 NAT yet. 
Only the old ip_conntrack, the IPv4-only conntrack, did. So IPv6 
conntrack and IPv4 NAT were mutually exclusive. AFAIK 2.6.18 kernel 
images from Debian etch are built with ip_conntrack in order to support 
IPv4 NAT, and do not support IPv6 conntrack.

I am just a bit surprised that using the state match in ip6tables with a 
kernel without IPv6 conntrack support does not trigger an error.

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:

> martin f krafft a écrit :
>>
>> Is IPv6 connection tracking on 2.6.18 just broken?
>
> Are you using a 2.6.18 kernel image from Debian etch or a custom one ?

I noticed the same behaviour on Etch + kernel 2.6.22 (from
backports.org): ICMPv6 echo replies are matched by INVALID.

-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.03.1129 +0200]:
> Are you using a 2.6.18 kernel image from Debian etch or a custom one ?

Debian's.

> IPv6 conntrack requires the (now not so) new nf_conntrack, but in kernel  
> versions older than 2.6.20 nf_conntrack did not support IPv4 NAT yet.  
> Only the old ip_conntrack, the IPv4-only conntrack, did. So IPv6  
> conntrack and IPv4 NAT were mutually exclusive. AFAIK 2.6.18 kernel  
> images from Debian etch are built with ip_conntrack in order to support  
> IPv4 NAT, and do not support IPv6 conntrack.

Excellent explanation, thanks. I can confirm that nf_* modules are
not present in Debian's 2.6.18, but they are with 2.6.24.



also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1136 +0200]:
> I noticed the same behaviour on Etch + kernel 2.6.22 (from
> backports.org): ICMPv6 echo replies are matched by INVALID.

See http://marc.info/?l=netfilter&m=120717177831833&w=2
And this is still the case with 2.6.24.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"whale feces or working at microsoft? i would probably be the whale
 feces researcher. salt air and whale flatulence; what
 could go wrong?"
             -- michael moyer, executive editor of _popular science_
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg]

martin f krafft a écrit :
> 
> also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1136 +0200]:
> 
>>I noticed the same behaviour on Etch + kernel 2.6.22 (from
>>backports.org): ICMPv6 echo replies are matched by INVALID.
> 
> See http://marc.info/?l=netfilter&m=120717177831833&w=2
> And this is still the case with 2.6.24.

I'm not sure what you both mean. I tested the IPv6 conntrack on vanilla 
2.6.20 and 2.6.24 kernels built from kernel.org sources and everything 
worked as expected :

- ping6 :
ICMPv6 echo request -> NEW
ICMPv6 echo reply -> ESTABLISHED

- UDP packet to a closed port :
UDP packet -> NEW
ICMPv6 port unreachable -> RELATED

- TCP connection to a closed port :
TCP SYN -> NEW
TCP RST -> ESTABLISHED

- TCP connection to an open port :
TCP SYN -> NEW
TCP SYN/ACK and the following -> ESTABLISHED

I do not see a reason why 2.6.22 would behave differently. Maybe there 
is something special in Debian kernels ?

Did you check that the echo reply source address matches the echo reply 
destination address ? I observed that some kernels may reply using a 
different source address when the box/interface has several IPv6 
addresses. When this happens the reply gets the INVALID state of course.

However it appears that ICMPv6 types related to neighbor discovery 
(router advertisement, neighbor solicitation/advertisement...) are 
always in the INVALID state.

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.03.1707 +0200]:
> I'm not sure what you both mean. I tested the IPv6 conntrack on vanilla  
> 2.6.20 and 2.6.24 kernels built from kernel.org sources and everything  
> worked as expected :

I agree, it works if you don't have INVALID at all, but try:

  -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  -A INPUT -m state --state INVALID -j DROP
  -A INPUT -m state --state NEW -j in-new

and this will match echo-requests on my 2.6.24. echo-replies get
matched by the first rule, but echo-requests should be NEW, not
INVALID.

> I do not see a reason why 2.6.22 would behave differently. Maybe
> there is something special in Debian kernels ?

This bug I see with 2.6.18 and someone else with 2.6.22. It's
a different issue than what this thread is about: that pre-2.6.24
kernels don't seem to register OUTGOING packets in the connection
table.

Or are you saying that if you ping6 from the machine with the
iptables rules to somewhere else, the echo-reply gets matched by
RELATED or ESTABLISHED? Because it certainly does *not* here.

$ ping6 ipv6.aerasec.de(2001:a60:9002:1::184:1) yields:

[INPUT6]: IN=eth2 OUT= MAC=00:16:3e:46:5a:86:00:0e:d6:b8:dc:1b:86:dd
SRC=2001:0a60:9002:0001:0000:0000:0184:0001
DST=2001:1620:2004:0000:0000:0000:0000:0002 LEN=104 TC=0 HOPLIMIT=57
FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=34094 SEQ=1

which is logged after falling through the end of the chain and *not*
being matched by ESTABLISHED,RELATED. Note that the source address
is the same as the destination address to which I sent the
echo-request.

If I do the same from a 2.6.24 machine, it works, meaning the
echo-reply is matched by ESTABLISHED,RELATED and accepted.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"all language designers are arrogant. goes with the territory..."
                                                         -- larry wall
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg]

martin f krafft a écrit :
> also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.03.1707 +0200]:
> 
>>I'm not sure what you both mean. I tested the IPv6 conntrack on vanilla  
>>2.6.20 and 2.6.24 kernels built from kernel.org sources and everything  
>>worked as expected :
> 
> 
> I agree, it works if you don't have INVALID at all, but try:
> 
>   -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>   -A INPUT -m state --state INVALID -j DROP
>   -A INPUT -m state --state NEW -j in-new
> 
> and this will match echo-requests on my 2.6.24. echo-replies get
> matched by the first rule, but echo-requests should be NEW, not
> INVALID.
> 
> 
>>I do not see a reason why 2.6.22 would behave differently. Maybe
>>there is something special in Debian kernels ?
> 
> 
> This bug I see with 2.6.18

Of course, Debian's 2.6.18 does not support IPv6 conntrack.

> and someone else with 2.6.22.

Nicolas ? He just wrote he couldn't reproduce it.

> It's
> a different issue than what this thread is about: that pre-2.6.24
> kernels don't seem to register OUTGOING packets in the connection
> table.

This is higly unlikely IMHO. People would have noticed it.

> Or are you saying that if you ping6 from the machine with the
> iptables rules to somewhere else, the echo-reply gets matched by
> RELATED or ESTABLISHED?

Yes, of course. The outgoing echo request is in the NEW state and the 
incoming echo reply is in the ESTABLISHED state. Same with an incoming 
echo request.

> Because it certainly does *not* here.
> 
> $ ping6 ipv6.aerasec.de(2001:a60:9002:1::184:1) yields:
> 
> [INPUT6]: IN=eth2 OUT= MAC=00:16:3e:46:5a:86:00:0e:d6:b8:dc:1b:86:dd
> SRC=2001:0a60:9002:0001:0000:0000:0184:0001
> DST=2001:1620:2004:0000:0000:0000:0000:0002 LEN=104 TC=0 HOPLIMIT=57
> FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=34094 SEQ=1
> 
> which is logged after falling through the end of the chain and *not*
> being matched by ESTABLISHED,RELATED. Note that the source address
> is the same as the destination address to which I sent the
> echo-request.

There must be something wrong with your kernel.
Here is what I get :

[NEW]   IN= OUT=eth2 SRC=2001:07a8:6d23:#### 
DST=2001:0a60:9002:0001:0000:0000:0184:0001 LEN=104 TC=0 HOPLIMIT=64 
FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55565 SEQ=1

[ESTAB] IN=eth2 OUT= MAC=#### 
SRC=2001:0a60:9002:0001:0000:0000:0184:0001 DST=2001:07a8:6d23:#### 
LEN=104 TC=0 HOPLIMIT=53 FLOWLBL=0 PROTO=ICMPv6 TYPE=129 CODE=0 ID=55565 
SEQ=1

with the following test ruleset :

ip6tables -t mangle -N logstate
ip6tables -t mangle -A logstate -m state --state NEW -j LOG \
   --log-prefix "[NEW]   "
ip6tables -t mangle -A logstate -m state --state ESTABLISHED -j LOG \
   --log-prefix "[ESTAB] "
ip6tables -t mangle -A logstate -m state --state RELATED -j LOG \
   --log-prefix "[RELAT] "
ip6tables -t mangle -A logstate -m state --state INVALID -j LOG \
   --log-prefix "[INVAL] "
ip6tables -t mangle -A logstate -m state --state UNTRACKED -j LOG \
   --log-prefix "[UNTRA] "

ip6tables -t mangle -A PREROUTING -j logstate
ip6tables -t mangle -A OUTPUT -j logstate

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg]

Pascal Hambourg a écrit :
> martin f krafft a écrit :
> 
>> It's
>> a different issue than what this thread is about: that pre-2.6.24
>> kernels don't seem to register OUTGOING packets in the connection
>> table.
> 
> This is higly unlikely IMHO. People would have noticed it.
> 
>> Or are you saying that if you ping6 from the machine with the
>> iptables rules to somewhere else, the echo-reply gets matched by
>> RELATED or ESTABLISHED?
> 
> Yes, of course. The outgoing echo request is in the NEW state and the 
> incoming echo reply is in the ESTABLISHED state. Same with an incoming 
> echo request.

Oops, I forgot to mention :
# uname -r
2.6.20.3

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.04.0100 +0200]:
>> This bug I see with 2.6.18
>
> Of course, Debian's 2.6.18 does not support IPv6 conntrack.

Okay, this is all I was asking in the original mail.

Note, however, that the 2.6.18 kernel modules exist and everything
can be set up without errors, it then just doesn't work.

>> and someone else with 2.6.22.
>
> Nicolas ? He just wrote he couldn't reproduce it.

Okay, I have not tried.

>> Or are you saying that if you ping6 from the machine with the
>> iptables rules to somewhere else, the echo-reply gets matched by
>> RELATED or ESTABLISHED?
>
> Yes, of course. The outgoing echo request is in the NEW state and
> the  incoming echo reply is in the ESTABLISHED state. Same with an
> incoming  echo request.

... except for 2.6.18, where everything seems like that should be
the case, but it doesn't work at all. Packets aren't even in the NEW
state, it seems.

On 2.6.18, I've observed that --state INVALID seems to match *all*
IPv6 packets, and NEW,ESTABLISHED,RELATED match *none*.

> There must be something wrong with your kernel.

Yeah, it's 2.6.18. You have 2.6.20. Apparently conntrack has been
worked on. That's all I wanted to know.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
you can't assign IP address 127.0.0.1 to the loopback adapter,
because it is a reserved address for loopback devices.
                                  -- micro$oft windoze xp professional
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Pascal Hambourg]

martin f krafft a écrit :
> 
>>>This bug I see with 2.6.18
>>
>>Of course, Debian's 2.6.18 does not support IPv6 conntrack.
> 
> Okay, this is all I was asking in the original mail.
> 
> Note, however, that the 2.6.18 kernel modules exist and everything
> can be set up without errors, it then just doesn't work.

This is getting confused. Didn't you wrote "I can confirm that nf_* 
modules are not present in Debian's 2.6.18" ?

>>>and someone else with 2.6.22.
>>
>> Nicolas ? He just wrote he couldn't reproduce it.
> 
> Okay, I have not tried.

But you reply him that "this is still the case with 2.6.24."
So what exactly is wrong with IPv6 conntrack in 2.6.24 ?
On which pre-2.6.24 versions - besides Debian's 2.6.18 image which has 
IPv6 conntrack support disable at build time, this is not a bug but a 
feature - do you see an IPv6 conntrack bug such as the "don't seem to 
register OUTGOING packets in the connection table" bug you described ?

>>>Or are you saying that if you ping6 from the machine with the
>>>iptables rules to somewhere else, the echo-reply gets matched by
>>>RELATED or ESTABLISHED?
>>
>>Yes, of course. The outgoing echo request is in the NEW state and
>>the  incoming echo reply is in the ESTABLISHED state. Same with an
>>incoming  echo request.
> 
> ... except for 2.6.18, where everything seems like that should be
> the case, but it doesn't work at all. Packets aren't even in the NEW
> state, it seems.
> 
> On 2.6.18, I've observed that --state INVALID seems to match *all*
> IPv6 packets, and NEW,ESTABLISHED,RELATED match *none*.

If I understood correctly, that's just because Debian's 2.6.18 kernel 
image has NF_CONNTRACK disabled at build time and lacks IPv6 conntrack 
support. So using the 'state' match in ip6tables rules with this kernel 
just makes no sense. If you build a custom 2.6.18 kernel with 
NF_CONNTRACK and IPv6 conntrack support enabled instead of 
IP_NF_CONNTRACK, I bet that IPv6 packets will have the proper state.

>>There must be something wrong with your kernel.
> 
> Yeah, it's 2.6.18.

I thought you meant a pre-2.6.24 kernel other than the Debian's 2.6.18.

> You have 2.6.20. Apparently conntrack has been
> worked on.

AFAIK, the only improvement in the area of this thread is that an error 
"can't load conntrack support for proto=10" is triggered when you try to 
use the 'state' match in ip6tables if the kernel is built with 
ip_conntrack, thus lacks IPv6 conntrack support.

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2008.04.04.1819 +0200]:
>> Note, however, that the 2.6.18 kernel modules exist and everything
>> can be set up without errors, it then just doesn't work.
>
> This is getting confused. Didn't you wrote "I can confirm that nf_*  
> modules are not present in Debian's 2.6.18" ?

No, nf_* are not, but ip_conntrack_* are and there is no error when
I load a -m state rule with ip6tables.

> But you reply him that "this is still the case with 2.6.24."
> So what exactly is wrong with IPv6 conntrack in 2.6.24 ?
>
> On which pre-2.6.24 versions - besides Debian's 2.6.18 image which
> has  IPv6 conntrack support disable at build time, this is not
> a bug but a  feature - do you see an IPv6 conntrack bug such as
> the "don't seem to  register OUTGOING packets in the connection
> table" bug you described ?

Yes, http://marc.info/?l=netfilter&m=120717177831833&w=2

Other than that, this thread was to find out whether work has been
done on IPv6 conntrack since 2.6.18.

And apparently in 2.6.22, it's not fixed:

  http://marc.info/?l=netfilter&m=120721692500732&w=2

or is this just a Debian issue? CONFIG_NF_CONNTRACK_IPV6=m is set in
2.6.22.

> AFAIK, the only improvement in the area of this thread is that an error  
> "can't load conntrack support for proto=10" is triggered when you try to  
> use the 'state' match in ip6tables if the kernel is built with  
> ip_conntrack, thus lacks IPv6 conntrack support.

Good. It *does* work on 2.6.24, so I guess we can close this thread.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"when a woman marries again it is because she detested her first husband.
 when a man marries again it is because he adored his first wife.
 women try their luck; men risk theirs."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:

> However it appears that ICMPv6 types related to neighbor discovery
> (router advertisement, neighbor solicitation/advertisement...) are
> always in the INVALID state.

Well, I am confused; I am not able to reproduce what I saw before...
(before last reboot) :-|


I now only have these kernel messages:

IN=eth0 OUT= MAC=33:33:00:00:00:02:00:0f:1f:c9:4e:7d:86:dd SRC=fe80:0000:0000:0000:020f:1fff:fec9:4e7d DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=56 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0

IN=eth0 OUT= MAC=33:33:00:00:00:02:00:0e:35:6c:eb:d0:86:dd SRC=fe80:0000:0000:0000:020e:35ff:fe6c:ebd0 DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=56 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0


ip6tables -nvL shows:

petole:~# ip6tables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  180 19680 ACCEPT     0        *      *       ::/0                 ::/0               state RELATED,ESTABLISHED
    5   340 LOG        0        *      *       ::/0                 ::/0               state INVALID LOG flags 0 level 4
    5   340 DROP       0        *      *       ::/0                 ::/0               state INVALID
    0     0 ACCEPT     0        lo     *       ::/0                 ::/0
    0     0 ACCEPT     0        eth0   *       fe80::/64            ::/0
    0     0 ACCEPT     0        eth0   *       2001:6f8:3f1::/48    ::/0
   13  1352 ACCEPT     icmpv6    *      *       ::/0                 ::/0
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:22
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:25
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:80
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:443
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:465
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:993
    0     0 DROP       0        *      *       ::/0                 ::/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0        *      *       ::/0                 ::/0               state RELATED,ESTABLISHED
    0     0 LOG        0        *      *       ::/0                 ::/0               state INVALID LOG flags 0 level 4
    0     0 DROP       0        *      *       ::/0                 ::/0               state INVALID
    0     0 ACCEPT     0        eth0   *       2001:6f8:3f1::/48    ::/0
    0     0 DROP       0        *      *       ::/0                 ::/0

Chain OUTPUT (policy ACCEPT 194 packets, 20168 bytes)
 pkts bytes target     prot opt in     out     source               destination

-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1735 +0200]:
> IN=eth0 OUT= MAC=33:33:00:00:00:02:00:0f:1f:c9:4e:7d:86:dd
> SRC=fe80:0000:0000:0000:020f:1fff:fec9:4e7d
> DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=56 TC=0
> HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0

Exactly. router-solicitation being matched by INVALID.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"anyone who is capable of getting themselves made president
 should on no account be allowed to do the job"
                                                      -- douglas adams
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

martin f krafft <madduck@madduck.net> writes:

> also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1735 +0200]:
>> IN=eth0 OUT= MAC=33:33:00:00:00:02:00:0f:1f:c9:4e:7d:86:dd
>> SRC=fe80:0000:0000:0000:020f:1fff:fec9:4e7d
>> DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=56 TC=0
>> HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0
>
> Exactly. router-solicitation being matched by INVALID.

Ok.

I added rules to accept these. Do you think this is harmfull ?

petole:~# ip6tables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   27  2808 ACCEPT     0        *      *       ::/0                 ::/0               state RELATED,ESTABLISHED
    0     0 ACCEPT     0        *      *       ::/0                 ff01::/32
    1    76 ACCEPT     0        *      *       ::/0                 ff02::/32
    0     0 LOG        0        *      *       ::/0                 ::/0               state INVALID LOG flags 0 level 4
    0     0 DROP       0        *      *       ::/0                 ::/0               state INVALID
    0     0 ACCEPT     0        lo     *       ::/0                 ::/0
    0     0 ACCEPT     0        *      *       fe80::/64            ::/0
    0     0 ACCEPT     0        eth0   *       2001:6f8:3f1::/48    ::/0
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:22
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:25
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:80
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:443
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:465
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0               tcp dpt:993
    0     0 DROP       0        *      *       ::/0                 ::/0


It works fine.

-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1748 +0200]:
> petole:~# ip6tables -nvL

iptables-save is a better format, I find... Maybe you could post the
output instead?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"aus der kriegsschule des lebens -
 was mich nicht umbringt, macht mich härter."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

martin f krafft <madduck@madduck.net> writes:

> also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1748 +0200]:
>> petole:~# ip6tables -nvL
>
> iptables-save is a better format, I find... Maybe you could post the
> output instead?

Sure, here it is:

# Generated by ip6tables-save v1.3.6 on Fri Apr  4 10:55:14 2008
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [12:1248]
-A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s ::/0 -d ff01::/32 -j ACCEPT
-A INPUT -s ::/0 -d ff02::/32 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
-A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP
-A INPUT -s ::/0 -d ::/0 -i lo -j ACCEPT
-A INPUT -s fe80::/64 -d ::/0 -j ACCEPT
-A INPUT -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -j DROP
-A FORWARD -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT
-A FORWARD -s ::/0 -d ::/0 -j DROP
COMMIT
# Completed on Fri Apr  4 10:55:14 2008


-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.04.1057 +0200]:
> -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -s ::/0 -d ff01::/32 -j ACCEPT
> -A INPUT -s ::/0 -d ff02::/32 -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP

Why do you treat multicast special before INVALID?

> -A INPUT -s fe80::/64 -d ::/0 -j ACCEPT

So local clients should be able to access everything on the machine?
Why treat them special?

> -A INPUT -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT

Source-authenticated rules *can* be exploited.

> -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT

You probably want --syn in there too.

> -A FORWARD -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT

You might want to use -o on those too.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"the 'volatile' keyword
 is implemented syntactically
 but not semantically"
                          -- documentation of m$ visual c, around 1992
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

Martin, Thanks for your reply and comments, they are helpfull !

martin f krafft <madduck@madduck.net> writes:

> also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.04.1057 +0200]:
>> -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>> -A INPUT -s ::/0 -d ff01::/32 -j ACCEPT
>> -A INPUT -s ::/0 -d ff02::/32 -j ACCEPT
>> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
>> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP
>
> Why do you treat multicast special before INVALID?

These rules matched the router sollicitation packets, apparently. I
will reorder the ICMPv6 ACCEPT rule before INVALID.

>> -A INPUT -s fe80::/64 -d ::/0 -j ACCEPT
>
> So local clients should be able to access everything on the machine?
> Why treat them special?

Yes, local clients have full access. So I only restrict remote access
to services. Not very secure, indeed; I will remove this.

>> -A INPUT -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT
>
> Source-authenticated rules *can* be exploited.

Even with the '-i eth0' ?

Well, I will remove this also.

>> -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
>> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
>
> You probably want --syn in there too.

ESTABLISHED,RElATED connections are matched before, so at this point
these can only be new sessions, and so I did not feel it was necessary
to add more checks. I will correct this.

>> -A FORWARD -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>> -A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT
>
> You might want to use -o on those too.

Right.


So, my new configuration is now:

# Generated by ip6tables-save v1.3.6 on Fri Apr  4 13:57:56 2008
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [24:28015]
-A INPUT -s ::/0 -d ::/0 -i lo -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
-A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 465 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 993 -m state --state NEW -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -j DROP
-A FORWARD -s ::/0 -d 2001:6f8:3f1::/48 -i sixxs -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -o sixxs -j ACCEPT
-A FORWARD -s ::/0 -d ::/0 -j DROP
COMMIT
# Completed on Fri Apr  4 13:57:56 2008


-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.04.1359 +0200]:
> > also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.04.1057 +0200]:
> >> -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> >> -A INPUT -s ::/0 -d ff01::/32 -j ACCEPT
> >> -A INPUT -s ::/0 -d ff02::/32 -j ACCEPT
> >> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
> >> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP
> >
> > Why do you treat multicast special before INVALID?
> 
> These rules matched the router sollicitation packets, apparently. I
> will reorder the ICMPv6 ACCEPT rule before INVALID.

I read in another email to this thread that conntrack does not
involved multicast (yet), so you're right.

> >> -A INPUT -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT
> >
> > Source-authenticated rules *can* be exploited.
> 
> Even with the '-i eth0' ?
> 
> Well, I will remove this also.

Sure, if they are on the inside. 70% of the attacks come from the
inside in companies. Of course, if this is a home network, the issue
(and security requirements) are different.

> >> -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
> >> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
> >
> > You probably want --syn in there too.
> 
> ESTABLISHED,RElATED connections are matched before, so at this point
> these can only be new sessions, and so I did not feel it was necessary
> to add more checks. I will correct this.

NEW just means that conntrack does not know about the connection.
--syn means that the SYN flag is set. They *should* be the same, and
if INVALID worked right, then you would never see non-syn flags at
this point, but they do have different meanings.

Ideally, however, --syn is no longer needed if you do

  -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A INPUT -m state --state INVALID -j DROP
  -A INPUT -m state --state NEW -j in-new

  -A in-new -p tcp --dport 22 -j ACCEPT
  [...]

  -A INPUT -j log-and-drop

I /think/ this is the correct way to write iptables rules, but
please correct me if I am wrong, anyone!

> -A INPUT -s ::/0 -d ::/0 -i lo -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Now make sure that your hosts don't honour redirects. I actually
don't think passing *all* ICMPv6 is a good idea. Do read the RFC
(see followup thread).

> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG
> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP

(might not want to log this, actually. who cares?)

> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 465 -m state --state NEW -j ACCEPT
> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 993 -m state --state NEW -j ACCEPT

note how I simplify the rules with the in-new chain...

> -A FORWARD -s ::/0 -d 2001:6f8:3f1::/48 -i sixxs -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -o sixxs -j ACCEPT

In an ideal world, the addresses shouldn't be needed because the
routing tables should ensure that no other peers could be routed
through the interfaces you specify, but I am still not sure about
this...

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
obviously i was either onto something, or on something.
                                 -- larry wall on the creation of perl
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Nicolas KOWALSKI]

martin f krafft <madduck@madduck.net> writes:

> Ideally, however, --syn is no longer needed if you do
>
>   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>   -A INPUT -m state --state INVALID -j DROP
>   -A INPUT -m state --state NEW -j in-new
>
>   -A in-new -p tcp --dport 22 -j ACCEPT
>   [...]
>
>   -A INPUT -j log-and-drop
>
> I /think/ this is the correct way to write iptables rules, but
> please correct me if I am wrong, anyone!

Ok, I use your suggestion.

> Now make sure that your hosts don't honour redirects. I actually
> don't think passing *all* ICMPv6 is a good idea. Do read the RFC
> (see followup thread).

I read the RFC (whose example script contains typos). "Just for fun",
I applied the recommandations, and ended up with the following. Note
the ruleset for ICMPv6... This is getting scary, isn't it ? These
certainly need some cleanup, but you get it.


# Generated by ip6tables-save v1.3.6 on Fri Apr  4 19:54:58 2008
*filter
:INPUT ACCEPT [1:200]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:360]
:IN-NEW - [0:0]
:icmpv6-filter - [0:0]
:icmpv6-filter-from-internal - [0:0]
:icmpv6-filter-to-internal - [0:0]
:icmpv6-filter-to-internal-s - [0:0]
-A INPUT -s ::/0 -d ::/0 -i lo -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP
-A INPUT -s ::/0 -d ::/0 -m state --state NEW -j IN-NEW
-A INPUT -s ::/0 -d ::/0 -j DROP
-A FORWARD -s ::/0 -d ::/0 -p ipv6-icmp -j icmpv6-filter
-A FORWARD -s ::/0 -d 2001:6f8:3f1::/48 -i sixxs -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -o sixxs -j ACCEPT
-A FORWARD -s ::/0 -d ::/0 -j DROP
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 25 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 80 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 443 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 465 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -p tcp -m tcp --dport 993 -j ACCEPT
-A IN-NEW -s ::/0 -d ::/0 -j DROP
-A icmpv6-filter -s ::/0 -d fe80::/10 -p ipv6-icmp -j DROP
-A icmpv6-filter -s fe80::/10 -d ::/0 -p ipv6-icmp -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 137 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 138 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 139 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 140 -j DROP
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/0 -j ACCEPT
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -m state --state RELATED,ESTABLISHED -m icmp6 --icmpv6-type 129 -j ACCEPT
-A icmpv6-filter -s 2001:6f8:3f1::/48 -d ::/0 -j icmpv6-filter-from-internal
-A icmpv6-filter -s ::/0 -d 2001:6f8:3f1::/48 -j icmpv6-filter-to-internal
-A icmpv6-filter -s ::/0 -d ::/0 -p ipv6-icmp -j DROP
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 3/0 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 3/1 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/2 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 145 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/2 -j ACCEPT
-A icmpv6-filter-from-internal -s ::/0 -d ::/0 -j DROP
-A icmpv6-filter-to-internal -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j icmpv6-filter-to-internal-s
-A icmpv6-filter-to-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A icmpv6-filter-to-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 144 -j ACCEPT
-A icmpv6-filter-to-internal -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 146 -j ACCEPT
-A icmpv6-filter-to-internal -s ::/0 -d ::/0 -j DROP
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 3/0 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 3/1 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -p ipv6-icmp -m icmp6 --icmpv6-type 4/2 -j ACCEPT
-A icmpv6-filter-to-internal-s -s ::/0 -d ::/0 -j DROP
COMMIT
# Completed on Fri Apr  4 19:54:58 2008


-- 
Nicolas

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Jozsef Kadlecsik]

On Thu, 3 Apr 2008, martin f krafft wrote:

> also sprach Nicolas KOWALSKI <niko@petole.dyndns.org> [2008.04.03.1735 +0200]:
> > IN=eth0 OUT= MAC=33:33:00:00:00:02:00:0f:1f:c9:4e:7d:86:dd
> > SRC=fe80:0000:0000:0000:020f:1fff:fec9:4e7d
> > DST=ff02:0000:0000:0000:0000:0000:0000:0002 LEN=56 TC=0
> > HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0
> 
> Exactly. router-solicitation being matched by INVALID.

ICMPv6 non-error types (i.e. above type 128) - the exception of 
echo-request (128) and node information query (139)  - are not tracked 
yet, thus such packets are marked as INVALID.

In order to handle ICMPv6 in the best way I'd suggest to read rfc4890
titled Recommendations for Filtering ICMPv6 Messages in Firewalls, which 
even comes with a sample ip6tables script.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.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: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[martin f krafft]

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

also sprach Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> [2008.04.03.1814 +0200]:
> ICMPv6 non-error types (i.e. above type 128) - the exception of 
> echo-request (128) and node information query (139)  - are not tracked 
> yet, thus such packets are marked as INVALID.

Ah, I am glad there is such a straight-forward answer.

Do you have a roadmap for this sort of stuff? Can we expect more
IPv6 support for netfilter in 2.6.25?

> In order to handle ICMPv6 in the best way I'd suggest to read
> rfc4890 titled Recommendations for Filtering ICMPv6 Messages in
> Firewalls, which even comes with a sample ip6tables script.

Perfect. Thanks a lot!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"all i know is that i'm being sued for unfair business 
 practices by micro$oft. hello pot? it's kettle on line two."
                                                  -- michael robertson
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip6tables icmp conntracking on 2.6.18 vs 2.6.24

[Jozsef Kadlecsik]

On Fri, 4 Apr 2008, martin f krafft wrote:

> also sprach Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> [2008.04.03.1814 +0200]:
> > ICMPv6 non-error types (i.e. above type 128) - the exception of 
> > echo-request (128) and node information query (139)  - are not tracked 
> > yet, thus such packets are marked as INVALID.
> 
> Do you have a roadmap for this sort of stuff? Can we expect more
> IPv6 support for netfilter in 2.6.25?

Can't say much because the "missing" informational ICMPv6 messages 
either use multicast addresses or experimental/exotic.

Needless to say most of the problems comes from multicast.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.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

RFC 4890 (icmpv6 firewall recommendations) and ip6tables (was: ip6tables icmp conntracking on 2.6.18 vs 2.6.24)

[martin f krafft]

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

also sprach Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> [2008.04.03.1814 +0200]:
> In order to handle ICMPv6 in the best way I'd suggest to read
> rfc4890 titled Recommendations for Filtering ICMPv6 Messages in
> Firewalls, which even comes with a sample ip6tables script.

I read over that document and I am a bit dazzled at the complexity
of the resulting ip6tables ruleset after running the script. It does
certain things that I'd *hope* wouldn't be necessary because they
remind me of the patchwork that used to be packet filters in their
early days, blocking corner cases that nobody has thought of before.
It's 2008 now and ip6tables/netfilter is highly advanced, so when
I see stuff like this:

  # Drop echo replies which have a multicast address as a destination
  ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
    --icmpv6-type echo-reply -j DROP

I really scratch my head because either Linux should be dropping
such invalid messages itself, or at the very least, netfilter
should, and not even as part of --state INVALID dropping, since
those are invalid packets (if I understand this right) no matter
whether I am tracking state or not.

The next thing I really have to wonder about is why the author
iterates the error messages and for each, adds a rule like

  ip6tables -A icmpv6-filter -m state -p icmpv6 \
    -d $inner_prefix \
    --state ESTABLISHED,RELATED
    --icmpv6-type packet-too-big \
    -j ACCEPT

for each.

This unnecessarily complicates the ruleset to the point an admin
will just lose track, I think. Why not just let a global --state
ESTABLISHED,RELATED rule accept those? I can hardly imagine a case
in which you don't want to ACCEPT ESTABLISHED,RELATED, and if you
do, you should be using NOTRACK, no?

Next, the script adds explicit DROP rules to the FORWARD chain for
most non-errors, like neighbor-solicitation and the like. Why? The
chain policy should be DROP and the ruleset limited to ACCEPTs, no?

I really wonder how this script made its way into an RFC. It's
hardly a recommendation, or well, it isn't a recommendation that's
built on any features in today's netfilter/ip6tables and general
kernel IP stack.

We're early enough in the IPv6 life-cycle that we can fix problems
at the core, rather than recommending rulesets with hundreds of
lines that guard against cases that should never happen anyway, or
rulesets which don't actually harness the power of the tools they
use.

I won't even mention stuff like typos, e.g. under "TIME EXCEEDED
ERROR MESSAGES" we find artifacts of copy-paste errors
("packet-too-big"). But then again, these days, ISO has lowered the
standards of, ha, "standards" anyway. But I won't mention it. :)

I still appreciate that you pointed out this RFC, Jozsef, it
contains a lot of good information and should be required reading
for any IPv6 firewall engineer. I hope you concur, however, that its
appendix B is useless.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the images rushed around his mind and tried
to find somewhere to settle down and make sense.
            -- douglas adams, "the hitchhiker's guide to the galaxy"
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC 4890 (icmpv6 firewall recommendations) and ip6tables (was: ip6tables icmp conntracking on 2.6.18 vs 2.6.24)

[Jozsef Kadlecsik]

On Fri, 4 Apr 2008, martin f krafft wrote:

> also sprach Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> [2008.04.03.1814 +0200]:
> > In order to handle ICMPv6 in the best way I'd suggest to read
> > rfc4890 titled Recommendations for Filtering ICMPv6 Messages in
> > Firewalls, which even comes with a sample ip6tables script.
> 
> I read over that document and I am a bit dazzled at the complexity
> of the resulting ip6tables ruleset after running the script. 
[...]

The RFC is well worth to read because it shows the complexity of ICMPv6 
and the related filtering problems:

- As ARP is replaced by ICMPv6 in IPv6, dropping ICMPv6 blindly means no 
  IPv6 at all.
- IPv6 inherently rely on multicast, but multicast is *not* 
  supported by netfilter connection tracking at all and that must be
  taken into account in the filtering rules.

> I hope you concur, however, that its appendix B is useless.

It's a sample script, as far as I know from the time when IPv6 connection 
tracking in netfilter was experimental and people mostly ran IPv6 
without conntrack.

Let me put this way: a new sample script which is cleaned up and takes the 
current kernel features into account would be highly useful for the 
netfilter user community. Everyone entering the realm of IPv6 faces the 
same filtering problems and a lot of headache, hair-pulling could be saved 
by providing proper recipes.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.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 4890 (icmpv6 firewall recommendations) and ip6tables (was: ip6tables icmp conntracking on 2.6.18 vs 2.6.24)

[martin f krafft]

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

also sprach Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> [2008.04.04.1112 +0200]:
> Let me put this way: a new sample script which is cleaned up and takes the 
> current kernel features into account would be highly useful for the 
> netfilter user community. Everyone entering the realm of IPv6 faces the 
> same filtering problems and a lot of headache, hair-pulling could be saved 
> by providing proper recipes.

With all your help and, it's quite conceivable that I will end up
providing this. Possibly not a script, since I just like
iptables-save format, but an annotated ruleset.

But I probably want to migrate my 2.6.18 hosts to 2.6.24 first so
that I can extensively test.

Feel free to ping me in a few weeks if I haven't written in with the
aforementioned annotated example ruleset.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
in africa some of the native tribes have a custom of beating the
ground with clubs and uttering spine chilling cries. anthropologists
call this a form of primitive self-expression. in america they call
it golf.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC 4890 (icmpv6 firewall recommendations) and ip6tables (was: ip6tables icmp conntracking on 2.6.18 vs 2.6.24)

[martin f krafft]

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

also sprach martin f krafft <madduck@madduck.net> [2008.04.04.1315 +0200]:
> With all your help and, it's quite conceivable that I will end up
> providing this. Possibly not a script, since I just like
> iptables-save format, but an annotated ruleset.

So this is long overdue, and it's not a script, but it's an IPv6
guideline, based on Debian but probably applicable to all other
distros: http://ipv6.debian.net

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
only by counting could humans demonstrate
their independence of computers.
            -- douglas adams, "the hitchhiker's guide to the galaxy"
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: RFC 4890 (icmpv6 firewall recommendations) and ip6tables

[Chris Hills]

On 11/03/09 13:44, martin f krafft wrote:
> So this is long overdue, and it's not a script, but it's an IPv6
> guideline, based on Debian but probably applicable to all other
> distros: http://ipv6.debian.net

This is the basis of my firewall taking into account RFC 4890:-

http://www.chaz6.com/files/ipv6-firewall-v0.01.txt

Regards,

Chris Hills