How reliable is RPZ in production? I'm seeing flakiness in testing.
Anne Bennett
anne at encs.concordia.ca
Wed Jan 7 19:38:12 UTC 2015
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.ca CNAME rpz-passthru.
*.concordia.ca CNAME rpz-passthru.
205.132.in-addr.arpa CNAME 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.ca CNAME 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
anne at encs.concordia.ca +1 514 848-2424 x2285
More information about the bind-users
mailing list