Op 17-4-2012 10:33, Carlos Martinez-Cagnazzo schreef:

IMO it's much easier to disable one rogue than to disable IPv6 on the whole network. That is if you can find it, but with some proper tcpdumping and/or CLI commands (depending on the switches that you have) it should be relatively easy.

Even better, the IPv6 gateway you got assigned is based on the MAC address. That means you can also find what brand of device is advertising. http://standards.ieee.org/develop/regauth/oui/public.html You can most likely find which IPv4 address the MAC corresponds too as well. Was that so hard?

Not to mention that, as pointed by others, this provides a wonderful opportunity to look into this new (*grin*) protocol.

Indeed!

Cheers!

~Carlos

Cheers, Seth

tcpdump -e will show source and dest mac address. On Apr 17, 2012, at 6:54 AM, Ray Soucy <rps@maine.edu> wrote:

tcpdump -ni eth0 'ip6 dst ff02::1'

06:48:48.044409 IP6 fe80::2d0:1ff:fedf:8400 > ff02::1: ICMP6, router advertisement, length 64

Thanks for useful reply everyone! As I mentioned - I applied quick temporary fix by stop broadcast from router and clearing of routing table on servers. Will apply disabling of autoconfig now. On Tue, Apr 17, 2012 at 5:25 PM, Mick O'Rourke <mkorourke+nanog@gmail.com>wrote:

RA guard is useful if your tcam capacity and or switching platform allows - http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-01

An older yet still a good read from Cisco on some IPv6 first hop security:

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_s...

Mick

-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com

On Mon, 16 Apr 2012 17:38:07 -0400, Brandon Penglase said:

flat out broke. Sadly this event left a really sour taste for IPv6 with Networking department (whom I was occasionally bugging about v6).

Talking point: "If you guys had deployed a proper IPv6 infrastructure, those tunnels wouldn't have happened and there would have been no problem". The best defense against a user accidentally deploying some infrastructure incorrectly is to do a pre-emptive correct deployment.

I don't understand why a problem with a tunnel 'leaves a bad taste with IPv6'. Since when a badly configured DNS zone left people with a 'bad taste for DNS', or a badly configured switch left people with 'a bad taste for spanning tree' or 'a bad taste for vlan trunking' ? It seems to me that what are perceived as operational mistakes and/or plain lack of knowledge for some technologies is perceived as a fault of the protocol itself in the case of IPv6. People need to get their acts together. ~Carlos On 4/16/12 11:38 PM, Brandon Penglase wrote:

I know you mentioned RedHat, but not if it was the router or other servers. Were you playing with Microsoft's Direct Access and turn on the dns entry (isatap.domain.com) internally? At my current place of employment, we had a security student (at the direction of our security analyst) turn up a DA test server. When they enabled the DNS entry, just about every Windows 7 and 2008 server setup a v6 tunnel back to this little tiny VM. This also included the DNS entries in AD, so all of the sudden, servers have v6 addresses. Needless to say, everything was horribly slow, and some things even flat out broke. Sadly this event left a really sour taste for IPv6 with Networking department (whom I was occasionally bugging about v6).

If you weren't testing this, did you possibly setup something similar where it would automatically generate a tunnel?

Brandon Penglase

On Mon, 16 Apr 2012 23:39:46 +0530 Anurag Bhatia <me@anuragbhatia.com> wrote:

...

Hello everyone

Just got a awfully crazy issue. I heard from our support team about failure of whois during domain registration. Initially I thought of port 43 TCP block or something but found it was all ok. Later when ran whois manually on server via terminal it failed. Found problem that server was connecting to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 and not just that one - almost all. This was scary - partial IPv6 setup and it was breaking things.

In routing tables, routes were all going to a router which I recently setup for testing. That router and other servers are under same switch but by no means I ever configured that router as default gateway for IPv6. I found option of "broadcast" was enabled on router for local fe80... address and I guess router broadcasted IPv6 and somehow (??) all servers found that they have a IPv6 router on LAN and started using it - automated DHCP IPv6?

I wonder if anyone else also had similar issues? Also, if my guesses are correct then how can we disable Red Hat distro oriented servers from taking such automated configuration - simple DHCP in IPv6 disable?

Thanks

--

Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com

Most switches nowadays have dhcpv4 detection that can be enabled for port ranges. Not sure about v6. -Grant On Sun, Apr 22, 2012 at 11:32 PM, Joel jaeggli <joelja@bogus.com> wrote:

On 4/17/12 01:37 , Carlos Martinez-Cagnazzo wrote:

...

I don't understand why a problem with a tunnel 'leaves a bad taste with IPv6'. Since when a badly configured DNS zone left people with a 'bad taste for DNS', or a badly configured switch left people with 'a bad taste for spanning tree' or 'a bad taste for vlan trunking' ?

It seems to me that what are perceived as operational mistakes and/or plain lack of knowledge for some technologies is perceived as a fault of the protocol itself in the case of IPv6.

rogue dhcp servers are sufficiently common that tools had to be developed to address their existence and they're still a nuisance after all that.

...

People need to get their acts together.

indeed.

On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote:

On 4/22/12, Grant Ridder <shortdudey123@gmail.com> wrote:

...

Most switches nowadays have dhcpv4 detection that can be enabled for port

Yes. Many L2 switches have DHCPv4 "Snooping", where some port(s) can be so designated as trusted DHCP server ports, for certain Virtual LANs; and dhcp messages can be detected and suppressed from unauthorized edge ports.

Sounds suspiciously like IPv6 RA Guard, no?

Particularly good L2 switches also have DAI or "IP Source guard" IPv4 functions, which when properly enabled, can foil certain L2 ARP and IPv4 source address spoofing attacks, respectively.

e.g. Source IP address of packet does not match one of the DHCP leases issued to that port -- then drop the packet.

Meh... I can see many cases where that might be more of a bug than feature. Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event.

As for IPv6; rfc6105; you have ipv6 nd raguard

and IOS NDP inspection.

However, there are caveats that should be noted. RA guard implementations can be trivially fooled by the use of crafted packets.

Frankly, I suggest dropping any RA that doesn't fit in a single packet as a simple solution to the crafted-packet issue. (The crafted packet attacks by and large depend on crafting it so that there are enough extension headers to put the RA header in the second or later fragment).

These are potentially good protections against accidental configuration errors, but not malicious attack from a general purpose computer.

If you have a malicious attack from a general purpose computer on your own LAN, you've already lost on multiple levels to some extent or other. The most effective solution at that point is to identify, locate, and excise said attacker.

Currently, IPv4 seems to win at L2 easily in regards to the level of hardware security features commonly available on L2 switches that pertain to IP.

There was a time when one probably could have argued that Novell beat IP on that basis alone. IPv4 loses when you consider that there are more than 3.2 billion people in the world. That people likely will need a minimum of 5 IP addresses each. That we also need to number infrastructure, routers, servers, sensor grids, etc. IPv4 also loses when you consider the pervasiveness of debilitated IPv4 internetworking in favor of address conservation over the last 20 years. Owen

...

-Grant -- -JH

On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote:

On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote:

...

On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote:

...

Particularly good L2 switches also have DAI or "IP Source guard" IPv4 functions, which when properly enabled, can foil certain L2 ARP and IPv4 source address spoofing attacks, respectively.

...

e.g. Source IP address of packet does not match one of the DHCP leases issued to that port -- then drop the packet.

Meh... I can see many cases where that might be more of a bug than feature.

Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event.

You're only supposed to use those features on the port directly connected to the end-system, or to a few end-systems via an unmanaged office switch that doesn't have redundant uplinks. I.e. edge ports.

In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6. Owen

On Apr 23, 2012, at 8:23 AM, Chuck Anderson wrote:

On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote:

...

On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote:

...

On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote:

...

On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote:

...

Particularly good L2 switches also have DAI or "IP Source guard" IPv4 functions, which when properly enabled, can foil certain L2 ARP and IPv4 source address spoofing attacks, respectively.

...

e.g. Source IP address of packet does not match one of the DHCP leases issued to that port -- then drop the packet.

Meh... I can see many cases where that might be more of a bug than feature.

Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event.

You're only supposed to use those features on the port directly connected to the end-system, or to a few end-systems via an unmanaged office switch that doesn't have redundant uplinks. I.e. edge ports.

In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6.

If a specific managed environment provides DHCPv6 and doesn't provide SLAAC, and the policies of said environment forbid static addressing, how can enforcing the use of DHCPv6 be counter-productive?

That's a lot of ifs. I said in a lot of cases. I didn't say in all cases. If you satisfy all of your ifs, then it's not one of the cases of which I speak. Owen

Hi, On Mon, Apr 23, 2012 at 12:27:53PM -0400, Valdis.Kletnieks@vt.edu wrote:

On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said:

...

...

On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6. If a specific managed environment provides DHCPv6 and doesn't provide SLAAC, and the policies of said environment forbid static addressing,

That's totally different from Owen's "in a lot of cases". Incidentally, there's absolutely nothing

except for LLT being the default DUID generation mechanism on pretty much every OS... thanks Enno preventing a DHCPv* server from being configured to

always hand out the same IP address to a given MAC address, making it effectively static (in fact, I've seen more than one site that carries nailed down DHCP entries for servers, just to ensure that even if the server gets borked and decides to DHCP itself, it will still come up with the "right" address anyhow).

...

how can enforcing the use of DHCPv6 be counter-productive?

Remember, Owen was talking about "in a lot of cases". I suspect Owen was saying that if you enforce that all source addresses are ones that the DHCPv6 server handed out, you just broke a host that tries to do RFC4941 addresses or other similar things.

-- Enno Rey ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de =======================================================