Category Archives: Security

Security issues inside networks, applications, or other IT cases.

DNSSEC ZSK Key Rollover

2016-11-08DNS/DNSSEC, Security, Tutorial/HowtoBIND, dig, DNS, DNSSEC, dnssec-keygen, DNSViz, Key Rollover, Public KeyJohannes Weber

One important maintenance requirement for DNSSEC is the key rollover of the zone signing key (ZSK). With this procedure a new public/private key pair is used for signing the resource records, of course without any problems for the end user, i.e., no falsified signatures, etc.

In fact it is really simply to rollover the ZSK with BIND. It is almost one single CLI command to generate a new key with certain time ranges. BIND will use the correct keys at the appropriate time automatically. Here we go:

Continue reading DNSSEC ZSK Key Rollover →

SSHFP: Authenticate SSH Fingerprints via DNSSEC

2016-11-01Authentication, DNS/DNSSEC, SSH, Tutorial/HowtoAuthentication, BIND, DNSSEC, Fingerprint, Hash, Man-in-the-Middle, PuTTY, SSH, ssh-keygen, SSHFPJohannes Weber

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:

Continue reading SSHFP: Authenticate SSH Fingerprints via DNSSEC →

How to use DANE/TLSA

2016-10-25Authentication, Certificate, DNS/DNSSEC, TLS, Tutorial/HowtoBIND, Certificate, DANE, DNS, DNSSEC, hash-slinger, HTTPS, Man-in-the-Middle, SMTPS, TLS, TLSAJohannes Weber

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.

Continue reading How to use DANE/TLSA →

DNSSEC Signing w/ BIND

2016-10-18Crypto, DNS/DNSSEC, Linux, Tutorial/HowtoBIND, Crypto, DNS, DNSSEC, DNSViz, Hash, KSK, Linux, NSEC, ZSKJohannes Weber

To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server to automatically sign zones. I am not explaining any details of DNSSEC, but only the configuration and verification steps for a concrete BIND server.

It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.

Continue reading DNSSEC Signing w/ BIND →

FortiGate 2-Factor Authentication via SMS

2015-12-08Authentication, Fortinet, Password, Tutorial/Howto2-Factor Authentication, FortiGate, Fortinet, SMS, TokenJohannes Weber

Two-factor authentication is quite common these days. That’s good. Many service providers offer a second authentication before entering their systems. Beside hardware tokens or code generator apps, the traditional SMS on a mobile phone can be used for the second factor.

The FortiGate firewalls from Fortinet have the SMS option built-in. No feature license is required for that. Great. The only thing needed is an email-to-SMS provider for sending the text messages. The configuration process on the FortiGate is quite simple, however, both the GUI as well as the CLI are needed for that job. (Oh Fortinet, why aren’t you improving your GUI?)

Here is a step-by-step configuration tutorial for the two-factor authentication via SMS from a FortiGate firewall. My test case was the web-based SSL VPN portal.

Continue reading FortiGate 2-Factor Authentication via SMS →

IPv6 Site-to-Site VPN Recommendations

2015-09-21Design/Policy, IPv6, Routing, SecurityFirewall, IPv6, IPv6 Global Unicast Address, IPv6 Security, Policy, Site-to-Site VPN, Static Route, Traceroute, uRPFJohannes Weber

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 →

F5 SSL Profile: “Single DH use” not working?

2015-05-28Crypto, F5 Networks, TLSCipher Suite, Diffie-Hellman, F5, Logjam, OpenSSL, Perfect Forward Secrecy, PFS, Prime, Public Key, TLS, tsharkJohannes Weber

In the paper of the Logjam attack, a sentence about the F5 load balancers confused me a bit: “The F5 BIG-IP load balancers and hardware TLS frontends will reuse $g^{b}$ unless the “Single DH” option is checked.” This sounds like “it does NOT use a fresh/ephemeral diffie-hellman key for new connections”. I always believed, that when a cipher suite with EDH/DHE is chosen, the diffie-hellman key exchange always generates a new $b$ for computing $g^{b}$ . Hm.

Therefore, I tested this “Single DH use” option on my lab F5 unit, in order to find out whether the same public key (as noted in Wireshark) is used for more than one session.

Continue reading F5 SSL Profile: “Single DH use” not working? →

Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve)

2015-02-13Crypto, Fortinet, IPsec/VPN, Juniper NetworksBits of Security, Brute-Force, Diffie-Hellman, ECC, Elliptic Curve Cryptography, FortiGate, Fortinet, IKE, IPsec, Juniper ScreenOS, Perfect Forward Secrecy, PFS, Site-to-Site VPNJohannes Weber

Similar to my test with Diffie-Hellman group 14 shown here I tested a VPN connection with elliptic curve Diffie-Hellman groups 19 and 20. The considerations why to use these DH groups are listed in the just mentioned post – mainly because of the higher security level they offer. I tested the site-to-site IPsec connections with a Juniper ScreenOS firewall and a Fortinet FortiGate firewall. (Currently, neither Palo Alto Networks nor Cisco ASA support these groups.)

Continue reading Site-to-Site VPNs with Diffie-Hellman Groups 19 & 20 (Elliptic Curve) →

“IPv6-Präfixe würfeln” – Was soll das?

2015-02-09Internet Access, IPv6, Privacyheise online, IPv6, IPv6 Dynamic Prefix, IPv6 Privacy Extensions, OpenWRT, TrackingJohannes Weber

Seit Monaten sieht man auf heise online an der rechten Seite den Link zu einem Artikel namens “IPv6-Präfixe würfeln“. Dabei geht es darum, OpenWRT einen Teil des IPv6-Präfixes innerhalb gewisser Zeitspannen würfeln zu lassen, damit normale IPv6-Clients nicht nur die Interface-ID der Adresse per Privacy Extensions regelmäßig ändern, sondern auch die Subnetz-ID. Da diese Idee aber so gar keinen Vorteil für den Datenschutz mit sich bringt, möchte ich hier mal etwas dazu schreiben.

Continue reading “IPv6-Präfixe würfeln” – Was soll das? →

Palo Alto PANOS 6.1.2: No more SSLv3/POODLE

2015-02-03Crypto, Palo Alto Networks, TLSGlobalProtect, Palo Alto Networks, Poodle, Qualys SSL Labs, TLSJohannes Weber

Another fixed issue in the just released PANOS version 6.1.2 from Palo Alto Networks is bug ID 71321: “Removed support for SSL 3.0 from the GlobalProtect gateway, GlobalProtect portal, and Captive Portal due to CVE-2014-3566 (POODLE).” I scanned my lab unit before (6.1.1) and after the OS upgrade (6.1.2) and here are the results.

Continue reading Palo Alto PANOS 6.1.2: No more SSLv3/POODLE →

Considerations about IPsec Pre-Shared Keys

2015-01-19Authentication, Crypto, IPsec/VPNBrute-Force, IKE, IPsec, Man-in-the-Middle, Pre-Shared Key, PSK, Site-to-Site VPN, VPNJohannes Weber

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.

Continue reading Considerations about IPsec Pre-Shared Keys →

If only one DNS query is malicious …

2015-01-15DNS/DNSSEC, Palo Alto Networks, SecurityDNS, malicious, Malware, Palo Alto Networks, URLJohannes Weber

… the whole Internet breaks down. So happened on a Palo Alto with a DNS proxy and a (slightly misconfigured) anti-spyware profile.

All network clients had a single DNS server configured, namely the DNS proxy of the Palo Alto. And as a single network client requested an URL that was classified as “spyware”, the Palo correctly (!) blocked the DNS session from its DNS proxy to the Internet. Unluckily, this session stayed active for a long time (with drop-all-packets) since many DNS requests were traversing through it. But since it stayed blocked, the Internet was “unavailable” for all end-users.

Continue reading If only one DNS query is malicious … →

Idea: Malware for Testing Next-Gen Firewalls and APT Solutions

2014-12-16Future Work, SecurityAdvanced Persistent Threat, APT, Callback, Malware, Next-Generation Firewall, Server, Trojan Horse, VirusJohannes Weber

When implementing new firewalls at the customers’ site it is always interesting to verify that the anti-virus scanners etc. are running as expected. For simple virus-engines, a sample virus such as the EICAR anti-malware test file can be used. If this “virus” traverses through the firewall inside various protocols such as http, ftp, or smtp, the firewall must block this connection.

However, next-generation firewalls or any other APT (Advanced Persistent Threat) solutions are able to send unknown executables to its own cloud in order to test it. If a malware is found, these products can block future connections with these files, e.g., by updating the anti-virus patterns or their URL categories.

The problem is: How to test whether the “upload unknown files” function works properly? -> My idea is to have a server that generates “dynamic” viruses. When downloading such a “fresh generated” virus, the antivirus engine does not have a pattern for it. That is, the file must be uploaded to an APT solution. The logs on the firewall should list this upload process.

Continue reading Idea: Malware for Testing Next-Gen Firewalls and APT Solutions →

Threema: Zwei Hinweise

2014-12-02Android, iPhone/iPad, PrivacyAuthentizität, Backup, Chat, Otto Normalverbraucher, Threema, VerschlüsselungJohannes Weber

Nach wie vor empfehle ich Threema, wenn es um einen sicheren, also Ende-zu-Ende verschlüsselten, Austausch von Nachrichten, Fotos, usw. geht.

Threema hat allerdings zwei Besonderheiten, die andere Chat Programme nicht haben: Eine Art Punktesystem als Wertung der Authentizität des Gesprächspartners, und die Notwendigkeit, ein Backup seiner ID zu machen, wenn man das Handy einmal wechseln möchte. Beide Sachen haben ihren Ursprung in der Kryptographie und sind daher nicht gerade einleuchtend für den Otto Normalverbraucher. Daher hier ein paar Worte dazu:

Continue reading Threema: Zwei Hinweise →

Apache SSL Cipher Suites: Perfect Forward Secrecy

2014-10-21Crypto, Memorandum, TLSApache, Cipher Suite, Crypto, Diffie-Hellman, OpenSSL, outdated, Perfect Forward Secrecy, Qualys SSL Labs, TLSJohannes Weber

I was interested to tune my https sites with Apache to support only cipher suites that use the ephemeral Diffie-Hellman key exchange = perfect forward secrecy. But after searching a while through the Internet, only SSLCipherSuite with a few concrete algorithms were presented, while I wanted to use a more generic option such as known from “!MD5”. Here it is:

Continue reading Apache SSL Cipher Suites: Perfect Forward Secrecy →

Weberblog.net

IT-Security, Networks, IPv6, VPN, DNSSEC, NTP