Angreifer verwenden gern Ping und Traceroute, um Server im Internet ausfindig zu machen. Das bringt viele Security-Admins in Versuchung, den Ping- und Traceroute-Verkehr mittels ihrer Firewall in ihrem Netz zu unterbinden. Doch damit behindern sie nur die Arbeit von Server-Administratoren, denn es gibt noch viel mehr Möglichkeiten, Server aufzuspüren.
… since we all can use pool.ntp.org ? Easy answer: Many modern (security) techniques rely on accurate time. Certificate validation, two-factor authentication, backup auto-deletion, logs generation, and many more. Meanwhile, we use an unauthenticated protocol (via stateless UDP) from unauthenticated sources (NTP pool) to rely on! Really?
If you are using a couple of different NTP sources it might be not that easy for an attacker to spoof your time – though not unfeasible at all. And think about small routers with VPN endpoints and DNSSEC resolving enabled, or IoT devices such as cameras or door openers – they don’t even have a real-time clock with battery inside. They fully rely on NTP.
This is what this blogpost series is all about. Let’s dig into it. ;)
It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.
But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.
Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.
Beside detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.
This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:
DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.
In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.
Pre-shared keys (PSK) are the most common authentication method for site-to-site IPsec VPN tunnels. So what’s to say about the security of PSKs? What is its role for the network security? How complex should PSKs be? Should they be stored additionally? What happens if an attacker catches my PSKs?
I am listing my best practice steps for generating PSKs.
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.
I wrote a very small summary of my IPv6 Security master thesis which gives an introduction to several IPv6 security issues. People that are interested in IPv6 security are welcome to read this summary prior to study the whole master thesis. In this way, they will get an overview of IPv6 security issues before they are flooded with too many details. ;) I wrote this article for the RIPE Labs (published here), but since it gives a good overview about my thesis, I publish it here, too.
Hier gibt es meinen Vortrag vom IPv6-Kongress 2013 in Frankfurt zum Download.
Es ist eine PDF-Datei in der a) die Präsentationsfolien und b) eine Menge Kommentare von mir stehen, die quasi das Gesagte während des Vortrags ziemlich gut abdecken.
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]