Meinberg, with the great help of Mr Weber, has implemented “syslog over TLS” in the LTOS version 7.06. The following report describes the general advantages of “syslog over TLS” and the implementation of it in the LTOS.
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.
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.
Again and again, I am adding some protocol samples to the Ultimate PCAP. Just for reference. And because I can. ;D
I am participating in the NTP Pool Project with at least one NTP server at a time. Of course, I am monitoring the count of NTP clients that are accessing my servers with some RRDtool graphs. ;) I was totally surprised that I got quite high peaks for a couple of minutes whenever one of the servers was in the DNS while the overall rate did grow really slowly. I am still not quite sure why this is the case.
For one month I also logged all source IP addresses to gain some more details about its usage. Let’s have a look at some stats:
If you’re following my blog you probably know that I am using IPv6 everywhere. Everything in my lab is dual-stacked if not already IPv6-only. Great so far.
A few months ago my lab moved to another ISP which required to change all IP addresses (since I don’t have PI space yet). Oh boy! While it was almost no problem to change the legacy IPv4 addresses (only a few NATs), it was a huge pain in the … to change the complete infrastructure with its global unicast IPv6 addresses. It turned out that changing the interface IPv6 addresses was merely the first step, while many modifications at different services were the actual problem. And this was *only* my lab and not a complex company or the like.
Following you find a list of changes I made for IPv6 and for legacy IP. Just an overview to get an idea of differences and stumbling blocks.
Some time ago I published a pcap that can be used to study basic IPv6 protocol messages such as ICMPv6 for Router Advertisements, Neighbor Solicitations, etc.: “Basic IPv6 Messages: Wireshark Capture“. You can use it to learn the basic IPv6 address assignment and layer 2 address resolution. However, that pcap does not include any upper layer protocols.
This time I captured a few application layer protocols that I used over IPv6 rather than over legacy IP. Common user protocols such as DNS, HTTP/S, IMAP, SMTP (with STARTTLS), as well as some network administration protocols: SSH, SNMP, and Ping. It is not that interesting at all ;) though you can use it to have some examples for Wireshark to prove that those application protocols are almost the same when run above IPv6 compared to IPv4.
Following is a list of the most common Cisco device configuration commands that I am using when setting up a router or switch from scratch, such as hostname, username, logging, vty access, ntp, snmp, syslog. For a router I am also listing some basic layer 3 interface commands, while for a switch I am listing STP and VTP examples as well as the interface settings for access and trunk ports.
This is not a detailed best practice list which can be used completely without thinking about it, but a list with the most common configurations from which to pick out the once required for the current scenario. Kind of a template. Of course with IPv6 and legacy IP.
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. ;)
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 46 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP. On some switches the SDM template must be changed to be IPv6 capable such as sdm prefer dual-ipv4-and-ipv6 default .
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.
While parsing logfiles on a Linux machine, several commands are useful in order to get the appropriate results, e.g., searching for concrete events in firewall logs.
In this post, I list a few standard parsing commands such as grep, sort, uniq, or wc. Furthermore, I present a few examples of these small tools. However, it’s all about try and error when building large command pipes. ;)
In a basic environment with a Cisco ASA firewall I am logging everything to a syslog-ng server. As there aren’t any reporting tools installed, I am using grep to filter the huge amount of syslog messages in order to get the information I want to know. In this blog post I list a few greps for getting the interesting data.
I am using such an installation for my firewalls, routers, etc., to have an archive with all of its messages. Later on, I can grep through these logfiles and search for specific events. Of course it does not provide any built-in filter or correlation features – it is obviously not a SIEM. However, as a first step it’s better than nothing. ;)
A few weeks ago I published an article in which I proposed a method on how to capture the MAC- to IPv6-address bindings via sniffing and storing IPv6 DAD messages. Though any IPv6 node MUST send these Duplicate Address Detection messages prior to assign the address, I was not fully assured that *really* each new IPv6 address is stored with this Tcpdump sniffer.
That is, over a whole month I captured the DAD messages on a test BYOD-LAN and furthermore the complete IPv6 connection logs of the corresponding firewall. At best, I should have any IPv6 address that made an outbound connection through the firewall in the DAD logfiles. Here are the results: