Data exfiltration using DNS RPZ

Blason R

unread,

Jun 17, 2018, 11:44:03 AM6/17/18

to bind-users

Hi Team,

Can someone please guide if DNS exfiltration techniques can be identified using DNS RPZ? Or do I need to install any other third party tool like IDS to identify the the DNS beacon channels.

Has anyone used DNS RPZ to block/detect data exfiltration?

Sten Carlsen

unread,

Jun 17, 2018, 12:44:38 PM6/17/18

to bind-...@lists.isc.org

Interesting, the Dnssec records with their by definition random and large content seems to be the most interesting vehicle, at least at first sight.

Will e.g. the google DNS server or any other resolver deliver and fetch this data? At the moment I can't think of any reason it should not do so.

To really block this, I think you would need to actually verify the correctness of the data.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

Vadim Pavlov

unread,

Jun 17, 2018, 12:46:56 PM6/17/18

to Blason R, bind-users

Hi,

RPZ is just a simple feature to block/log/redirect DNS requests. It doesn't analyse DNS requests & responses and a client behaviour.
So RPZ can block a domain which used for DNS Exfil/Infil/Tunneling but to detect Exfiltration you should to use 3rd party tools/software (e.g. Infoblox Threat Insight).
+ do not forget that "qname-wait-recurse" should be switched off and a RPZ with such domains must be before (e.g. first) by order any zone which contains IP/NS based rules.

Vadim

Vadim Pavlov

unread,

Jun 17, 2018, 12:52:52 PM6/17/18

to Sten Carlsen, bind-...@lists.isc.org

DNSSEC can be used for infiltration/tunneling (when you get data from a DNS servers) but there is a catch that such requests can be easily dropped.

Vadim

On 17 Jun 2018, at 09:44, Sten Carlsen <st...@s-carlsen.dk> wrote:

Interesting, the Dnssec records with their by definition random and large content seems to be the most interesting vehicle, at least at first sight.
Will e.g. the google DNS server or any other resolver deliver and fetch this data? At the moment I can't think of any reason it should not do so.
To really block this, I think you would need to actually verify the correctness of the data.

On 17-06-2018 08.43, Blason R wrote:
Hi Team,

Can someone please guide if DNS exfiltration techniques can be identified using DNS RPZ? Or do I need to install any other third party tool like IDS to identify the the DNS beacon channels.

Has anyone used DNS RPZ to block/detect data exfiltration?
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

_______________________________________________

Grant Taylor

unread,

Jun 17, 2018, 1:00:59 PM6/17/18

to bind-...@lists.isc.org

On 06/17/2018 09:43 AM, Blason R wrote:
> Can someone please guide if DNS exfiltration techniques can be
> identified using DNS RPZ?

I don't think that Response Policy *Zone* can do what you want to do.
(I've often wondered about this my self and have spent some time
thinking about it.)

> Or do I need to install any other third party tool like IDS to identify
> the the DNS beacon channels.

I don't think you need to replace BIND with another tool.

BIND has a relatively new feature called Response Policy *Service* that
I think is well suited to this.

I think of BIND's RPS much like I do Sendmail's Milter or Cisco' WCCP,
in that they provide a way for BIND (Sendmail, Cisco routers) to ask
something else to do the filtering for them.

Queries come to BIND and it serves them mostly like normal with the
exception being that it gives the RPS daemon an opportunity to do some
more intelligent filtering. The RPS daemon can (theoretically) do some
analysis on the queries including number of queries (to a given
(sub)domain), the length of the queries, the type and length of the
reply, etc.

In short, RP*S* allows active processing to be done on the query. Where
as RP*Z* is only doing a simple textual match

BIND includes the RPS interface for other RPS daemons to interact with.
I believe there is at least one commercial RPS daemon. I'm not aware of
any open source RPS daemons (yet).

> Has anyone used DNS RPZ to block/detect data exfiltration?

I don't think that RPZ is a good candidate for this, given it's textual
matching. I do think that RPS will be a MUCH better match for this as
it matures.

--
Grant. . . .
unix || die

Grant Taylor

unread,

Jun 17, 2018, 1:06:56 PM6/17/18

to bind-...@lists.isc.org

On 06/17/2018 10:52 AM, Vadim Pavlov via bind-users wrote:
> DNSSEC can be used for infiltration/tunneling (when you get data from a
> DNS servers) but there is a catch that such requests can be easily dropped.

Will you please elaborate and provide a high level overview of how
DNSSEC can be used for infiltration or tunneling?

It is my understanding that DNSSEC is just a cryptographic hash that
clients can verify by calculating their own hash over the results for
the same query. As such, nothing is actually hidden. 1) You know the
outbound query, 2) you know the inbound reply + DNSSEC signature, 3) you
know the algorithm used to generate the hash, and 4) you validate the
DNSSEC signature. So, what about that is hidden?

I fail to see how DNSSEC can be a covert channel, even if there is
manipulation in what key is used. Unless you're expiring & modifying
the ZSK about once a second so that you can change things and try to
hide using something like steganography. Even then, I'm not sure how
well that would work.

Vadim Pavlov

unread,

Jun 17, 2018, 1:19:06 PM6/17/18

to Grant Taylor, bind-...@lists.isc.org

Just to be more clear. DNSSEC records can contain any content and can be used for infiltration/tunneling.
E.g. If you request DNSKEY record (you can encode your request in fqdn) you will get it exactly "as is". Intermediate DNS servers do not validate the records.
So instead of "standard/usual" TXT records you can use DNSKEY to pass data from a DNS remote server.

Vadim

Grant Taylor

unread,

Jun 17, 2018, 1:26:38 PM6/17/18

to bind-...@lists.isc.org

On 06/17/2018 11:18 AM, Vadim Pavlov via bind-users wrote:
> Just to be more clear. DNSSEC records can contain any content and can
> be used for infiltration/tunneling.

Ah. I think I see.

> E.g. If you request DNSKEY record (you can encode your request in fqdn)
> you will get it exactly "as is". Intermediate DNS servers do not validate
> the records.

You aren't talking about using the DNSSEC mechanisms to {in,ex}filtrate
data as much as you are talking about {ab}using the resource records
that DNSSEC uses as a vector to hide data.

> So instead of "standard/usual" TXT records you can use DNSKEY to pass
> data from a DNS remote server.

ACK

Thank you for the explanation.

Blason R

unread,

Jun 17, 2018, 1:49:06 PM6/17/18

to Grant Taylor, bind-users

Excellent Inputs guys and thanks a ton for your feedbacks. RPS is quite interesting and which one is commercial offering for the same?

Grant Taylor

unread,

Jun 17, 2018, 2:01:20 PM6/17/18

to bind-...@lists.isc.org

On 06/17/2018 11:48 AM, Blason R wrote:
> Excellent Inputs guys and thanks a ton for your feedbacks.

You're welcome.

> RPS is quite interesting and which one is commercial offering for
> the same?

The best (read: quick) I have is Paul Vixie's email to OARC's
DNS-Operations mailing list.

Link - [dns-operations] DNS RPS (response policy service) API
-
https://lists.dns-oarc.net/pipermail/dns-operations/2017-October/016860.html

I suspect that will give you a few threads to pull at.

I know that I've exchanged a few emails with Paul and he's always been
quite helpful. I beet he'd be happy to point you to his company's
commercial product.