Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

On 03/08/2013 07:45 PM, Kevin Chadwick wrote:
>>> What would have been best, could have been done years ago and
>>> not cost lots of money and even more in security breaches and
>>> what I meant by ipv5 and would still be better to switch to even
>>> today with everyone being happy to switch to it is simply ipv4
>>> with more bits for address space.
>>
>> This should be FAQ entry zero for the IPV6 FAQ... *NO* you can
>> *NOT* add more bits to IPV4, and still have it backwards
>> compatable.  It won't work... period... end of story.  Every piece
>> of hardware and software that deals with IPV4 has the concept of 32
>> bits *HARD-CODED* into it. Switching over to IPV4-extended would be
>> just as painfull as switching over to IPV6.
>
> No it would not, the headers would be different. All the hardware
> would have already updated because there would be no bad sides and
> it would have been released something like 15 years ago. But lets
> not discuss them as we would be here for an eternity and there are
> already whole websites dedicated to just that.

I don't know, you just dropped the 2-3 most trollish anti-IPv6 posts
I've ever seen.


>
> I re-iterate it would be worth hardware not being backwards
> compatible again to go to ipv4 with large address space today.

"IPv4 with large address space" would have taken just as long to deploy;
it's the hardware support that's held us back the most.

>
> http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf
>
> That's just on security. There's a whole bad side to it's
> functionality too.
>

Let's discuss security. I'll walk through the slide deck.

"We have much less experience with IPv6 than with IPv4"

That's a meaningless statement...

"IPv6 implementations are much less mature than their IPv4 counterparts."

Only in hardware Software has been much better. Windows has had full
IPv6 support since Vista. Linux has
had full IPv6 support for a few years, including IPSec. The software
implementations are written...the stuff that's still arriving is
feature-add.

Offload engines and managed switches haven't switched over because
clients were more interested in putting off a transition (the same
transition you'd have to go through for IPv4 with extended address
space) than paying for the upgrades. This would have happened with any
IPv4 replacement.

"Security products (firewalls, NIDS, etc.) have less support for IPv6
than for
IPv4"

Dedicated commercial products, yes. General-purpose products? Like I
said, Windows Vista made IPv6 a first-class protocol, including firewall
support. Linux's implementation is a bit quirky. I don't care for the
separation between iptables and ip6tables; I think people tend to write
an iptables script and forget to set up a firewall of any kind for IPv6.
Most of the builder tools (i.e. fwbuilder), require seperate setup
between the two, too.

That's why I use sanewall (formerly firehol); defined rules apply to
both IPv4 and IPv6.

"The complexity of the resulting network will greatly increase during
the transition/co-existence period:"

Yes, and that would apply to any transition period.

"Lack of trained human resources"

That's why people like me go out and do training sessions. (I'll be at
Penguicon again this year, if anyone else was thinking about going...)
That's why Hurricane Electric offers free online certification programs.

Regarding flow labels:

"Currently unused by many stacks – others use it improperly"

Honestly, I don't know about this. It's not something most people will
need to work with.

"Might be leveraged to perform “dumb” (stealth) address scans"

I don't understand the relevance; you get the same information by
observing the packet flow without the flow label.

"Might be leveraged to perform Denial of Service attacks"

So might absolutely anything.

Regarding hop limit:

"Could be leveraged for Detecting the Operating System of a remote node"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Fingerprinting a remote physical device"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Locating a node in the network topology"

tcptraceroute does this with IPv4 TTLs. And traceroute has been doing
this with IPV4's ICMP echo for decades.

"Could be leveraged for Evading Network Intrusion Detection Systems (NIDS)"

Just like IPv4 TTL.

"Could be leveraged for Reducing the attack exposure of some
hosts/applications"

Not sure what's being said here, but we're talking about a feature
directly analogous to IPv4 TTL.

(skipping the remainder of the section, as there's nothing in there
that's bad that's unique to IPv6)

(skipping the next several sections, as they're just general technical
training material, and don't discuss security implications)

Re Fragmentation security implications that are different from IPv4:

"The Identification field is much larger: chances of “IP ID collisions”
are reduced"

Good thing.

"Note: Overlapping fragments have been recently forbidden (RFC 5722) –
but they are still allowed by many Oses"

This will improve.

"IPv6 Idle scan"

Noted as being applicable to IPv4.

(skipping some general technical material aimed at sysadmin use for
securing their systems)

(skipping description of IPv6 headers; basic technical information)

(skipping suggested countermeasures for theorized attacks)

"IPv6 can be easily leveraged for evading firewalls."

Not if the firewall is set up properly to begin with. Part of that is
described in the preceding 'countermeasures' section. Most of the
remainder is leveraging the same source, dest, port and state data
that's known in IPv4. Finally, use IPSec if possible. (Right now, IPSec
is largely useful as a VPN technique natively supported by by layer 3)

"Most likely, firewalls will block packets with extension headersEs muy
probable que se haga común el filtrado (en firewalls) de paquetes que
contengan en encabezados de extensión"

Not really; firewalls will continue to be based on known factors, and
most of the interesting known factors are in the first header, not the
extension headers.

"The result will be: less flexibility, possibly preventing any use of
IPv6 exntesion headers"

Extension headers will be used where appropriate.

(skip more benign material)

"Some ICMPv6 messages are assumed to indicate “hard errors”. Some stacks
used to abort TCP connections when hard errors were
received. BSD-derived and Linux implementations don’t--Good!"

I believe Windows's stack is based on BSD. I don't know of any stacks
which do. (None are listed, either)

(skip portion which notes straightforward solutions)

(skip benign material)

Re ICMPv6 Echo Request/Echo response

"Also usually exploited for network reconnaissance"

A.K.A. 'traceroute', a known entity in IPv4.

(skip benign material)

Re Node Information Query/Response

"My take: unless you really need your nodes to support Node Information
messages, disable it (i.e., “sysctl –w net.inet6.icmp6.nodeinfo=0)."

Or even firewall it off at your network edge, like you would any
unblessed, unsolicited inbound traffic.

(skip benign material)

Re Address Resolution Games

"Neighbor Cache Poisoning attacks – the v6 version of V4’s ARP cache
poisoning"

Says it for me...same as IPv4's ARP poisoning. (Incidentally, this is
the attack bandied about the most by people arguing that IPv6 is insecure)

"Advertising “special” link-layer addresses, e.g.,"

That's probably a bug in the implementation. It will be fixed.

"Some implementations (FreeBSD, NetBSD) don’t enforce limits on the
number of entries that can be created in the Neighbor Cache"

Certainly that will change soon.

(Skipping MitM and DoS discussion, as it's analogous to IPv4's ARP
poisoning)

"Not much support in layer-2 security boxes to mitigate these attacks"

This is improving. It hadn't shown up yet because commercial purchasers
had been dragging their feet in demanding their vendors support IPv6 in
the first place.

(skip more benign material)

"Disable an Existing Router"

Depends on the attacker being on the local network, and is what RAGuard
is for.

"Exploit DAD for Denial of Service"

This is the first interesting attack I've seen mentioned in the slide
deck (and I'm on slide 109 out of 167, getting to it).

I don't think there's a way to mitigate against it, except to prevent
the attacker from getting on layer 2 network in the first place.
(Entirely doable with things like 802.1x.)

"Advertise Malicious Network Parameters"

Again, what RAGuard is for.

Re Autoconf Addresses & Privacy

"There were concerns that autoconf addresses hurt privacy, as they could
be used to correlate network activity"

Not all that interesting, actually. That kind of correlating activity is
happening more effectively with DPI and HTTP request headers, and *that*
sees through NAT, privacy addresses and proxy servers.

When people express concerns about autoconf addresses to me, I tell them
that if they're that worried about it, they need to already be using
source-obfuscating techniques like the Tor network.

(skip benign material)

"The use of a single “Destination Options” header is enough to evade
most implementations of RA-Guard."

Sadly, that's on the hardware vendors again. Hopefully, the
commercial-grade vendors will get their crap patched. There's no reason
(that I know of) for an RA-Guard implementation to need to inspect the
destination options header.

"This technique can also be exploited to circumvent Neighbor Discover
monitoring tools such as NDPMon"

I don't know so much about this attack, honestly.

Re DHCPv6

"It can be exploited in a similar way to Router Advertisement messages."

And protected in the same way.

Re MLD

"Potential issues: If a MLD-snooping switch is employed, MLD could be
exploited for Denial of Service attacks."

Largely the same class of attacks as if the attacker is on the local
segment. Enable MLD snooping if and only if you're willing to expand
your attack surface in that way. That's not a difficult question; it's
similar to asking whether you want to use a wireless bridge to a wired
network, or if you want to use a router instead.

Re IPSec

"IPsec support is currentlymantatory for IPv6 implementations – the IETF
is changing this requirement to “optional” thus acknowledging reality."

I have yet to encounter a widely-used IPv6 stack that does not support
IPSec. *BSD, Linux and Windows all support it. The idea of it being
"optional" is irrelevant to the question of whether it's available for
use by servers and desktop machines.

"Also, many IPv4 implementations support IPsec, while many IPv6
implementations do not."

As I said, I have yet to encounter a widely-used IPv6 stack that doesn't
support IPSec. Actually, I haven't encountered *any* IPv6 stack that
doesn't support IPSec. I imagine the ones that don't are in things like
voip phones.

"Most of the key problems (e.g., PKI) for IPsec deployment in IPv4 apply
to IPv6, as well."

This is true, if you want to use PKI for IPSec deployment. If you're
setting up static relationships between campus endpoints, it's not so
big a deal.

"There is no reason to believe that IPv6 will result in an increased use
of IPsec."

Bull. The biggest barrier to IPsec use has been NAT! If an intermediate
router has to rewrite the packet to change the apparent source and/or
destination addresses, then the cryptographic signature will show it,
and the packet will be correctly identified as having been tampered with!

With IPsec, NAT is unnecessary. (You can still use it if you need
it...but please try to avoid it!)

Re "DNS support for IPv6"

"Increased size of DNS responses due to larger addresses might be
exploited for DDos attacks"

That's not even significant. Have you looked at the size of DNS
responses? The increased size of the address pales in comparison to the
amount of other data already stuffed into the packet.

Re "IPv6 Transition Co-Existence Technologies"

"Original transition plan: deploy IPv6 before we ran out of IPv4
addresses, and eventually turn off IPv4 when no longer needed – it
didn’t happen"

That's correct; the IPv6 deployment didn't happen when it should have.
Instead, a ton of coping mechanisms for a shrinking address pool came
around. NAT is the big one. If IPv6 had been deployed early on, people
wouldn't think of "one IP address per customer" as the norm...and they
shouldn't have to.

"An attacker can connect to an IPv4-only network, and forge IPv6 Router
Advertisement messages. (*)"

Again, this depends on them being on the same layer 2 network segment.

The same class of attacks would be possible for any IPv4 successor that
implemented either RAs or DHCP.

(Yes, you will want to deploy the countermeasures described)

(skipping more benign material)

Re ISATAP

"An attacker could forge name resolution responses to--"

Secure your DNS.

"This could be used in conjunction with other attacks (e.g. forging DNS
responses such that--"

Secure your DNS.

Re Problems with 6to4

Actually, I'm going to skip most of this and simply acknowledge it: Yes.
6to4 sucks. It's terrible and horrible. *Everyone* of low-to-moderate
knowledge in IPv6 knows it. Use 6rd instead if you need that kind of
tunnel; at least you'll know who to yell at if it breaks.

Re Security Implications of Teredo:

Yes, Teredo sucks, too. Disable it.

Re 'Translation'

(pardon the US-centric view, here) All major ISPs have deployed (or are
in the process of deploying) native IPv6. Mobile carriers have deployed
IPv6. Tunnels will be largely unnecessary. NAT will remain, but it will
be more prevalent in IPv4 than in IPv6.

Re 'Exploiting Transition Technologies'

"Some systems (notably Windows) have support of trnasition technologies
enabled by default."

Yes. Disable Teredo. I'm not aware any other distro that enables a
tunneling protocol by default.

(skip benign material.)

Re Application-layer protocols

"A number of applications may leak IPv6 addresses: E-mail headers, P2P
applications"

As far as email headers, that's just as in IPv4. You can examine some
folks' IPv4 RFC1918 topology by their email headers today, so don't tell
me IPv6 brings much new to the table.

As for P2P applications, this is actually a good thing; P2P applications
can use what they learn for more efficient peer association.

(skip the rest, as it's benign)