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