If you are searching for a DNSSEC validating DNS server, you can use BIND to do that. In fact, with a current version of BIND, e.g. version 9.10, the dnssec-validation is enabled by default. If you are already using BIND as a recursive or forwarding/caching server, you’re almost done. If not, this is a very basic installation guide for BIND with DNSSEC validation enabled and some notes on how to test it.
This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server in order to run it as an authoritative DNS server. It differs from other tutorials because I am using three servers (one as a hidden primary and two secondaries as the public accessible ones), as well as some security such as denying recursive lookups and public zone transfers, as well as using TSIG for authenticating internal zone transfers. That is, this post is not an absolute beginner’s guide.
This blog post is about using NetFlow for sending network traffic statistics to an nProbe collector which forwards the flows to the network analyzer ntopng. It refers to my blog post about installing ntopng on a Linux machine. I am sending the NetFlow packets from a Palo Alto Networks firewall.
My current ntopng installation uses a dedicated monitoring ethernet port (mirror port) in order to “see” everything that happens in that net. This has the major disadvantage that it only gets packets from directly connected layer 2 networks and vlans. NetFlow on the other hand can be used to send traffic statistics from different locations to a NetFlow flow collector, in this case to the tool nProbe. This single flow collector can receive flows from different subnets and routers/firewalls and even VPN tunnel interfaces, etc. However, it turned out that the “real-time” functionalities of NetFlow are limited since it only refreshes flows every few seconds/bytes, but does not give a real-time look at the network. It should be used only for statistics but not for real-time troubleshooting.
This is a really cool and easy to use feature of the FortiGate firewall: the traffic shaper. Once an application category uses too much traffic, the bandwidth consumption can be decreased with it. Just about three clicks:
I really love ping! It is easy to use and directly reveals whether the network works or not. Refer to Why Ping is no Security Flaw! (But your Friend) and Advanced Tracerouting. At least outgoing pings (from trust to untrust) should be allowed without any security concerns. However, many companies are denying these ICMP echo-requests from untrust into the DMZ which makes it difficult to test whether all servers are up and running.
I was sitting at the customer’s site replacing the DMZ firewall. Of course I wanted to know (from the outside) whether all servers are connected correctly (NAT) and whether the firewall permits the connections (policy). However, ping was not allowed. Therefore I used several layer 7 ping tools that generate HTTP, DNS, or SMTP sessions (instead of ICMP echo-requests) and revealed whether the services (and not only the servers) were running. Great!
This post shows the installation and usage of httping, dnsping, and smtpping on a Linux machine, in my case a Ubuntu server 14.04.4 LTS, as well as some Wireshark screenshots from captured sessions. Finally, a pcap file can be downloaded that shows the sample runs of all three tools.
A common mistake when analyzing network speed/bandwidth between different applications and servers is to fully rely on the mere size of the files being transferred. In fact, one big file will transfer much faster than thousands of small files that have the same accumulated size. This depends on the overhead of reading/writing these files, building TCP/IP sessions, scanning them for viruses, etc. Furthermore, it is application dependent.
I built a small lab with an FTP server, switch, firewall, and an FTP client in which I played a bit with different file sizes. In this blog post I am showing the measured transfer times and some Wireshark graphs.
This is a step-by-step tutorial for configuring a high availability cluster (active-standby) with two FortiGate firewalls. Since almost all firewall vendors have different principles for their HA cluster, I am also showing a common network scenario for Fortinet.
Some time ago I published a post introducing ntopng as an out-of-the-box network monitoring tool. I am running it on a Knoppix live Linux notebook with two network cards. However, I have a few customers that wanted a persistent installation of ntopng in their environment. So this is a step-by-step tutorial on how to install ntopng on a Ubuntu server with at least two NICs.
Since a few weeks I am using Tufin SecureTrack in my lab. A product which analyzes firewall policies about their usage and their changes by administrators (and much more). Therefore, the first step is to connect the firewalls to SecureTrack in two directions: SSH from SecureTrack to the device to analyze the configuration, as well as Syslog from the device to SecureTrack to real-time monitor the policy usage.
This blog post shows the adding of the following firewalls into Tufin: Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, and Palo Alto PA.
A few weeks ago I constructed an MRTG/Routers2 template for the Fortinet FortiGate firewalls. I am using it for monitoring the FortiGate from my MRTG/Routers2 server. With the basic MRTG tool “cfgmaker” all graphs for the interfaces are generated automatically. My template is an add-on that appends graphs for CPU, memory, and disk usage, as well as connections and VPN statistics. Furthermore, it implements the ping statistics graph and a “short summary”, which only shows the system relevant graphs.
This blog post is a list of common troubleshooting commands I am using on the FortiGate CLI. It is not complete nor very detailled, but provides the basic commands for troubleshooting network related issues that are not resolvable via the GUI. I am not focused on too many memory, process, kernel, etc. details. These must only be used if there are really specific problems. I am more focused on the general troubleshooting stuff. I am using it personally as a cheat sheet / quick reference and will update it from time to time.
It’s really great that the FortiGate firewalls have a DHCPv6 server implemented. With this mandatory service, IPv6-only networks can be deployed directly behind a FortiGate because the stateless DHCPv6 server provides the DNS server addresses. (This is unlike Palo Alto or Cisco which have no DHCPv6 server implemented.)
However, the configuration on the FortiGate is really bad because nothing of the IPv6 features can be set via the GUI. (And this is called a Next-Generation Firewall? Not only the features count, but also the usability!) Everything must be done through the CLI which is sometimes hard to remember. Therefore I am publishing this memo of the appropriate CLI configuration commands.
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.
The Juniper ScreenOS firewall is one of the seldom firewalls that implements DHCPv6 Prefix Delegation (DHCPv6-PD). It therefore fits for testing my dual stack ISP connection from Deutsche Telekom, Germany. (Refer to this post for details about this dual stack procedure.)
It was *really* hard to get the correct configuration in place. I was not able to do this by myself at all. Also Google did not help that much. Finally, I opened a case by Juniper to help me finding the configuration error. After four weeks of the opened case, I was told which command was wrong. Now it’s working. ;) Here we go.
This guide is a little bit different to my other Policy Based Forwarding blog post because it uses different virtual routers for both ISP connections. This is quite common to have a distinct default route for both providers. So, in order to route certain traffic, e.g., http/https, to another ISP connection, policy based forwarding is used.