Again two more commonly used network protocols for the Ultimate PCAP: the Remote Authentication Dial-In User Service (RADIUS) and the Terminal Access Controller Access-Control System Plus (TACACS+) protocols. Captured with quite some details:
At SharkFest’22 EU, the Annual Wireshark User and Developer Conference, I attended a beginners’ course called “Network Troubleshooting from Scratch”, taught by the great Jasper Bongertz. In the end, we had some high-level discussions concerning various things, one of them was the insight that TCP RSTs are not only sent from a server in case the port is closed, but are also commonly sent (aka spoofed) from firewalls in case a security policy denies the connection. Key question: Can you distinguish between those spoofed vs. real TCP RSTs? Initially, I thought: no, you can’t, cause the firewalls out there do a great job.
It turned out: you can!
In general, Network Address Translation (NAT) solves some problems but should be avoided wherever possible. It has nothing to do with security and is only a short-term solution on the way to IPv6. (Yes, I know, the last 20 years have proven that NAT is used everywhere every time. 😉) This applies to all kinds of NATs for IPv4 (SNAT, DNAT, PAT) as well as for NPTv6 and NAT66.
However, there are two types of NATs that do not only change the network addresses but do a translation between the two Internet Protocols, that is IPv4 <-> IPv6 and vice versa. Let’s focus on NAT46 this time. In which situations is it used and why? Supplemented by a configuration guide for the FortiGates, a downloadable PCAP and Wireshark screenshots.
The other day I just wanted to capture some basic Linux traceroutes but ended up troubleshooting different traceroute commands and Wireshark display anomalies. Sigh. Anyway, I just added a few Linux traceroute captures – legacy and IPv6 – to the Ultimate PCAP. Here are some details:
Fortunately, there was a SharkFest – the “Wireshark Developer and User Conference” – this year in Europe again. I was there and gave an IPv6 Crash Course likewise. Yeah! It’s my favourite topic, you know. 75 minutes full of content, hence the name crash course.
Here are my slides as well as the video recording. If you want a crash course for IPv6, here we go:
From time to time I stumble upon Tweets about counting the number of IPv6 addresses (1 2 3). While I think it is ok to do it that way when you’re new to IPv6 and you want to get an idea of it, it does not make sense at all because the mere number of IPv6 addresses is ridiculously high and only theoretically, but has no relevance for the real-world at all. Let me state why:
For some reason, I came across a blog post by Gian Paolo called Small servers. This reminded me of some fairly old network protocols (that no one uses as far as I know) that are not in my Ultimate PCAP yet. Hence I took some minutes, captured them, and took some Wireshark screenshots. They are: echo, discard, daytime, chargen, and time. Mostly via TCP and UDP, and, as you would have expected, IPv6 and legacy IP.
I’m aware that this is not of interest to most of you. :) But for the sake of completeness, and because I love adding new protocols to the Ultimate PCAP, I added them though.
Das moderne Internetprotokoll IPv6 gilt als so komplex und umständlich, dass manche Administratoren beharrlich beim vertrauten, aber veralteten IPv4 bleiben. Zehn Praxisbeispiele belegen, warum viele Netzwerkanwendungen besser und kostengünstiger auf IPv6 laufen und wie Admins davon profitieren.
Wenn es im Netzwerk knirscht, versuchen Admins den Fehler in Analyse-Tools wie Wireshark anhand von Paketmitschnitten einzukreisen. Jedoch hat der Herr viel mehr Netzwerkprotokolle gegeben, als sich ein Admin-Hirn in allen Details merken kann. Eine Referenzdatei, die zahlreiche korrekte Protokollabläufe enthält, gibt Orientierung.
Haben Sie mal Netzwerkmitschnitte untersucht, ohne zu wissen, was genau Sie suchen? Mit Wireshark wird das leicht zu einer Odyssee: Das Analysewerkzeug filtert zwar fabelhaft, reagiert bei großen Datenmengen aber schnell zäh.
Was bei solchen Problemstellungen hilft ist: tshark! Ein Tool, mit welchem Sie auch große Packet Captures einfach anhand gängiger Kriterien durchforsten können.
Angreifer verwenden gern Ping und Traceroute, um Server im Internet ausfindig zu machen. Das bringt viele Security-Admins in Versuchung, den Ping- und Traceroute-Verkehr mittels ihrer Firewall in ihrem Netz zu unterbinden. Doch damit behindern sie nur die Arbeit von Server-Administratoren, denn es gibt noch viel mehr Möglichkeiten, Server aufzuspüren.
Palo Alto firewalls have a nice packet capture feature. It enables you to capture packets as they traverse the firewall. While you might be familiar with the four stages that the Palo can capture (firewall, drop, transmit, receive), it’s sometimes hard to set the correct filter – especially when it comes to NAT scenarios. (At least it was hard for me…)
I am using the packet capture feature very often for scenarios in which the IP connections are in fact working (hence no problems at the tx/rx level nor on the security policy/profile) but where I want to verify certain details of the connection itself. I’m simply using the Palo as a capturing device here, similar to a SPAN port on a switch. (Yes, I’m aware of all disadvantages of not using a real TAP and a real capture device.) In the end, I want a single pcap which shows all relevant packets for a client-server connection, even if NAT is in place. Wireshark should be able to correlate the incoming/outgoing packets into a single TCP stream. Furthermore, I definitely want to use a filter to limit the amount of captured packets. This is how I’m doing it:
I just had a hard time figuring out that a network routing setup was not working due to a correctly enforced IP Spoofing protection on a Palo Alto Networks firewall. Why was it a hard time? Because I did not catch that the IP spoofing protection kicked in since there were no logs. And since we do log *everything*, a non-existent log means nothing happened, right? Uhm, not in this case. Luckily you can (SHOULD!) enable an additional thread log on the Palo.
An analysis of some falsified leap second warnings that appeared in November 2021 on public NTP servers out of the NTP Pool Project.
Ich durfte zu Gast bei der #heiseshow zum Thema IPv6 sein. In Anlehnung an die Artikelserie über IPv6 in der c’t 7/2022, in der auch mein Artikel über die Vorteile von IPv6-Adressen erschienen ist, ging es bei diesem Video-Podcast um gängige Fragen zu IPv6 sowohl im Heimanwender- als auch im Enterprise-Segment. Ne knappe Stunde lief die Schose und ich empfand es als ziemlich kurzweilig. ;)