1 |
El 26/06/12 05:03, Alex Efros escribió: |
2 |
> Hi! |
3 |
Hi! |
4 |
> On Mon, Jun 25, 2012 at 08:58:49AM -0500, Matthew Thode wrote: |
5 |
>>> I'm alerting users so that you can make whatever changes you like to |
6 |
>>> ipv6 in your /etc/make.conf. In about 24 hours I will turn on by |
7 |
>>> default ipv6 on all hardened profiles. |
8 |
>> I use ipv6 on all my servers (not that everyone does). We will have to |
9 |
>> enable it eventually, sooner is probably better then later I think. |
10 |
> Correct me if I'm wrong, but enabling IPv6 mean needs in supporting two |
11 |
> different routing tables and two different firewalls. |
12 |
Different routing tables maybe but the firewall is still the same, the |
13 |
iptables based one. And with the ipv6 USE you get it. |
14 |
> Also, I suppose |
15 |
> enabling IPv6 on any server/router with non-trivial IPv4 firewall rules |
16 |
> may (and probably will!) result in creating new security holes until admin |
17 |
> will develop IPv6 firewall rules similar to existing IPv4 firewall rules. |
18 |
The use has little to nothing to see with this, the ipv6 is not a magic |
19 |
use flag that necessarily works with all packages, it only does it with |
20 |
those that have it. Other may just not have an option to disable ipv6. |
21 |
Anyway for this to happen you must (and these are all necessary conditions): |
22 |
* Have an ipv6 route from the attacker to the affected machine |
23 |
* Have ipv6 enable on the kernel. |
24 |
* Have an ipv6 address assigned accesible by the attacker. |
25 |
* Get the attacker to know said address (since bruteforcing the address |
26 |
space is hard to say the least). |
27 |
* Have anything listening on that address (depending on the attack the |
28 |
icmpv6 server could be it but there are other services who listen to |
29 |
ipv6 no matter what you do). |
30 |
|
31 |
If one of them doesn't hold the risk is not much more than the risk some |
32 |
uncalled code can provide which is still not much. |
33 |
> And I suppose just trying to duplicate existing rules as is won't be |
34 |
> enough because of new IPv6-specific features, which is absent in IPv4, |
35 |
> and which should be additionally blocked/enabled too. |
36 |
This depends a lot on which rules you have. In general it is more about |
37 |
the address block than anything else. |
38 |
> If I'm right (about creating new security holes because of enabling ipv6 |
39 |
> USE flag) then it may be bad idea to enable it by default until we'll be |
40 |
> sure admin is ready for this (for example, we may check is IPv6 enabled in |
41 |
> kernel and is there exists IPv6 firewall rules). |
42 |
You are mostly wrong, the only issue I can think of is if you enabled |
43 |
ipv6 on the kernel in which case you are probably fucked since daemons |
44 |
may be listening there anyway even before the change. |
45 |
> BTW, is there exists (Gentoo?) guides/howtos which explain these issues |
46 |
> (preferably from "differences from IPv4" point of view) to average admin |
47 |
> who know how to setup IPv4 and know nothing about IPv6, and provide |
48 |
> minimum recommended configuration for IPv6 routing/firewall? I think |
49 |
> enabling IPv6 by default should begins from writing such docs. |
50 |
# ip6tables -A INPUT -j DROP |
51 |
# ip6tables -A OUTPUT -j DROP |
52 |
# ip6tables -A FORWARD -j DROP |
53 |
There you are safe now. |