|
Hierbei gibt es zwei zu trennenden Dinge: DNS-Server, die
Clientanfragen bearbeiten, und Autoritative-Server. Man kann
diese auf getrennten Maschinen unterbringen, denn DNS-Server, die
Clientanfragen beantworten, sind von Denial-Of-Service Attacken
nicht so stark betroffen, wie Authoritative-Server. Mit der Option
query-source address * port 53;
kann man bind anweisen, alle Anfragen von
Port 53 aus zu machen.
Damit kann man die Firewall für die hohen Ports (>1023) auch
noch sperren. Zusätzlich kann man auch die Zieladdressen
begrenzen, wenn man den Server "forward-only;"
konfiguriert. Dann
gibt man ihm z.B. drei Forwarder, und erlaubt nur Verbindungen zu
diesen. Diese Verbindungsregeln müssen für UDP und TCP gelten, da
bind bei Anfragen, die nicht mehr in ein einzelnes UDP-Paket
passen, TCP verwendet. Selbstverständlich sollte die Firewall
Regelverstöße loggen.
Betreibt man einen Primary, und läßt die Secondaries vom ISP
machen, so muß mit diesem abgesprochen werden, von welchen
Maschinen aus welche Art von Zugriff zu erlauben ist. Einige
verwenden z.B. ping für Tests, außerdem wird
evtl. von einer anderen Maschine zu Testzwecken ein Zonetransfer
probiert, bevor der Eintrag in den "richtigen" Server
gemacht wird. Erhält man ungenügende Auskunft, so erstellt man
eine Firewallregel, die alle Anfragen durchläßt, aber dabei
loggen (Es reicht aus, Pakete mir gesetztem SYN-Bit zu loggen,
allerdings macht das in der Praxis selten Sinn, da zu verbotenen
Ports sowieso nur SYN-Pakete kommen werden, und der Aufwand für
die zusätzlichen Regeln [die für TCP] kaum Nutzen bringt, sofern
man keine "ACCEPTS" loggt).
Dann kann man das Logfile analysieren, und erkennt, welche
Maschinen Daten austauschen.
Leider kann man DNS nicht durch den rinetd
redirecten, da dieser kein UDP unterstützt.
Da mindestens ein Slave außerhalb des Netzes steht, muß also
mindestens dieser durch die Firewall dürfen. Um das testen zu
können, sollte immer ein zusätzlicher Host erlaubt werden, also
sowohl durch die Firewall dürfen, als auch einen Zonentransfer
machen dürfen. Dann kann man nslookup auf
diesem Host verwenden, um mit
ls <Zonenname> einen
Test-Zonetransfer durchzuführen.
Beim ersten Zugriff der Secondaries sollte man immer das Firewall-
Log im Auge behalten, da die Provider gern einen Host, der
Zugriff benötigt, vergessen. Das ist z.B. die Testmaschine, an
dem die Zonen geprüft werden. So sieht man das Problem sofort,
und kann eine entsprechende Regel evtl. schnell einfügen.
|
SelfLinux 
