運維安全之NFS安全

說起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的身份驗證

下面闡述一下V3的連線過程：

NFSv3協議的伺服器端是無狀態的，所以就算機器重啟了，NFS服務起來以後，客戶端依然可以拿著舊檔案控制程式碼繼續讀寫檔案。但是伺服器端的lockd程式是有狀態的，重啟就有點麻煩，解決方案是伺服器端的rpc.statd讓客戶端報告自己手裡的鎖，然後重新讓lockd恢復鎖狀態。

客戶端問伺服器端的portmap：rpc.mount目前的用哪個埠？客戶端向伺服器端的rpc.mount請求掛載NFS； 伺服器端的rpc.mount判斷許可權後給客戶端一個檔案控制程式碼； 客戶端使用這個控制程式碼與伺服器端的nfsd交流（使用TCP/UDP的2049埠），以讀寫檔案。

NFS V3的驗證機制及安全：

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分配出去的埠。