Zum wiederholten Mal habe ich es getan: Ich war zwei Wochen mit der Familie im Urlaub – und zwar ohne Smartphone, ohne Tablet, ohne Notebook, ohne Fernseher. Offline! So ganz. 14 Tage lang. Und das war auch gut so. Urlaub eben.
Also zumindest so, wie ich es wirklich als Urlaub wahrnehme. Und meiner Meinung nach auch die einzige Möglichkeit, in unserer heutigen Zeit wenigstens einmal im Jahr ganz abzuschalten.
TL;DR: Smartphone zu Hause lassen -> Urlaub wieder zur Zeit des Ausruhens machen!
Continue reading Urlaub ohne Internet & Smartphone – ein Traum!
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
There are two methods of site-to-site VPN tunnels: route-based and policy-based. While some of you may already be familiar with this, some may have never heard of it. Some firewalls only implement one of these types, so you probably don’t have a chance to configure the other one anyway. Too bad since route-based VPNs have many advantages over policy-based ones which I will highlight here.
I had many situations in which network admins did not know the differences between those two methods and simply configured “some kind of” VPN tunnel regardless of any methodology. In this blogpost I am explaining the structural differences between them along with screenshots of common firewalls. I am explaining all advantages of route-based VPNs and listing a table comparing some firewalls regarding their VPN features.
Continue reading Route- vs. Policy-Based VPN Tunnels
In some situations you want to manage your firewall only from a dedicated management network and not through any of the data interfaces. For example, when you’re running an internal data center with no Internet access at all but your firewalls must still be able to get updates from the Internet. In those situations you need a real out-of-band (OoB) management interface from which all management traffic (DNS, NTP, Syslog, Updates, RADIUS, …) is sourced and to which the admins can connect to via SSH/HTTPS. Another example is a distinct separation of data and management traffic. For example, some customers want any kind of management traffic to traverse through some other routing/firewall devices than their production traffic.
Unfortunately the Fortinet FortiGate firewalls don’t have a reasonable management port. Their so-called “MGMT” port is only able to limit the access of incoming traffic but is not able to source outgoing traffic by default. Furthermore, in an HA environment you need multiple ports to access the firewalls independently. What a mess.
A functional workaround is to add another VDOM solely for management. From this VDOM, all management traffic is sourced. To have access to all firewalls in a high availability environment, a second (!) interface within this management VDOM is necessary. Here we go:
Continue reading FortiGate Out-of-Band Management
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
Just a quick note concerning the session sync on a Palo Alto Networks firewall cluster: Don’t trust the green HA2 bubble on the HA widget since it is always “Up” as long as the HA interface is up. It does NOT indicate whether the session sync is working or not. You MUST verify the session count on the passive unit to be sure. Here are some details:
Continue reading Notes regarding Palo Alto HA2 Session Sync
I am using an almost hidden FTP server in my DMZ behind a Palo Alto Networks firewall. FTP is only allowed from a few static IP addresses, hence no brute-force attacks on my server. Furthermore, I have an “allow ping and traceroute from any to DMZ” policy since ping is no security flaw but really helpful while troubleshooting.
Now, here comes the point: My FTP server logfile showed dozens of connections from many different IP addresses from the Internet. WHAT? For the first moment I was really shocked. Have I accidentally exposed my FTP server to the Internet? Here is what happened:
Continue reading Palo Alto Application: First Packets Will Pass!
I already published a few examples how you can use layer four traceroutes in order to pass firewall policies that block ping but allow some well-known ports such as 80 or 443. Long story short: Using TCP SYN packets on an opened firewall port with the TTL trick will probably succeed compared to a classical traceroute based on ICMP echo-requests.
Another nice use case for layer 4 traceroutes is the recognition of policy based routes within your own network (or even beyond). That is: Depending on the TCP/UDP port used for the traceroute you can reveal which paths your packets take over the network. This is quite useful compared to classical traceroutes that only reveal the straightforward routing tables but not the policy based ones.
Continue reading Discovering Policy-Based Routes with Layer 4 Traceroutes (LFT)
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
Unpredictable random numbers are mandatory for cryptographic operations in many cases (ref). There are cryptographically secure pseudorandom number generators (CSPRNG) but the usage of a hardware random number generator (TRNG) is something I am especially interested in since many years. While there are many proprietary TRNGs (list) with different prices, I had a look at two cheap solutions: the Raspberry Pi’s hardware random number generator as well as an application that uses a DVB-T/RTL/SDR stick for gathering some noise.
I have tested both of them with various options and ran them against the dieharder test suite. In this post I am listing the CLI commands to get the random data from those source and I am listing the results of the tests.
Continue reading Playing with Randomness
Let me post some words about financial issues concerning this blog. Well, it’s kind of annoying. I am writing blogposts for fun in my free time because I want to document my work in a proper way and I want to “give something back” to the community. It is not my primary goal to earn money with this blog at all.
However, I have some costs for the hosting as well as for the equipment within my laboratory. For this purpose I placed ads by Google AdSense inside my articles. 2-3 banners; depending on the size of the blogposts. Unfortunately this brings only about 70 cents per day. ;( This is really not that much and does not suffice for the costs. What’s the problem? All of us (including me *g*) have adblockers installed. I know I know. Furthermore, no employee will donate to my blog, since companies simply don’t have a need to donate. And why should an admin donate from his private pocket?
Hence I have one request for you:
If you’re reading my blog regularly, please be fair and turn off your adblocker. Or even better: donate a couple of Euros. ;) I would really appreciate it. Thanks a lot! Thomann wishlist
(guitars, synths, effects, cables).
Or if you would like to send me a special present not related to IT stuff, here is my
Continue reading Blog Financing
Today my blog celebrates its 5th birthday as I published my Master Thesis about IPv6 Security on the 6th of May, 2013. Wow. When I started back then I did not expect that I will blog almost once a week for that many years and that the blog gets that many readers. ;)
With this blogpost I’ll give you some insights about the stats of the blog and some plans for the future. Furthermore I am highly interested in comments from you. What do you think about the blog in general? What is good, what could I improve? Where do you agree or disagree. Please write some comments to give me some feedback. Thanks a lot!
Continue reading The first 5 Years of Blog.Webernetz.net
Last but not least I was interested which “home-calling” connections my Yamaha R-N500 Network Receiver initiates. In my previous post I already analyzed the open ports within the network, while I showed a complete Apple AirPlay capture here. This time I was only interested in outgoing TCP/UDP connections to the Internet as well as how the Yamaha App “NP Controller” communicates with the receiver.
It turned out that it was not easy for me to fully analyze such a packet trace even though only a couple of connections were made. It consists of many protocols that I am not familiar with such as UPnP, MDNS, SSDP, and RTP. Anyway, ere we go:
Continue reading Yamaha R-N500 Network Receiver Packet Capture
During my analysis of Apple AirPlay connections to my Yamaha Network Receiver I was also interested in which TCP/UDP ports are opened on this audio device at all. Hence I did a basic port scan with Nmap for both transport layer protocols. (In an upcoming blogpost I am analyzing a packet capture from the Yamaha receiver which will show more details about the used ports and outgoing connections.) At first here are the Nmap results:
Continue reading Yamaha R-N500 Network Receiver Port Scan