This article is part of a series which depicts some of the notes I took during several sessions in the Palo Alto Networks Ignite conference in Las Vegas.
IPv6 Security Notes
– Ensure that the IPv6 Firewalling option has been enabled under device > settings otherwise the PaloAlto will just route IPv6 traffic. Post PAN-OS v5 will enable this option by default
– When writing IPv6 security policies targeting ICMP traffic, use the ipv6-icmp application object. Contrast this to IPv4 traffic which uses the icmp and ping address objects
– ICMP plays a much more important role in IPv6 than it did in IPv4, so do not completely block ICMP. This will definitely break some features such as Path MTU discovery and possibly others such as neighbor discovery.
Checklist when buying or migrating to IPv6 capable equipment
– Ensure routers and switches are IPv6 capable. Unless these are very old, they tend to be very feature rich and generally only a software upgrade is needed to obtain IPv6 capabilities
– IPv6 management capability
– IPv6 High Availability features
– IPv6 application and user based policies
– Reporting and visibility into IPv6 traffic
– IPv6 SSL decryption
– IPv6 Holistic threat prevention
– Check for IPv6 ready certification:
The above checks for compliance with several IPv6 features, such as:
- Correct header processing
- Extension header processing
- Fragmentation behavior
- Neighbor discovery and auto configuration
- Router redirects
- ICMPv6 behavior
– However, note that the above do not include any security considerations
Illustration of IPv6 security issues
– Tunneling and other transitional mechanisms can circumvent IPv4 based security policies
– Example: SLAAC [stateless autoconfiguration] attack
The above described attack is easy and normally successfully carried out because:
– IPv6 is now enabled and prefered by default
– Tunneling over IPv6 can provide an easy way out to the internet for an attacker
– Since world IPv6 day, more and more sites are switching on IPv6, meaning most PC prefer to use IPv6 to reach sites such as facebook, google, etc
Mitigation of IPv6 attacks
– Use a static IPv6 host configuration
– Disable IPv6
– Positive enforcement: use policy to shut down tunneling and other known mechanisms that are unneeded and can be used for nefarious purposes
IPv6 PAN-OS notes
Updated support for:
– USER ID
– NAT64 (transition mechanism, NAT IPv6 addresses to IPv4
– OSPFv3 support still lacking
– MP-BGP support still lacking
The article is a more in-depth look at residential IPv6, the final installment of the 2 part series. If you’ve missed it, the 1st article can be found here.
After having established a successful connection to an IPv6 broker server, I fired up wireshark to see what is going on over the wire. We immediately observe IPv6, and in outgoing packets, we can also see the IPv6 in IPv4 encapsulation I mentioned previously:
You can see the inner IPv6 header, encapsulated within a UDP IPv4 datagram on the outside. This transition method is the whole reason why isolated IPv6 “islands” can talk to each other over an as-of-yet predominantly IPv4 internet. As I noted in part 1, observers will note that I did not need any sort of DHCP server to get IPv6 addresses on other nodes in my home network. While DHCPv6 still does play a very important role, another, more automatic method has been introduced in IPv6. This is the router solicitation and router advertisement method. We can see two such packets here:
The first packet, a router solicitation, is sent from a nodes link local address to the “all routers” address (ff02::2). A router will answer with the second packet, a router advertisement, always using the link local address, which looks something like this:
Among the myriad of options, the most important to note is the “prefix information”, which the client uses to build it’s unique global address, using a combination of this prefix and it’s MAC address, without the need of any DHCP server. Similarly, IPv6 has done away with broadcasts, which also includes IPv4’s cornerstone ARP. Instead of ARP, IPv6 uses a similar mechanism to the one presented above, called neighbor solicitation and neighbor advertisement. It serves exactly the same function as ARP… translating a L3 IP address to a L2 MAC address, yet instead of using broadcasts which every node on the link must process, it uses a special form of multicast which only a few nodes will process. For example, we see two such packets here:
In the above screenshot you see the first packet as a “neighbor solicitation” for fe80::5e26:aff:fe15::772f“. Note I drew a relationship between the IP being asked for and the multicast address which the solicitation is being sent on. The multicast’s address last few octets match the MAC address, in fact this multicast address is built from the MAC address. While this is not a one-to-one relation (more than one node may process this multicast), it does significantly reduce the number of nodes that do actually process this packet. The second packet is the “neighbor advertisement” which you can see returns the MAC address.
While sniffing, we also see a bunch of ICMP “packet too big” packets:
These are because of another difference between IPv6 and IPv4: fragmentation. In IPv4, as many admin know, fragmentation can occur at any point along the packet’s path. In fact, in some cases modifying a gateway router/firewalls MTU can solve a number of issues. However, in IPv6, fragmentation can only be done by the end nodes – the PCs themselves. In order for PCs to be able to determine the path MTU, they rely on ICMP “packet too big” messages to figure out what size of packets are acceptable. This points to a valid lesson when building out IPv6 networks… do not block all ICMP traffic like we used to be able to do in IPv4! As you can see above, ICMP in IPv6 is an integral part of the protocol and it would not work without ICMP.
And finally…. a small screenshot of normal HTTP traffic over IPv6:
That is the end of this short IPv6 tutorial / primer, many thanks for reading!