1 |
On 15/02/11 16:52, Alex Efros wrote: |
2 |
[...snip...] |
3 |
> |
4 |
> Keeping this in mind, I think it have sense to avoid enabling IPv6 by |
5 |
> default on hardened until IPv6 will be wide used/tested/hacked on |
6 |
> non-hardened systems for some time or until it become critical feature |
7 |
> required for normal operation on most servers. |
8 |
|
9 |
IMHO, this logic doesn't really make sense. This is a backwards attitude. |
10 |
IPv6 will come for sure, we *need* to implement it. Not enabling it now, |
11 |
will just postpone these security issues further. It's better to flush out |
12 |
those security issues ASAP before even more people uses it. |
13 |
|
14 |
Also consider that most distributions (including |
15 |
RHEL/CentOS/ScientificLinux 5 - with 2.6.18 based kernels) ships with IPv6 |
16 |
enabled. In addition security issues gets found and fixed quicker with |
17 |
broader usages. In most distros security fixes gets included rather |
18 |
quickly, even into the upstream kernels and applications, no matter IPv4 or |
19 |
IPv6. |
20 |
|
21 |
[...snip...] |
22 |
> P.S. BTW, enabling "ipv6" USE-flag isn't enough. Using dual-stack on |
23 |
> secure server also mean doubling nearly all network configuration, |
24 |
> including firewall setup. And while it's well-known how to securely setup |
25 |
> network for IPv4, it still doesn't clear how to do same for IPv6 - both |
26 |
> because IPv6 is much more complex and feature-rich, and because there not |
27 |
> much information/howto available for IPv6 right now. |
28 |
|
29 |
This is much more fear of something new. IPv6 is a different protocol, but |
30 |
when using it, it behaves very much the same as IPv4. You just need to use |
31 |
ip6tables instead of iptables to do filtering, and the addresses look |
32 |
differently. |
33 |
|
34 |
For those really not ready to dive into the IPv6 world yet, they should |
35 |
rather compile their kernel without IPv6 support or blacklist the ipv6 |
36 |
kernel module. Then, no IPv6 traffic will be tackled. And all the user |
37 |
space can still be IPv6 enabled. |
38 |
|
39 |
> So, I think it have |
40 |
> sense to prepare some documentation about IPv6-related configuration on |
41 |
> gentoo site and notify users with `eselect news` mechanism about it before |
42 |
> enabling default "ipv6" USE-flag in any profile. |
43 |
|
44 |
Documentation is *always* a good thing. So improving documentation related |
45 |
to IPv6 is not a bad thing. |
46 |
|
47 |
<rant> |
48 |
But the fact is, which many have not understood: IPv6 simplifies networks |
49 |
much more than complicates it. |
50 |
|
51 |
- There is no netowork address (like 192.168.0.0 for 192.168.0.0/24) |
52 |
|
53 |
- There is no broadcast address (like 192.168.0.255) |
54 |
|
55 |
- There is no 127.0.0.0/8 localhost subnet - only ::1 |
56 |
|
57 |
- There is no NAT - only public IP addresses - which needs to be filtered |
58 |
|
59 |
- Automatic stateless and stateful configuration (if using radvd or DHCPv6) |
60 |
|
61 |
- Manual IPv6 is still an option for those wanting that |
62 |
|
63 |
- Subnetting a /48 or /56 subnet is very easy. |
64 |
{your IPv6 prefix}:{your subnet address} - which gives you a /64 subnet |
65 |
for your network zone ... and you basically don't need to think about |
66 |
any other network masks. A /48 subnet gives you 0000 to FFFF as valid |
67 |
subnet addresses after your IPv6 prefix from your ISP. A /56 subnet |
68 |
gives 00 to FF as valid subnet address. And just think about it ... /48 |
69 |
leaves space for 16 bits for subnetting, so 48 + 16 = 64, hence /64. |
70 |
And the same for 56 + 8 = 64. There is really no big magic. 8 bits |
71 |
gives you values 00-FF, 16 bits gives you 0000-FFFF. And the ISP prefix |
72 |
defines your IPv6 address scope. You can do whatever you'd like with |
73 |
that. |
74 |
|
75 |
The only tricky thing is that you need to enable some ICMPv6 traffic on |
76 |
your internal networks. But if you just open up for all ICMPv6 on internal |
77 |
interfaces, you're practically good to go. |
78 |
|
79 |
Routing is exactly the same as on IPv4. You need to either use 'ip -6 |
80 |
route' or 'route -6' so modify the IPv6 routing table. |
81 |
|
82 |
So the biggest difference, is basically the new addressing scheme, with 128 |
83 |
bits available instead of 32bits. That's all, from the users perspective. |
84 |
|
85 |
What probably should be done is to enable a default IPv6 iptables config |
86 |
which is loaded by default ... which just sets default policy to DROP on |
87 |
INPUT, FORWARD and OUTPUT ... that way, users need to modify the ip6tables |
88 |
rules to gain access. That way we won't take anyone by surprise. |
89 |
|
90 |
This is really not rocket science! Even though it might feel so in the |
91 |
beginning. But take of your IPv4 hat, and accept that IPv6 is simpler to |
92 |
setup - and you'll get far very quickly. |
93 |
</rant> |
94 |
|
95 |
|
96 |
But my core message is, enable IPv6 in all packages asap. Blocking IPv6 |
97 |
should not be done on application level. That should happen on the kernel |
98 |
level. |
99 |
|
100 |
|
101 |
kind regards, |
102 |
|
103 |
David Sommerseth |