Fixes for dnswasher #3720

merged 6 commits into from Apr 19, 2016


None yet

2 participants

edmonds commented Apr 16, 2016

This fixes a number of issues I found while trying to use dnswasher on a DLT_RAW pcap containing IPv6 traffic.

Robert Edmonds added some commits Apr 16, 2016
Robert Edmonds dnswasher: Fix comment at top of file (RD -> QR)
Only the QR bit (not the RD bit) is consulted when determining which IP
address to obfuscate.
Robert Edmonds dnspcap: Decode IPv6 packets in DLT_RAW captures correctly
DLT_RAW captures (linktype 101) were not handling IPv6 packets

For DLT_RAW, PcapPacketReader::getUDPPacket() synthesizes a fake
ethertype value (the "contentCode" variable), but for IPv6 it was
incorrectly set to 0x0806 (ARP) instead of 0x86dd (IPv6). This caused
IPv6 packets to silently be discarded.
Robert Edmonds dnswasher: Don't spam stdout in IPObfuscator::obf6() bf3c7b3
Robert Edmonds dnswasher: Only zero the IP header checksum for IPv4
IPv6 doesn't have a checksum field. This code previously zeroed the
space in the header where the IPv4 header checksum would be, regardless
of IP header version.
Robert Edmonds dnswasher: Remove offsets from IPv6 src/dst pointers
I'm not entirely sure why this code was offsetting the IPv6
source/destination header fields, but this commit removes those offsets.

This results in the obfuscation of the first 64 bits of the IPv6
source/destination addresses. (Arguably the whole address should be
obfuscated, though.)
Robert Edmonds dnswasher: Write obfuscated IPv6 prefixes in network byte order
Make the IPv6 code path follow the IPv4 code path by writing out the
IPObfuscator counter in network byte order.

This makes the obfuscated IPv6 addresses easier to read and avoids
making the output of the tool vary based on the host byte order.
@ahupowerdns ahupowerdns merged commit b214801 into PowerDNS:master Apr 19, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed

Robert, as a followup, I think the offset on IPv6 meant we were attempting to zero out the last 64 bits of the IP address. Thoughts?

edmonds commented Apr 19, 2016

Yeah, that didn't make much sense to me because the first 64 bits of the IPv6 address is still quite a lot of information. E.g., the first 64 bits of my IPv6 address is enough to uniquely identify me :-)

Also, due to the bug fixed in a8b9d93, since it would appear the IPv4 header checksum field physically overlaps the first 64 bits of the IPv6 source address field, I think you were also punching a 16 bit hole in the first 64 bits of the IPv6 source address, at least for queries.

In my local branch I wanted to obfuscate the full 128 bits so I ended up calling the obfuscator twice for each 64 bit half of the IPv6 address.


7856684 has the proper fix, will be merged shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment