說起NFS是（Network File System）的縮寫，相信這很多人都知道。其最大的優點就是可以在網絡里使不同的主機，不同的操作系統來互相分享文件。由于NFS不像WEB那樣經常使用，一般也就用到的時候去網上隨便找篇文檔安裝一下，剩下的就是能用就行了。所以安全性往往是比較容易忽略的問題。
NFS的聯動進程有nfsd，rpc.mountd，rpc.statd， locked，rpc.idmapd，rpc.gssd，rpc.svcgssd，其主進程nfsd使用的是TCP/UDP的2049端口，其中TCP協議是在V3版本才引入的。下面是NFS的發展歷程：
NFS V1是SUN公司研發，包含在SUN操作系統里。
NFS V2是最原始的NFS協議，在RFC1904中有相關描述，這個版本是基于UDP的，單個文件最大支持4G
NFS V3在RFC1813中描述，相對于V2增加了TCP協議的相關支持，安全異步，服務端ACL，V3相對于V2來說性能上有一個很大的提升，但是安全性并沒有多少改進。
NFS V4在RFC3530中描述，相對于V3版本，它把lock喝mount整合進協議中，開發了新的AC L控制機制，引入對UTF-8字符集的支持，NFS V4要求所有實現都必須支持kerberos的身份驗證，替代了原有的基于UID/GID的身份驗證
NFSv3協議的服務器端是無狀態的，所以就算機器重啟了，NFS服務起來以后，客戶端依然可以拿著舊文件句柄繼續讀寫文件。但是服務器端的lockd進程是有狀態的，重啟就有點麻煩，解決方案是服務器端的rpc.statd讓客戶端報告自己手里的鎖，然后重新讓lockd恢復鎖狀態。
客戶端問服務器端的portmap：rpc.mount目前的用哪個端口？客戶端向服務器端的rpc.mount請求掛載NFS； 服務器端的rpc.mount判斷權限后給客戶端一個文件句柄； 客戶端使用這個句柄與服務器端的nfsd交流（使用TCP/UDP的2049端口），以讀寫文件。
NFS V3及其附屬協議采用標準的RPC AUTH_SYS（又稱AUTH_UNIX）機制驗證掛載后的客戶端對具體文件的權限，服務器完全信任客戶端聲名的自己的權限（其實不能被稱為是“驗證”了
大概過程就是客戶端會在讀寫之前告訴服務器自己的UID和GID，然后NFS就把這些ID視同自己系統上的ID來驗證權限；
客戶端可以很容易偽造出高權限的ID以達到攻擊的目的，防御的臨時解決之道是不讓NFS暴露在公有網絡上且不打開NFS的root權限（是比較弱的防御）
還有一個麻煩是，不同客戶端上同一個username的UID想保持同步是件不容易的事。
不要把包含配置文件的目錄export出去
export整個文件系統的根出去，而不是export文件系統中某個目錄出去。因為即使只是export一個目錄出去，攻擊者也可能通過猜測的方式得到文件系統中其它目錄的讀寫權限。比如說一個ext3掛載在/mnt/下了，用NFS export/mnt/data1/出去，攻擊者就可能讀寫/mnt/data2/下的文件。這顯然不是我們希望的，因此不如干脆共享整個文件系統（也就是/mnt/）出去。或者也可以使用NFS的substree_check來幫我們做檢查來防止這種入侵，但是這個選項會較大幅度降低NFS的性能
如果一個文件系統掛載點是另一個文件系統的子目錄，那么父系統開啟crossmnt或者子系統開啟nohide就可以把兩個文件系統都共享出去，使用這個選項的時候要小心，別共享了自己不想共享的內容出去
雖然nfsd固定使用2049端口，但是lockd、mountd、statd都使用portmap隨機分配的端口，這讓防火墻很難配置，而且還可能占用還沒起來的其它服務的端口。可以在/etc/sysconfig/nfs中把這些進程的端口都配置成固定的，這樣配置防火墻（只放行自己信任的IP）就容易了
rpcinfo?-p可以查看portmap分配出去的端口。