A security device such as a firewall should rely on NTP authentication to overcome NTP spoofing attacks. Therefore I am using NTP authentication on the FortiGate as well. As always, this so-called next-generation firewall has a very limited GUI while you need to configure all details through the CLI. I hate it, but that’s the way Fortinet is doing it. Furthermore the “set authentication” command is hidden unless you’re downgrading to NTPv3 (?!?) and it only supports MD5 rather than SHA-1. Not that “next-generation”!
Finally, you have no chance of knowing whether NTP authentication is working or not. I intentionally misconfigured some of my NTP keys which didn’t change anything in the NTP synchronization process while it should not work at all. Fail!
Continue reading Fortinet FortiGate (not) using NTP Authentication
Everyone uses NTP, that’s for sure. But are you using it with authentication on your own stratum 1 servers? You should since this is the only way to provide security against spoofed NTP packets, refer to Why should I run own NTP Servers?. As always, Palo Alto has implemented this security feature in a really easy way, since it requires just a few clicks on the GUI. (Which again is much better than other solutions, e.g., FortiGate, which requires cumbersome CLI commands.) However, monitoring the NTP servers, whether authentication was successful or not, isn’t implemented in a good way. Here we go:
Continue reading Palo Alto Networks NGFW using NTP Authentication
This is how you can use NTP authentication on Cisco IOS in order to authenticate your external NTP servers respectively their NTP packets. Though it is not able to process SHA-1 but only MD5, you’re getting an authentic NTP connection. Let’s have a look:
Continue reading NTP Authentication on Cisco IOS
Now that we have enabled NTP authentication on our own stratum 1 NTP servers (Linux/Raspbian and Meinberg LANTIME) we need to set up this SHA-1 based authentication on our clients. Here we go for a standard Linux ntp setup:
Continue reading NTP Authentication: Client Side
Operating NTP in a secure manner requires the usage of NTP authentication, refer to my Why should I run own NTP Servers? blogpost. Using the Meinberg LANTIME NTP appliance with NTP authentication is quite simply since it requires just a few clicks. Even adding more and more keys (which requires manual work on any other Linux ntp installation) is done within clicks. That’s the way it should be.
Continue reading Meinberg LANTIME NTP Authentication
As already pointed out in my NTP intro blogpost Why should I run own NTP Servers? it is crucial to leverage NTP authentication to have the highest trustworthiness of your time distribution all over your network. Hence the first step is to enable NTP authentication on your own stratum 1 NTP servers, in my case two Raspberry Pis with DCF77/GPS reference clocks.
Continue reading NTP Authentication: Server Side
… 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?
TL;DR: If you want to operate a secure environment you should use your own on-site stratum 1 NTP servers along with authentication. This is the only way to eliminate time spoofing attacks from the outside. Don’t reduce your overall security to a stateless and unauthenticated (read: easy-to-spoof) network protocol!
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 a battery inside. They fully rely on NTP.
This is what this blogpost series is all about. Let’s dig into it. ;)
Continue reading Why should I run own NTP Servers?
Yet another routing protocol I played with in my lab. ;) This time: EIGRP, Enhanced Interior Gateway Routing Protocol, the
proprietary distance-vector routing protocol developed by Cisco, which is now public available (RFC 7868). However, no third-party products in here but only Cisco routers. I am using named EIGRP for both Internet Protocols, IPv6 and legacy IP, along with MD5 authentication and redistribution from OSPF.
Continue reading Dual-Stack EIGRP Lab
Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.
Continue reading OSPFv3 with IPsec Authentication
I already had an OSPFv2 for IPv4 lab on my blog. However, I missed capturing a pcap file in order to publish it. So, here it is. Feel free to have a look at another small lab with three Cisco routers and OSPFv2. Just another pcapng file to practise some protocol and Wireshark skills.
Continue reading OSPFv2 Capture
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
Continue reading Basic MP-BGP Lab: Cisco Router, Palo Alto, Fortinet
It is widely believed that public/private keys or certificates are “more secure” than passwords. E.g., an SSH login via key rather than using a password. Or a site-to-site VPN with certificate authentication rather than a pre-shared key (PSK). However, even certificates and private keys are not unlimited secure. They can be compromised, too, since the public-key cryptography only implies that private keys won’t be exposed if a brute-force attack is nearly impossible.
So, what’s the real security level of passwords compared to public keys/certificates?
Continue reading Passwords vs. Private Keys
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
TL;DR: While Fortinet is able to block encrypted files, Palo Alto fails since it does not identify encrypted office documents! [UPDATE: Palo Alto has fixed the main problem, see notes below.]
Continue reading File Blocking Shootout – Palo Alto vs. Fortinet
I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?
Continue reading Palo Alto policy-deny though Action allow
In my previous blogpost I talked about the true random number generator (TRNG) within the Raspberry Pi. Now I am using it for a small online pre-shared key (PSK) generator at https://random.weberlab.de (IPv6-only) that you can use e.g. for site-to-site VPNs. Here are some details how I am reading the binary random data and how I built this small website.
Continue reading True Random PSK Generator on a Raspi