It happens occasionally that a customer has to choose between a Palo and a Forti. While I would always favour the Palo for good reasons, I can understand that the Forti is chosen for cost savings, for example.
Fortunately, there is a hidden way of installing PAN-OS, the operating system from Palo Alto Networks, on FortiGate hardware firewalls. Here’s how you can do it:
Continue reading How to install Palo Alto’s PAN-OS on a FortiGate
At SharkFest’22 EU, the Annual Wireshark User and Developer Conference, I attended a beginners’ course called “Network Troubleshooting from Scratch”, taught by the great Jasper Bongertz. In the end, we had some high-level discussions concerning various things, one of them was the insight that TCP RSTs are not only sent from a server in case the port is closed, but are also commonly sent (aka spoofed) from firewalls in case a security policy denies the connection. Key question: Can you distinguish between those spoofed vs. real TCP RSTs? Initially, I thought: no, you can’t, cause the firewalls out there do a great job.
It turned out: you can!
If you’re following my blog you probably know that I am using IPv6 everywhere. Everything in my lab is dual-stacked if not already IPv6-only. Great so far.
A few months ago my lab moved to another ISP which required to change all IP addresses (since I don’t have PI space yet). Oh boy! While it was almost no problem to change the legacy IPv4 addresses (only a few NATs), it was a huge pain in the … to change the complete infrastructure with its global unicast IPv6 addresses. It turned out that changing the interface IPv6 addresses was merely the first step, while many modifications at different services were the actual problem. And this was *only* my lab and not a complex company or the like.
Following you find a list of changes I made for IPv6 and for legacy IP. Just an overview to get an idea of differences and stumbling blocks.
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.)
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 allowing 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! :)
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:
Hello world,
with this post I want to publish my own master thesis which I finished in 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]
