Jeg er på ingen måte en PC sikkerhets ekspert. Men jeg har et lite råd for dere bekymret for sikkerheten. Men vær advart: Det er på ingen måte en komplett liste over NFS relaterte problemer og hvis du tror at du er sikker med en gang du har lest og implementert alt dette så har jeg ei bro jeg vil selge deg.
Denne delen er sansynligvis ikke noen bekymring dersom du er på et lukket nettverk hvor du må stole på alle brukerene, og ingen du ikke stoler på kan få adgang til maskiner på nettverket. F.eks, det bør ikke finnes noen måte å ringe til nettet på, og det bør på ingen måte være tilknyttet andre nettverk hvor du ikke stoler på alle som bruker det så vel som sikkerheten. Synes du at jeg er paranoid? Jeg er slett ikke paranoid. Det er bare et grunnleggende sikkerhetsråd. Og husk, det jeg sier her er bare begynnelsen på det hele. En sikker plass trenger en kunskapsrik administrering som vet hvor man skal finne informasjon om mulige sikkerhetsproblemer.
NFS har et grunnleggende problem i at klienten, hvis ikke fortalt noe annet, vil stole på NFS serveren og omvendt. Dette kan være farlig. Det betyr at dersom serverens root konto er brutt inn til kan det være ganske enkelt å komme inn til klientens root konto også. Og motsatt. Det finnes noen strategier mot dette, som vi vil komme tilbake til.
Noe du også bør lese er CERT rådene om NFS, mesteparten av teksten nedenfor omhandler saker CERT har skrevet råd om. Se ftp.cert.org/01-README for en oppdatert liste over CERT råd. Her er noen NFS relaterte råd:
CA-91:21.SunOS.NFS.Jumbo.og.fsirand 12/06/91
Sårbarheten angående Sun Microsystems, Inc. (Sun) Network
File System (NFS) og fsirand programmet. Disse sårbarhetene
gjelder SunOS versions 4.1.1, 4.1, og 4.0.3 på alle systemer.
Patcher er tilgjengelig for SunOS 4.1.1. En start patch for SunOS
4.1 NFS er også tilgjengelig. Sun vil gi fullstendige patcher for
SunOS 4.1 og SunOS 4.0.3 på et senere tidspunkt.
CA-94:15.NFS.Sårbarheter 12/19/94
Dette rådet beskriver et sikkerhets mål for å beskytte mot flere
sårbarheter i Network File System (NFS). Rådet kom av en økning i
root kompromisser fra inntrengere som bruker programmer til å
utnytte sårbarhetene.
CA-96.08.pcnfsd 04/18/96
Rådet beskriver en sårbarhet i pcnfsd programmet (også kjent som
rpc.pcnfsd). En patch er inkludert.
På klienten kan vi bestemme om vi ikke vil stole på serveren for mye
med noen valg med mount. For eksempel kan vi forby suid brukere å
jobbe på NFS filsystemet med nosuid valget. Dette er en god ide og du
bør tenke på å bruke dette på alle NFS monterte disker. Det betyr at
serverens root bruker ikke kan lage et suid-root program på
filsystemet, logge in på klienten som en normal bruker og så bruke
suid-root programmet til å bli root på klienten også. Vi kan også
totalt forby kjøring av filer på det monterte filsystemet med noexec
valget. Men dette er sansynligvis mer upraktisk enn nosuid siden
filsystemet sansynligvis inneholder minst noen script eller programmer
som trengs å kjøres. Du fører på disse valgene i valg(options)-
kolonnen, sammen med rsize og wsize, separert med kommaer.
På serveren kan vi bestemme at vi ikke ønsker å stole på klientens root konto. Vi kan gjøre det ved å bruke root_squash valget i exports:
/mn/eris/local apollon(rw,root_squash)
Dersom en bruker med UID 0 på klienten nå prøver å få adgang (lese,
skrive, fjerne) til filsystemet vil serveren bytte UIDen med den til
serverens `nobody' konto. Noe som betyr at root brukeren på klienten
ikke kan få adgang til eller forandre filer som bare root på serveren
kan få adgang til eller endre. Det er bra, og du bør sansynligvis
bruke root_squash på alle filsystemer du eksporterer. "Men root
brukeren på en klient kan fremdeles bruke 'su' til å bli en annen
bruker og få adgang til og forandre den brukerens filer!" sier du.
Svaret til det er: Ja, og det er sånn det er er, og må være med
Unix og NFS. Det har en viktig implikasjon: Alle viktige binær-filer
og andre filer bør eies av root, og ikke bin eller andre ikke-root
kontoer, siden den eneste kontoen klientenes root bruker ikke kan
få adgang til er serverens root konto. I NFSd man sidene er det
flere andre squash vald listet slik at du kan velge å mistro de du
liker (eller ikke) på klientene. Du har også valg til å squashe
hvilke som helt UID og GID områder du ønsker. Dette er forklart i
Linux NFSd man sidene.
root_squash er faktisk standard med Linux NFSd, for å gi root adgang
til et filsystem bruk no_root_squash.
En annen viktig ting er å forsikre seg om at nfsd sjekker at alle dens forespørsler kommer fra en bestemt port. Hvis den godtar forespørsler fra noen gamle porter på klienten kan en bruker uten spesielle privilegier kjøre et program som er lett å få tak i på Internet. Det snakker nfs protokoll og vil påstå at brukeren er den brukeren den ønsker å være. Spooky. Linux nfsd kjører denne sjekken som standard, på andre OSer må du slå på denne selv. Det ska være forklart i nfsd man sidene til OSet.
En annen ting. Aldri eksporter et filsystem til 'localhost' eller 127.0.0.1. Tro meg.
Den grunnleggende portmapperen, kombinert med nfsd har et design problem som gjør det mulig å komme til filer på NFS servere uten noen privilegier. Heldigvis er portmapperen til Linux relativt sikker mot dette angrepet, og kan gjøres sikrere ved å konfigurere adgangs lister i to filer.
Først editerer vi /etc/hosts.deny. Den bør inneholde linjen
portmap: ALL
som vil nekte alle adgang. Det er kanskje litt drastisk, så vi åpner
igjen ved å editere /etc/hosts.allow. Men først må vi finne ut hva vi
skal putte i den. Den bør i hovedsak inneholde alle maskiner som skal
ha adgang til din portmapper. Det er generelt veldig få maskiner som
har noen form for behov for adgang. Portmapperen administrerer nfsd,
mountd, ypbind/ypserv, pcnfsd og 'r' tjenester som ruptime og rusers.
Av disse er det bare nfsd, mountd, ypbind/ypserv og kanskje pcnfsd
som er viktige. Alle maskiner som trenger adgang til tjeneste på din
maskin bør gis adgang til det. La oss si at din maskinadresse er
129.240.223.254 og at de lever i subnettet 129.240.223.0 skal ha
adgang til den (det er termer introdusert i networking HOWTO, gå
tilbake og frisk opp minnet hvis du trenger det). Da skriver vi
portmap: 129.240.223.0/255.255.255.0
i hosts.allow. Det er det samme som nettverks adressen du gir til
route og subnet masken du gir til ifconfig. For devicen eth0 på denne
maskinen skal ifconfig vise
...
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
...
og netstat -rn skal vise
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 ...
(Nettverks adresse i første kolonne).
hosts.deny og hosts.allow filene er forklart i manual sidene med de
samme navnene.
VIKTIG: Putt aldri noe annet enn IP NUMMER i portmap linjene til disse filene. Host navn sjekker kan indirekte forårsake portmap aktivitet som vil starte host navn sjekker som kan indirekte forårsake portmap aktivitet som vil forårsake...
Tingene overfår vil gjør din server strengere. Det eneste gjenstående problemet (Ja, liksom!) er at noen knekker root (eller booter MS-DOS) på en maskin som stoles på og bruker det privilegiet til å sende ønsker fra en sikker port som hvilken som helst bruker de ønsker å være.
Det er en veldig god ide å ha brannmur på nfs og portmap porter i
din router eller brannmur. Nfsd opererer på port 2049, både udp og
tcp protokoller. Portmapperen på port 111, tcp og udp, og mountd på
port 745 ig 747, tcp og udp. Normalt. Du må sjekke portene med
rpcinfo -p kommandoen.
Hvis du derimot ønsker at NFS skal gå gjennom brannmuren er det noen valg for nyere NFSder og mountder som får dem til å bruke spesielle (ikke-standard) porter som kan være åpne i brannmuren.
Hvis du bruker hosts.allow/deny, root_squash, nosuid og priviligerte
porter valgene i portmapper/nfs programvaren så unngår du mange av de
nå velkjente feilene i nfs og kan nesten føle deg sikker på det i det
minste. Men fremdeles, etter alt det: Når en inntrenger har adgang til
ditt nettverk, kan han/hun få merkelige kommandoer til å oppstå i din
.forward eller mailbox fil hvis din /home eller
/var/spool/mail er mounted over NFS. Av samme grunn bør du aldri
bruke din private PGP nøkkel over nfs. Eller du bør i det minste
kjenne til risikoen ved det. Og nå vet du litt om det.
NFS og portmapperen gjør et komplekst undersystem og det er defor ikke helt usansynlig at nye feil vil oppdages, enten i det grunnleggende designet eller implementasjonen vi bruker. Det kan til og med være huller kjent nå, som noen utnytter. Men sånn er livet. For å holde kontroll på dette må du i det minste lese nyhetsgruppene comp.os.linux.announce og comp.security.announce som et absolutt minimum.