Weberblog.nethttps://weberblog.net
IT-Security, Networks, IPv6, DNSSEC, NTP, Monitoring, DIYSat, 23 May 2020 10:11:20 +0000en-US
hourly
1 https://wordpress.org/?v=5.4.1https://weberblog.net/wp-content/uploads/2018/05/cropped-webernetz-logo-4-icon-2000x2000-1-32x32.pngWeberblog.nethttps://weberblog.net
3232Slowing down my Blogging Ratehttps://weberblog.net/slowing-down-my-blogging-rate/?utm_source=rss&utm_medium=rss&utm_campaign=slowing-down-my-blogging-rate
https://weberblog.net/slowing-down-my-blogging-rate/#commentsFri, 22 May 2020 20:29:13 +0000https://weberblog.net/?p=10316A few days ago, my blog turned seven (7). Wow! And this post right here is number 329. This is roughly one post per week over the last seven years. Not bad. ;D I can’t believe I was able to publish that much at this rate for so long. However, I have decided to slow … Continue reading Slowing down my Blogging Rate→]]>

A few days ago, my blog turned seven (7). Wow! And this post right here is number 329. This is roughly one post per week over the last seven years. Not bad. ;D I can’t believe I was able to publish that much at this rate for so long. However, I have decided to slow down my publishing rate for some reason. Following are some insights:

Previous Motivation

Right from the beginning, I wanted to share knowledge in order to give something back to the community. That is: Not only consuming information from the Internet but feeding it with information as well. Since I was working with some interesting firewall vendors such as Palo Alto Networks or Fortinet as well as (new) technologies such as IPv6 or DNSSEC, I had many things to write about that were not that commonly present on other blogs. Since back then my list of post ideas increased constantly. And while I spent a couple of nights per month at some hotels (due to my job), I also had some time left to write those posts.

My 2nd motivation was to document everything for myself. Kind of “the project is only finished when the blog post is published”. Indeed, doing it that way I learned a lot of details for every technology I am working with (because I don’t want to share smattering), while I have quite a good wiki for myself. It happens really often that I am using the search field in my own blog to find something I was doing a couple of years ago. ;)

Anyway: I really want to thank you for visiting my blog. I am proud to deliver some kind of information to various technical persons. Thanks to Google, by the way. ;)

Life Changes

However, life changes. In the meantime, our family has grown – now we got 3 kids – and we have moved into our own house. Yeah. And as everyone owning a house knows, you’re never finished. ;D I have also changed my job to be at home every evening to have more time with my family. Good decision!

Now, talking about my blog, after all those years of using my spare time documenting something for the Internet, I got some reputation (which is nice), but no income at all. This was not a problem for the first years. But since I don’t have spare time left anymore, it’s kind of hard to prioritize something that costs you a couple of hours a week. Getting a positive comment every now and then won’t keep you motivated for decades.

I have tried to monetize my blog in a couple of ways – but none of them worked at all. Ads via Google AdSense was easy to use but did not pay off. About 90 % of my readers have adblockers. Disabling the adblockers for my blog voluntarily doesn’t work. Furthermore, I don’t want to overcrowd my blog with ads. It will only annoy those people without adblockers. I don’t want to hide my blog behind a paywall as well.

I also tried a donate button for some years. But, do you know what? Within two years only one single person has donated. Only one. In 2 years. To be honest, this is kind of disappointing. I have a couple of hundred readers a day, but everyone only wants to get good information for free. Well, that’s how the Internet works. I have to deal with it. (Maybe because my articles are not of interest to private persons, but only for employees. And why should an employee donate from his private pocket for something in regard to his job? Hence I can understand it.)

Finally, I tried to find some sponsors. Long story short: Nobody was interested in sponsoring my blog. That is, no company related to network firewalls. Okay, they have their marketing budgets and my blog isn’t big enough to justify such an effort. (By the way: I am receiving some weird guest blog post inquiry mails every other day. But this is not the way I want to sell my blog.)

What Happens Next?

So, I won’t shut down my blog, but I will decrease the blogging rate from one post per week to about one post per month. I still have lots of ideas and I still like to hit the publish button. ;)

This way, I will keep my blog alive. Maybe I will get even more new readers since they won’t be flooded that much anymore. ;)

What do you think about it? General ideas? Know issues? ;) Please write a comment below and share your opinions. I am highly interested in them. Appreciate it.

Other Hobbies

In case you are interested, I’m making music at our church (find me at the electric guitar):

]]>https://weberblog.net/slowing-down-my-blogging-rate/feed/2UK IPv6 Council Spring 2020: Incorrect Working IPv6 Clients & Networkshttps://weberblog.net/uk-ipv6-council-spring-2020-incorrect-working-ipv6-clients-networks/?utm_source=rss&utm_medium=rss&utm_campaign=uk-ipv6-council-spring-2020-incorrect-working-ipv6-clients-networks
https://weberblog.net/uk-ipv6-council-spring-2020-incorrect-working-ipv6-clients-networks/#respondWed, 29 Apr 2020 10:44:41 +0000https://weberblog.net/?p=10287I did a short presentation at the spring 2020 roundtable of the UK IPv6 Council. The talk was about a case study I did with my NTP server listed in the NTP Pool project: For 66 days I captured all NTP requests for IPv6 and legacy IP while analyzing the returning ICMPv6/ICMPv4 error messages. (A … Continue reading UK IPv6 Council Spring 2020: Incorrect Working IPv6 Clients & Networks→]]>

I did a short presentation at the spring 2020 roundtable of the UK IPv6 Council. The talk was about a case study I did with my NTP server listed in the NTP Pool project: For 66 days I captured all NTP requests for IPv6 and legacy IP while analyzing the returning ICMPv6/ICMPv4 error messages. (A much longer period than my initial capture for 24 hours.) Following are my presentation slides along with the results.

At first, here are the slides (PDF):

If you’re only interested in the mere results, here is a short summary:

note: only 1 out of 5 DNS names from *.pool.ntp.org is handing out AAAA records

but there are roughly 2x more IPv4 servers in the pool

Number of NTP PacketsDistribution of ICMP ErrorsDistribution NTP Clients

PS: A more detailed version of this presentation was initially planned for TROOPERS 20, which was canceled for obvious reasons. ;( Maybe I am re-running this study again (for a longer period?) and will submit this talk for #TR21. It would have more details about the capturing process, the tools used for analyzing the messages (tshark among others), and further strange investigations.

I gave a session about IPv6 at SharkFest’19 EUROPE, the annual Wireshark developer and user community conference, named “IPv6 Crash Course: Understanding IPv6 as seen on the wire“. The talk is about the IPv6 basics, which are: IPv6 addresses & address assignment, link-layer address resolution, and ICMPv6. Tips for using Wireshark coloring rules and display filters round things up.

As I have not yet published the slides, here they are. Unfortunately, we were not able to record the session due to technical problems. Neither the video nor the audio. ;( Hence, here are only mere slides.

(Yes, I know that Sharkfest’19 was about 5 months ago. ;) Sorry. Time flies by…)

]]>https://weberblog.net/sharkfest19-europe-ipv6-crash-course/feed/0Types of VPNhttps://weberblog.net/types-of-vpn/?utm_source=rss&utm_medium=rss&utm_campaign=types-of-vpn
https://weberblog.net/types-of-vpn/#commentsThu, 02 Apr 2020 11:01:43 +0000https://weberblog.net/?p=10201Another small post out of my “At a Glance” series: The different types of virtual private networks (VPNs). Looking at Site-to-Site and Remote Access VPNs. This sketch shows the common IPsec and TLS based VPNs that are used on modern next-generation firewalls. Tunnel mode only – no transport mode. It does not depict MPLS, L2TP, … Continue reading Types of VPN→]]>

Another small post out of my “At a Glance” series: The different types of virtual private networks (VPNs). Looking at Site-to-Site and Remote Access VPNs.

This sketch shows the common IPsec and TLS based VPNs that are used on modern next-generation firewalls. Tunnel mode only – no transport mode. It does not depict MPLS, L2TP, GRE, and SSH. While those protocols do tunneling with or without encryption, the term “VPN” is normally used for the following types:

]]>https://weberblog.net/types-of-vpn/feed/1More Capture Detailshttps://weberblog.net/more-capture-details/?utm_source=rss&utm_medium=rss&utm_campaign=more-capture-details
https://weberblog.net/more-capture-details/#respondWed, 11 Mar 2020 06:52:21 +0000https://blog.webernetz.net/?p=9951In the previous post, I released my Ultimate PCAP which includes every single pcap I had so far on my blog. But that’s not all: I have some packets in there that were not yet published up to now. That is, here are some more details about those (probably well-known) protocols. These are: DNS Dynamic … Continue reading More Capture Details→]]>

In the previous post, I released my Ultimate PCAP which includes every single pcap I had so far on my blog. But that’s not all: I have some packets in there that were not yet published up to now. That is, here are some more details about those (probably well-known) protocols. These are:

DNS Dynamic Update

(Not to be confused with DynDNS for your home router.) I updated three RRs (A, AAAA, PTR) to my authoritative DNS server. While my server is authoritative and within the global DNS tree for “ib-unsigned.weberdns.de”, it’s quite obviously not in the DNS tree for the IPv4 address block reserved for documentation (RFC 5737), 198.51.100.0/24. Hence I had to set the server manually.

IPv6 Router Advertisement (RA) with RDNSS and DNSSL

Router advertisements with the recursive DNS server option and the DNS search list option (of course, along with the default prefix information). Also, note the delta time (red marked box, a custom column in Wireshark) as it varies randomly between 19-60 seconds since I manually configured those min and max values. (Due to RFC 4861, the min should be 0.33*max.)

Wireshark RA with RDNSS and DNSSL

DHCPv6 Prefix Delegation

Router to router conversation via DHCPv6-PD in which the downstream router asks for a prefix. In my case, it gets a /56 one:

Wireshark DHCPv6 Prefix Delegation

Telnet

Uh, wait, what? Yes, it’s Telnet. For the sake of completeness. Not because I’m using it, but because it’s still alive. Follow TCP Stream and you can see everything, including the login password. Ouch. Welcome to 2020. ;)

Wireshark Telnet Packet ListWireshark Telnet Follow TCP Stream

Generic Routing Encapsulation (GRE)

A tunneling protocol that is known from Cisco but used by other vendors as well such as Palo Alto Networks NGFW. In its basic usage, it is tunneling IP in IP. It is a layer 4 protocol with protocol number 47. (Not to be confused with TCP/UDP port numbers.) In my capture, I am using legacy IP tunnel endpoints while IPv6 and IPv4 were tunneled. You’ll find pings, traceroute and an SSH connection. Note that Wireshark displays the tunneled source/destination IP addresses (which is great!):

Wireshark GRE Tunnel

If configured, keepalives are sent from both sides. “When you enable keepalives on the tunnel endpoint of Router A, the router at every interval constructs the inner IP header. At the end of the header, the router also appends a GRE header with a Protocol Type (PT) of 0, and no other payload”, How GRE Keepalives Work:

Wireshark GRE Keepalive

NetFlow

Reporting metadata of IP flows to a flow collector. In my case, a Palo Alto Networks firewall sends NetFlow version 9 packets. Some data-templates are also found in the trace.

]]>https://weberblog.net/more-capture-details/feed/0The Ultimate PCAPhttps://weberblog.net/the-ultimate-pcap/?utm_source=rss&utm_medium=rss&utm_campaign=the-ultimate-pcap
https://weberblog.net/the-ultimate-pcap/#commentsTue, 25 Feb 2020 07:20:06 +0000https://blog.webernetz.net/?p=9942For the last couple of years, I captured many different network and upper-layer protocols and published the pcaps along with some information and Wireshark screenshot on this blog. However, it sometimes takes me some time to find the correct pcap when I am searching for a concrete protocol example. There are way too many pcaps … Continue reading The Ultimate PCAP→]]>

I’m publishing a single pcap meant to be a single point of source for Wireshark samples. It is summarizing *all* previous ones from my blog and even adding some more protocols and details. I will constantly add more packets to this pcap if I have some. Currently, it has > 50 different protocols and hundreds of variants, such as IPv6 and legacy IP traffic, different DNS query types, ICMP error codes, and so on.

Download the Ultimate PCAP

Download it, 7zipped, 4 MB:

Side note: Since the packets are captured over many years (at least 2014-2020), your “time” and “delta time” columns will display odd values. ;) Side note 2: As I will add more packets to the pcap, the frame numbers will change in the future.

]]>https://weberblog.net/the-ultimate-pcap/feed/19Who is WHOIS?https://weberblog.net/who-is-whois/?utm_source=rss&utm_medium=rss&utm_campaign=who-is-whois
https://weberblog.net/who-is-whois/#respondThu, 13 Feb 2020 15:02:29 +0000https://blog.webernetz.net/?p=9551I am using the WHOIS client a lot these days since I am migrating some RIPE objects such as ASes, inetnum/inet6num, etc. Meanwhile, I recognized that I have never captured this TCP port 43 protocol, nor looked at it with Wireshark. That’s what this post is all about, incl. a downloadable pcap for your own … Continue reading Who is WHOIS?→]]>

I am using the WHOIS client a lot these days since I am migrating some RIPE objects such as ASes, inetnum/inet6num, etc. Meanwhile, I recognized that I have never captured this TCP port 43 protocol, nor looked at it with Wireshark. That’s what this post is all about, incl. a downloadable pcap for your own analysis.

For this trace, I basically queried a couple of different names which resulted in a couple of different WHOIS queries to *some* destinations. To be honest, I don’t know exactly which destinations are chosen, but this seems to be correct. ;) Citing the manpage of whois: “the whois client tries to guess the right server to ask for the specified object”. If you are interested in more details of the tool itself, please have a look at:

Basically, WHOIS is a telnet-like TCP protocol running at port 43. Single query – single response. It is not encrypted at all but in plain text. Since all queried information is public anyway, that’s not a big deal. (However, a passive attacker can record which queries you’re sending.)

Download the pcap, 7zipped, 21 KB. I left all those surrounding DNS and ICMP packets in there intentionally:

Wireshark screenshots:

Demo Requests

These are the queries you’ll find in the trace. Besides querying the keywords that the server supports, I asked for some domains of different TLDs (which failed for *.blog), IPv4 and IPv6 networks, an ASN, a RIPE handle (which worked with the -a option) and a full name (which is quite common in German and hence lists many different persons):

Real World Use Case: traceroute -A

One major, but probably unknown, use case of WHOIS is the traceroute tool when performed with the -A option to perform AS path lookups in routing registries. It then does not only issue IP packets with increased hop limits (and printing the ICMP hop limit exceeded error messages) but also sends WHOIS queries along with DNS PTR requests.

]]>https://weberblog.net/who-is-whois/feed/0VoIP Captureshttps://weberblog.net/voip-captures/?utm_source=rss&utm_medium=rss&utm_campaign=voip-captures
https://weberblog.net/voip-captures/#respondTue, 28 Jan 2020 12:37:05 +0000https://blog.webernetz.net/?p=10092VoIP calls, using the network protocols SIP/SDP and RTP, are the de-facto standard when it comes to voice calls. Wireshark offers some special features to analyze those calls and RTP streams – even with a nice “Play Streams” option, which discretely decodes your calls. Ouch. Again and again, frightening which privacy-related protocols are completely unencrypted … Continue reading VoIP Captures→]]>

VoIP calls, using the network protocols SIP/SDP and RTP, are the de-facto standard when it comes to voice calls. Wireshark offers some special features to analyze those calls and RTP streams – even with a nice “Play Streams” option, which discretely decodes your calls. Ouch. Again and again, frightening which privacy-related protocols are completely unencrypted on the Internet!

Here are some hints for Wireshark as well as a downloadable pcap with three calls in there. ;) Have fun!

I won’t explain any SIP/SDP/RTP details here. There is much information out there already. I basically want to share a pcap to play with, along with some Wireshark screenshots.

Download the pcap, 7zipped, 473 KB:

Open it with Wireshark and go to Telephony -> VoIP Calls to get this overview:

You can either have a look at the Flow Sequence:

Or you hit the “Play Streams” button to actually listen to the calls in the RTP Player. Wuh:

I have three VoIP calls in the pcap. Two g711A streams and one HD stream with g722.

Challenge: Who called me? ;D Answer in the comment section!

Another way to have a look at the RTP details is to open Telephony -> RTP -> RTP Streams, click the stream of interest, followed by “Find Reverse” and then Analyze:

This gives you details about the jitter, losses, etc.:

Of course, the great Wireshark dissectors work for all protocol details as well, e.g., the SIP packet details:

]]>https://weberblog.net/voip-captures/feed/0DNS Capture – The Records Editionhttps://weberblog.net/dns-capture-the-records-edition/?utm_source=rss&utm_medium=rss&utm_campaign=dns-capture-the-records-edition
https://weberblog.net/dns-capture-the-records-edition/#respondMon, 13 Jan 2020 13:29:25 +0000https://blog.webernetz.net/?p=9754Some time ago I published a post called DNS Test Names & Resource Records which lists many different FQDNs with lots of different RRs. You can use those public available DNS names to test your DNS servers or the like. However, I was missing a packet capture showing all these resource records as they appear … Continue reading DNS Capture – The Records Edition→]]>

Some time ago I published a post called DNS Test Names & Resource Records which lists many different FQDNs with lots of different RRs. You can use those public available DNS names to test your DNS servers or the like. However, I was missing a packet capture showing all these resource records as they appear on the wire. So now, here it is. If you are searching for some packets to test your tools for whatever reason, feel free to download this pcap.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

Some Notes

I was basically looking up every single hostname that I listed in this blogpost.

I was using “host” to query A and AAAA records simultaneously and “dig” for more specific RRs. (Yes, I could do everything with each of them. But now I have some variance in the trace as well.)

However, I ran into some issues with “host”. For example,

host 64aaaa.weberdns.de 2620:fe::fe

was not working; error message “;; connection timed out; no servers could be reached”. Probably due to my intermediate firewall (Palo Alto Networks) or the used IPv6 Tunnel Broker?!? (I have looked up the counters on Palo Alto, but no drops. So probably due to the 6in4 tunnel broker?) Wireshark shows some “malformed DNS” packets. With dig, it was working

dig 64aaaa.weberdns.de @2620:fe::fe aaaa

. Anyway, I let those falsified connections in the trace as well. That’s life. ;)

Since I am generally more interested in IPv6 rather than legacy IP, I issued all queries via IPv6 and IPv4. This should give a wide range of different DNS packets in the trace file.

I was using the recursive DNS servers from Quad9, for IPv6 (2620:fe::fe) as well as for legacy IP (9.9.9.9).

For some reason, I had problems querying Quad9 for “RRSIG” resource records.

dig @2620:fe::fe many-rrs.weberdns.de rrsig

let to SERVFAIL responses in some situations, while others worked. Don’t know why as well.

I did not specify whether UDP or TCP shall be used. I simply let the tools decide.

I end up with 71 queries for each Internet Protocol, that is, 142 queries in total. ;) And since “host” queries A/AAAA/MX records for each FQDN, there are even more queries in the final trace.

]]>https://weberblog.net/dns-capture-the-records-edition/feed/0Dive into delv: DNSSEC Validationhttps://weberblog.net/dive-into-delv-dnssec-validation/?utm_source=rss&utm_medium=rss&utm_campaign=dive-into-delv-dnssec-validation
https://weberblog.net/dive-into-delv-dnssec-validation/#respondThu, 19 Dec 2019 21:34:38 +0000https://blog.webernetz.net/?p=9757If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv. Citing the manpage again: Without any options, delv outputs the A record and the corresponding RRSIG (if present), … Continue reading Dive into delv: DNSSEC Validation→]]>

If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv.

delv will send to a specified name server all queries needed to fetch and validate the requested data; this includes the original requested query, subsequent queries to follow CNAME or DNAME chains, and queries for DNSKEY, DS and DLV records to establish a chain of trust for DNSSEC validation. It does not perform iterative resolution, but simulates the behavior of a name server configured for DNSSEC validating and forwarding.

Citing the manpage again:

By default, responses are validated using built-in DNSSEC trust anchor for the root zone (“.”). Records returned by delv are either fully validated or were not signed. If validation fails, an explanation of the failure is included in the output; the validation process can be traced in detail. Because delv does not rely on an external server to carry out validation, it can be used to check the validity of DNS responses in environments where local name servers may not be trustworthy.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

Without any options, delv outputs the A record and the corresponding RRSIG (if present), while it fully validates the DNSSEC signature. A simple call looks like this, while for IPv6 addresses you have to specify the type with AAAA. Note the “fully validated” line since the following hostnames are DNSSEC signed:

Uh. What has happened? My recursive DNS server *does* DNSSEC validation as well, hence delve is unable to query it for falsified records. Unluckily, you can’t set the cd bit (checking disabled) for delv requests. (Why?!? This would be that useful for troubleshooting!)

Hence we must use a non-validating recursive DNS server to test with, like the second one from Quad9: 2620:fe::10 respectively 9.9.9.10.

Depending on the failure, delv gives you appropriate notes, such as “insecurity proof failed”:

]]>https://weberblog.net/dive-into-delv-dnssec-validation/feed/0PoE-powered NTP Displayhttps://weberblog.net/poe-powered-ntp-display/?utm_source=rss&utm_medium=rss&utm_campaign=poe-powered-ntp-display
https://weberblog.net/poe-powered-ntp-display/#commentsThu, 12 Dec 2019 14:47:26 +0000https://blog.webernetz.net/?p=9724As you might have noticed, I am playing a lot with NTP these days. Having a networking background I also like Power over Ethernet. So what’s more obvious than using a PoE-powered NTP display for test purposes? ;D Let’s have a look at the Meinberg OnTime LED NTP Display. It’s a quite big 7-segment LED … Continue reading PoE-powered NTP Display→]]>

As you might have noticed, I am playing a lot with NTP these days. Having a networking background I also like Power over Ethernet. So what’s more obvious than using a PoE-powered NTP display for test purposes? ;D

This article is one of many blogposts within this NTP series. Please have a look!

Let’s have a look at the Meinberg OnTime LED NTP Display. It’s a quite big 7-segment LED display that has only one single interface: the Ethernet port. Nice. Plugging it into a PoE switch it boots up, gets an IPv4 address via DHCP and leverages SNTP to a predefined NTP server (by DNS name) to get the time. Every 60 minutes it refreshes its time from that server again. Quite simple.

I am using this NTP display in two of my recurring network and security training:

NTP/NTP-Security: When I want to show how easy an attacker can spoof NTP packets by a MITM attack. Or that this IoT device will accept any time, no matter how far it drifts from the actual time since it has no built-in real-time clock to compare with.

Configuration

Though the display works out of the box, you may want to configure a couple of things. Two configuration methods are possible: Either via Telnet (uh, yes, Telnet; no SSH available) by using a classical CLI, or via custom DHCP options. While you can do some more stuff with Telnet, the DHCP based approach perfectly fits when you have a couple of those NTP clocks and want to provide basic settings such as the NTP server to use, the timezone, daylight saving time, or 24-hour mode.

The CLI offers some more options. It is quite simple as well. Only a couple of commands such as help, sntp (to set the NTP server), ipconfig (to set the IPv4 address), stats, dhcpconfig (to see the overrides by DHCP options), or config (to see the complete configuration). Following is the “config” output, which gives a glance about all options:

Sample Run

Disabling Telnet

Oh yeah, at least there is a “disabletelnet” command. This greatly improves security. Without any confirmation the command immediately worked:

iclock-32e />disabletelnet
Telnet has been disabled.
The clock will reboot in ten seconds.

After some tests that telnet is indeed disabled, I wanted to enable it again. But how? Nothing in the documentation. Finally, I found how to reenable it on the Novanex support site, stating: “Return the clock to Inova Solutions where we can perform a factory reset for you for a support charge, or contact technical support.” Hence I opened a support ticket and here is how you can factory reset the device:

To perform the factory reset of a v2 clock, open the case with four screws, then power-up the clock by inserting the PoE cable, and when the clock has finished booting, press the reset button on the circuit board and hold it for about 15 seconds until the clock reboots. This should be done with static protection in mind as the circuit board components can be damaged by static discharge.

To my mind, this is a good solution to keep the clock tamper-proof, since it will probably reside in a public location. No single button/switch at the clock at all, while no single IP connection to it, as well.

Wireshark

As already pointed out, I am using this clock for demo purposes during my network and/or NTP talks. You don’t have that many disturbing packets on it, but only a very straightforward run of DHCP, DNS, and NTP. (And probably some STP and LLDP packets from the switch itself.) That’s why it’s easy for beginners to have a look at live packet captures.

This is what the bootup looks like: (Though there is a small error in waiting only 1 second for DNS to reply, while any packets after that second are “port unreachables”.)

After that, every hour a single NTP request is sent (default setting). That’s it.

Portscan with Nmap

After I disabled Telnet I did a basic Nmap scan to check if there are some (hidden) opened ports. No single one was found. Good. Details:

]]>https://weberblog.net/poe-powered-ntp-display/feed/1Setting up NTS-Secured NTP with NTPsechttps://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/?utm_source=rss&utm_medium=rss&utm_campaign=setting-up-nts-secured-ntp-with-ntpsec
https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/#commentsThu, 05 Dec 2019 14:13:11 +0000https://blog.webernetz.net/?p=9671This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany. In the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already … Continue reading Setting up NTS-Secured NTP with NTPsec→]]>

In the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already some independent NTS implementations and public time servers (IETF106). NTPsec is one of the important representatives of this series and already offers an advanced NTS solution. In this post, I’ll give you a short guide to setting up an NTS-secured NTP client/server with NTPsec.

Overview

NTPsec is a fork of the NTP reference implementation NTPD that has removed inherited burdens to provide a smaller codebase. In addition, the relevance of NTPsec in the Linux environment is increasing and it is one of the first NTS-capable NTP implementations.

Due to the missing Windows support, this guide is only intended for Linux systems. Therefore I’m using a Raspberry Pi 3B with the recent Debian-based operating system Raspbian. The procedure described here also works with other Linux distributions in the same or similar form.

Software Components Used

In order to use NTS, we need the following software components. You can find detailed instructions for installation and setup below:

Important: All NTS implementations that use OpenSSL with TLS 1.3 support require OpenSSL 1.1.1b or higher. OpenSSL 1.1.1a contained a bug which caused the TLS key export to fail during the NTS Key Establishment (NTS-KE) phase.

NTS Properties of NTPsec

Currently (Q4/2019), NTPsec has implemented the NTS draft 17. The following adjustments of the specification up to the latest draft version 20 do not contain any significant changes so that NTPsec is representative. The following NTS features are included in the implementation:

*The server only discards invalid request packets and does not send an NTSN (NTS NAK) back to the client. This is okay, but a client then doesn’t know whether a request has been lost or if an error occurred during verification.

Preparation

Okay, now we can finally get started. First, we log into our Raspberry Pi (RPi) and make sure that we have an Internet connection. This device can be accessed directly with a connected screen and keyboard or headless via SSH. Then we update the system and the installed packages:

# update system
sudo apt update
sudo apt upgrade

Next, we check the OpenSSL version, which must be 1.1.1b or higher:

# check openssl version
openssl version

To ensure the correct functioning of NTPsec, we should also disable the local time synchronization service. This also applies to other services (such as OpenNTPD, Chrony, …).

If an NTP service (e.g. NTPD) is used instead, we can remove it as follows:

# remove NTP
sudo apt remove --auto-remove ntp

This is necessary since NTPD and NTPsec use the same files and names for the application.

Installation of NTPsec

The installation of NTPsec can be done via the package manager as well as by manually building the source code.

Method 1: Using the Package Manager

The easiest way to install NTPsec is through the use of a package manager. For NTS support, we need the version 1.1.8 or higher. To check which package version is available, we use the command apt show:

apt show ntpsec | grep Version

If version 1.1.8 is available, we can simply install it as follows:

sudo apt install ntpsec

That’s it! You can skip the following steps and go directly to the configuration (see below).

Method 2: Build the Source Code Manually

The manual setup consists of building and installing NTPsec as well as its registering as a system service (systemd).

Part 1: Building and Installing

This installation guide is based on the NTPsec instructions and can be carried out without much effort. We begin with the installation of some basic tools and compilers. Then we create a temporary working directory in which we copy and build the NTPsec source code.

The following script now installs all tools or packages (bison, libssl-dev, libcap-dev, libseccomp-dev) that are needed for building. These can also be installed manually. But in our case we use the script:

# install necessary packages
sudo ./buildprep

Now we can make initial configurations. We can display the available options with

./waf configure --help

. If no parameters are specified, the NTPsec installation is done in the /usr/local/ directory by default. The application (ntsd) is then located in /usr/local/sbin. With the parameter –prefix=<dest/path> we can change the path arbitrarily. If NTPsec is to be configured as a server, the parameter –refclock=all is necessary, since it allows the use of any local reference clock (GPS, PTP, SHM, etc.).

Now NTPsec is executed automatically when rebooting the system. At the moment the service is not running yet, because we have to configure it first.

Configuration of NTPsec

After the installation of NTPsec the configuration has to be created. The NTP service uses ntp.conf, which is located in the /etc/ directory by default. If this file is not yet available, it must be created:

In the first example, the Raspberry Pi synchronizes its clock with a public NTPsec time server using a classical unsecured NTP connection.

In the second example, the client communicates with the same time server via an NTS-secured NTP connection. The initial channel to the NTS-KE server uses the default port 123 TCP (currently implementation-specific). Since the NTPsec time server uses certificates issued by Let’s Encrypt, we do not need to set any additional parameters. To check the certificates, the client uses the local root CA pool (/etc/ssl/certs/ca-certificates.crt), which also allows the verification of certificates issued by Let’s Encrypt.

In the third example, we connect to the time server of the Ostfalia University, which is also NTS-capable. This uses TCP port 443 for the NTS-KE connection and uses self-signed test certificates. To check the server certificate we have to specify the root CA manually. The corresponding certificate can be downloaded by the following command:

Caution: The time server of the Ostfalia University also publishes its private key, as it is a public test server. This time server should not be used for clock synchronization of productive systems.

The fourth example differs from the third one only from the deactivated domain validation. This can be useful when we running a local NTS server with certificates without a registered domain.

The other entries in the configuration file are optional and are used to record statistics and log files. The descriptions as well as the complete parameter list (incl. NTS) can be found in ntp_conf.adoc. Here only very briefly described:

Server Configuration

In this example, we use the local clock as the reference time source, which we distribute to all connected clients. When activating NTS, we have to specify a server certificate and the private key. This may have been created manually or issued by an external CA instance (e.g. Let’s Encrypt again).

By the way, the client and server configurations can be combined to run both simultaneously. For example, a client could fetch the time NTS-secured from external time servers and distribute it as a server in the local network without NTS.

Manipulated or invalid packets are detected and discarded. The number is listed accordingly (NTS server recvs w error).

Wireshark Examples and Pcap Files

At this point, I would like to show a few examples, how the whole thing looks like in Wireshark. Since NTS is not yet supported in Wireshark, there are still incorrect interpretations of the binary data. But that shouldn’t bother us at all.

Example 1: NTS with TLS 1.2 and 512-Bit AEAD Algorithm:

In this figure we see an NTS-secured NTP connection. This starts with the NTS-KE over TLS 1.2. Due to the strong AEAD algorithm and the resulting large cookies, the NTP packets have a size of 296 bytes (or 338 bytes including all headers). The yellow markings in Wireshark are due to misinterpretations of the content.

NTS with TLS 1.2 and 512 bit AEAD algorithm

Example 2: Possible NTS Behavior with Packet Loss or Manipulation:

Here we see the behavior of manipulated NTP packets. The server simply discards them. The client then sends another packet and wants an additional cookie because one is missing. Therefore, the size of the following request increases by the size of a cookie. This is repeated until the client has no cookies left and repeats the NTS-KE. This behavior also occurs if the client does not receive the response due to packet loss.

Possible NTS behavior with multiple packet loss

Exampe 3: NTPsec with Default Settings and NTS

Like example 1, but with TLS 1.3 and a 256 bit AEAD algorithm. The NTP messages are therefore smaller.

NTPsec with default settings and NTS

Example 4: Multiple Unsecured NTP and NTS-Secured NTP Connections

In this example, we see unsecured and NTS-secured NTP connections of the Ostfalia time server. The NTS connections use different configurations (AEAD algorithms), so that the packet sizes vary.

Multiple unsecured NTP and NTS-secured NTP connections

The current connections of the Ostfalia time server are recorded and can be freely downloaded. This allows better diagnosis and live tracking when testing with NTS. The current pcap files can be found here and here. The pcap files of the Wireshark examples above are here.:

]]>https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/feed/1I Love IPv6 Addressing!https://weberblog.net/i-love-ipv6-addressing/?utm_source=rss&utm_medium=rss&utm_campaign=i-love-ipv6-addressing
https://weberblog.net/i-love-ipv6-addressing/#commentsMon, 25 Nov 2019 16:38:28 +0000https://blog.webernetz.net/?p=9920Probably the biggest prejudice when it comes to IPv6 is: “I don’t like those long addresses – they are hard to remember.” While this seems to be obvious due to the length and hexadecimal presentation of v6 addresses, it is NOT true. In the end, you’ll love IPv6 addresses in your own networks. This is … Continue reading I Love IPv6 Addressing!→]]>

Probably the biggest prejudice when it comes to IPv6 is: “I don’t like those long addresses – they are hard to remember.” While this seems to be obvious due to the length and hexadecimal presentation of v6 addresses, it is NOT true. In the end, you’ll love IPv6 addresses in your own networks. This is why – summed up in one poster:

]]>https://weberblog.net/i-love-ipv6-addressing/feed/3Intro to NetworkMinerhttps://weberblog.net/intro-to-networkminer/?utm_source=rss&utm_medium=rss&utm_campaign=intro-to-networkminer
https://weberblog.net/intro-to-networkminer/#commentsWed, 20 Nov 2019 14:46:22 +0000https://blog.webernetz.net/?p=9856This is a guest blogpost by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC. Wireshark is the default goto tool for analyzing captured network traffic for most network engineers. But there are a few other free and open source alternatives that are sometimes overlooked, one of which is NetworkMiner (disclaimer: … Continue reading Intro to NetworkMiner→]]>

This is a guest blogpost by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC.

Wireshark is the default goto tool for analyzing captured network traffic for most network engineers. But there are a few other free and open source alternatives that are sometimes overlooked, one of which is NetworkMiner (disclaimer: I’m the creator of NetworkMiner).

Extracting Files from PCAP Files

Many users turn to NetworkMiner when it comes to extracting artifacts, such as files or credentials from pcap files. You can solve such tasks with Wireshark too, but NetworkMiner will save you time and spare you some tedious manual work. In fact, NetworkMiner automatically extracts files from protocols like FTP, TFTP, HTTP, HTTP/2, SMB, SMB2, SMTP, POP3, and IMAP as soon as a pcap file is opened.

Files extracted by NetworkMiner 2.5

Extracted files that are recognized as images are also shown as thumbnails on the images tab. This image list can give a quick overview of what is going on in the capture file.

Thumbnails of extracted images in NetworkMiner 2.5

Usernames and Passwords

User credentials, such as usernames, passwords and hashes that NetworkMiner detects are all placed under the “Credentials” tab. The protocols and data structures from which NetworkMiner can extract credentials include FTP, HTTP cookies, HTTP POST requests, IMAP, Kerberos hashes, MS SQL, NTLM hashes, POP3, RDP cookies, SMTP, SOCKS and a few more.

Usernames, passwords, hashes and cookies extracted by NetworkMiner

Passive Host Inventory

Another popular feature in NetworkMiner is the “Hosts” tab, which provides an overview of which devices have been observed in the loaded capture files. NetworkMiner aggregates data based on IP address in the Hosts tab, which is useful if you want to create a host inventory list without actively scanning a network or if you want to learn more about a particular IP address.

Details about 192.168.0.54 extracted by NetworkMiner

The Hosts tab is great if you want to find out what hostname(s) an IP address has since it doesn’t just rely on captured DNS traffic to perform passive hostname resolution. NetworkMiner also extracts and aggregates hostname info from the CIFS Browser Protocol, DHCP, HP Switch Protocol, HTTP/2 authority headers, HTTP host headers, HTTP User-Agent strings, Kerberos, NetBIOS Datagram Service, NetBIOS Name Service, NTLMSSP, TLS SNI, X.509 certificates, and a few additional protocols and data structures.

The Hosts tab is also often used in order to find out which operating system a host is running as well as details like what web browser User-Agents or open SMB file shares it has.

So why not give NetworkMiner a try next time you want to extract a few files from a capture file or get an overview of what’s going on in a capture? It’s a free tool that doesn’t even require an installation, you just extract the zip file and run it!

The capture file loaded into NetworkMiner in the screenshots above is “snort.log.1426204807” from the FIRST 2015 “Hands-on Network Forensics” training PCAP dataset. You can download this capture file, and many more, from Netresec’s Publicly available PCAP files.

]]>https://weberblog.net/intro-to-networkminer/feed/1Basic TCP and UDP Demos w/ netcat and telnethttps://weberblog.net/basic-tcp-and-udp-demos-w-netcat-and-telnet/?utm_source=rss&utm_medium=rss&utm_campaign=basic-tcp-and-udp-demos-w-netcat-and-telnet
https://weberblog.net/basic-tcp-and-udp-demos-w-netcat-and-telnet/#commentsTue, 12 Nov 2019 07:37:23 +0000https://blog.webernetz.net/?p=9523I am currently working on a network & security training, module “OSI Layer 4 – Transport”. Therefore I made a very basic demo of a TCP and UDP connection in order to see the common “SYN, SYN-ACK, ACK” for TCP while none of them for UDP, “Follow TCP/UDP Stream” in Wireshark, and so on. I … Continue reading Basic TCP and UDP Demos w/ netcat and telnet→]]>

I am currently working on a network & security training, module “OSI Layer 4 – Transport”. Therefore I made a very basic demo of a TCP and UDP connection in order to see the common “SYN, SYN-ACK, ACK” for TCP while none of them for UDP, “Follow TCP/UDP Stream” in Wireshark, and so on. I wanted to show that it’s not that complicated at all. Every common application/service simply uses these data streams to transfer data aka bytes between a client and a server.

That is: Here are the Linux commands for basic lab, a downloadable pcap, and, as always, some Wireshark screenshots:

weberjoh@vm24-ns0:~$ telnet 2001:470:765b::b15:22 1337
Trying 2001:470:765b::b15:22...
Connected to 2001:470:765b::b15:22.
Escape character is '^]'.
Hello
Hi there
Greetings from the client to the server!
Thanks. Greetings back from the server to the client.
Cheers
Goodbye
^]
telnet> quit
Connection closed.

Wireshark reveals the TCP flags in the Info column for connection establishment and termination. Have a look at the ACKs directly after each sent message, regardless of which direction. Finally, a “Follow TCP Stream” shows the raw data, coloured by the way they were transmitted:

Wireshark’s glasses. No connection establishment nor termination. No ACKs. Only the raw data in both directions. One single UDP packet per sent text message. Quite easy. “Follow UDP Stream” works as well: