Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for dnswasher #3720

Merged
merged 6 commits into from Apr 19, 2016

Conversation

edmonds
Copy link
Contributor

@edmonds 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 6 commits April 15, 2016 20:34
Only the QR bit (not the RD bit) is consulted when determining which IP
address to obfuscate.
DLT_RAW captures (linktype 101) were not handling IPv6 packets
correctly.

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.
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.
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.)
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
@ahupowerdns
Copy link
Contributor

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
Copy link
Contributor Author

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.

@ahupowerdns
Copy link
Contributor

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants