Next Previous Contents

6. Ασφάλεια και NFS

Δεν είμαι καθόλου ειδικός στην ασφάλεια των Η/Υ. Αλλά μπορώ να δώσω μερικές μικρές συμβουλές σε όσους ενδιαφέρονται γιά την ασφάλεια. Όμως, με μιά επιφύλαξη : Η παρακάτω δεν είναι καθόλου μιά πλήρης λίστα των προβλημάτων που σχετίζονται με το NFS, και αν νομίζετε ότι είσαστε ασφαλείς, αφού διαβάσατε και υλοποιήσατε όλα τούτα εδώ, έχω μιά γέφυρα να σας πουλήσω. (Σ.τ.μ. : Εννοεί "bridge" δικτύων.)

Αυτή η ενότητα προφανώς δεν σας ενδιαφέρει, αν έχετε ένα κλειστό δίκτυο, όπου εμπιστεύεστε όλους τους χρήστες, και κανένα μη έμπιστο άτομο δεν μπορεί να βρει πρόσβαση στους Η/Υ του δικτύου. Δηλαδή, δεν υπάρχει κανένας τρόπος να συνδεθούν μέσω τηλεφώνου στο δίκτυό σας, και δεν υπάρχει σύνδεση με άλλα δίκτυα, όπου δεν είναι ο κάθε χρήστης άτομο εμπιστοσύνης, ούτε η ασφάλεια του δικτύου. Νομίζετε ότι είμαι παρανοϊκός; Δεν είμαι καθόλου. Τα παραπάνω είναι απλά οι βασικές συμβουλές ασφάλειας. Και θυμηθείτε, τα πράγματα που γράφω εδώ είναι απλά η αρχή των συμβουλών. Ένα ασφαλές δίκτυο χρειάζεται έναν επιμελή και ειδήμονα SysAdmin, που γνωρίζει πού να βρει πληροφορίες αντιμετώπισης των τωρινών και των πιθανών προβλημάτων.

Το NFS έχει ένα βασικό πρόβλημα, δηλαδή ο client (αν δεν του πούμε να κάνει διαφορετικά) εμπιστεύεται τον NFS server, και αντίστροφα. Αυτό μπορεί ν' αποβεί κακό : Σημαίνει πως, αν ο root account του server hackευτεί, είναι αρκετά εύκολο να hackευτεί και ο root account του client, και αντίστροφα. Υπάρχουν καναδυό τρόποι αντιμετώπισης, στους οποίους θα επανέλθουμε.

Κάτι που πρέπει να διαβάσετε, είναι τα συμβουλευτικά κείμενα του CERT (σ.τ.μ. : site γιά την ασφάλεια στο Internet, www.cert.org) γιά το NFS. Το μεγαλύτερο κομμάτι του κειμένου παρακάτω, ασχολείται με θέματα, γιά τα οποία το CERT έχει γράψει συμβουλές. Δες το ftp.cert.org:/01-README γιά μιά ενημερωμένη λίστα των συμβουλών του CERT. Εδώ σας δίνω μερικές τέτοιες συμβουλές, σχετικές με το NFS :


CA-91:21.SunOS.NFS.Jumbo.and.fsirand                            12/06/91
     Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network
     File System (NFS) and the fsirand program.  These vulnerabilities
     affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures.
     Patches are available for SunOS 4.1.1.  An initial patch for SunOS
     4.1 NFS is also available. Sun will be providing complete patches
     for SunOS 4.1 and SunOS 4.0.3 at a later date.

CA-94:15.NFS.Vulnerabilities                                    12/19/94
     This advisory describes security measures to guard against several
     vulnerabilities in the Network File System (NFS). The advisory was
     prompted by an increase in root compromises by intruders using tools
     to exploit the vulnerabilities.

CA-96.08.pcnfsd                                                 04/18/96
     This advisory describes a vulnerability in the pcnfsd program (also
     known as rpc.pcnfsd). A patch is included.

6.1 Η ασφάλεια του client

Γιά τον client, μπορούμε ν' αποφασίσουμε με καναδυό τρόπους (και με τις αντίστοιχες επιλογές στο mount) ότι δεν εμπιστευόμαστε και πολύ τον server. Πχ, μπορούμε ν' απαγορεύσουμε σε προγράμματα suid να δουλεύουν εκτός NFS filesystem, με την επιλογή nosuid. (Αυτή είναι μιά καλή ιδέα, και θα' πρεπε να κάνετε το ίδιο με όλους τους δίσκους επάνω στο NFS.) Σημαίνει πως ο root user του server δεν μπορεί να τρέξει ένα suid-root πρόγραμμα επάνω στο filesystem, να κάνει login στον client ως κανονικός χρήστης, και μετά να χρησιμοποιήσει το suid-root πρόγραμμα αυτό, γιά να γίνει και root στον client. Θα μπορούσαμε επίσης να απαγορεύσουμε τελείως το τρέξιμο αρχείων επάνω στο mounted filesystem, με την επιλογή noexec. Αλλά αυτό μάλλον δεν είναι πρακτικό, επειδή ένα filesystem πιθανότατα περιέχει τουλάχιστον μερικά scripts ή προγράμματα, που πρέπει να τρέξουν. Αυτές τις επιλογές τις βάζουμε στις στήλες επιλογών των rsize και wsize, και τις χωρίζουμε με κόμμα.

6.2 Η ασφάλεια του server : Ο nfsd

Στον server, μπορούμε ν' αποφασίσουμε ότι δεν εμπιστευόμαστε τον root account του client. Συνεπώς, μπορούμε να χρησιμοποιήσουμε την επιλογή the root_squash στα exports :


/mn/eris/local apollon(rw,root_squash)

Τώρα, αν ένας χρήστης με userID 0 στον client προσπαθήσει να βρει πρόσβαση (ανάγνωσης, εγγραφής, σβησίματος) στο filesystem, ο server υποκαθιστά την UID του χρήστη με την αντίστοιχη του "nobody account" του server. Που σημαίνει ότι ο root χρήστης του client δεν μπορεί να δει ή ν' αλλάξει αρχεία, που μόνο ο root του server μπορεί. Αυτό είναι καλό, και πιθανότατα πρέπει να βάζετε root_squash σε όλα τα filesystems που κάνετε export. "- Αλλά ο root user του client εξακολουθεί να μπορεί να χρησιμοποιεί την εντολή su, γιά να γίνει οποιοσδήποτε άλλος χρήστης, άρα να μπορεί να βλέπει και ν' αλλάζει τα αρχεία!", λέτε. Στο οποίο, η απάντηση είναι : Ναι, έτσι ακριβώς είναι, και πρέπει να είναι με τα *nix's και με το NFS. Αυτό, όμως, έχει μιά σημαντική συνέπεια : Όλα τα σημαντικά binaries και γενικότερα αρχεία πρέπει να τα έχει own ο root, όχι το bin, ή οποιοσδήποτε άλλος μη-root account, μιά που ο μόνος account, στον οποίο δεν μπορεί να βρει πρόσβαση ο root user του client, είναι ο root account του server. Στη σελίδα man του NFSd υπάρχουν καταχωρημένες πολλές άλλες επιλογές γιά squash, ώστε ν' αποφασίσετε μόνοι σας ποια (δεν) θα εμπιστευθείτε γιά τους clients. Επίσης, σας δίνονται επιλογές να κάνετε squash σ' οποιοδήποτε σύνολο UID και GID θέλετε. Αυτά όλα περιγράφονται στη man σελίδα του Linux NFSd.

Στην πραγματικότητα, η επιλογή root_squash είναι η default με τον Linux NFSd. Γιά να δώσετε πρόσβαση root σ' ένα filesystem, βάλτε no_root_squash.

Ακόμη κάτι σημαντικό, είναι να βεβαιωθούμε ότι ο nfsd ελέγχει πως όλες οι αιτήσεις του έρχονται μόνο από μία προνομιούχο θύρα (privileged port). Αν δεχθεί αιτήσεις από οποιοδήποτε port, ένας οποιοσδήποτε χρήστης χωρίς ιδιαίτερα προνόμια μπορεί να τρέξει ένα πρόγραμμα, που θα βρει κάπου στο Internet, που "μιλάει" στο πρωτόκολλο του nfs, και που ισχυρίζεται ότι ο χρήστης είναι αυτός που ο ίδιος θέλει να είναι. Τρομακτικό! Ο nfsd του Linux κάνει εξ ορισμού τέτοιον έλεγχο, όμως σε άλλα ΛΣ πρέπει να ενεργοποιήσετε αυτόν τον έλεγχο εσείς. Το πώς, πρέπει να γράφεται στη σελίδα βοήθειας γιά τον nfsd το συγκεκριμένου ΛΣ.

Ακόμη κάτι : Ποτέ μην κάνετε export ένα filesystem στον localhost, ή στο 127.0.0.1 . Εμπιστευθείτε με!

6.3 Η ασφάλεια του server : Ο portmapper

Ο βασικός portmapper, σε συνδυασμό με τον nfsd, έχουνε ένα σχεδιαστικό πρόβλημα, που καθιστά δυνατό το να παίξουμε με τα αρχεία σε NFS servers, χωρίς να έχουμε προνόμια (privileges). Ευτυχώς, ο portmapper τον οποίο χρησιμοποιούν οι περισσότερες Linux distributions, είναι σχετικά ασφαλής εναντίον τέτοιων επιθέσεων, και μπορεί να γίνει ασφαλέστερος, αν ρυθμίσουμε σε δύο συγκεκριμένα αρχεία τις λίστες πρόσβασης.

Δεν πλάσθηκαν ίσες όλες οι Linux distributions! Μερικές φαινομενικά σύγχρονες δεν περιλαμβάνουν ασφαλή portmapper, ακόμη και σήμερα, πολλά χρόνια αφ' ότου αυτή η τρύπα ασφάλειας έγινε κοινή γνώση. Τουλάχιστον μία ακόμη διανομή περιέχει τη σελίδα man γιά ασφαλή portmapper, αλλά ο ίδιος ο portmapper δεν είναι ασφαλής. Ο εύκολος τρόπος να ελέγξετε αν ο portmapper σας είναι ασφαλής ή όχι, είναι να τρέξετε την εντολή strings(1) και να δείτε αν διαβάζει τα σχετικά αρχεία /etc/hosts.deny και /etc/hosts.allow. Υποθέτοντας ότι ο portmapper σας είναι ο /usr/sbin/portmap, μπορείτε να τον ελέγξετε με την εντολή : strings /usr/sbin/portmap | grep hosts. Στον δικό μου Η/Υ, απαντάει κάπως έτσι :


/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27

Πρώτα διορθώνουμε το αρχείο /etc/hosts.deny. Πρέπει να περιέχει τη γραμμή :


portmap: ALL

που θα αρνηθεί την πρόσβαση σε όλους. Ενώ έχουμε κλείσει την πρόσβαση μ' αυτόν τον τρόπο, τρέχουμε την εντολή rpcinfo -p γιά να ελέγξουμε ότι ο portmapper πραγματικά διαβάζει και κάνει ό,τι του λέει το αρχείο αυτό. (Η rpcinfo δεν πρέπει να δίνει έξοδο, ή, πιθανά, ένα μήνυμα λάθους.) Δεν θα έπρεπε να είναι απαραίτητο να επανεκκινήσουμε τον portmapper.

Το να κλείσουμε τον portmapper γιά όλους είναι πολύ δραστικό μέτρο. Συνεπώς τον ξανανοίγουμε, διορθώνοντας το αρχείο /etc/hosts.allow. Αλλά πρώτα, πρέπει να ξεκαθαρίσουμε τί θέλουμε να γράψουμε μέσα του. Βασικά, θα έπρεπε να περιέχει όλους τους Η/Υ που πρέπει να έχουν πρόσβαση στον portmapper μας. Στον τυπικό Η/Υ με Linux, ελάχιστοι άλλοι Η/Υ θα ήθελαν πρόσβαση root γιά οποιονδήποτε λόγο. Ο portmapper διευθύνει τα : nfsd, mountd, ypbind/ypserv, pcnfsd, και τις "r" services, όπως η ruptime και η rusers. Από τα παραπάνω, μόνο τα nfsd, mountd, ypbind/ypserv, και ίσως και ο pcnfsd, έχουν κάποια σημασία. Όλοι οι Η/Υ που χρειάζονται πρόσβαση στον δικό σας, θα έπρεπε να μπορούν. Ας πούμε ότι η διεύθυνση του Η/Υ σας είναι 129.240.223.254 , και ότι είναι συνδεδεμένος στο υποδίκτυο 129.240.223.0 , αν κάποιος άλλος Η/Υ θέλει πρόσβαση σ' αυτόν. (Αυτούς τους όρους του εισήγαγε το Networking HOWTO. Αν χρειαστεί, επιστρέψτε σ' αυτό γιά να φρεσκάρετε τη μνήμη σας.) Τότε, εισάγουμε τη γραμμή :


portmap: 129.240.223.0/255.255.255.0

στο αρχείο hosts.allow. Είναι το ίδιο με την διεύθυνση δικτύου που δίνουμε στο αρχείο route, και τη μάσκα υποδικτύου (subnet mask) που δίνουμε στο ifconfig. Γιά τη συσκευή eth0 στον Η/Υ μας, το ifconfig πρέπει να δείχνει :


...
eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320 
...

και η εντολή netstat -rn πρέπει να βγάζει :


Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
...
129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
...

(Η διεύθυνση δικτύου βρίσκεται στην πρώτη στήλη.)

Τα αρχεία hosts.deny και hosts.allow περιγράφονται στις αντίστοιχες man σελίδες με τα ίδια ονόματα.

ΣΗΜΑΝΤΙΚΟ : Μην βάζετε ο,τιδήποτε, εκτός από αριθμούς IP στις σχετικές με τον portmapper γραμμές αυτών των αρχείων. Τυχόν πίνακες αντιστοιχιών με ονόματα Η/Υ, μπορούν έμμεσα να προκαλέσουν δραστηριότητα του portmapper, που θα ξεκινήσει ψάξιμο στους πίνακες αντιστοιχιών, που έμμεσα μπορούν να προκαλέσουν δραστηριότητα του portmapper, που...

Τα παραπάνω λογικά πρέπει να κάνουν ασφαλέστερο τον server σας. Το μόνο (ναι, σιγά!) πρόβλημα που παραμένει, είναι κάποιος που μπαίνει ως root σε "έμπιστο" μηχάνημα (ή κάνει εκκίνηση με MS-DOS), και χρησιμοποιεί αυτό το προνόμιο γιά να στείλει αιτήσεις από ένα ασφαλισμένο (secure) port, ως οποιοσδήποτε χρήστης θα ήθελε να παρουσιάζεται ο ίδιος.

6.4 Το NFS και τα firewalls

Είναι πολύ καλή ιδέα να βάλετε firewall στο nfs, και να κατευθύνετε με portmap τα ports στον router ή στο firewall σας. Ο nfsd δρα στο port 2049, και με το udp και με το tcp πρωτόκολλο. Ο portmapper δρα στο port 111 (και με tcp και με udp), και ο mountd στα ports 745 και 747 (tcp και udp). Συνήθως. Φυσικά, πρέπει να ελέγξετε τα ports με την εντολή rpcinfo -p.

Αν, από την άλλη πλευρά, θέλετε το NFS να περνάει από firewall, υπάρχουν επιλογές στους νεώτερους NFSds και mountds, που τους κάνουν να χρησιμοποιούν μιά ειδική (όχι, όμως, πρότυπη) θύρα, που μπορεί να μένει ανοιχτή σε firewall.

6.5 Περίληψη

Αν χρησιμοποιείτε τα : hosts.allow/deny, root_squash, nosuid, και διάφορα προνομιούχα (privileged) χαρακτηριστικά των ports στο software των portmapper/nfs, θ' αποφύγετε πολλά από τα σήμερα γνωστά bugs του nfs, και θα μπορέσετε να αισθανθείτε σχεδόν σίγουροι τουλάχιστον γι' αυτά. Αλλά, ακόμη και μετά απ' όλ' αυτά : Όταν ένας εισβολέας έχει πρόσβαση στο δίκτυό σας, μπορεί να εμφανίσει περίεργες εντολές στο .forward σας, ή να διαβάσει το ταχυδρομείο σας, όταν γίνει export κατά NFS στο /home, ή το /var/spool/mail. Γιά τον ίδιο λόγο, ποτέ δεν θα 'πρεπε να δίνετε πρόσβαση στο ιδιωτικό σας κλειδί του PGP με το nfs. 'Η, τουλάχιστον, πρέπει να γνωρίζετε τον κίνδυνο που συνεπάγεται μιά τέτοια ενέργεια. Και τώρα γνωρίζετε ήδη μιά πλευρά αυτού του κινδύνου!

Το NFS και ο portmapper συναποτελούν ένα σύνθετο υποσύστημα, και άρα δεν είναι εντελώς απίθανο ν' ανακαλυφθούν νέα bugs, είτε στη βασική σχεδίαση, είτε στην υλοποίηση του συστήματος που χρησιμοποιούμε εμείς. Ακόμη και τρύπες ασφάλειας μπορεί να είναι ήδη γνωστές σήμερα, τις οποίες κάποιος χρησιμοποιεί με κακό σκοπό. Όμως, έτσι είναι η ζωή! Γιά να βρίσκεστε, λοιπόν, σε απόσταση ασφαλείας από τέτοια πράγματα, πρέπει τουλάχιστον να διαβάζετε τα newsgroups comp.os.linux.announce και comp.security.announce, ως το ελάχιστο δυνατόν που μπορείτε να κάνετε.


Next Previous Contents