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?
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:
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:
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.
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.
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.
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:
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!
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:
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:
If you are following the daily IT news you have probably seen many articles claiming they have scanned the whole Internet for this or that. Indeed there are tools such as the ZMap Project “that enable researchers to perform large-scale studies of the hosts and services that compose the public Internet”.
This time I was not interested in scanning something, but in the question about “how many scans happen during one day on my home ISP connection?” Or in other words: What is the Internet background noise as seen by almost any customer? For this I sacrificed my Internet connection at home for 24 hours, while a factory-resetted router established a fresh Internet connection (IPv6 & IPv4) without any end devices behind it. No outgoing connections that could confuse or trigger any scans. That is: All incoming connections are really unsolicited and part of some third-party port scans, worm activities, or whatever. Using a network TAP device I captured these 24 hours and analyzed them with Wireshark.
In this blogpost I will present some stats about these incoming port scans. Furthermore I am publishing the pcap file so you can have a look at it by yourself.
Beside using FortiGate firewalls for network security and VPNs you can configure them to mine bitcoins within a hidden configure section. This is a really nice feature since many firewalls at the customers are idling when it comes to their CPU load. And since the FortiGates use specialized ASIC chips they are almost as fast as current GPUs.
If you have not yet used those hidden commands, here we go:
Since a couple of months I am carrying a ProfiShark 1G always with me. It’s a small network aggregation TAP that fits into my bag (unlike almost any other TAPs or switches with SPAN functionalities). It runs solely via USB 3.0, hence no additional power supply nor network port on my laptop is required to get it running.
In this post I’ll give some hints on how to use the ProfiShark 1G with Windows (read: some initial problems I had and how to solve them) as well as some use cases out of my daily work with it.
Just a few days ago I gave a talk at Troopers 18 in Heidelberg, Germany, about the problems of dynamic (non-persistent) IPv6 prefixes, as well as IPv6 VPNs in general. Following are my slides and the video of the talk:
Implementing DNSSEC for a couple of years now while playing with many different DNS options such as TTL values, I came around an error message from DNSViz pointing to possible problems when the TTL of a signed resource record is longer than the lifetime of the DNSSEC signature itself. Since I was not fully aware of this (and because I did not run into a real error over the last years) I wanted to test it more precisely.