From: "Nikolay S." <nowhere@hakkenden.ath.cx>
To: erik-lists@arpa.org
Cc: netfilter@vger.kernel.org
Subject: Re: ipv6 link local address
Date: Tue, 07 Jun 2011 11:12:56 +0400 [thread overview]
Message-ID: <1307430776.7853.5.camel@hakkenden> (raw)
In-Reply-To: <4DEDCE11.3090004@arpa.org>
В Втр, 07/06/2011 в 00:06 -0700, Erik Schorr пишет:
> On 06/06/2011 11:44 PM, Nikolay S. wrote:
> > В Пнд, 06/06/2011 в 21:47 +0000, bmcdowell@coxhealthplans.com пишет:
> >> Hello list. I'm updating my IBF (invisible bridging firewall) deployments, and I'd like to add support for ip6tables. In the near-term, I'd like to '-P DROP' everything, but I'd rather not have to reinvent the wheel once/when/if we start supporting this protocol in the DMZ.
> >>
> >> Everything seems to be moving along just fine, except the matter of the link local addressing. While not specifically a netfilter issue, I do wonder if anyone on the list has dealt with this in the past. It seems to my somewhat-limited understanding of the protocol that there's simply no way to filter ipv6 without 'speaking' it. Even in my very early days of learning ipv4 I could have specified a '0.0.0.0' address on the interface, but ipv6 is designed from the ground up to prohibit this behavior. Ostensibly for issues such as address allotment, any ipv6 enabled interface defaults to being able to converse with any other interface on the same layer 3 link. For an IBF this is potentially a bad thing, because now my unaddressable device is suddenly addressable, even if only to those on the same local link. The simplest example scenario I can imagine is a compromised FTP/Web server speaking to a vulnerable iptables firewall and re-writing the rules it carries.
> >>
> >> While I can certainly firewall off this traffic easily using netfilter today, I'll not be able to do that forever. The moment I allow link-local traffic I'll be exposing my bridge interfaces to the same. Assuming netfilter is never down or misconfigured seems to be a fatal conceit.
> >>
> >> Thoughts?
> >>
> >>
> >
> > You can turn off ipv6 on interfaces. This should not prevent bridging
> > ipv6, but will remove any ipv6 logic from them.
>
> I wish I'd known this. Could you give an example of how to remove ipv6
> functionality from an interface? I think this was the only thing
> preventing me from unloading an accidentally-loaded ipv6.ko module.
>
Sure
sysctl net.ipv6.conf.{interface|all|default}.disable_ipv6=1
or
echo 1 > /proc/sys/net/ipv6/conf/{interface|all|default}/disable_ipv6
next prev parent reply other threads:[~2011-06-07 7:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 19:35 [2:656]? bmcdowell
2011-06-06 19:57 ` [2:656]? John Lister
2011-06-06 19:59 ` [2:656]? bmcdowell
2011-06-07 9:02 ` [2:656]? Jan Engelhardt
2011-06-07 12:41 ` [2:656]? bmcdowell
2011-06-07 6:44 ` ipv6 link local address Nikolay S.
2011-06-07 7:06 ` Erik Schorr
2011-06-07 7:12 ` Nikolay S. [this message]
2011-06-07 9:04 ` Jan Engelhardt
2011-06-07 9:24 ` Erik Schorr
2011-06-07 9:24 ` Jan Engelhardt
2011-06-07 9:35 ` AW: " Fiedler Roman
2011-06-07 12:44 ` bmcdowell
2011-06-07 14:23 ` Nikolay S.
2011-06-07 14:26 ` bmcdowell
2011-06-07 14:32 ` Nikolay S.
2011-06-07 16:50 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1307430776.7853.5.camel@hakkenden \
--to=nowhere@hakkenden.ath.cx \
--cc=erik-lists@arpa.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.