djveremix / google-dnswall Goto Github PK

We should randomize the source port to avoid this mysterious DNS security
issue.

This is a test of Google Code. Please ignore this bug.

128.121.146.100
128.121.146.228
168.143.162.100
168.143.162.116
168.143.162.68
202.106.1.2
202.181.7.85
203.161.230.171
209.145.54.50
211.94.66.147
216.234.179.13
4.36.66.178
64.33.88.161

Some of the DNS resolves to fake IP to redirect request to ISP's ad, and 
China's GFW may censor ALL TCP/UDP port 53 traffic to the fake IP's above.

Blocked prefix should be 224/28, not 224/24.

We correctly block the "IPv4-mapped IPv6 address" embedding at
::ffff:00:00:00:00/96, but we don't block block the "IPv4-compatible IPv6
address" embedding at ::/96.

dnswall 0.1.3 issues query IDs which are consecutive. As a defence against 
reply spoofing, query IDs should not be predictable. For background
information, search Google for "dns predictable query id".

This is compounded by dnswall sending its queries from the same source
port. By observing one query from dnswall on the network I can predict with
100% certainty the source port and query ID of the next query and thereby
send a spoofed reply to it.

In light of this I consider dnswall to only be safe to use when its path
to the "real" upstream DNS server is certain to be private (e.g. over a
loopback interface on the same machine).

The suggestion in the README file to forward to a remote DNS server, such
as an ISP's resolver, is wholly inappropriate and should be removed in
favour of a strong recommendation for a loopback-only scenario.

In order to reliably make changes to dnswall, we need a suite of unit
tests.  Even something simple would be very valuable.

RFC 3330 defines some ranges which can not be found on the internet. for 
example 192.0.2.0/24. As a result those ranges can be used behind NAT 
like usual RFC 1918 IPs.

dnswall should make sure those ranges are not returned neither.

The trivial patch provided below add filtering for :

   192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
   documentation and example code.  It is often used in conjunction with
   domain names example.com or example.net in vendor and protocol
   documentation.  Addresses within this block should not appear on the
   public Internet.

You may consider filtering for this range as well :

   198.18.0.0/15 - This block has been allocated for use in benchmark
   tests of network interconnect devices.  Its use is documented in
   [RFC2544].


diff -ur dnswall.org/src/dnswall.c dnswall.documentation/src/dnswall.c
--- dnswall.org/src/dnswall.c   2007-11-14 19:59:52.000000000 +0000
+++ dnswall.documentation/src/dnswall.c 2010-01-01 
15:25:31.000000000 +0000
@@ -94,6 +94,10 @@
      (ptr[0] == 192 && ptr[1] == 168))
     return 0;

+  // Documentation
+  if (ptr[0] == 192 && ptr[1] == 0 && ptr[2] == 2)
+    return 0;
+
   // Multicast
   // (we are unable to determine the groups internal machines
   // belong to, so we have to block everything)

We're using this test for link-local:

  // Link-local
  if (ptr[0] == 0xf0 && (ptr[1] >> 6) == (0x80 >> 6))
    return 0;

This corresponds to f080::/10, but https://ietf.org/rfc/rfc3513.txt says we
should be using fe80::/10 for link-local.

Also, we should consider blocking site-local (fec0::/10) even though the
allocation is deprecated.

We should use a cryptographically strong PRNG to generate query ids. 
Currently we're just using rand().

Currently you need to build the gtest library manually before building the
unit tests for dnswall.  We should integrate the build so that `make` and
`make check` work seamlessly.  Sadly, my autoconf skills were not up to the
challenge.