From vixie at fsi.io  Thu Mar 11 00:43:20 2021
From: vixie at fsi.io (Paul Vixie)
Date: Wed, 10 Mar 2021 16:43:20 -0800
Subject: [DNSfirewalls] RPZ mentioned
In-Reply-To: <7e415139-25cf-f8bb-5ba1-2d57655b2d9c@fsi.io>
References: <7e415139-25cf-f8bb-5ba1-2d57655b2d9c@fsi.io>
Message-ID: <ccbd7e4d-b543-901b-3919-4540a495e5cd@fsi.io>

https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_PROTECTIVE%20DNS_UOO117652-21.PDF

-- Are you in??? https://labs.fsi.io/

From paul at redbarn.org  Mon Mar 15 18:33:30 2021
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 15 Mar 2021 18:33:30 +0000
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response policy
 information in dnstap]
Message-ID: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>

there's work afoot to support rpz triggers and actions as part of 'dnstap'.
this was an active area of research for april lorenzen when rpz first came
out, but using the name server's text-format log files made her path rocky.
i'm very much hoping that the telemetry features described below will unlock
a massive wave of innovation over what should be done about an rpz "hit".

vixie

re:

----- Forwarded message from Chris Mikkelson <cmikk at fsi.io> -----

Date: Mon, 15 Mar 2021 12:47:50 -0500
From: Chris Mikkelson <cmikk at fsi.io>
To: dnstap at lists.redbarn.org
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: [dnstap] (PR) Adding response policy information in dnstap

Greetings,

A pull request for the response policy information field and
type proposed last month is up for review, at:

	https://github.com/dnstap/dnstap.pb/pull/12

Feedback, questions, and requests for changes, clarifications,
or edits are welcome, either on the PR or via this mailing list.

If there are no objections, requests for more time to
review, or requests for substantive changes requiring
further discussion before this Friday (3/19, UTC-05:00),
I will merge the change.

Thanks,
-- 
Chris Mikkelson
Farsight Security, Inc.
cmikk at fsi.io 
_______________________________________________
dnstap mailing list
dnstap at lists.redbarn.org
http://lists.redbarn.org/mailman/listinfo/dnstap

----- End forwarded message -----

-- 
Paul Vixie

From afried at deteque.com  Mon Mar 15 20:15:55 2021
From: afried at deteque.com (Andrew Fried)
Date: Mon, 15 Mar 2021 16:15:55 -0400
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response
 policy information in dnstap]
In-Reply-To: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
References: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
Message-ID: <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>

I'm assuming this logging feature would require each RPZ resolver vendor
to incorporate support for this.  Has ISC/NLnet Labs/PowerDNS indicated
that they were amenable to adding that support?

Andy

On 3/15/21 2:33 PM, Paul Vixie wrote:
> there's work afoot to support rpz triggers and actions as part of 'dnstap'.
> this was an active area of research for april lorenzen when rpz first came
> out, but using the name server's text-format log files made her path rocky.
> i'm very much hoping that the telemetry features described below will unlock
> a massive wave of innovation over what should be done about an rpz "hit".
> 
> vixie
> 
> re:
> 
> ----- Forwarded message from Chris Mikkelson <cmikk at fsi.io> -----
> 
> Date: Mon, 15 Mar 2021 12:47:50 -0500
> From: Chris Mikkelson <cmikk at fsi.io>
> To: dnstap at lists.redbarn.org
> User-Agent: NeoMutt/20170113 (1.7.2)
> Subject: [dnstap] (PR) Adding response policy information in dnstap
> 
> Greetings,
> 
> A pull request for the response policy information field and
> type proposed last month is up for review, at:
> 
> 	https://github.com/dnstap/dnstap.pb/pull/12
> 
> Feedback, questions, and requests for changes, clarifications,
> or edits are welcome, either on the PR or via this mailing list.
> 
> If there are no objections, requests for more time to
> review, or requests for substantive changes requiring
> further discussion before this Friday (3/19, UTC-05:00),
> I will merge the change.
> 
> Thanks,
> 

-- 
Andrew Fried
afried at deteque.com
+1.703.667.4050

From paul at redbarn.org  Mon Mar 15 20:40:00 2021
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 15 Mar 2021 20:40:00 +0000
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response
 policy information in dnstap]
In-Reply-To: <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>
References: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
 <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>
Message-ID: <20210315204000.5tyr5ir6hnmullmz@family.redbarn.org>

On Mon, Mar 15, 2021 at 04:15:55PM -0400, Andrew Fried wrote:
> I'm assuming this logging feature would require each RPZ resolver vendor
> to incorporate support for this.  Has ISC/NLnet Labs/PowerDNS indicated
> that they were amenable to adding that support?

bind9, powerdns, knot, and unbound all have rpz, and all have 'dnstap'. some
of them directly incorporate some 'dnstap' source code, which we're patching.
i fully expect that every one of these f/l/oss dns servers will adopt these
changes, and i will start the outreach on that after the patch is reviewed.

if anybody uses a dns server that's not one of those, please feel to reach out
to us so that we can add their name to the relevant web page (directory) and
reach out to them about joining the relevant mailing list.

in these matters, more is better.

vixie

From brian.peter.dickson at gmail.com  Mon Mar 15 20:43:01 2021
From: brian.peter.dickson at gmail.com (Brian Dickson)
Date: Mon, 15 Mar 2021 13:43:01 -0700
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response
 policy information in dnstap]
In-Reply-To: <20210315204000.5tyr5ir6hnmullmz@family.redbarn.org>
References: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
 <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>
 <20210315204000.5tyr5ir6hnmullmz@family.redbarn.org>
Message-ID: <CAH1iCiriEOWuPZ5qszcLcPcLB9Kj-ZA4__BF0bLbVfi4PFHq-Q@mail.gmail.com>

On Mon, Mar 15, 2021 at 1:40 PM Paul Vixie <paul at redbarn.org> wrote:

> On Mon, Mar 15, 2021 at 04:15:55PM -0400, Andrew Fried wrote:
> > I'm assuming this logging feature would require each RPZ resolver vendor
> > to incorporate support for this.  Has ISC/NLnet Labs/PowerDNS indicated
> > that they were amenable to adding that support?
>
> bind9, powerdns, knot, and unbound all have rpz, and all have 'dnstap'.
> some
> of them directly incorporate some 'dnstap' source code, which we're
> patching.
> i fully expect that every one of these f/l/oss dns servers will adopt these
> changes, and i will start the outreach on that after the patch is reviewed.
>
> if anybody uses a dns server that's not one of those, please feel to reach
> out
> to us so that we can add their name to the relevant web page (directory)
> and
> reach out to them about joining the relevant mailing list.
>

I am not 100% sure, but I think dnsdist is one. (It may share a code base
with one of those other projects, not sure.)

Brian


>
> in these matters, more is better.
>
> vixie
> _______________________________________________
> DNSfirewalls mailing list
> DNSfirewalls at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/dnsfirewalls
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnsfirewalls/attachments/20210315/cadad5f4/attachment-0001.htm>

From jeroen at massar.ch  Mon Mar 15 21:25:04 2021
From: jeroen at massar.ch (Jeroen Massar)
Date: Mon, 15 Mar 2021 22:25:04 +0100
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response
 policy information in dnstap]
In-Reply-To: <CAH1iCiriEOWuPZ5qszcLcPcLB9Kj-ZA4__BF0bLbVfi4PFHq-Q@mail.gmail.com>
References: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
 <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>
 <20210315204000.5tyr5ir6hnmullmz@family.redbarn.org>
 <CAH1iCiriEOWuPZ5qszcLcPcLB9Kj-ZA4__BF0bLbVfi4PFHq-Q@mail.gmail.com>
Message-ID: <c00f87de-4dc3-283f-7c0e-77a0f788f65a@massar.ch>

On 2021-03-15 21:43, Brian Dickson wrote:
[..]
 >     if anybody uses a dns server that's not one of those, please feel to
 >     reach out
 >     to us so that we can add their name to the relevant web page
 >     (directory) and
 >     reach out to them about joining the relevant mailing list.
 >
 >
 > I am not 100% sure, but I think dnsdist is one. (It may share a code 
base with one of those other projects, not sure.)

dnsdist does not do rpz; the backend needs to do that; dnsdist being 
'just' an advanced load balancer / "proxy".

dnsdist does do dnstap though: https://dnsdist.org/reference/dnstap.html

Greets,
  Jeroen



From peter.van.dijk at powerdns.com  Mon Mar 15 21:56:00 2021
From: peter.van.dijk at powerdns.com (Peter van Dijk)
Date: Mon, 15 Mar 2021 22:56:00 +0100
Subject: [DNSfirewalls] [cmikk@fsi.io: [dnstap] (PR) Adding response
 policy information in dnstap]
In-Reply-To: <c00f87de-4dc3-283f-7c0e-77a0f788f65a@massar.ch>
References: <20210315183330.t3hadmpvmrbzooyk@family.redbarn.org>
 <0a54b0f4-f85b-7ad1-efe2-741c4add7c9a@deteque.com>
 <20210315204000.5tyr5ir6hnmullmz@family.redbarn.org>
 <CAH1iCiriEOWuPZ5qszcLcPcLB9Kj-ZA4__BF0bLbVfi4PFHq-Q@mail.gmail.com>
 <c00f87de-4dc3-283f-7c0e-77a0f788f65a@massar.ch>
Message-ID: <14815f91174e91b982426281a4188a37aa932590.camel@powerdns.com>

On Mon, 2021-03-15 at 22:25 +0100, Jeroen Massar wrote:
> On 2021-03-15 21:43, Brian Dickson wrote:
> [..]
>  >     if anybody uses a dns server that's not one of those, please feel to
>  >     reach out
>  >     to us so that we can add their name to the relevant web page
>  >     (directory) and
>  >     reach out to them about joining the relevant mailing list.
>  >
>  >
>  > I am not 100% sure, but I think dnsdist is one. (It may share a code 
> base with one of those other projects, not sure.)
> 
> dnsdist does not do rpz; the backend needs to do that; dnsdist being 
> 'just' an advanced load balancer / "proxy".
> 
> dnsdist does do dnstap though: https://dnsdist.org/reference/dnstap.html

Replying to both of you, just collecting the facts:
* dnsdist does not do RPZ, but some people convert RPZs into other
things that dnsdist can consume (like CDB or LMDB databases)
* dnsdist does share some code with PowerDNS Auth and Recursor
* dnsdist does have dnstap
* PowerDNS Recursor has both RPZ and dnstap and users have shown
interest in changes like cmikk's

I've poked my coworkers to have a look at cmikk's changes. (I believe
one of them already found a typo in an earlier emailed version.)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/


From m3047 at m3047.net  Fri Mar 19 18:47:14 2021
From: m3047 at m3047.net (Fred Morris)
Date: Fri, 19 Mar 2021 11:47:14 -0700
Subject: [DNSfirewalls] Using DnsTap to populate a reverse DNS RPZ
Message-ID: <b2c698e2-cba4-0ed6-78bd-710079749ccc@m3047.net>

I figured I'd come here to these two lists for feature criticism/input
because this is where all the cool kids for both DnsTap and RPZ hang out...

I wrote ShoDoHFlo (https://github.com/m3047/shodohflo) and one of the
things it lays bare are the shortcomings of reverse DNS (PTR records).
But basically what I've written there are the necessary pieces for
dynamically populating a reverse lookup zone to point back to the
initial FQDN queried. It occurs to me that if it was an RPZ, then it
would override the reverse lookups for whatever (sparse) content it
contained.

That's the initial thought in a nutshell. I'm here for your criticism
and input on use cases and implementation architecture.

The use case in my mind is that I can (literally) do

    dig -x 10.0.0.1

and it gives me back actual.example.com when in reality

    actual.example.com. CNAME 10-0-0-1.example.com.
    10-0-0-1.example.com. A 10.0.0.1

I mean "literally" as I see this as a command line tool, although it
could also be accessed programmatically. I suppose I'm also thinking
that tools which support a -n option (tshark, iptables, etc.) to disable
the feature would avail themselves of it to tell me what the initial
FQDN was, in the absence of said option, as a bonus.

In some cases there might also be a legitimate PTR record. In other
cases there might be multiple initial FQDNs. So what would be best to
populate the zone with:

  * Just the initial FQDN?
  * Initial FQDN and legitimate PTR?
  * Multiple initial FQDNs or just one? (Which one?)
  * Intermediate FQDNs in a CNAME chain? (Or a reverse CNAME chain in
    the reverse lookup zone?)
  * All the things?

Any suggestions for encoding a desire for a different flavor of any of
the above?

What about architecture: I already have flow going to Redis. What would
be the most accessible architecture, knowing that that might be
different for someone already running the ShoDoHFlo agents and someone
who is not:

  * A periodic task running against the existing Redis database?
  * A daemon monitoring a Redis queue?
  * A brand new agent which performs the dynamic updates itself?


As far as drawbacks: this interferes with the reverse lookups which
occur for some authentication and logging schemes, most commonly with
email and web requests. Any others I'm missing? Any suggestions for
mitigations? I've thought of two mitigations:

  * Use a different view or server without the reverse zone for services
    utilizing such schemes.
  * Exclude DNS queries produced by such services when populating the
    reverse zone.

I note the two are not mutually exclusive.


You can respond here or privately, or open an issue on GitHub.

Thanks in advance...

--

Fred Morris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnsfirewalls/attachments/20210319/7ab8b111/attachment.htm>

From afried at deteque.com  Fri Mar 19 19:33:30 2021
From: afried at deteque.com (Andrew Fried)
Date: Fri, 19 Mar 2021 15:33:30 -0400
Subject: [DNSfirewalls] Using DnsTap to populate a reverse DNS RPZ
In-Reply-To: <b2c698e2-cba4-0ed6-78bd-710079749ccc@m3047.net>
References: <b2c698e2-cba4-0ed6-78bd-710079749ccc@m3047.net>
Message-ID: <13f8a94f-92bb-0ee7-3e79-a624b256ad4e@deteque.com>

Fred,

In a perfect world every IP would have a one to one matching PTR record.
 In the real world this isn't often the case.

You will often see generic 4-3-2-1.some.domain ptr records despite an
actual host/domain points at the ip, particularly in cloud environments.

Furthermore, a rewrite triggered by some query won't necessarily match
the ptr record, especially if the query was for a hostname but the
rewrite triggered, for example, on a bad nameserver.

The only useful logs I've found over time are the actual rewrite logs
that bind or unbound generates.

Andrew


On 3/19/21 2:47 PM, Fred Morris wrote:
> I figured I'd come here to these two lists for feature criticism/input
> because this is where all the cool kids for both DnsTap and RPZ hang out...
> 
> I wrote ShoDoHFlo (https://github.com/m3047/shodohflo) and one of the
> things it lays bare are the shortcomings of reverse DNS (PTR records).
> But basically what I've written there are the necessary pieces for
> dynamically populating a reverse lookup zone to point back to the
> initial FQDN queried. It occurs to me that if it was an RPZ, then it
> would override the reverse lookups for whatever (sparse) content it
> contained.
> 
> That's the initial thought in a nutshell. I'm here for your criticism
> and input on use cases and implementation architecture.
> 
> The use case in my mind is that I can (literally) do
> 
>     dig -x 10.0.0.1
> 
> and it gives me back actual.example.com when in reality
> 
>     actual.example.com. CNAME 10-0-0-1.example.com.
>     10-0-0-1.example.com. A 10.0.0.1
> 
> I mean "literally" as I see this as a command line tool, although it
> could also be accessed programmatically. I suppose I'm also thinking
> that tools which support a -n option (tshark, iptables, etc.) to disable
> the feature would avail themselves of it to tell me what the initial
> FQDN was, in the absence of said option, as a bonus.
> 
> In some cases there might also be a legitimate PTR record. In other
> cases there might be multiple initial FQDNs. So what would be best to
> populate the zone with:
> 
>   * Just the initial FQDN?
>   * Initial FQDN and legitimate PTR?
>   * Multiple initial FQDNs or just one? (Which one?)
>   * Intermediate FQDNs in a CNAME chain? (Or a reverse CNAME chain in
>     the reverse lookup zone?)
>   * All the things?
> 
> Any suggestions for encoding a desire for a different flavor of any of
> the above?
> 
> What about architecture: I already have flow going to Redis. What would
> be the most accessible architecture, knowing that that might be
> different for someone already running the ShoDoHFlo agents and someone
> who is not:
> 
>   * A periodic task running against the existing Redis database?
>   * A daemon monitoring a Redis queue?
>   * A brand new agent which performs the dynamic updates itself?
> 
> 
> As far as drawbacks: this interferes with the reverse lookups which
> occur for some authentication and logging schemes, most commonly with
> email and web requests. Any others I'm missing? Any suggestions for
> mitigations? I've thought of two mitigations:
> 
>   * Use a different view or server without the reverse zone for services
>     utilizing such schemes.
>   * Exclude DNS queries produced by such services when populating the
>     reverse zone.
> 
> I note the two are not mutually exclusive.
> 
> 
> You can respond here or privately, or open an issue on GitHub.
> 
> Thanks in advance...
> 
> --
> 
> Fred Morris
> 
> 
> _______________________________________________
> DNSfirewalls mailing list
> DNSfirewalls at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/dnsfirewalls
> 

-- 
Andrew Fried
afried at deteque.com
+1.703.667.4050

From m3047 at m3047.net  Fri Mar 19 19:57:42 2021
From: m3047 at m3047.net (Fred Morris)
Date: Fri, 19 Mar 2021 12:57:42 -0700 (PDT)
Subject: [DNSfirewalls] Using DnsTap to populate a reverse DNS RPZ
In-Reply-To: <13f8a94f-92bb-0ee7-3e79-a624b256ad4e@deteque.com>
References: <b2c698e2-cba4-0ed6-78bd-710079749ccc@m3047.net>
 <13f8a94f-92bb-0ee7-3e79-a624b256ad4e@deteque.com>
Message-ID: <alpine.LSU.2.21.2103191238210.6870@flame.m3047>

This is a tactical defender-centric tool, intended to augment everyday 
tools' usability, e.g. "iptables -L -v". It's an RPZ, but it's not a ban 
hammer.

On Fri, 19 Mar 2021, Andrew Fried wrote:
> [...]
> You will often see generic 4-3-2-1.some.domain ptr records despite an
> actual host/domain points at the ip, particularly in cloud environments.

Exactly the point!

> Furthermore, a rewrite triggered by some query won't necessarily match
> the ptr record, especially if the query was for a hostname but the
> rewrite triggered, for example, on a bad nameserver.

As much sense as I can make out of that, not sure it applies since these 
tools are blessedly stupid or at least unimaginative and are going to do 
"normal, unsurprising" PTR lookups. Therefore it would be surprising for 
one of those queries to stumble upon a nameserver.

The objective is also not to import "all the things", although I really 
hadn't thought about expiry. This is implicitly about "did someone here 
resolve something to this address?"

--

Fred Morris