[dns-operations] release of ISC SIE cache poisoning attempt detection tool

[Robert Edmonds]

hi,

ISC SIE has developed a tool for detecting cache poisoning attempts. it
consists of two parts: ncaptool, the part which performs packet gathering,
reassembly, and dns filtering; and mod_urstate, a message processing module
which attempts to statefully detect unsolicited responses that may be
indicative of cache poisoning attempts. specifically, the tool is designed
to listen at the network layer of a recursive dns server, auditing the
query-response stream between recursive and authoritative dns servers. when
a potential cache poisoning attempt is detected, both the offending and
original dns responses will be emitted into the output stream.

ncaptool and mod_urstate may be obtained via ftp:

    ftp://ftp.isc.org/isc/ncap/

the defaults are tuned for a dedicated IDS-style setup; e.g. fairly fast
machines with >= 1 GB of memory and aggregated taps of dns traffic
between recursive and authoritative nameservers. it ought to be
possible to run it directly on a machine running a recursive nameserver,
however.

we would like people to use it, and if possible provide feed back or
contribute the data it generates to SIE.

mod_urstate is an ncaptool dns message parsing plugin that attempts to
detect unsolicited dns responses that may be indicative of cache poisoning
attempts. it does this by statefully tracking the application layer state
of the dns transactions between recursive and authoritative dns servers. it
gracefully handles query retransmissions due to client timeouts and byte
identical responses from dns authorities.

two data collections are employed by mod_urstate:

 * a fifo cache of the query / response payloads generated by dns
   transactions. a hard limit on the number of entries in this cache will
   be enforced to bound memory consumption. the default limit of 1048576
   entries tends to consume around 700 MB of memory. the larger this cache
   is, the more accurate the output will be. as a rule of thumb, the cache
   should be large enough to hold at least 5 to 30 seconds or so of the most
   recent dns transactions.

 * an associative array for locating entries in the cache based on a
   tuple of fields from the packet headers and payload.

when a query for a previously unknown tuple arrives, the query payload is
cached so that subsequent byte identical queries may be discarded. when the
first response for this query arrives, its payload is also cached. the vast
majority of dns queries will only elicit a single response, so most cache
entries will be quietly expired in fifo order.

however, in the usual case that a domain name's authoritative nameservers
are reachable and functioning, a potentially successful cache poisoning
attempt has these properties:

 * the malicious response payload differs in some way from legitimate
   response payloads.

 * the malicious response matches the tuple for an outstanding query.

 * the malicious response arrives at approximately the same time as a
   legitimate response.

(it should be noted that certain types of benign dns responses unfortunately
also match these criteria. it will be possible to filter these out in the
post-processing / analysis phase.)

the mod_urstate module will output dns responses matching the above
criteria. this output can then be analyzed to help answer the following
questions:

 * was an attempt made to introduce malicious data into my cache?

 * did the attempt succeed? i.e., did the malicious response arrive prior
   to the legitimate response?

 * what are the contents of the malicious dns response? e.g., in the most
   common scenario, where is the attacker's doppelgaenger located?

it should be noted that an out of band method of distinguishing malicious
from legitimate responses will be needed by the analyst.

-- 
Robert Edmonds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080804/4ff42196/attachment.sig>