With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!
However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!
The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)
Continue reading IPv6 Site-to-Site VPN Recommendations
One core topic when designing firewall policies is the following question: Is ping a security attack? Should ICMP echo-request messages be blocked in almost any directions?
My short answer: Ping is your friend. :) You won’t block hackers if you block ping. Instead, ping is quite useful for network administrators checking basic network connectivity. That is: I suggest to allow ping anywhere around, accept incoming connections from the Internet to the trusted networks.
Here comes a discussion:
Continue reading Why Ping is no Security Flaw! (But your Friend)
I missed a sequence diagram for DHCP which not only shows the four basic messages (DISCOVER, OFFER, REQUEST, ACK), but also the used source/destination addresses and ports, the type of connection (unicast/broadcast), the differences between the initial and the renewing messages, and the needed firewall rules for allowing DHCP traffic to/from the own interface or to/from a DHCP relay agent.
Here it comes! :)
Continue reading DHCP Sequences: Broadcast vs. Unicast
During my job I am frequently discussing with people why they use NAT or why they believe that NAT adds any security to their networks, mainly some obscurity as NAT (PAT) hides the internal network structure. However, NAT does not add any real security to a network while it breaks almost any good concepts of a structured network design. To emphasize this thesis, here is a discussion:
Continue reading Why NAT has nothing to do with Security!
with this post I want to publish my own master thesis which I finished on February 2013 about the topic “IPv6 Security Test Laboratory”. (I studied the Master of IT-Security at the Ruhr-Uni Bochum.) I explained many IPv6 security issues in detail and tested three firewalls (Cisco ASA, Juniper SSG, Palo Alto PA) against all these IPv6 security attacks.
[UPDATE]Before reading the huge master thesis, this overview of IPv6 Security may be a good starting point for IPv6 security issues.[/UPDATE]
Continue reading IPv6 Security Master Thesis