This time around, packets from one of my own DNS servers. If you would like to follow along, you can find the full unobfuscated packet trace here.
(quick update... turns out that the router and DNS queries involved are part of www.nlnetlabs.nl, a network research labs that does experiment with DNS servers... so maybe this is all some side effect of an experiment they are running. Thanks to Don for pointing this out to me. After visiting their website, I did see a number of similar ICMP admin prohibited packets with flipped fragmentation bytes, but the embeded packet's source port was 80! ;-) )
You should find 9 packets. To abbreviate, I am using the following notation:
DNS = my DNS Server
Q = DNS Query Source
R = router sending ICMP Admin Prohibited messages.
Here the "big picture":
Q -> DNS: Query for NS sans.orgThese are all the packets my system exchanged with these three systems at the time. Overall, this happened in about 0.13 second. The server failure was actually a temporary issue. The DNS server is authoritative for 'sans.org' and usually responds to these queries.
Lets look at the big picture first:
We got three DNS queries, three DNS responses and three "admin prohibited" packets. Kind of makes sense. A host is requesting information from our DNS server, but a (misconfigured?) router is rejecting the responses. The timing is a bit off (would have expected 'Query','Response','ICMP' ... 'Query','Response','ICMP'...). But this is not that unusual.
So lets look at the packets in detail. First the Query for 'NS sans.org':
Internet Protocol, Src: 126.96.36.199 (188.8.131.52), Dst: 184.108.40.206 (220.127.116.11)
I removed some lines from the tethereal output. The packet looks "normal" withe the one exception of EDNS0 being used. EDNS0 is used to indicate to the receiving DNS server that the querying DNS server is able to receive more then 512 bytes of the response as a UDP packet. In this case, its 4k. A bit large, and frequently large EDNS0 packets are used to increase the amplification f or denial of service attacks.
Couple other things if you compare the packets:
Internet Protocol, Src: 18.104.22.168 (22.214.171.124), Dst: 126.96.36.199 (188.8.131.52)
The response from my DNS server: well, nothing unusual here. I would like to point out that no fragmentation is used (well, there is no need to). The 'DF flag is set. The IPID is set to 0, which is typically for recent Linux kernels if the DF flag is set.Now lets look at the ICMP packets. These are the packets that caused me to look at this issue in the first place. So far, we don't actually have much out of the ordinary. I am using the last ICMP packet here:
Internet Protocol, Src: 184.108.40.206 (220.127.116.11), Dst: 18.104.22.168 (22.214.171.124)
Now this is where the "blast from the past" shows up:
Fragment offset 512Bytes. If you look at the Flag/Fragment offset bytes: 00 40.. flip them and you end up with '40 00' or: no fragment offset and 'do not fragment' flag set. hm... interesting...
Now if we just forget for a moment that this packet claims to be fragmented, we see that the "payload" is actually a normal UDP header: Source port 53 and Destination port 63417. This is the same port we had as a source port earlier. So if you ignore the fragmentation issue, this kind of looks like the result to the DNS response we sent earlier. Even the TTLs work out right! But then again... the size of the packet is HUGE. Looks like another byte-order issue: a size of 0x41 (65 bytes) is much closer to the size of the packet we sent.
We had a case a couple years ago with a similar byte order issue. But this is odd in the sense that the spoofed packet appears to be a direct result of the real packet. The spoofed packet is very close to the real packet. Maybe its not actually spoofed but just "mangled" by some kind of in-line device?
I will be teaching next: Defending Web Applications Security Essentials - SANS San Francisco Spring 2020
Nov 13th 2006
1 decade ago