Skip to content

Latest commit

 

History

History
89 lines (59 loc) · 5.57 KB

README.md

File metadata and controls

89 lines (59 loc) · 5.57 KB
Raw

Rear View RPZ (tm)

status: good to go with no backlog items. I expect it to work if you satisfy the prerequisites. tested with python 3.6, 3.8, 3.11; dnspython 1.15, 2.1, 2.2; bind 9.12.3, 9.16.23, 9.18.9

Turn your recursive DNS (BIND) server into a network investigation enabler with DnsTap and Response Policy Zones!

What are "DnsTap" and "Response Policy Zones"?

DnsTap and Response Policy Zones (RPZ) are features available with the ISC BIND 9 DNS server. BIND is open source and is nearly ubiquitous in software distributions as either the "go to" or an optional recursive DNS service / server.

Unfortunately DnsTap and RPZ are generally considered to be optional features and so may not be available with the BIND binary installed by your operating system, although ISC's alternate packages are compiled with support. It's not hard to compile it from source, particularly on linux (or in a linux container). These features are documented as part of the regular BIND reference manual.

What's perhaps unusual about usage here is putting DnsTap to work to update a zone served and utilized by the same DNS server as an RPZ and utilizing that RPZ not as a "ban hammer" but as a source of preferred information.

How does this work?

Rear View RPZ Agent runs as a service and interacts with the BIND Server in two ways:

  1. It listens for DnsTap telemetry generated by the BIND Server, and uses that telemetry to derive "best guess" name-to-address mappings.
  2. It uses dynamic DNS updates sent to the BIND Server to maintain PTR entries in an RPZ which targets the in-addr.arpa. namespace.

BIND runs as a service answering user (and application) DNS requests. In the process it does two things:

  1. Generates DnsTap telemetry concerning the DNS request and response.
  2. Consults any Response Policy Zones for "overrides" or edits to be applied in place of what is provided by the global DNS database.

Put it together and you get PTR responses enhanced with local knowledge.

Run the policy incorporating this RPZ as a view, possibly bound to a special address, and any client which wants "xray vision" for tools which support it just has to point their network configuration at the appropriate address for DNS services. (If you're running a service which needs the "ground truth" for DNS, have a different view on a different address for that.) In other words: you can do all the admin in BIND.

Here is a post with an example: https://lists.isc.org/pipermail/bind-users/2021-December/105450.html or see Examples.txt in this directory.

Will this really help me?

It depends on what's on the network you're defending: know your assets! This is a tool for discovering more about the off-network assets your network communicates with.

Some networks (particularly in the cloud) are mostly services; these networks generally don't perform discovery of clients as a matter of course (access control notwithstanding). Other networks are mostly clients; these networks do perform discovery of services as a matter of course, and the primary mechanism to do this is the DNS. Some, such as networks hosting medical devices or industrial control systems, can be both.

Threat indicator feeds (of DNS IOCs) are predominantly derived from global telemetry, whereas this tool provides information about your own network. Services don't perform discovery as a matter of course: the discovery process is outside of our knowledge horizon and global telemetry is the only option for information about that process.

This tool exposes information from the local service discovery process.

  • Are you defending clients of off-network services? those clients are the assets which are going to have a local discovery process for services
  • Are you mature enough to want visibility of permitted services? although the vendor emphasis is on threat indicators, intelligence about allowed / expected non-threat artifacts becomes more useful and desirable as maturity increases. the information surfaced by this tool is largely non-threat artifacts

What are the prerequisites?

At the present time, you'll probably be frustrated unless you meet the following prerequisites. If we get some more road dirt, maybe we can get some more playbooks: by all means submit a PR or open an issue.

  • You are familiar with running and configuring BIND
  • You are familiar with:
    1. building from source...
      • satisfying prerequisites
      • configure; make; make install...
    2. ...or installing BIND using ISC's packages (https://www.isc.org/bind/)
  • You can use git clone
  • You are familiar with Python syntax
  • You can figure out a systemd service file

There's more!

In /utilities you'll find a KNIME workflow which analyzes the RPZ data. It includes Python nodes for:

  • reading the zone (with AXFR)
  • fetching PTR records for identified addresses
  • canonicalizing DNS domains (based on the public suffix list)

Want Help?

I like talking with people!

  • Want to walk through the code?
  • Do you like having company when you're installing something for the first time?
  • Just want to talk about DNS, BIND, Python, and all that?
  • Other questions about threat intelligence, or indicator hunting generally?

I'm reserving a one hour slot every week, just for you: whatever you want, for free. Reach out to me at [email protected] or open an issue! (For clarity I'm envisioning this as a single free slot for you in the singular person sense, although I might make it a regular thing for you, in the singular person sense, if it tickles my fancy.)