Re: How reliable is RPZ in production? I'm seeing flakiness in testing.
John, thanks for helping.
> You might start things out by giving us your bind version
9.10.1-P1
> and your response-policy {} config.
response-policy {
zone "rpz-whitelist" policy given;
zone "rpz-quarantine" policy given;
zone "rpz-phish" policy given;
zone "rpz-malware" policy given;
zone "rpz-isc-suspicious" policy given;
zone "rpz-mwdoms-doms" policy given;
zone "rpz-mwdoms-hosts"policy given;
};
At the moment, only the first four contain any records
aside from SOA and NS.
> Also print out the exact rules (one or two
> examples should suffice) you're using for client quarantining --
> that'll help narrow things down.
"rpz-whitelist" has QNAME/passthru entries for names in
my domain and for patch sites. It also has rpz-ip/passthru
entries for IP addresses of the same. To show a few examples,
first for our University's public network:
concordia.caCNAME rpz-passthru.
*.concordia.ca CNAME rpz-passthru.
205.132.in-addr.arpaCNAME rpz-passthru.
*.205.132.in-addr.arpa CNAME rpz-passthru.
16.0.0.205.132.rpz-ip CNAME rpz-passthru.
... and for a patch site:
12.0.0.0.23.rpz-ip CNAME rpz-passthru. ; Akamai
(Note that I added the in-addr.arpa lines just lately, and
haven't re-run the tests with those in place, but those weren't
the names I was testing for; I was testing with nslookup.)
"rpz-quarantine" had, when I was testing, my workstation's address:
32.192.47.205.132.rpz-client-ip CNAME serv-quarantine.encs.concordia.ca.
"rpz-phish" and "rpz-malware" have a few test entries, for example:
nonexistent.porcupine.caCNAME serv-fishnet.encs.concordia.ca.
*.nonexistent.porcupine.ca CNAME serv-fishnet.encs.concordia.ca.
emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
*.emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
> Also, how are you publishing to your
> client quarantine zones? Presumably you're using some sort of DDNS
> publishing that gets triggered when a client does something
> suspicious.
No, actually, so far it's all manual (edit the zone file and
issue a reload), and the first four will remain that way.
The last three will contain data we obtain automatically from
offsite, but my download-parse-update-reload script will do
essentially the same as my manual operation. We don't use
DDNS at all.
I'm going to re-run my tests with a fresh mind (I last tested
before I took a vacation in December, and I needed that
vacation!), though I find it hard to see what I could possibly
have done wrong that would have the nameserver changing its
responses to me without the data having been touched.
I'll report back with my new test results.
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How reliable is RPZ in production? I'm seeing flakiness in testing.
On 06/01/15 22:52, Anne Bennett wrote: I don't know what to make of this; it looks as though the technology is several years old, and my experience with ISC bind is usually excellent. Has anyone else encountered this type of flakiness? No, but we're not using client-ip RPZ, just qname-based blacklists. I've had a couple of occurrences of runaway CPU use triggered by a large RPZ AXFR, but no-one seems to believe me when I bring it up here, so I've stopped bothering :o/ But we certainly haven't see the kind of sporadic issue you describe. It might be that the client-ip stuff is newer? Not sure how you'd debug it. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How reliable is RPZ in production? I'm seeing flakiness in testing.
Hi Anne,
We've been using RPZ in production for over six months, and haven't
had any serious issues. We haven't encountered this specific type of
flakiness, but then again, it's likely our configs and bind versions
aren't the same either: we do our quarantining at layer 2.
You might start things out by giving us your bind version and your
response-policy {} config. Also print out the exact rules (one or two
examples should suffice) you're using for client quarantining --
that'll help narrow things down. Also, how are you publishing to your
client quarantine zones? Presumably you're using some sort of DDNS
publishing that gets triggered when a client does something
suspicious.
John
--
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
On Tue, Jan 6, 2015 at 5:52 PM, Anne Bennett wrote:
> I'm playing with RPZ with a view to both quarantining internal
> compromised or vulnerable hosts, and capturing attempts at
> communication with known external bad hosts. I start with a
> fairly extensive whitelist, to avoid "lying" about any of my own
> hosts, and to give truthful answers for patch sites, so that my
> users can patch their systems even when otherwise quarantined.
>
> The masters for my RPZs do not themselves use the zones
> for policy (nor do they recurse on queries). However the
> nameservers that do recursive resolution for my network are
> slaves for those RPZs, and *do* use them for policy.
>
> My set-up works, but sporadically - it's as though the RPZs wink
> in and out of use for no apparent reason, even when I'm not
> changing the data. At one point while testing last December,
> my by-client-IP test quarantine rule just stopped matching
> (based on no logged hits, and no redirection of my queries
> from the quarantined host). Only a restart of named on the
> resolver brought the quarantine back, but then the whitelist
> worked only partially.
>
> I don't know what to make of this; it looks as though the
> technology is several years old, and my experience with ISC
> bind is usually excellent. Has anyone else encountered this
> type of flakiness?
>
> If not, any advice about how to debug this?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
How reliable is RPZ in production? I'm seeing flakiness in testing.
Happy New Year, folks. I posted last December to dnsfirewalls, but I'm told that RPZ is no longer particularly new, and I'd be more likely to get feedback here. So here goes... I'm playing with RPZ with a view to both quarantining internal compromised or vulnerable hosts, and capturing attempts at communication with known external bad hosts. I start with a fairly extensive whitelist, to avoid "lying" about any of my own hosts, and to give truthful answers for patch sites, so that my users can patch their systems even when otherwise quarantined. The masters for my RPZs do not themselves use the zones for policy (nor do they recurse on queries). However the nameservers that do recursive resolution for my network are slaves for those RPZs, and *do* use them for policy. My set-up works, but sporadically - it's as though the RPZs wink in and out of use for no apparent reason, even when I'm not changing the data. At one point while testing last December, my by-client-IP test quarantine rule just stopped matching (based on no logged hits, and no redirection of my queries from the quarantined host). Only a restart of named on the resolver brought the quarantine back, but then the whitelist worked only partially. I don't know what to make of this; it looks as though the technology is several years old, and my experience with ISC bind is usually excellent. Has anyone else encountered this type of flakiness? If not, any advice about how to debug this? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
