Verder Terug Inhoud

6. Security en NFS

Ik ben helemaal geen computer security expert. Maar ik heb een klein advies voor de security bewusten. Maar wees gewaarschuwd: Dit is bij lange na geen komplete lijst van de NFS gerelateerde problemen en als je denkt dat je veilig bent als je alles gelezen en geimplementeerd hebt heb je het mis.

Deze sectie is waarschijnlijk van geen belang als je op een gesloten netwerk zit met allemaal vertrouwde gebruikers en niemand die je niet vertrouwd kan op je netwerk inbellen, en het zou op geen manier verbonden met een ander netwerk waar je niet alle gebruikers vertrouwd. Vindt je dat ik parnoide klink? Dat ben ik helemaal niet. Dit is gewoon een algemeen veiligheids advies. En onthoud, de dingen die ik net heb gezegd is nog maar het begin. Een veilige site heeft een vlijtige en veel begrijpende admin die weet waar hij informatie kan vinden over aktuele en potentiele security problemen.

NFS heeft een basis probleem de client, zo niet anders om, vertrouwd de NFS server en omgekeert. Dit kan slecht zijn. Het betekend dat als het root account van de server is doorbroken kan het best simpel zijn om die van de client ook te doorbreken. En andersom. Er zijn een aantal kopie strategieen voor dit, waar we op terug komen.

Iets dat je moet lezen zijn de CERT adviezen over NFS, de meest tekst hieronder gaat over onderwerpen waar CERT adviezeurs over hebben geschreven. Zie ftp.cert.org:/01-README voor een lijst van CERT adviziezen. Hier zijn enkele NFS gerelateerde adviezen:


CA-91:21.SunOS.NFS.Jumbo.and.fsirand                            12/06/91
     Kwetsbaarheden betreffende Sun Microsystems, Inc. (Sun) Netwerk
     File systeem (NFS) en het fsirand programma. Deze kwetsbaarheden
     betreffen SunOS versies 4.1.1, 4.1 en 4.0.3 op alle architecturen.
     Patches zijn verkrijgbaar voor SunOS 4.1.1. Een eerste parch voor
     SunOS 4.1 is ook verkrijgbaar. Sun zal komplete patches beschikbaar
     stellen voor SunOS 4.1 en SunOS 4.0.3 later.

        
CA-94:15.NFS.Vulnerabilities                                    12/19/94
     Dit advies beschrijft veiligheid middelen om te bewaken tegen verschillende
     kwetsbaarheden in het Netwerk file systeem (NFS). De adviseur stond
     versteld van het stijgende aantal root doorbraken door indringers 
     door het gebruik van tools om de kwetsbaarheden te misbruiken.

CA-96.08.pcnfsd                                                 04/18/96
     Dit advies beschrijft de kwetsbaarheden in het pcnfsd programma (ook
     bekend als rpc.pcnfsd). Er zit een patch bij.

6.1 Client Veiligheid

Op de client kunnen we besluiten dat we de server niet te veel willen vertrouwen op een paar manieren dit doen we met mount opties. Bijvoorbeeld we kunnen suid programma's niet laten werken vanaf het NFS file systeem met de nosuid optie. Dit is een goed idee en je moet overwegen dit te gebruiken bij elke met NFS gemounte disk. Dit betekend dat de root gebruiker van de server geen suid-root programma kan maken op het file systeem en dan inlogd als een normale gebruiker op de client om dan het suid programma te gebruiken om ook root op de client te worden. We kunnen ook het uitvoeren van files op het NFS gemounte file systeem verbieden met de noexec optie. Maar dit is niet zo handig als de nosuid optie sinds omdat het normaal is dat een filesysteem nog een paar scriptjes of programmas inhoud die uitgevoerd moeten worden. Je vult deze opties in in de opties kolom, met de rsize en wsize optie, gescheiden door komma's.

6.2 Server security: nfsd

Op de server kunnen we beslissen dat we het root account op client niet vertrouwen. Dit kunnen we doen door het gebruik van de root_squash optie in exports:


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

Nu, als een gebruiker met UID 0 op de client probeert toegang (lezen, schrijven, verwijderen0 te krijgen op het filesysteem van de server veranderd de server het UID op de server naar het 'nobody' account. Wat betekend dat root op de client geen toegang krijgt tot files die alleen root op de server toegang tot kan krijgen. En je zou root_squash op alle geexporteerde filesystemen moeten gebruiken. Maar root op de client kan nog steeds elke gebruiker worden met het su commando en zo alsnog de file editten. Dit heeft een belangrijke betekenis: Alle belangrijke binaries en files moet van root zijn, en niet bin of een ander niet root account, sinds dat het enige account is dat root gebruiker op de client niet kan gebruiken. In de NFSd man page zijn er nog enkele andere squash opties zodat je iedereen kan wantrouwen die je wilt wantrouwen op de client. Je hebt ook de mogelijkheid om een bepaalt UID en GID bereik te squashen. Dit is beschreven in de Linux NFSd man page.

root_squash is eigenlijk standaard met Linux NFSd. Je kan root toegang geven tot je filesysteem met de no_root_squash optie.

Iets anders belangrijks is zeker te weten dat nfsd checkt om alle zijn aanvraag komt van een bevoorrechte poort. Als het aanvragen toestaat van elke oude poort op de client kan een gebruiker zonder speciale priveleges een programma verkregen van het internet makkelijk uitvoeren. Het praat tegen het nfs porotocol en zegt elke gebruiker te zijn die hij maar wil zijn. Griezelig. De linux nfsd checkt dit automatisch, bij een ander OS moet je dit zelf aanzetten. Dit is beschreven in de nfsd man page van je OS.

Iets anders. Exporteer nooit een file systeem naar 'localhost' of 127.0.0.1. Vertrouw me.

6.3 Server security: de portmapper

De basis portmapper, in combinatie met nfsd heeft een design probleem dat het mogelijk maakt om files te krijgen om de NFS server zonder enige priveleges. Gelukkig is de portmapper die de meeste Linux distributies gebruiken relatief veilig tegen deze aanval, en kan nog veiliger gemaakt worden door het configureren van toegangslijsten in twee files.

Niet alle Linux distributies zijn identiek gemaakt. Sommige schijnbare bij de tijdse distributies heben geen beveiligbare portmapper, zelfs niet vandaag de dag, vele jaren nadat de kwetsbaarheid werd ontdekt. Op z'n minst een distributie heeft de man page voor een beveiligbare portmapper maar de echte portmapper kan niet beveiligd worden. De makkelijkste manier om dit na te kijken is met het commando strings en kijk of hij de relevante files leest, /etc/hosts.deny en /etc/hosts.allow. Aannemend dat je portmapper /usr/sbin/portmapper is. Je kunt met dit commando kijk of je portmapper beveiligbaar is: strings /usr/sbin/portmap | grep hosts. Op mijn machine komt er dit:


/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

Eerst editten we /etc/hosts.deny. De volgende regel moet er in staan


portmap: ALL

wat toegang voor iedereen ontzegt. Nu portmapper gesloten is gaan we eerst even kijken of dat echt zo is met rpcinfo -p. rpcinfo zou als het goed is geen uitvoer moeten geven of misschien een fout bericht. Portmapper opnieuw opstarten zou niet nodig moeten zijn.

De portmapper afsluiten voor iedereen is een beetje drastisch, dus we openen hem weer door het veranderen van de /etc/hosts.allow file. Maar eerst moeten we uitvinden wat we erin gaan zetten. Het zijn normaal alle machines die toegang moeten hebben tot de portmapper. Normaal zijn er erg weinig machines die toegang moeten hebben voor elke reden. De portmapper onderhoud nfsd, mountd, ypbind/ypserv, pcnfsd, en de 'r' diensten zoals ruptime en rusers. Van deze zijn alleen nfsd, mountd, ypbind/ypserv en misschien pcnfsd van belang. Alle machines die daar toegang tot moeten hebben moeten dat ook hebben. Laten we zeggen dat het adres van je machine 129.240.233.254 is en dat hij leeft op het subnet 129.240.223.0 moet er toegang tot hebben (dat zijn termen die zijn geinteresseert door de networking HOWTO, ga terug en fris je geheugen op als dat nodig is). Dan schrijven we


portmap: 129.240.223.0/255.255.255.0

in hosts.allow. Dit is het zelfde netwerk adres als dat wat je geeft aan route en het subnet mask welke je aan ifconfig geeft. Voor het apparaat eth0 op deze machine zou ifconfig dit moeten geven


...
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 
...

en netstat -rn zou dit moeten geven


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
...

(Netwerk adres in de eerste kolom).

De hosts.deny en hosts.allow files worden bescreven in de gelijknamige man pagina's.

BELANGRIJK: Zet niets anders dan IP NUMMER in de portmap regels van deze files. Host naam lookups kunnen inderict lijden tot portmap activiteit veroorzaken welke hostnaam lookups opwekt wat er indirect portmap activiteit veroorzaakt welke hostnaam lookups opwekt....

Het bovenstaande zou je server vaster moeten maken. Het enige overblijvende probleem (Ja, juist) is iemand die root verbreekt (of MS-DOS opstart) op een vertrouwde machine en het recht gebruikt om vragen te sturen van de veilige poort als elke gebruik willen ze zijn.

6.4 NFS en firewalls

Het is een erg goed idee om je nfs en portmap poorten te firewallen in je router of firewall. De nfsd opereerd op poort 2049, beiden udp en tcp protocollen. De portmapper op poort 111, tcp en udp, en mountd op port 745 en 747, tcp en udp. Normaal. Moet je de poorten checken met het rpcinfo -p commando.

Als je wilt dat NFS door de firewall gaat zijn er opties in de nieuwere NFSds en mountds om ze een specifieke (niet standaard) poort te laten gebruiken welke geopend kan worden in de firewall.

6.5 Samenvatting

Als je de hosts.allow/deny, root_squash, nosuid en privileged port gebruikt in de portmapper/nfs software vermijd je veel van de nu bekende bugs in nfs en kan bijna veilig voelen over dat ten minste. Maar nog steeds, na dat alles: Als een indringer toegang heeft tot je netwerk, s/he kan hij vreemde commandos laten verscheinen in je .forward of leest je mail als /home of /var/spool/mail is geexporteerd met NFS. Om de zelfde reden, moet je nooit je PGP prive sleutel benaderen over nfs. Of op z'n minst zou je het risico moeten kennen. En je weet er een beetje van.

NFS en de portmapper maken een complex subsysteem en daarom is het helemaal niet vreemd dat nieuwe bugs worden gevonden, in het basis design of in de implementatie die wij gebruiken. Er zijn misschien zelfs gaten die jij kent, welke iemand anders misbruikt. Maar dat is leven. Om op de hoogte te blijven van zulke dingen lees dan op z'n minst de nieuwsgroepen comp.os.linux.announce en comp.security.announce als een minimum.


Verder Terug Inhoud