Windows Rants και ένα εργαστήριο με FreeBSD Samba Server

Κάθε χρόνο στις γιορτές έχω το χρόνο να ασχοληθώ και να συντηρήσω το εργαστήριο και τους υπολογιστές της γραμματείας του παραρτήματος Χανίων του ΚΕΚ ΔΕΛΤΑ. Έτσι και φέτος, ξεκίνησα με μια απόφαση: να αποσύρω τον Windows 2003 Server και να τον αντικαταστήσω με ένα Samba server σε FreeBSD 9.1-RELEASE. Οι ανάγκες του συγκεκριμένου δικτύου άνετα καλύπτονται πλέον με Samba σε domain controller configuration και τα επιπλέον licenses που χρειαζόμαστε για το 2003 είναι πεταμένα λεφτά...

Ιστορικά στοιχεία

Ξεκίνησα να συντηρώ το παράρτημα της συγκεκριμένης σχολής από τις πρώτες μέρες της λειτουργίας της στα Χανιά, κάπου το 1995-96. Την εποχή εκείνη τα μηχανήματα τους ήταν παλιά (τα είχαν φέρει από άλλο παράρτημα) και είχαν διάφορα προβλήματα. Όταν μετακόμισαν κάπου το 1999-2000 στο νέο τους κτήριο, ανέλαβα να τους φτιάξω από την αρχή ένα δίκτυο με νέα μηχανήματα και εξοπλισμό. Το αρχικό εκείνο δίκτυο βασίστηκε σε:

• Windows 2000 Server
• Windows 2000 Professional για τους σταθμούς εργασίας
• Λίγα παλιά μηχανήματα με Windows 98 (!)

Την εποχή εκείνη είχα ήδη καλή επαφή με το Linux, ωστόσο μετά από πολλές δοκιμές κατέληξα στο συμπέρασμα ότι το συγκεκριμένο δίκτυο θα εξυπηρετούνταν πολύ καλύτερα από ένα Windows Server. Και πράγματι, ο 2000 Server (που αργότερα αντικαταστάθηκε από το 2003) είχε πολλά πλεονεκτήματα: αναφέρω για παράδειγμα τη δυνατότητα assign και publish εφαρμογών - αρχεία msi και mst - για αυτόματη εγκατάσταση τους στους σταθμούς εργασίας.

Το αρχικό εκείνο δίκτυο είχε καλά μηχανήματα για την εποχή τους - Pentium III 866Mhz. Υπήρχαν δύο εργαστήρια και συνολικά περίπου 30 μηχανήματα μαζί με τα γραμματειακά.

Ο καιρός όμως πέρναγε, τα μηχανήματα πάλιωναν, τα 2000 Professional έπαψαν να καλύπτουν τις ανάγκες (μετά από πολύ καιρό είναι αλήθεια) και κάποιες δοκιμές με XP δεν ήταν ιδιαίτερα... ενθαρρυντικές στο υπάρχον hardware. Καθώς διάφορα PC χάλαγαν και δεν μπορούσαν να επισκευαστούν, τα αντικαθιστούσαμε με πιο νέα μηχανήματα. Η ομοιογένεια του υλικού και του λογισμικού της αρχικής εγκατάστασης είχε πάει περίπατο.

To 2012 λήφθηκε η απόφαση για τη δημιουργία νέου εργαστηρίου 20 υπολογιστών με σύγχρονο λογισμικό. Τα παλιά μηχανήματα - όσα ήταν ακόμα λειτουργικά - θα μεταφέρονταν σε δεύτερο βοηθητικό εργαστήριο, με την προυπόθεση να μπορούν να τρέξουν XP. Το νέο εργαστήριο θα βασίζονταν σε Windows 7 64bit. Και εδώ αρχίζουν τα προβλήματα.

• Τα Windows 2000 ήταν δύο εκδόσεις: Η Professional που έχει τα πάντα για ένα σταθμό εργασίας και ο Server που προορίζεται για... server. Τα Windows 7 είναι σε αρκετές εκδόσεις, αυτές δε που συμφέρουν είναι τεχνητά περιορισμένες να μην έχουν βασικές δυνατότητες. Για παράδειγμα η έκδοση Home Premium δεν υποστηρίζει σύνδεση μέσω remote desktop και φυσικά δεν υποστηρίζει domain logins.
• Όπως αποκαλύφθηκε, εν έτει 2012 υπάρχει ακόμα πλήθος εφαρμογών που δεν μπορούν να εκτελεστούν με δικαιώματα χρήστη, απαιτώντας Administrator access. Μέσος χρόνος ζωής μηχανήματος με administrator access χωρίς κάποιο πρόγραμμα τύπου deep freeze: Μισή ώρα.
• Δεν θέλω καν να μπω στη διαδικασία των ενεργοποιήσεων, ελέγχων κλπ που είναι ένα μαρτύριο που τραβάνε μόνο οι χρήστες που έχουν πληρώσει: οι υπόλοιποι τρέχουν τα έτσι και αλλιώς πειρατικά τους προγράμματα και γελάνε με την MS.

Το νέο εργαστήριο

Για λόγους κόστους (είναι περίεργες οι εποχές) αποφασίστηκε να χρησιμοποιηθούν τα Windows 7 Home Premium 64 bit. Χάνουμε έτσι το domain login (το οποίο όμως παραμένει στα παλιότερα μηχανήματα με XP) αλλά αυτό έτσι και αλλιώς δεν ήταν πολύ χρήσιμο στα εκπαιδευτικά μηχανήματα. Το μόνο που χρειάζεται πρακτικά είναι καθένα από αυτά να κάνει autologin με ένα διαφορετικό λογαριασμό και το home directory να γίνεται map από το server στην εκκίνηση του περιβάλλοντος. Αυτό είναι πολύ εύκολο και δεν αποτελεί πρόβλημα: όσο τα user credentials ταιριάζουν στο μηχάνημα και το server, η πρόσβαση στα shares γίνεται χωρίς πρόβλημα.

Μετά το αρχικό στήσιμο του εργαστηρίου, τα Windows 7 συνδέθηκαν με αυτό τον τρόπο στον 2003 Server ενώ το παλιότερο εργαστήριο XP παρέμεινε στο domain. Καθώς ο ρόλος του 2003 server ήταν πλέον πολύ πιο περιορισμένος, συμφωνήσαμε κάποια στιγμή να αλλαχθεί με ελεύθερο λογισμικό. Εξάλλου είχαμε ήδη ξεπεράσει τα αρχικά CALs. Και όπως πάντα, τέτοιες μαζικές αλλαγές γίνονται στις γιορτές, όπου και εγώ έχω χρόνο και η σχολή είναι κλειστή.

Η Αντικατάσταση του Server

Υπήρχε ήδη ένας FreeBSD Server στη σχολή! Τον είχα εγκαταστήσει αρκετά παλιά για να κρατάει backup στα δεδομένα του 2003 και να μπορεί να αναλάβει βασικές λειτουργίες σε περίπτωση σοβαρής βλάβης του 2003. Τόσο ο 2003 όσο και ο υπάρχον FreeBSD server λειτουργούσαν με mirror. To mirror του FreeBSD παρέδωσε πνεύμα (ο ένας δίσκος) κάπου το Νοέμβρη. Συνέχιζε να λειτουργεί με τον ένα δίσκο φυσικά, αλλά σκοπός ήταν στη διάρκεια της συντήρησης να βρεθεί κάπου ένας δίσκος αντίστοιχης χωρητικότητας και τεχνολογίας (το μηχάνημα είναι Pentium III!) για να αντικατασταθεί. Αυτό πράγματι επιτεύχθηκε την πρώτη μέρα της συντήρησης.

Αντίθετα, το hardware του 2003 Server είναι επαρκώς σύγχρονο (Core2Duo) με SATA δίσκους και Intel Network Card. Στο μηχάνημα αυτό εγκαταστάθηκε το FreeBSD 9.1-RELEASE 64bit. Στην εγκατάσταση του χρησιμοποιήθηκαν τα παρακάτω:

• Εγκατάσταση χωρίς το bsdinstall (με κάποιες παραλλαγές λόγω gmirror)
• Πακέτα που δημιουργήθηκαν με το pkgng
• DNS Server
• DHCP Server
• DHCP και Dynamic DNS updates
• FreeBSD Samba Domain Controller

Για ευκολία, η εγκατάσταση έγινε αρχικά στο σπίτι σε VMWare και αφού ρυθμίστηκε σύμφωνα με τις βασικές ρυθμίσεις του 2003 που θα αντικαθιστούσε (και δοκιμάστηκε φυσικά σε άλλο virtual client), έγινε dump και restore στο πραγματικό μηχάνημα. Έτσι χρειάστηκε πολύ λίγος χρόνος για επιπλέον παραμετροποίηση (πρακτικά μόνο η δημιουργία λογαριασμών χρηστών/μηχανημάτων.

Αφού έγινε backup ο παλιός server σε ένα atomaki που κουβαλάω μαζί μου για τέτοιες περιπτώσεις, έσβησα τα πάντα, έκανα restore από το dump, βασικές ρυθμίσεις και αντιγραφή ξανά των δεδομένων.

Δημιουργήθηκαν έπειτα οι χρήστες του εργαστηρίου και έγιναν map τα κατάλληλα shares σε κάθε υπολογιστή. Στο παλιό εργαστήριο, τα μηχανήματα βγήκαν από το παλιό domain και συνδέθηκαν στο νέο χωρίς κανένα πρόβλημα.

Όχι ένας, αλλά δύο!

Δύο FreeBSD servers φυσικά! Γιατί υπάρχει και ο παλιός Pentium III o οποίος πλέον:

• Έχει ρόλο δεύτερου DNS σαν slave του κύριου server.
• Παίρνει backup τα δεδομένα μέσω rsync.
• Μπορεί ξανά να παρέχει βασικές υπηρεσίες και πρόσβαση στα δεδομένα της γραμματείας σε περίπτωση βλάβης του κύριου server.

Φωτογραφικό υλικό

Ακολουθεί φωτογραφικό υλικό απο τα μηχανήματα και τη διαδικασία.

Δοκιμαστικό restore του atlantis στο atom για να ελεχθεί το dump.

Πολύ ευχαριστημένος, ο phoenix με καινούριο δίσκο στο mirror και το gmirror να αναφέρει "complete".

O atlantis λίγο μετά το καθάρισμα του hardware από τη σκόνη και λίγο πριν το "καθάρισμα" του 2003 Server από τους δίσκους!

Δημιουργία των partitions με το gpart, λίγο πριν το restore. Η διαδικασία έγινε με τη λειτουργία Live CD που παρέχει το FreeBSD 9.X

To atomακι με το ενσωματωμένο τροφοδοτικό να έχει παραδώσει το πνεύμα. Για άλλη μια φορά.

Αν δεν θέλετε να φάτε όλη τη μέρα αντιγράφοντας δεδομένα, βγάλτε το καλώδιο δικτύου από το πάνω switch και βάλτε το στο κάτω :)

Μικρός και μεγάλος δαίμονας σε δράση! Atlantis και Phoenix στις τελικές τους θέσεις.

ΟΚ, το τερματίσαμε!

Καλή Χρονιά!

DHCP και Dynamic DNS Updates

Σε παλιότερο μας άρθρο είχαμε συζητήσει τη δημιουργία ενός DHCP server για την απόδοση διευθύνσεων και ρυθμίσεων δικτύου στα client μηχανήματα του δικτύου μας. Σε άλλο μας άρθρο είχαμε συζητήσει τη δημιουργία ενός DNS Server κατάλληλο για σχολικά εργαστήρια - αλλά γιατί όχι και για το οικιακό ή εταιρικό σας δίκτυο. Μάλιστα του είχαμε φτιάξει και μια ωραία... μαύρη τρύπα για να κόψουμε κάποιες διευθύνσεις.

Αν τώρα καταφέρουμε τον DHCP server μας να ενημερώνει το DNS κάθε φορά που αποδίδει μια νέα διεύθυνση (δημιουργεί / τροποποιεί ένα lease) θα έχουμε πετύχει το τέλειο. Πάμε να δούμε πως!

Το Σενάριο

Σε ένα δίκτυο έχετε ένα FreeBSD server με υπηρεσίες DHCP & DNS. Τα client μηχανήματα παίρνουν δυναμικές διευθύνσεις (και λοιπές ρυθμίσεις δικτύου) από τον DHCP server. Θέλετε να μπορείτε ανά πάσα στιγμή να έχετε πρόσβαση στα μηχανήματα αυτά από οποιοδήποτε άλλο μηχάνημα χρησιμοποιώντας το όνομα τους και όχι το IP τους - που έτσι και αλλιώς δεν ξέρετε.

Παράδειγμα: Το μηχάνημα workstation01.lab1.local πήρε χθες δυναμική IP 192.168.0.33. Μια βδομάδα μετά, πήρε την 192.168.0.24. Οι διευθύνσεις είναι αδιάφορες: Θέλουμε να μπορούμε να αναφερθούμε σε αυτό γράφοντας κάτι σαν:

# ping workstation01.lab1.local

Είναι φανερό, ότι ο DHCP server θα πρέπει να ενημερώνει τον DNS: Να δημιουργεί εγγραφές για νέα μηχανήματα της ζώνης αλλά και να ανανεώνει υπάρχουσες. Καλώς ήλθατε στα dynamic DNS updates! Για το παράδειγμα μας θα υποθέσουμε οτι ο DNS/DHCP server εκτελούνται στο ίδιο μηχάνημα με IP 192.168.0.1

Γενικές γνώσεις

Αν ψάξετε λίγο το αρχείο σας /etc/named.conf, θα βρείτε κάτι σαν το παρακάτω για τις ζώνες σας:

zone "lab1.local" {
        type master;
        file "/etc/namedb/master/lab1.local.db";
};

zone "0.168.192.in-addr.arpa" {
       type master;
       file "/etc/namedb/master/0.168.192.in-addr.arpa";
};

Παρατηρήστε ότι τα αρχεία αυτά βρίσκονται στον υποκατάλογο master στον οποίο ο χρήστης bind (με τα δικαιώματα του οποίου εκτελείται ο DNS server στο FreeBSD) δεν έχει δικαιώματα εγγραφής. Άρα ακόμα και αν στείλετε με κάποιο τρόπο μήνυμα "update" στον server, δεν θα μπορέσει να γράψει κάτι σε αυτό τον κατάλογο.

Μη βιαστείτε να αλλάξετε τα δικαιώματα: Αν αλλάξετε το χρήστη/group του καταλόγου σε bind:wheel, το bind θα τα αλλάξει ξανά στην επόμενη εκκίνηση της υπηρεσίας και θα δείτε και το παρακάτω μήνυμα:

Stopping named.
Waiting for PIDS: 6707.
etc/namedb/master changed
 user expected 0 found 53 modified
Starting named.

Το οποίο σε απλά ελληνικά σημαίνει: "μη πειράζετε τα δικαιώματα σε αυτό τον κατάλογο!". Και τι πρέπει να κάνουμε; Μα πολύ απλά. Θα μεταφέρετε τα αρχεία στον κατάλογο dynamic. Γιατί εκεί θα γίνονται οι δυναμικές ανανεώσεις και o bind έχει την κατάλληλη πρόσβαση.

# service named stop
# cd /etc/namedb/master
# mv lab1.local.db   ../dynamic
# mv 0.168.192.in-addr.arpa   ../dynamic

Και πριν επανεκκίνησετε, φυσικά θα αλλάξετε και τις καταχωρίσεις ώστε να δείχνουν στον κατάλογο dynamic:

zone "lab1.local" {
        type master;
        file "/etc/namedb/dynamic/lab1.local.db";
};

zone "0.168.192.in-addr.arpa" {
       type master;
       file "/etc/namedb/dynamic/0.168.192.in-addr.arpa";
};

Μπορείτε τώρα να επανεκκινήσετε την υπηρεσία όση ώρα θα ψάχνετε πως γίνεται το dynamic DNS update από τον DHCP server. Όχι τίποτα, άλλο μη γκρινιάζουν και οι χρήστες που δεν θα έχουν δίκτυο στο μεταξύ :)

# service named start

Δημιουργία... μυστικών

Για να γίνεται το DNS update, θα πρέπει ο DHCP server να στέλνει το κατάλληλο μήνυμα στον DNS κάθε φορά που απαιτείται να δημιουργηθεί ή να τροποποιηθεί μια εγγραφή. Όμως δεν μπορούμε να αφήσουμε τον DNS να δέχεται updates από παντού. Οι εποχές είναι πονηρές! Πρέπει να δημιουργήσουμε ένα μυστικό κλειδί που θα γνωρίζουν ο DNS και ο DHCP για να συννενοούνται:

# dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpupdatekey
Kdhcpupdatekey.+157+10817

Δείτε το περιεχόμενο του αρχείου με κατάληξη .key που δημιουργήθηκε:

# more Kdhcpupdatekey.+157+10817.key 
dhcpupdatekey. IN KEY 0 3 157 dw5akl5zJw8Rc/8za61TLA==

Το κλειδί που θέλετε είναι αυτό το τελευταίο πεδίο:

dw5akl5zJw8Rc/8za61TLA==

Τροποποιήστε το /etc/named.conf όπως φαίνεται παρακάτω:

key "dhcpupdatekey" {
  algorithm hmac-md5;
  secret "dw5akl5zJw8Rc/8za61TLA==";
};

zone "lab1.local" {
        type master;
        file "/etc/namedb/dynamic/lab1.local.db";
        allow-update { key "dhcpupdatekey"; };
};

zone "0.168.192.in-addr.arpa" {
       type master;
       file "/etc/namedb/dynamic/0.168.192.in-addr.arpa";
       allow-update { key "dhcpupdatekey"; };
};

Κάντε restart το bind και για να πείσετε τον εαυτό σας ότι το dynamic update λειτουργεί, δοκιμάστε να του στείλετε ένα update χειροκίνητα. Επιλέξτε μια διεύθυνση που γνωρίζετε και περάστε την:

# service named restart
# nsupdate
> server 192.168.0.1
> key dhcpupdatekey dw5akl5zJw8Rc/8za61TLA==
> zone lab1.local
> update add workstation01.lab1.local. 600 IN A 192.168.0.24
> send
> quit

Δεν θα πρέπει να δείτε κανένα μήνυμα μετά το send. Μπορείτε να επιβεβαιώσετε την εγγραφή τρέχοντας την nslookup:

# nslookup
> workstation01.lab1.local

Server:  192.168.0.1
Address: 192.168.0.1#53

Name:  workstation01.lab1.local
Address: 192.168.0.24
> exit

Αφού λειτουργεί, δεν μένει παρά να βάλουμε τον DHCP να κάνει τη δουλειά που κάναμε εμείς χειροκίνητα! Πάμε λοιπόν να επεξεργαστούμε το /usr/local/etc/dhcpd.conf

Αλλαγή του dhcpd.conf

Και εδώ πρόκειται για πολύ απλές και αναμενόμενες αλλαγές. Προσθέτουμε το ίδιο μυστικό κλειδί (προσέξτε εδώ χωρίς εισαγωγικά!):

key dhcpupdatekey {
  algorithm hmac-md5;
  secret dw5akl5zJw8Rc/8za61TLA==;
}

Προσθέτουμε τη γραμμή που ενημερώνει το DHCP server ότι θα κάνει πλέον dynamic dns updates:

ddns-update-style interim;

Και τέλος τα στοιχεία για τις ζώνες που θα ενημερώνονται:

zone lab1.local. {
  primary 192.168.0.1;
  key dhcpupdatekey;
}

zone 0.168.192.in-addr.arpa. {
  primary 192.168.0.1;
  key dhcpupdatekey;
}

Κάντε και μια επανεκκίνηση το DHCP σας και είμαστε έτοιμοι:

# service isc-dhcpd restart

Μπορείτε να διαβάσετε και αυτό το σχετικό άρθρο με το οποίο ξεκινήσαμε και εμείς τις αναζητήσεις μας.

Ελπίζουμε να περάσετε ένα ευχάριστο χειμωνιάτικο απόγευμα. Καλές γιορτές!

Ένας DNS Server για Σχολικά Εργαστήρια - Μέρος ΙΙ

Στο προηγούμενο άρθρο μας ρυθμίσαμε ένα FreeBSD Server στο ρόλο του DNS ενός σχολικού εργαστηρίου (αλλά και γενικότερα της σχολικής μονάδας). Επανερχόμαστε τώρα για να δούμε πως μπορούμε να χρησιμοποιήσουμε τις δυνατότητες που μας παρέχει για να "φιλτράρουμε" κάποιες διευθύνσεις.


Το φιλτράρισμα σε πολλές περιπτώσεις είναι επιβεβλημένο καθώς (δυστυχώς) η χρήση του Internet γίνεται γενικά χωρίς μέτρο στα σχολεία και το αποτέλεσμα είναι πλήρης απώλεια ελέγχου της κατάστασης. Ειδικά η χρήση site όπως το facebook είναι από μόνη της αρκετή για να διαταράξει κάθε εργαστηριακό μάθημα. Πέρα από αυτό βέβαια υπάρχουν και άλλα sites που ενδεχομένως θέλετε να φιλτράρετε, είτε γιατί το περιεχόμενο είναι ακατάλληλο, είτε γιατί περιέχουν κακόβουλα προγράμματα. Γενικά όμως αυτά αποτελούν μικρότερο πρόβλημα.

DNS Blackhole

Καθώς ετοιμαζόμουν να γράψω το πρώτο άρθρο, ο hakmem σε ένα tweet αναφέρθηκε σε άρθρο δημιουργίας DNS blackhole με χρήση του FreeBSD. To DNS blackhole χρησιμοποιεί το δικό μας DNS server για να "βραχυκυκλώσει" ουσιαστικά ένα site, κατευθύνοντας το προς μια ανύπαρκτη διεύθυνση ή σελίδα (π.χ. 127.0.0.1) ή σε μια σελίδα που έχουμε δημιουργήσει εμείς και εξηγεί γιατί δεν επιτρέπεται η πρόσβαση στο site. Το άρθρο είναι πολύ καλό και μπορείτε να το χρησιμοποιήσετε αυτούσιο αν θέλετε. Για τη δική μας περίπτωση ωστόσο, προτιμήσαμε να φτιάξουμε μια λύση που να υλοποιεί το DNS blackhole με βάση μια δική μας λίστα και μάλιστα να μπορεί να ανανεώνεται και κάτα κάποιο τρόπο αυτόματα.

DNS Blackhole - Απόπειρα 1

Προφανώς είναι αρκετά εύκολο να προσθέσουμε μια καταχώριση στο /etc/namedb/named.conf και να κλείσουμε ένα site όπως το facebook. Για παράδειγμα αυτό θα ήταν αρκετό:

zone "facebook.com" {
       type master;
       file "/etc/namedb/master/voidurls.db";
};

όπου φυσικά το /etc/namedb/master/voidurls.db θα είναι κάτι σαν το παρακάτω:

$TTL 3h
@ IN SOA aquarius64.lab1.local.  sonicy.otenet.gr. (
       2008081501      ; Serial - increment everytime something changes
       1d              ; Refresh
       2h              ; Retry
       1000h           ; Expire
       2d )            ; Minimum

                               IN      NS      10.14.28.10.
                               IN      A       10.14.28.251
www                             IN      A       10.14.28.251
localhost                       IN      A       127.0.0.1 ; just in case

Στην περίπτωση μας, ο 10.14.28.251 είναι ο δεύτερος μας server και περιέχει επίσης μια σελίδα που απλά εξηγεί ότι απαγορεύεται η πρόσβαση. Το σύστημα αυτό λειτουργεί μια χαρά - φυσικά μέχρι όλοι οι μαθητές να ανακαλύψουν ότι υπάρχουν χιλιάδες site που αναλαμβάνουν να κάνουν unlock / unblock το facebook. Και είναι απλά αδύνατον να τα προσθέσουμε με το χέρι ένα-ένα. Μπορούμε όμως να χρησιμοποιήσουμε ένα απλό script το οποίο να διαβάζει το query-log του DNS, να βρίσκει τις ανεπιθύμητες διευθύνσεις και να τις προσθέτει αυτόματα. Μπορείτε να το κατεβάσετε από εδώ. Ακολουθεί μια μικρή ανάλυση.

Ένα Script για την... Μαύρη Τρύπα

Η παρακάτω γραμμή ορίζει το αρχείο καταγραφής του DNS που θα αναλύει το script:

INFILES="/etc/namedb/logs/query-log"

Αν θέλουμε περισσότερα από ένα αρχεία, μπορούμε να βάλουμε όλα τα ονόματα σε αυτή τη γραμμή, χωρισμένα με κενά. Την πρώτη φορά που θα το τρέξουμε πιθανόν έχει νόημα να αναλύσουμε όλα τα query-log που υπάρχουν ήδη.

Τα πρώτα αποτελέσματα που βγάζει το script αποθηκεύονται σε αυτό το αρχείο:

OUTFILE=/etc/namedb/logs/outfile.log

Ενώ το ταξινομημένο αρχείο εξόδου και backup:

SORTFILE=/etc/namedb/logs/sorted.log
SORTFILEBAK=/etc/namedb/logs/sorted.log.bak

Το τελικό αρχείο που παράγεται για το BIND:

ADDBLOCKFILE=/etc/namedb/addblock.conf
ADDBLOCKFILEBAK=/etc/namedb/addblock.conf.bak

To αρχείο που περιέχει τις "απαγορευμένες" λέξεις:

WORDLISTFILE=/home/sonic/blockwords

το οποίο σε μας περιέχει:

unblock
unlock
facebook
googleearth
miniclip
minigames.com

Αν θέλουμε κάποια domains να αγνοούνται ακόμα και αν περιέχουν μέσα τους τις απαγορευμένες λέξεις, τα βάζουμε εδώ και χωρίζονται με "|":

IGNORELIST="lab1.local|chan.sch.gr|.newlab|.lan"

Το αρχείο addblock.conf παράγεται μόνο αν η νέα εκτέλεση του script δημιούργησε νέα αποτελέσματα σε σχέση με την προηγούμενη. Στην περίπτωση αυτή γίνεται και η απαραίτητη επαναφόρτωση της ζώνης με την εντολή:

rndc reload

Σε κάθε περίπτωση, υπάρχει πάντα backup του προηγούμενου addblock.conf ώστε αν η ζώνη αποτύχει να φορτωθεί για κάποιο λόγο, χρησιμοποιείται το backup. Αυτό εξασφαλίζει ότι δεν θα μείνουμε χωρίς DNS.

Για να λειτουργήσει, θα βάλουμε την παρακάτω γραμμή στο τέλος του /etc/namedb/named.conf:

include "/etc/namedb/addblock.conf";

Λογικά, θα πρέπει να δημιουργήσετε μια καταχώριση στο /etc/crontab ώστε το script να εκτελείται αυτόματα σε τακτά διαστήματα (π.χ. ανά πέντε λεπτά). Αυτό δεν δημιουργεί πρόβλημα, καθώς δεν γίνεται επαναφόρτωση της ζώνης αν δεν υπάρχουν νέες καταχωρίσεις και έτσι ο DNS server λειτουργεί απρόσκοπτα. Φυσικά μπορείτε να βελτιώσετε και να τροποποιήσετε το script κατά τις ανάγκες σας.

Ένας DNS Server για Σχολικά Εργαστήρια - Μέρος Ι

Στη δική μου περίπτωση βέβαια, πρόκειται για δύο DNS servers. Καλό είναι να υπάρχει και ένα backup DNS, ειδικά όταν στηρίζει όλο το δίκτυο του σχολείου και όχι μόνο ένα σχολικό εργαστήριο. Αλλά ας πάρουμε τα πράγματα από την αρχή.

Σε τι χρησιμεύει ένας DNS Server; Αν ρωτήσετε ένα μαθητή της Γ' Τάξης του τομέα Πληροφορικής ΕΠΑΛ (και είστε τυχερός) θα σας πει ότι ο DNS απαντάει σε ερωτήματα του τύπου "Ποιο είναι το IP του www.freebsd.org" και "ποιος υπολογιστής έχει την διεύθυνση 10.14.28.10". Καθώς καταλαβαίνετε βέβαια δεν είναι δυνατόν ένα μηχάνημα να γνωρίζει τις διευθύνσεις όλου του διαδικτύου - αν και φυσιολογικά θα ξέρει και θα ανταποκρίνεται αυτόνομα στα ερωτήματα που αφορούν το εσωτερικό μας δίκτυο. Σε κάθε άλλη περίπτωση θα επικοινωνεί με άλλους DNS server για να ανακτήσει την απάντηση.

Σε ένα απλό οικιακό δίκτυο - και όταν δεν μας ενδιαφέρει το DNS για εσωτερικές διευθύνσεις - αρκούμαστε στο DNS Server του παροχέα. Αυτός αναλαμβάνει να επιλύσει τις ερωτήσεις μας για τα site του Internet που θα επισκεπτούμε (ρωτώντας αν χρειάζεται και άλλους DNS servers, αλλά αυτή η διαδικασία είναι διάφανη για εμάς και δεν μας αφορά). Από τη στιγμή που θα επιλέξουμε να εκτελούμε δικό μας DNS Server έχουμε άλλα πλεονεκτήματα:

• Μπορούμε να τον χρησιμοποιήσουμε για τα μηχανήματα του εσωτερικού μας δικτύου


• Μπορούμε να είμαστε ανεξάρτητοι από την υπηρεσία DNS του παροχέα


• Μπορούμε να τον χρησιμοποιήσουμε για να φιλτράρουμε διευθύνσεις που είναι κακόβουλες ή απλά που δεν θέλουμε να επισκέπτονται οι χρήστες του δικτύου μας.

Ειδικά αυτή η τελευταία δυνατότητα είναι πολύ σημαντική για ένα σχολικό δίκτυο! Ας δούμε πως μπορεί να ρυθμίσουμε τον πλέον δημοφιλή DNS server, το BIND χρησιμοποιώντας το λειτουργικό σύστημα FreeBSD!

Ρύθμιση του BIND

Το BIND έρχεται ως μέρος του base system στο FreeBSD. Η ενεργοποίηση του είναι απλή υπόθεση. Στο /etc/rc.conf προσθέστε τις γραμμές:

named_enable="YES"

Το βασικό αρχείο ρυθμίσεων του BIND είναι το /etc/namedb/named.conf. Ας δούμε τι προσθήκες έχουμε κάνει σε σχέση με το αρχικό που έρχεται με το FreeBSD 8.2-RELEASE:

logging {
        channel query-log {
                file "/etc/namedb/logs/query-log" versions 3 size 1m;
                };
        category queries { query-log; };
};

Εδώ ενεργοποιούμε το logging. Έτσι γίνεται καταγραφή των διευθύνσεων που ζητούνται από τον BIND. Θα το χρειαστούμε αυτό για το φιλτράρισμα.

Αλλάζουμε τη γραμμή listen για να περιέχει και την IP διεύθυνση του server που εκτελεί το BIND (εκτός από το local loopback). O δικός μας έχει την διεύθυνση 10.14.28.10:

listen-on { 10.14.28.10; 127.0.0.1; };

Δηλώνουμε τα αρχεία που αφορούν τις ζώνες του τοπικού μας δικτύου:

zone "lab1.local" {
 type master;
 file "/etc/namedb/master/lab1.db";
 also-notify { 10.14.28.251; };
};

zone "newlab" {
 type slave;
 file "/etc/namedb/slave/newlab.db";
 masters {
  10.14.28.251;
  };
 };

Όπως ανέφερα παραπάνω, διαθέτουμε δύο DNS servers και τυπικά καθένας εξυπηρετεί ένα εργαστήριο (ο πρώτος εξυπηρετεί και το υπόλοιπο σχολείο). Ο δεύτερος DNS είναι στη διεύθυνση 10.14.28.251. Για backup, καθένας από τους δύο διαθέτει και την ζώνη του άλλου. Πιστεύω ότι είναι αρκετά κατανοητός ο τρόπος που επιτυγχάνεται αυτό (hint: master, slave, masters, also-notify). Για ένα μόνο DNS server και ένα εσωτερικό domain θα αρκούσε αυτό:

zone "lab1.local" {
 type master;
 file "/etc/namedb/master/lab1.db";
};

Η υπόθεση μας είναι ότι το εσωτερικό μας domain ονομάζεται lab1.local και φυσικά θα χρειαστεί να φτιάξουμε το αρχείο /etc/namedb/master/lab1.db. Mοιάζει με το παρακάτω:

$TTL 3h
@ IN SOA aquarius64.lab1.local.  sonicy.otenet.gr. (
        2008081511      ; Serial - increment everytime something changes
        1d              ; Refresh
        2h              ; Retry
        1000h           ; Expire
        2d )            ; Minimum

                                IN      NS      10.14.28.10.
aquarius64   IN A 10.14.28.10
localhost                       IN      A       127.0.0.1 ; just in case
PC1    IN A 10.14.28.11
PC2    IN A 10.14.28.12
PC3    IN A 10.14.28.13

Προσθέτουμε σε αυτό όλα τα μηχανήματα του εργαστηρίου μας. Στη συγκεκριμένη περίπτωση βέβαια έχουμε στατικές διευθύνσεις οπότε ξέρουμε ότι δεν θα γίνει κάποια αλλαγή (Ο DHCP server που επίσης εκτελείται δίνει άλλες περιοχές διευθύνσεων).

Ενεργοποίηση και Δοκιμή

Έχοντας κάνει όλα τα παραπάνω, ενεργοποιούμε το BIND:

# service named start
Starting named.

Για να χρησιμοποιεί ο server μας τον... εαυτό του ως DNS για τα δικά του ερωτήματα, βεβαιωνόμαστε ότι το /etc/resolv.conf περιέχει κάτι σαν αυτό:

domain lab1.local
nameserver 10.14.28.10
#Μπορεί να χρησιμοποιηθεί και το local loopback
#nameserver 127.0.0.1
#Αν έχουμε και άλλο DNS
#nameserver 10.14.28.251

To domain είναι προαιρετικό (αλλά χρήσιμο). Μπορείτε να δείτε περισσότερες λεπτομέρειες στο man resolv.conf. H δοκιμή είναι απλή:

$ nslookup
> www.freebsd.org
Server:  10.14.28.10
Address: 10.14.28.10#53

Non-authoritative answer:
www.freebsd.org canonical name = red.freebsd.org.
Name: red.freebsd.org
Address: 69.147.83.34
> PC1.lab1.local
Server:  10.14.28.10
Address: 10.14.28.10#53

Name: PC1.lab1.local
Address: 10.14.28.11
> exit

Το μόνο που μένει είναι να δηλώσετε το 10.14.28.10 ως DNS server σε όλα τα μηχανήματα του δικτύου σας (ή να το στείλετε μέσω DHCP αν έχετε δυναμικές διευθύνσεις). Φαντάζομαι ξέρετε πως να βάλετε DNS στα Windows ;) Για τα UNIXοειδή μηχανήματα ρυθμίστε απλώς το /etc/resolv.conf όπως παραπάνω ή χρησιμοποιήστε τον (brrrrr....) Network Manager.

Στο επόμενο άρθρο θα δούμε πως να χρησιμοποιήσουμε το DNS για φιλτράρισμα ανεπιθύμητων διευθύνσεων.