Discussion:
[ipv6hackers] IPv6 Hardening Guide for Linux Servers
Enno Rey
2014-12-16 23:48:59 UTC
Permalink
Hi,

we just released a document with the said title, aimed at specific environments (with high security requirements) which are willing to spend significant resources for hardening.
Details can be found at http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.

We hope some of you may find this helpful and we're happy to get any comments, feedback, criticism from the experts from this group.

Happy holidays to everybody,

Enno & Antonios
--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================
samlt
2014-12-17 13:09:05 UTC
Permalink
Hello,

I have two questions regarding the suggestions from the section "6.2.1
Incoming ICMPv6":

1) why not only accepting ICMP packet-to-big packets related to some
others RELATED connections since you're using a statefull firewall?

2) More generally, for the ICMP types destination-unreachable,
packet-too-big, time-exceeded and parameter-problem, should not it be
enough to match and accept them if they are RELATED to some other
connections? Can these type of packet be direct answers of some other
ICMP probes? (I'm just wondering if the ESTABLISHED state is of any use
in these rules).

I'm probably missing something, so please, don't hesitate to state the
obvious!

Thanks!

samuel
Post by Enno Rey
Hi,
we just released a document with the said title, aimed at specific environments (with high security requirements) which are willing to spend significant resources for hardening.
Details can be found at http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.
We hope some of you may find this helpful and we're happy to get any comments, feedback, criticism from the experts from this group.
Happy holidays to everybody,
Enno & Antonios
Antonios Atlasis
2014-12-17 13:56:07 UTC
Permalink
Hi Sammit,

thanks for your e-mail,
Post by samlt
Hello,
I have two questions regarding the suggestions from the section "6.2.1
1) why not only accepting ICMP packet-to-big packets related to some
others RELATED connections since you're using a statefull firewall?
That's actually a good point. We should/could use the same policy as we did
with the rest of ICMPv6 messages (destination-unreachable, etc.). We wrote
this specific rule in a more relaxed way than the rest because we
considered PTB messages fundamental for the IPv6 operation, but, in the
end, I agree with your comment/question.
Post by samlt
2) More generally, for the ICMP types destination-unreachable,
packet-too-big, time-exceeded and parameter-problem, should not it be
enough to match and accept them if they are RELATED to some other
connections? Can these type of packet be direct answers of some other
ICMP probes? (I'm just wondering if the ESTABLISHED state is of any use
in these rules).
I believe that ESTABLISHED is required. A state RELATED is used when a new
connection is related with _another_ already ESTABLISHED connection (e.g
FTP). On the other hand, ICMP "reply" messages can be considered as
ESTABLISHED, if we receive them as a response to a packet that we sent and
which in turn generated this reply ICMP message. But. to be honest, I
haven't tested the rules with the ESTABLISHED and only with the RELATED
state.
Post by samlt
I'm probably missing something, so please, don't hesitate to state the
obvious!
You are not missing anything, we may do and so, we thank you for your
constructive comments :)

Best

Antonios
Post by samlt
Thanks!
samuel
Post by Enno Rey
Hi,
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Post by Enno Rey
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.
Post by Enno Rey
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Post by Enno Rey
Happy holidays to everybody,
Enno & Antonios
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
s***@intelunix.fr
2014-12-17 21:45:37 UTC
Permalink
Post by Antonios Atlasis
Hi Sammit,
thanks for your e-mail,
...<snip>...
Post by Antonios Atlasis
Post by samlt
2) More generally, for the ICMP types destination-unreachable,
packet-too-big, time-exceeded and parameter-problem, should not it be
enough to match and accept them if they are RELATED to some other
connections? Can these type of packet be direct answers of some other
ICMP probes? (I'm just wondering if the ESTABLISHED state is of any use
in these rules).
I believe that ESTABLISHED is required. A state RELATED is used when a new
connection is related with _another_ already ESTABLISHED connection (e.g
FTP). On the other hand, ICMP "reply" messages can be considered as
ESTABLISHED, if we receive them as a response to a packet that we sent and
which in turn generated this reply ICMP message. But. to be honest, I
haven't tested the rules with the ESTABLISHED and only with the RELATED
state.
This is not how I understand it, I think ICMP "informationnal" messages
are RELATED to other NEW or ESTABLISHED connection.

The following test seems to confirm this:
1) on the host:
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate RELATED -j LOG
--log-prefix "RELATED "
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate ESTABLISHED -j
LOG --log-prefix "ESTABLISHED "

2) on my next hop
sudo ip link set eth0 mtu 1300

3) then here is two lines from the journal:
Dec 17 22:17:33 stl kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=14989 PROTO=ICMP
TYPE=3 CODE=4 [SRC=10.11.12.18 DST=217.70.182.162 LEN=1428 TOS=0x00
PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=4943 SEQ=1 ]
MTU=1300

Dec 17 22:17:34 slt kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=14990 PROTO=ICMP
TYPE=3 CODE=1 [SRC=10.11.12.18 DST=54.192.187.40 LEN=40 TOS=0x00
PREC=0x00 TTL=63 ID=13474 DF PROTO=TCP SPT=57407 DPT=443 WINDOW=0
RES=0x00 RST URGP=0 ]



anyone for a definitive answer?
Post by Antonios Atlasis
Post by samlt
I'm probably missing something, so please, don't hesitate to state the
obvious!
You are not missing anything, we may do and so, we thank you for your
constructive comments :)
Best
Antonios
Post by samlt
Thanks!
samuel
Post by Enno Rey
Hi,
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Post by Enno Rey
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.
Post by Enno Rey
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Post by Enno Rey
Happy holidays to everybody,
Enno & Antonios
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
Antonios Atlasis
2014-12-17 22:31:53 UTC
Permalink
Hi Samuel,

Frankly, I haven't tested it. But you are probably right. At least this is
what your example shows and what in the meantime I also found on the Net,
at least regarding ICMP and IPv4. ICMP error messages (like Dest Unreach,
etc,) are also considered to be RELATED, as you said. Have you tested it
with ip6tables too?

i am going to give it a try soon and will inform the list for the outcome.

Thanks for your valuable feedback.

Antonios
Post by s***@intelunix.fr
Post by Antonios Atlasis
Hi Sammit,
thanks for your e-mail,
Post by s***@intelunix.fr
...<snip>...
2) More generally, for the ICMP types destination-unreachable,
Post by s***@intelunix.fr
packet-too-big, time-exceeded and parameter-problem, should not it be
enough to match and accept them if they are RELATED to some other
connections? Can these type of packet be direct answers of some other
ICMP probes? (I'm just wondering if the ESTABLISHED state is of any use
in these rules).
I believe that ESTABLISHED is required. A state RELATED is used when a
new
connection is related with _another_ already ESTABLISHED connection (e.g
FTP). On the other hand, ICMP "reply" messages can be considered as
ESTABLISHED, if we receive them as a response to a packet that we sent and
which in turn generated this reply ICMP message. But. to be honest, I
haven't tested the rules with the ESTABLISHED and only with the RELATED
state.
This is not how I understand it, I think ICMP "informationnal" messages
are RELATED to other NEW or ESTABLISHED connection.
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate RELATED -j LOG
--log-prefix "RELATED "
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate ESTABLISHED -j LOG
--log-prefix "ESTABLISHED "
2) on my next hop
sudo ip link set eth0 mtu 1300
Dec 17 22:17:33 stl kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=14989 PROTO=ICMP
TYPE=3 CODE=4 [SRC=10.11.12.18 DST=217.70.182.162 LEN=1428 TOS=0x00
PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=4943 SEQ=1 ] MTU=1300
Dec 17 22:17:34 slt kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=14990 PROTO=ICMP TYPE=3
CODE=1 [SRC=10.11.12.18 DST=54.192.187.40 LEN=40 TOS=0x00 PREC=0x00 TTL=63
ID=13474 DF PROTO=TCP SPT=57407 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 ]
anyone for a definitive answer?
Post by Antonios Atlasis
I'm probably missing something, so please, don't hesitate to state the
Post by s***@intelunix.fr
obvious!
You are not missing anything, we may do and so, we thank you for your
constructive comments :)
Best
Antonios
Thanks!
Post by s***@intelunix.fr
samuel
Hi,
Post by Enno Rey
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Post by Enno Rey
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-
for-linux-servers/.
Post by Enno Rey
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Post by Enno Rey
Happy holidays to everybody,
Enno & Antonios
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
Antonios Atlasis
2014-12-18 20:32:43 UTC
Permalink
Hi Samuel,

I verified what you said with ICMPv6 Destination Unreachable. As you said,
it seems that RELATED is more than enough. I haven't gone through the rest
though.

Thanks again for your input.

Antonios
Post by Antonios Atlasis
Hi Samuel,
Frankly, I haven't tested it. But you are probably right. At least this is
what your example shows and what in the meantime I also found on the Net,
at least regarding ICMP and IPv4. ICMP error messages (like Dest Unreach,
etc,) are also considered to be RELATED, as you said. Have you tested it
with ip6tables too?
i am going to give it a try soon and will inform the list for the outcome.
Thanks for your valuable feedback.
Antonios
Post by s***@intelunix.fr
Post by Antonios Atlasis
Hi Sammit,
thanks for your e-mail,
Post by s***@intelunix.fr
...<snip>...
2) More generally, for the ICMP types destination-unreachable,
Post by s***@intelunix.fr
packet-too-big, time-exceeded and parameter-problem, should not it be
enough to match and accept them if they are RELATED to some other
connections? Can these type of packet be direct answers of some other
ICMP probes? (I'm just wondering if the ESTABLISHED state is of any use
in these rules).
I believe that ESTABLISHED is required. A state RELATED is used when a
new
connection is related with _another_ already ESTABLISHED connection (e.g
FTP). On the other hand, ICMP "reply" messages can be considered as
ESTABLISHED, if we receive them as a response to a packet that we sent and
which in turn generated this reply ICMP message. But. to be honest, I
haven't tested the rules with the ESTABLISHED and only with the RELATED
state.
This is not how I understand it, I think ICMP "informationnal" messages
are RELATED to other NEW or ESTABLISHED connection.
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate RELATED -j LOG
--log-prefix "RELATED "
sudo iptables -I INPUT -i wlp3s0 -m conntrack --ctstate ESTABLISHED -j
LOG --log-prefix "ESTABLISHED "
2) on my next hop
sudo ip link set eth0 mtu 1300
Dec 17 22:17:33 stl kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=14989 PROTO=ICMP
TYPE=3 CODE=4 [SRC=10.11.12.18 DST=217.70.182.162 LEN=1428 TOS=0x00
PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=4943 SEQ=1 ] MTU=1300
Dec 17 22:17:34 slt kernel: RELATED IN=wlp3s0 OUT=
MAC=60:67:20:cd:b7:42:b8:27:eb:a6:0b:de:08:00 SRC=10.11.12.15
DST=10.11.12.18 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=14990 PROTO=ICMP TYPE=3
CODE=1 [SRC=10.11.12.18 DST=54.192.187.40 LEN=40 TOS=0x00 PREC=0x00 TTL=63
ID=13474 DF PROTO=TCP SPT=57407 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 ]
anyone for a definitive answer?
Post by Antonios Atlasis
I'm probably missing something, so please, don't hesitate to state the
Post by s***@intelunix.fr
obvious!
You are not missing anything, we may do and so, we thank you for your
constructive comments :)
Best
Antonios
Thanks!
Post by s***@intelunix.fr
samuel
Hi,
Post by Enno Rey
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Post by Enno Rey
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-
for-linux-servers/.
Post by Enno Rey
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Post by Enno Rey
Happy holidays to everybody,
Enno & Antonios
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
Markus Reschke
2014-12-17 14:23:21 UTC
Permalink
On Wed, 17 Dec 2014, samlt wrote:

Hi!
Post by samlt
I have two questions regarding the suggestions from the section "6.2.1
Since we're talking about filter rules for linux servers, what do you
think about RFC4890? I've set up my rules for ICMPv6 based on RFC4890 and
added some rate limiting for the obvious stuff.

Cheers,
Markus
--
/ Markus Reschke \ / ***@theca-tabellaria.de \ / FidoNet 2:240/1661 \
\ / \ / \ /
Jake Cee
2014-12-17 18:09:17 UTC
Permalink
Thanks for a great guide! One very minor suggestion for the next revision:

In the iptables examples your rules apply to all interfaces (as they
should) except for the drop extension header rules, which your examples
only apply to eth1. Some folks that copy/paste might miss that detail and
only end up protecting one of their interfaces.

Cheers and thanks,
Jake Czyz
jczyz.com
Post by Enno Rey
Hi,
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Happy holidays to everybody,
Enno & Antonios
--
Enno Rey
ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey
=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
=======================================================
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
Antonios Atlasis
2014-12-17 18:28:23 UTC
Permalink
Thanks for the suggestion, Jake!

You are absolutely right :)

Best

Antonios
Post by Jake Cee
In the iptables examples your rules apply to all interfaces (as they
should) except for the drop extension header rules, which your examples
only apply to eth1. Some folks that copy/paste might miss that detail and
only end up protecting one of their interfaces.
Cheers and thanks,
Jake Czyz
jczyz.com
Post by Enno Rey
Hi,
we just released a document with the said title, aimed at specific
environments (with high security requirements) which are willing to spend
significant resources for hardening.
Details can be found at
http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/.
Post by Enno Rey
We hope some of you may find this helpful and we're happy to get any
comments, feedback, criticism from the experts from this group.
Happy holidays to everybody,
Enno & Antonios
--
Enno Rey
ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey
=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
=======================================================
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
Loading...