# FortiGate Syslog via TLS

As we have just set up a TLS capable syslog server, let’s configure a Fortinet FortiGate firewall to send syslog messages via an encrypted channel (TLS). Let’s go:

# Palo Alto Syslog via TLS

As we have just set up a TLS capable syslog server, let’s configure a Palo Alto Networks firewall to send syslog messages via an encrypted channel. While it was quite straightforward to configure I ran into a couple of (unresolved) problems as I added and deleted some syslog servers and their certificates. Uhm.

# syslog-ng with TLS: Installation Guide

Some years ago I wrote a blog post called “Basic syslog-ng Installation“. While I used it myself quite often in my labs or at the customers’ sites, it shows only basic UDP transport which is both unreliable and insecure. So, let’s have a look at a fresh installation of syslog-ng with TLS support for security reasons. However, TCP and UDP as transport are covered as well for the support of legacy systems.

# Decrypting TLS Traffic with PolarProxy

This is a guest blog post by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC.

PolarProxy is a transparent TLS proxy that outputs decrypted TLS traffic as PCAP files. PolarProxy doesn’t interfere with the tunnelled data in any way, it simply takes the incoming TLS stream, decrypts it, re-encrypts it and forwards it to the destination. Because of this PolarProxy can be used as a generic TLS decryption proxy for just about any protocol that uses TLS encryption, including HTTPS, HTTP/2, DoH, DoT, FTPS, SMTPS, IMAPS, POP3S and SIP-TLS.

PolarProxy is primarily designed for inspecting otherwise encrypted traffic from malware, such as botnets that use HTTPS for command-and-control of victim PCs. Other popular use cases for PolarProxy is to inspect encrypted traffic from IoT devices and other embedded products or to analyze otherwise encrypted traffic from mobile phones and tablets. The fact that PolarProxy exports the decrypted traffic in a decrypted format without any TLS headers also enables users to inspect the decrypted traffic with products that don’t support TLS decryption, such as intrusion detection and network forensics products like Suricata, Zeek and NetworkMiner.

# NTS Published as Standard

This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.

The Internet Engineering Task Force (IETF) published the Network Time Security protocol (NTS) as RFC 8915 on October 1, 2020. This new standard offers security mechanisms for the widely used Network Time Protocol v4 (NTPv4), which has been operated mostly unsecured until now. After almost eight years of development, global collaboration, and many interoperability tests of leading NTP software developers, NTS represents a mature security protocol. In this post, I’ll give you a short overview of the development progress of NTS and provide a list of public implementations and NTS secured time servers…

# Types of VPN

Another small post out of my “At a Glance” series: The different types of virtual private networks (VPNs). Looking at Site-to-Site and Remote Access VPNs.

# Setting up NTS-Secured NTP with NTPsec

This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.

In the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already some independent NTS implementations and public time servers (IETF106). NTPsec is one of the important representatives of this series and already offers an advanced NTS solution. In this post, I’ll give you a short guide to setting up an NTS-secured NTP client/server with NTPsec.

# Network Time Security – Strengths & Weaknesses

This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.

The Network Time Security protocol (NTS) is close to completion as an Internet standard and will replace the existing security mechanisms in NTP. The introductory article on NTS describes the basic communication process as well as the most important features. Despite high-security efforts, NTS also has its limitations. In this blogpost, I list the strengths and weaknesses of the new authentication mechanism and describe them briefly.

# Network Time Security – New NTP Authentication Mechanism

This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.

In many areas, the use of authentication mechanisms in NTP is important to prevent the manipulation of time information by an attacker. For many years, NTP has been offering solutions such as a Symmetric Key based method and the Autokey approach. However, both have serious disadvantages, for which reason they are rarely used to secure NTP connections. After years of development, a new standard is to be adopted in 2020 that solves the problems of the current mechanisms and offers a real alternative. First implementations of the so-called Network Time Security protocol (NTS) are already available and interoperate with each other …

# Idea: On-the-Fly TLSA Record Spoofing

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.

# How to use DANE/TLSA

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.

# Roundcube Installation Guide

Roundcube is an email webclient which is easy and intuitive to use. I am using it for my private mails, connecting via IMAP and SMTP to my hoster. One of the great advantages is the “flag” option which is synchronized via IMAP to my Apple devices.

Following is a step-by-step installation guide for Roundcube plus an update scenario. It is a kind of “memo for myself”, but hopefully, others can use it as well.

# Yet another ownCloud Installation Guide

If you want to use you own ownCloud installation, you can find several documentation on the Internet on how to set up this server, e.g. the official ownCloud documentation, or installation guides such as this or that or here. But none of these page alone provided enough information for installing a secure server completely from the beginning.

So here comes my step-by-step guide which surely won’t be complete, too. ;) However, hopefully it will help other people while searching for their way to install ownCloud. Additionally I am showing how to upgrade an ownCloud server.

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

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.

# Palo Alto PANOS 6.1.2: No more SSLv3/POODLE

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.