When talking about VPNs it is almost always clear that they are encrypted. However, it is not so clear on which security level a VPN is established. Since the Perfect Forward Secrecy (PFS) values of “DH group 5″ etc. do not clearly specify the “bits of security”, it is a misleadingly assumption that the security is 256 bits due to the symmetric AES-256 cipher. It is not! Diffie-Hellman group 5 has only about 89 bits of security…
Therefore, common firewalls implement DH group 14 which has a least a security level of approximately 103 bits. I tested such a site-to-site VPN tunnel between a Palo Alto and a Juniper ScreenOS firewall which worked without any problems.
I tested the Palo Alto GlobalProtect app on my iPhone, but also the native IPsec Cisco VPN-Client on iOS which connects to the GlobalProtect Gateway on a Palo Alto firewall, too. Since this variant needs no further licenses from Palo Alto, it is a cheap alternative for a basic VPN connection.
Though not that much exciting, there are a few differences in the logs on the firewall which I will show here on the basis of a few screenshots.
This is a tutorial on how to configure the GlobalProtect Gateway on a Palo Alto firewall in order to connect to it from a Linux computer with vpnc.
Short version: Enable IPsec and X-Auth on the Gateway and define a Group Name and Group Password. With this two values (and the gateway address), add a new VPN profile within vpnc on the Linux machine. Login with the already existing credentials.
Long version with screenshots comes here:
Eine sehr praktische Variante, möglichst viele Sensoren übers Netzwerk abzufragen ohne dabei viel basteln zu müssen, ist die Ethernetbox von MessPC. Man kann sie zum Beispiel mit mehreren kombinierten Temperatur/Luftfeuchtigkeits-Sensoren bestücken. Die Auswertung erfolgt am besten über ein zentrales Monitoring-System.
Auf der Homepage von MessPC befindet sich zwar eine kleine Dokumentation für die Verwendung von MRTG, allerdings wird dort ein zusätzliches Skript vorgestellt, was dank der Verwendung von SNMP ja gar nicht nötig ist. Deswegen poste ich hier mein Template von einem MessPC mit zwei Kombisensoren für Temperatur/Luftfeuchtigkeit, welches für die Verwendung mit MRTG und Routers2 gemäß meiner Installation geeignet ist. Mit nur drei Suchen-und-Ersetzen Durchläufen hat man das Template angepasst.
I made the following observation: Just after publishing a link on Twitter, there are several accesses from different IPv4 addresses on that URL. Since I published a link to one of my own servers, I saw these connections on the firewall as well as on the server itself. They all called the http website and stayed for 2-3 seconds on that page.
I would have expected a few search engine bots, but most of the reverse lookup resolutions led to unknown or meaningless names. Maybe someone out there made the same observation with more details on that? Who is accessing the links? Automated bots from Twitter itself? Search engines? Malware bots searching for new victims? And over which function do theses hosts know, that someone has published a new link?
In the IPv4 world, the DHCP server allocates IPv4 addresses and thereby stores the MAC addresses of the clients. In the IPv6 world, if SLAAC (autoconfiguration) is used, no network or security device per se stores the binding between the MAC (layer 2) and the IPv6 (layer 3) addresses from the clients. That is, a subsequent analysis of network behaviour corresponding to concrete IPv6 addresses and their client machines is not possible anymore.
A simple way to overcome this issue is to install a service that captures Duplicate Address Detection (DAD) messages from all clients on the subnet in order to store the bindings of MAC and IPv6 addresses. This can be done with a small Tcpdump script on a dedicated Ethernet interface of a Linux host.
In this blog post I will present a use case for storing these bindings, the concept of the DAD messages, a Tcpdump script for doing this job, and the disadvantages and alternatives of this method.
“We have two independent DSL connections to the Internet and want to share the bandwidth for our users.” This was the basic requirement for a load balancing solution at the customers site. After searching a while for dedicated load balancers and thinking about a Do-It-Yourself Linux router solution, I used an old Cisco router (type 2621, about 40,- € on eBay) with two default routes, each pointing to one of the ISP routers. That fits.