This is a cool and easy to use (security) feature from Palo Alto Networks firewalls: The External Dynamic Lists which can be used with some (free) 3rd party IP lists to block malicious incoming IP connections. In my case I am using two free IP lists to deny any connection from these sources coming into my network/DMZ. I am showing the configuration of such lists on the Palo Alto as well as some stats about it.
I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.
Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems. (The remote office could even tunnel every outbound IPv6 traffic through a VPN to the headquarter. But if it wants to use a local breakout, this won’t be an alternative.)
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.)
Since IPv6 gets more and more important, I am using it by default on all my test firewalls, which of course support IPv6. However, when comparing the different functions and administration capabilities, they vary significantly.
Here comes my short evaluation of the IPv6 functions on the following four firewalls: Cisco ASA, Fortinet FortiGate, Juniper SSG, and Palo Alto.
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! :)
It was not easy for me to understand the type of zones and “from – to” policy definitions when working with a Palo Alto firewall that has multiple vsys’s and a shared gateway. I was missing an at-a-glance picture that shows which zones to use. (Though this document describes the whole process quite good.) So, here it comes…
The Palo Alto firewall supports policy entries that refer to multiple source and destination zones. This is useful especially when there are branch offices with multiple zones and a site-to-site VPN to the main office. In this scenario, every zone in the branch office might have a “permit any any” to the main office and vice versa, while the zones on the branch office should not have a permit among themselves. (Of course, the traffic on the main office is restricted and not permitted generally.) Here are two ways to accomplish that scenario.
How are passwords stolen? What are common password flaws? What are the security techniques to enhance the security of passwords respectively the security of the login-services? What authentication methods provide long-term security? How often should a password be changed? Which methods achieve good security while not being too complicated to be used by end-users?
This blog post discusses several methods of how passwords are stolen and provides approaches of how login-services can be secured.
Wie dem auch sei: Wir kommen nicht um die Benutzung von Passwörtern herum und es ist nach wie vor wichtig, sichere (= komplexe) Passwörter zu verwenden. Dabei ist es vor allem schwierig, einen Mittelweg aus *sehr schwierigem Passwort* und *trotzdem merkbar* zu finden. Ich möchte hier eine Methode erläutern, bei der man sich ein komplexes Passwort so erzeugt, dass es sich durch eine Eselsbrücke einfach merken lässt.
Continue reading Sichere Passwörter erzeugen & merken