O

d wersji 9.8.1 serwera BIND dostępny jest mechanizm DNS RPZ (ang. Domain Name Service Response Policy Zones). Główną motywacją do stworzenia tej funkcji była ochrona użytkowników przed zagrożeniami w internecie związanymi z złośliwymi domenami, nazwami hostów lub innymi serwerami nazw. Cyberprzestępcy zwykle używają tych samych domen na wielu ofiarach, dopóki nie zostaną im odebrane. Niestety zdolność branży bezpieczeństwa internetowego w kwestii likwidacji infrastruktury przestępczej u rejestratorów domen, dostawcach hostingu lub dostawcach usług internetowych z różnych czynników nie zawsze jest możliwa. Korzystając z RPZ administrator sieci może wdrożyć własne zasady ochrony przed niebezpiecznymi domenami w oparciu o reputację zebraną od dostawców usług bezpieczeństwa niemal w czasie rzeczywistym.

Jak obliczenia – to rozproszone.
Jak wiedza – to scentralizowana.

CERT Polska wspólnie z operatorami telekomunikacyjnymi rozpoczął publikować listę domen wykorzystywanych do nadużyć – jak możemy przeczytać w komunikacie – każdy może ją pobrać i wdrożyć w swoich systemach bezpieczeństwa do blokady złośliwych treści. Rolą operatorów, którzy przystąpili do współpracy jest uniemożliwienie dostępu swoim użytkownikom do zidentyfikowanych i przeanalizowanych przez CERT domen.

Jak wspomniałem RPZ pozwala operatorom rekurencyjnych serwerów DNS (np. działających u dostawcy usług lub w naszym środowisku sieciowym) na przepisywanie odpowiedzi zwracanych przez autorytatywne serwery DNS. Jest to mechanizm podobny do tego, który posiada unbound w swoich dyrektywach local-zone oraz local-data z tą różnicą, że RPZ pozwala nam replikować strefy (od nadrzędnych do podrzędnych serwerów DNS) oferując w ten sposób swoje wpisy większej liczbie serwerów nazw. Dla przykładu stworzymy strefę RPZ na podstawie listy dostarczonej przez zespół CERT Polska i włączymy ją na serwerze bind pełniącego rolę serwera cache DNS dla naszej sieci lokalnej. Poniżej znajduje się prosty skrypt napisany w języku python, który na podstawie listy z pliku tekstowego stworzy nam strefę RPZ i będzie ją aktualizował za każdym uruchomieniem:

#!/usr/bin/env python3

# requests==2.24.0

import time
import requests
from datetime import datetime

serial = datetime.now().strftime("%y%m%d%H%M")
hole = "https://hole.cert.pl/domains/domains.txt"

status = True
while status:
    domains = requests.get(hole)
    if (domains.status_code != 200):
        time.sleep(5)
    else:
       status = False

template = """$TTL 60
@       IN      SOA     localhost. root.localhost. (
                        {serial}   ; serial
                        1H  ; refresh
                        1H  ; retry
                        1H  ; expiry
                        1H) ; minimum
@               IN    NS    localhost.

"""
variables = {
  "serial": serial
}

with open("rpz.cert.db","w") as dnsfile:
    dnsfile.write(template.format(**variables))
    dnsfile.close()

with open("rpz.cert.db","a") as dnsfile:
    for entry in domains.text.splitlines():
        print(entry + "   CNAME   .", file=dnsfile)
    dnsfile.close()

Po uruchomieniu skryptu holetodns.py powinniśmy otrzymać plik o nazwie rpz.cert.db:

$TTL 60
@       IN      SOA     localhost. root.localhost. (
                        2011102010   ; serial
                        1H  ; refresh
                        1H  ; retry
                        1H  ; expiry
                        1H) ; minimum
@               IN    NS    localhost.

aplikacja-lnpost.com   CNAME   .
0lx.group   CNAME   .
allegro.su   CNAME   .
...

Stworzony plik jest naszą strefą RPZ, którą klienci nie będą odpytywać bezpośrednio, ale nasz serwer będzie odpowiadał na zdefiniowane w niej wpisy zgodnie z naszą polityką. Definicję strefy dodajemy tak, jak każdą inną tylko wyłączamy dla niej zupełnie rekurencyjne zapytania:

zone "rpz" {
      type master;
      file "/etc/bind/zones/rpz.cert.db";
      allow-query { none; };
};

Jeśli nasz serwer oprócz pamięci podręcznej dla domen internetowych pełni rolę nadrzędną możemy pozwolić na transfery strefy do jego serwerów podrzędnych za pomocą opcji:

      allow-transfer { $IP_NS2; $IP_NS3 };

Ostatnim krokiem jest włączenie obsługi Response Policy Zones:

options {
        ...
        response-policy { zone "rpz"; };
        ...
};

I przeładowanie konfiguracji serwera:

Nov 10 23:24:15 darkstar named[3013]: zone localhost/IN: loaded serial 2
Nov 10 23:24:15 darkstar named[3013]: (re)loading policy zone 'rpz' 
                                      changed from 0 to 5259 qname, 
                                      0 to 0 nsdname, 0 to 0 IP, 
                                      0 to 0 NSIP, 0 to 0 CLIENTIP entries
Nov 10 23:24:15 darkstar named[3013]: zone rpz/IN: loaded serial 2011102010
Nov 10 23:24:15 darkstar named[3013]: all zones loaded

Spytajmy teraz z komputera w sieci lokalnej korzystającego tylko i wyłącznie z w/w serwera DNS o domenę allegro.su:

agresor@johnny5:~$ dig allegro.su

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> allegro.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37653
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: cc5f554ee15d44cad2c9ba4e5fab1661e88f820670f4b533 (good)
;; QUESTION SECTION:
;allegro.su. IN A

;; ADDITIONAL SECTION:
rpz. 60 IN SOA localhost. root.localhost. 2011102010 3600 3600 3600 3600

;; Query time: 2 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Tue Nov 10 23:38:25 CET 2020
;; MSG SIZE  rcvd: 120

agresor@johnny5:~$ host allegro.su
Host allegro.su not found: 3(NXDOMAIN)

Otrzymaliśmy informację o braku takiej domeny, co oczywiście nie jest prawdą, ale to dla bezpieczeństwa użytkownika serwer go “okłamał”:

Nov 10 23:44:20 darkstar named[3013]: client @0x7fdcf8629f60 10.0.0.2#15355 (allegro.su): 
                rpz QNAME NXDOMAIN rewrite allegro.su via allegro.su.rpz

Jak potraktujemy złośliwe domeny – zależy od nas – możemy zwracać dla nich: kod NXDOMAIN – non-existent domain – domena nie istnieje, NOERROR – żadnych danych lub przekierować ją adres, gdzie będzie strona informacyjna o zagrożeniu. Informacje o domenach aktualizowane są, co 5 minut dlatego nie ma sensu aktualizacji i pobierania listy częściej. Po ponownym uruchomieniu skryptu zostanie podbity numer seryjny strefy (serial), który umożliwa jej przeładowanie i wprowadzenie zmian:

rndc reload rpz

Nov 11 23:49:43 darkstar named[3013]: received control channel command 'reload rpz'
Nov 11 23:49:44 darkstar named[3013]: (re)loading policy zone 'rpz' 
                                      changed from 5259 to 5259 qname, 
                                      0 to 0 nsdname, 0 to 0 IP,
                                      0 to 0 NSIP, 0 to 0 CLIENTIP entries
Nov 11 23:49:44 darkstar named[3013]: zone rpz/IN: loaded serial 2011102015

Do powyższego skryptu możemy dodać jeszcze naszą listę – w formie osobnych wpisów lub osobnej strefy RPZ, która będzie zawierała nasze uniwersalne definicje (jeśli takich potrzebujemy). Istnieje również możliwość podpięcia swojego serwera DNS, jako podrzędnego dla danej strefy RPZ, która jest obsługiwana przez zewnętrzne serwisy bezpieczeństwa. Gdy tylko serwer nadrzędny dokona aktualizacji takiej listy – nasz pobierze ją od niego i wprowadzi zmiany.

Więcej informacji: Building DNS Firewalls with Response Policy Zones (RPZ), DNS Response Policy Zones, API listy ostrzeżeń CERT Polska