6.12. Sikret-DNS

6.12.1. Indsamling af oplysninger om serverens opsætning før "chroot".

Der findes flere distributioner og de placerer filer på hver sin måde. Det ville være for snævert hvis denne vejledning, var lavet således at den kun kan bruges til én af disse distributioner. For at sætte serveren op skal man kende navnet og placeringen på de relevante filer i hver distribution. Vi nøjes med 4 forskellige distributioner i håb om at det rammer tilstrækkelig bredt.

Vi skal bruge stinavnet på opstartsfilen der anvendes til at starte og stoppe processen.

• Red Hat: /etc/rc.d/init.d/named

• Debian: /etc/init.d/bind9

• Mandrake: /etc/rc.d/init.d/named

• SuSE: /etc/init.d/named

Placeringen af den overordnede opsætningsfil. Variablen KONFIL sættes lig med denne mappe, dog uden det første skråstreg.

• konfil=

• Red Hat, Mandrake og SuSE: etc/named.conf

• Debian: etc/bind/named.conf

Serverens forvalgte placering af zone filer. Denne mappe nævnes som regel i den overordnede opsætningsfil ( se eksemplet i Afsnit 6.10.1) og den er angivet som var/named i det følgende eksempel:

 options { directory "/var/named";} 

Variablen OPTDIR sættes lig med denne mappe, dog uden det første skråstreg.

• optdir=

• Red Hat, Mandrake og SuSE: var/named

• Debian: var/cache/bind

En mappe hvor masterzone filer normalt placeres. Denne mappe nævnes som regel i den overordnede opsætningsfil og den er angivet som etc/bind i det følgende eksempel:

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

Variablen MASTERZD sættes lig med denne mappe, dog uden det første skråstreg.

• masterzd=

• Red Hat, Mandrake og SuSE: var/named

• Debian: etc/bind

Det er et potentielt sikkerhedshul at lægge sine "master zone"-filer i mapper som selve processen har skriverettigheder til idet en angriber derved kunne ændre dem.

En mappe hvor processen har skriveadgang og hvor der normalt placeres slave-zone-filer. Denne mappe nævnes undtagelsesvis i den overordnede opsætningsfil og den er angivet som etc/named/slave i det følgende eksempel:

  zone "intranet" in {
  type slave;
  file "/etc/named/slave/intranet";
  masters { 192.168.0.1; };

Den forvalgte mappe kan sagtens bruges her hvis master filerne lægges i en anden mappe. Variablen SLAVEZD sættes lig med denne mappe, dog uden det første skråstreg.

• slavezd=

• Red Hat, Mandrake og SuSE: var/named

• Debian: var/cache/bind

For at få variabler med fornuftige værdier skal man køre det følgende som passer for den enkelte distribution.

I Red Hat, Mandrake og SuSE:

export konfil=etc/named.conf
export optdir=var/named
export masterzd=var/named
export slavezd=var/named/slave 

I Debian:

export konfil=etc/bind/named.conf
export optdir=var/cache/bind
export masterzd=etc/bind
export slavezd=var/cache/bind

Der kan opstå forvirring vedrørende placeringer af filer og mapper hvilket nok ikke er særlig underligt idet der grundlæggende set er tale om 3 forskellige filsystemrødder, nemlig systemets egentlige rod / , den nye rod der etableres ved "chroot" og som er angivet ved variablen $JAIL samt DNS-serverens forvalgte mappe angivet bl.a. ved variablen $OPTDIR.

Det kan forøge forvirringen at DNS-serveren fortolker relative filnavne i forhold til serverens forvalgte mappe mens absolutte filnavne fortolkes i forhold til den nye rod der etableres ved "chroot".

Variablerne OPTDIR , MASTERZD samt SLAVEZD skal allesammen fortolkes i forhold til filsystemets rod, nemlig / eller $JAIL.

Et fiktivt eksempel hvor variablen SLAVEZD er forskellig fra værdien i den overordnede opsætningsfil.

export slavezd=var/named/slave

Mens der i den overordnede opsætningsfil bl.a. står:

  options { directory "/var/named";
  };
  zone "intranet" in {
  type slave;
  file "slave/intranet";
  masters { 192.168.0.1; };
};

Variablerne $OPTDIR , MASTERZD samt SLAVEZD skal allesammen fortolkes i forhold til filsystemets rod / eller $JAIL.

6.12.2. DNS-serverens brugernavn

Nogle distributioner opretter automatisk en bruger der svarer til DNS-serveren. Et hurtigt blik på /etc/passwd kan afsløre en bruger der hedder f.eks. named, bind eller dns og så kan man lave de nødvendige rettelser i kommandoerne. Her antages at brugeren hedder named samt at gruppen hedder ligeledes named.

Hvis denne bruger ikke findes i forvejen, kan den i Debian oprettes med den følgende kommando:

[root@linus /root]# adduser --system --group --home /opt/chroot/named named
Adding system user named...
Adding new group named (116).
Adding new user named (116) with group named.
Creating home directory /opt/chroot/named.

6.12.3. Tilføjelse til filsystemtabellen

DNS-serveren bruger 3 /dev filer. Disse er log, null, og random. For hver af disse /dev filer skal der oprettes en forbindelse til de tilsvarende filer i den isolerede del af filsystemet. Når det er gjort kan serveren skrive til syslog.

Tidligere er der lavet forskellige krumspring for at DNS-serveren kan skrive til syslog. Med version 2.4 af kernen kom muligheden for at løse dette let og elegant med kommandoen mount.

I det følgende er der givet 2 forskellige metoder for at opnå forbindelse til filerne i den isolerede del af filsystemet. I den første metode bruges en mount kommando for hver af disse /dev filer. Den første metode giver mulighed for at afprøve opsætningen men den vil være tabt ved genstart af computeren.

mount --bind /dev/log $JAIL/dev/log
mount --bind /dev/random $JAIL/dev/random
mount --bind /dev/null $JAIL/dev/null

Erfarne brugere vil vide at mount kommandoen også kan bruges i forbindelse med filsystemtabellen /etc/fstab og derved kan man opnå en varig opsætning af disse filer. Der tilføjes nogle linjer til filsystemtabellen (derfor er det tilrådeligt at man lige tager en kopi af denne fil idet den er meget vigtig for systemet). Dette gøres lettest med de følgende kommandoer:

export jail=/opt/chroot/named &&
cd /etc &&
cp --backup=t fstab fstab.orig &&
echo -e '/dev/log\t'$JAIL'/dev/log\tnone \t rw,bind \t 0 0' >>fstab &&
echo -e '/dev/null\t'$JAIL'/dev/null\tnone \t rw,bind \t 0 0' >>fstab &&
echo -e '/dev/random\t'$JAIL'/dev/random\tnone \t rw,bind \t 0 0' >>fstab

Ovenstående kommandoer er nok til at sætte computeren op så ændringerne er varige også ved genstart.

Hvis mappestrukturen er blevet opsat (Se Afsnit 6.12.4) , kan man med følgende kommando afprøve om dette fungerer som det skal:

[root@linus /root]#  
mount --all

Derpå vil kommandoen mount afsløre de interne forbindelser i kernen.

[root@linus /root]#  mount

/dev/log on /opt/chroot/named/dev/log type none (rw,bind)
/dev/null on /opt/chroot/named/dev/null type none (rw,bind)
/dev/random on /opt/chroot/named/dev/random type none (rw,bind)

6.12.4. Oprettelse af mappestruktur

Der oprettes en mappestruktur, til DNS-serveren hvori den skal køre isoleret. Set fra DNS-serveren vil denne mappestruktur udgøre hele serverens filsystem, og den vil således ikke kunne se den resterende del af filsystemet. Dette vil således også gælde for en eventuel angriber der har haft held med at tage kontrollen over DNS-processen.

I nedenstående eksempel oprettes mappestrukturen med roden /opt/chroot/named hvilket er i overensstemmelse med standarden for filhierarki i Linux ( for flere oplysninger om FHS se: http://www.pathname.com/fhs/). Hvis man ønsker en anden rod (feks. /chroot/named kan man blot ændre variablen $JAIL i starten af kommandoerne. Ligeledes kan man rette brugernavnet i kommandoerne så det svarer til det brugernavn DNS-processen skal køre som. De følgende kommandoer kan klippes og klistres med et par museklik ind i et terminalvindue hvor root allerede har logget ind:

export jail=/opt/chroot/named &&
export piddir=var/run &&
export lokaltid=etc/localtime &&
export unamed=named &&
export gnamed=named &&
mkdir -p $JAIL &&
cd $JAIL &&
mkdir -p dev $OPTDIR $PIDDIR $MASTERZD $SLAVEZD &&
cd / 
cp $LOKALTID $JAIL/$LOKALTID  &&
cd $JAIL/dev &&
touch log null random &&
mount --all &&
cd / &&
cp $KONFIL $JAIL/$KONFIL &&
cd $MASTERZD &&
find . | cpio -pm  $JAIL/$MASTERZD &&
cd $JAIL &&
chown $UNAMED.$GNAMED .  $PIDDIR $SLAVEZD &&
chmod 700 . .. &&
chattr +i  dev etc var $LOKALTID

Kommandoen i femte nederste linje, kopierer hele DNS-serverens opsætning til mappen $JAIL/$MASTERZD . Den tredje øverste linje sætter DNS-serveren som ejer af bl.a. mappen $JAIL , hvilket jo også er meget passende idé det jo er dens hjemmekatalog (det burde det i hvertfald være hvis alting gik godt i Afsnit 6.12.2). Den næstnederste linje siger adgang forbudt for uvedkommende. Den allersidste er kommandoen chattr der på et Linux filsystem (ext2, ext3 og evt. andre) kan sætte "immutable"-bitten på bestemte filer. Filer med denne bit sat, kan ikke ændres, omdøbes eller slettes. Dette er nødvendigt idet named brugeren ejer mappen $JAIL og har dermed ret til at omdøbe og slette enhver fil i denne mappe, uanset hvem ejer dem. Denne bit vil altså forhindre named brugeren i at omdøbe feks. etc mappen til noget andet og oprette en ny etc mappe med falske eller ændrede domæner. Dette kan named brugeren gøre uden videre hvis denne bit ikke er sat. Hvis en angriber opdager at denne bit ikke er sat, kan han/hun juble ligesom Benny i "The Julekalender" da han havde eksperimenteret med nissernes magiske bog og udbrød i ekstase: "Sikke muligheder man! Sikke muligheder!" Hvis man er i gang med at eksperimentere med denne opsætning, gør man dog klogest i at undgå denne bit idet den forbyder selv root-brugeren at slette eller ændre hele $JAIL mappen. Denne bit ("immutable"-bitten) skal resettes med kommandoen chattr -i før root kan ændre eller slette filer hvor den er sat. Så er folk blevet advaret.

Hvis der har været fejl i opsætningen eller kommandoerne kan man fjerne mappestrukturen med nogle eller alle af de følgende kommandoer og derpå kan man prøve endnu en gang at installere mappestrukturen. Som den Linuxkyndige læser vil se, er der sat to små sikkerhedsventiler på kommandoen rm -rf for det tilfælde at variablen &JAIL ikke findes.

umount $JAIL/dev/* &&
cd $JAIL &&
chattr -i  dev etc var $LOKALTID &&
cd /tmp &&
rm -rf $JAIL findesikke 

6.12.5. Parametre til bind-processen.

Hvis det er lykkedes at oprette mappestrukturen samt montere /dev filerne i foregående afsnit, er filsystemet klart til at isolere DNS-serveren og dermed også isolere en eventuel angriber.

Det eneste der mangler nu er at fortælle DNS-serveren at den skal isoleres i denne del af filsystemet og køre som en bestemt bruger. Tidligere versioner af DNS-serveren måtte genoversættes til formålet, men BIND version 9 kan bruges uden videre ved at tilføje nogle parametre til kommandolinjen. Disse parametre er:

• -u named processen skal køre som brugeren named i stedet for root.

• -t /opt/chroot/named processen skal isoleres i "chroot-jail" der er blevet klargjort.

Der tilføjes nogle linjer til opstartsfilerne:

opts="-u named -t /opt/chroot/named" &&
/usr/sbin/named $OPTS 

For at gøre opsætningen varig, kan ovenstående sættes ind i opstartsfilen.

I Red Hat ser opstartsfilen således ud med ovenstående ændringer:

   #!/bin/sh
   #
   # named           This shell script takes care of starting and stopping
   #                 named (BIND DNS server).
   #
   # chkconfig: - 55 45
   # description: named (BIND) is a Domain Name Server (DNS) \
   # that is used to resolve host names to IP addresses.
   # probe: true

   # Source function library.
   . /etc/rc.d/init.d/functions

   # Source networking configuration.
   . /etc/sysconfig/network

   # Check that networking is up.
   [ ${NETWORKING} = "no" ] && exit 0

   [ -f /usr/sbin/named ] || exit 0

   [ -f /etc/named.conf ] || exit 0

   retval=0

   # See how we were called.
   case "$1" in
   start)
   # Start daemons.
   echo -n "Starting named: "
# *** De foelgende linjer er udkommenteret for chroot
#   daemon named 
# *** De foelgende linjer er indsat for chroot
opts="-u named -t /opt/chroot/named"
daemon named $OPTS
# *** De ovenstaaende linjer er indsat for chroot
   retval=$?
   [ $RETVAL -eq 0 ] && touch /var/lock/subsys/named
   echo
   ;;
   stop)
   # Stop daemons.
   echo -n "Shutting down named: "
   killproc named
   retval=$?
   [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named
   echo
   ;;
   status)
   /usr/sbin/ndc status
   exit $?
   ;;
   restart)
   $0 stop
   $0 start
   ;;
   reload)
   /usr/sbin/ndc reload
   exit $?
   ;; 
   probe)
   # named knows how to reload intelligently; we don't want linuxconf
   # to offer to restart every time
   /usr/sbin/ndc reload >/dev/null 2>&1 || echo start
   exit 0
   ;;

   *)
   echo "Usage: named {start|stop|status|restart}"
   exit 1
   esac

   exit $RETVAL

I Debian ser opstartsfilen således ud for bind version 9:

#!/bin/sh

path=/sbin:/bin:/usr/sbin:/usr/bin
# for a chrooted server: "-u nobody -t /var/lib/named"
opts="-u named -t /chroot/named"

test -x /usr/sbin/named || exit 0

case "$1" in
    start)
        echo -n "Starting domain name service: named"
        start-stop-daemon --start --quiet --exec \
        /usr/sbin/named -- $OPTS
        echo "."
    ;;

    stop)
        echo -n "Stopping domain name service: named"
        start-stop-daemon --stop --quiet  \
            --pidfile /var/run/named.pid --exec /usr/sbin/named
        echo "."
    ;;

    reload)
        /usr/sbin/rndc reload
    ;;

    restart|force-reload)
        $0 stop
        sleep 2
        $0 start
    ;;
    
    *)
        echo "Usage: /etc/init.d/bind {start|stop|reload|restart|force-reload}" >&2
        exit 1
    ;;
esac
exit 0

Med ovenstående opstartsfil kan serveren køre efter genstart, uden indgreb fra administrator.

6.12.6. Afprøvning af DNS-serveren

For at starte DNS-processen uden at genstart maskinen, giver man følgende kommando i henholdsvis Red Hat og Debian (den er desuden pyntet med lidt && krusiduller og Co. for at man kan se hvordan opstarten går):

[root@linus /root]# /etc/rc.d/init.d/named start && tail -f /var/log/messages  

[root@linus /root]#  /etc/init.d/bind9 start && tail -f /var/log/daemon.log 

Jun  8 14:29:28 nse named[308]: starting BIND 9.2.0 -u named -t /opt/chroot/named \ 
-c /etc/bind/named.conf
Jun  8 14:29:28 ns named[308]: using 1 CPU
Jun  8 14:29:29 ns named[311]: loading configuration from '/etc/bind/named.conf'
Jun  8 14:29:29 ns named[311]: listening on IPv4 interface eth0, 192.168.8.1#53
Jun  8 14:29:29 ns named[311]: command channel listening on 127.0.0.1#953
Jun  8 14:29:29 ns named[311]: zone 0.in-addr.arpa/IN: loaded serial 1
Jun  8 14:29:29 ns named[311]: zone 127.in-addr.arpa/IN: loaded serial 1
Jun  8 14:29:29 ns named[311]: zone 168.192.in-addr.arpa/IN: loaded serial 2000111605
Jun  8 14:29:29 ns named[311]: zone 255.in-addr.arpa/IN: loaded serial 1
Jun  8 14:29:29 ns named[311]: zone localhost/IN: loaded serial 1

Hvis alting er som det skal være, udskrives noget der ligner det ovenstående.

Opsætningen kan desuden afprøves ved at se om bind virkelig kører samt kigge i logfiler. Hvis bind kører, vil kommandoen ps aux | grep named vise en eller flere linjer som den følgende:

named 2043 0.0  2.8 10396 1432 ?  S  03:11 0:00 /usr/sbin/named \
  -u named -t /opt/chroot/named -c /etc/bind/named.conf

Ovenstående linje bekræfter at BIND kører som den upriviligerede bruger named og at den er isoleret i /opt/chroot/named som hensigten var.

Den afgørende bekræftelse af opsætningen får man hvis serveren svarer når den forepørges om forskellige domæner. Hvid den er authoritativ/primær DNS-server for et domæne bør man selvfølgelig forespørge DNS-serveren om dette domæne. Man kan konkludere at "chroot" opsætningen er korrekt hvis serveren svarer.

Hvis der er noget i vejen, kan man få yderligere oplysninger kan findes i logfilen med kommandoen tail /var/log/daemon.log eller tail /var/log/messages.

Hvis serveren ikke kører, bør man kigge nærmere efter om alle filer og mapper er placeret som de skal og om der er manglende sammenhæng mellem de filnavne der er angivet i opsætningsfilerne og de filnavne og mappenavne der blev oprettet.

Alle øvrige problmemer med DNS-serveren har at gøre med den generelle opsætning i opsætningsfilerne. Yderligere oplysninger om opsætning og test af DNS, findes i Afsnit 6.8.

6.12.7. DNS-serveren som upriviligeret bruger

Dette afsnit handler hovedsagelig om hvordan DNS-serveren BIND 9 opfører sig når den kører som upriviligeret bruger. Selve opsætningen omhandles i foregående afsnit.

Traditionelt set, tilhører alle porte lavere end 1024 til root eller daemoner der kører som root. Når BIND køres som en upriviligeret bruger, har den ikke rettigheder til at sende førespørgsler til andre servere fra port 53. Som udgangspunkt vil den vælge et tilfældigt upriviligeret port at sende fra. Hvis netværket beskyttes af en dørvogter der udtrykkeligt specificerer hvilket port DNS-serveren kan sende fra, vil forespørgslerne ikke kunne komme forbi dørvogteren. For at afhjælpe dette kan man vælge en bestemt upriviligeret port, f.eks. 1053 og sætte BIND op til kun at bruge denne port som afsenderport. I den overordnede opsætningsfil til BIND bør den nederste af de følgende linjer tilføjes i sektionen options {}:

        listen-on port 53 { 192.168.8.1; };
        query-source address * port 1053;

I eksemplet ovenfor, har serveren IP-nummeret 192.168.8.1 på trods af at det er en offentlig DNS server. Forklaringen er, at serveren ikke har fået tildelt et offentligt IP-nummer, men trafik til den bliver dirigeret til den gennem en dørvogter. Dørvogteren skal blot ændres så den tillader udgående trafik med dette source port. Dermed kan BIND fortsætte med at fungere bag selv den mest restriktive dørvogter.

6.12.8. Testkørsel af DNS serveren.

Hvis serveren kører, bør den kunne svare på forespørgsler. Der findes flere værktøj til dette men her skal nævnes det nu snart forældede "nslookup" samt "dig". Man kan bede "dig" om at forespørge en vilkårlig DNS server ved blot at angive dens IP-nummer med parameteren @. I det følgende eksempel, skal den nyopsatte DNS-server give os oplysninger om domænet "sslug.dk".

[tyge@hven tyge]$ dig @192.168.8.1 sslug.dk
; <<>> DiG 9.2.0  <<>> @192.168.8.1 sslug.dk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<- opcode: QUERY, status: NOERROR, id: 45711
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sslug.dk.                      IN      A

;; ANSWER SECTION:
sslug.dk.               86400   IN      A       130.228.2.150

;; AUTHORITY SECTION:
sslug.dk.               86400   IN      NS      ns.sslug.dk.
sslug.dk.               86400   IN      NS      ptah.dkuug.dk.
sslug.dk.               86400   IN      NS      ns-soa.darenet.dk.

;; ADDITIONAL SECTION:
ns.sslug.dk.            86400   IN      A       130.228.2.150
ptah.dkuug.dk.          71539   IN      A       195.215.30.66
ns-soa.darenet.dk.      71539   IN      A       130.226.1.4

;; Query time: 237 msec
;; SERVER: 192.168.8.1#53(192.168.8.1)
;; WHEN: Sat Apr 13 18:11:17 2002
;; MSG SIZE  rcvd: 161

Sådan kan man afprøve serveren ved at pege den på forskellige domæner. Hvid den er authoritativ/primær DNS-server for et domæne bør man selvfølgelig forespørge DNS-serveren om dette domæne. Man kan konkludere at "chroot" opsætningen er korrekt hvis serveren svarer.

En af de ting der gør dig interessant sammenlignet med nslookup er at man let kan få fat i alle de forskellige oplysninger der ligger i DNS. Til gengæld giver dig også en masse oplysninger man normalt ikke er interesseret i, så det kan være nødvendigt at filtrere programmets uddata lidt.

Hvis man vil vide hvor post til en bestemt maskine afleveres giver man, udover maskinens navn, dig argumentet MX:

[tyge@hven tyge]$ dig kaoslx07.nbi.dk MX

;; <<>> DiG 9.2.1 <<>> kaoslx07.nbi.dk MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28989
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;kaoslx07.nbi.dk.               IN      MX

;; ANSWER SECTION:
kaoslx07.nbi.dk.        86400   IN      MX      10 alf.nbi.dk.

;; AUTHORITY SECTION:
nbi.dk.                 86400   IN      NS      alf.nbi.dk.
nbi.dk.                 86400   IN      NS      garm.adm.ku.dk.
nbi.dk.                 86400   IN      NS      sarastro.nbi.dk.

;; ADDITIONAL SECTION:
alf.nbi.dk.             86400   IN      A       130.225.212.55
garm.adm.ku.dk.         8272    IN      A       130.225.127.34
sarastro.nbi.dk.        86400   IN      A       130.225.212.46

;; Query time: 24 msec
;; SERVER: 130.225.212.46#53(130.225.212.46)
;; WHEN: Thu Sep  5 11:36:33 2002
;; MSG SIZE  rcvd: 164

Der kommer altså en hel masse data, hvoraf det eneste vi egentlig er interesserede i er "ANSWER SECTION". Med tilvalget +short kan vi få dig til kun at give os det egentlige svar:

[tyge@hven tyge]$ dig kaoslx07.nbi.dk MX +short
10 alf.nbi.dk.

Man kan også bruge dig til at få oplysninger som maskinens IP-adresse:

[tyge@hven tyge]$ dig kaoslx07.nbi.dk A +short
130.225.212.98

Hvilke maskiner der står for et domænes navnetjeneste:

[tyge@hven tyge]$ dig linuxlab.dk NS +short
www.itu.dk.
ns-soa.darenet.dk.

Eventuelt også lidt oplysninger om selve isenkrammet:

[tyge@hven tyge]$ dig kaoslx07.nbi.dk HINFO +short
"Pentium 4/1.5GHz" "Linux 7.3/2.4.18"

Endelig kan man også få lidt løse uformaterede oplysninger om domænet:

[tyge@hven tyge]$ dig nbi.dk TXT +short
"Niels Bohr Institute, Copenhagen University"