| 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. |
Archives