NFS协议分析——wireshark实战

时间:2024-03-08 07:14:47

【理论课程FTP协议与NFS协议

实验目的

1、NFS协议的应用范围
??文件读写的时候?

2、NFS挂载操作的原理
整个协议,与文件的读写有什么关联??

3、NFS的安全机制
NFS的安全机制到底是啥??
SSL这种原理有借鉴之处吗? 如果有,效率是如何保障的?

4、NFS读写操作的原理
读?写操作会有什么不一样?一样?

5、学习使用Wireshark分析NFS的方法
【请忽略以上脑残问题!O(∩_∩)O哈哈~】

实验环境

操作机:Windows XP

实验工具

wireshark

学习NFS协议的挂载

这里我们结合着Wireshark来分析一下NFS协议数据,来学习一下它的挂载过程安全机制以及读写过程,以直观的方式进行学习。首先分析一下协议的挂载时所捕获的数据包:

上图中,IP地址为10.32.106.159是客户端10.32.106.62则为服务器端,我们逐条分析一下每个数据包:
1、客户端想连接服务器的NFS进程,于是询问应该使用哪个端口(GETPORT)。“Replay In 2”,说明2号数据包就是对于这个数据包的回应。
2、服务器回应客户端:NFS端口是2049(随机端口)。“Call In 1”说明这是对1号数据包的回应。
3、客户端尝试连接服务器的NFS进程判断2049端口是否被防火墙拦截NFS服务是否已经开启
4、服务器回应:我已收到请求,你可以连接我了。
5、客户端想连接服务器的mount服务,询问该服务的端口。但由于mount端口是随机生成的,因此客户端需要先进行询问。
6、服务器回应:我的mount服务端口是1234.
7、客户端尝试连接mount进程判断1234端口是否被防火墙拦截mount服务是否已经开启
8、服务器响应请求:你可以连接我了。
9、客户端提出要求,请求挂载(MNT)”/code”这个共享目录。NFS主要提供了 /code/document这两个共享目录,分贝被挂载到多台客户端的本地目录上。 当用户在这些本地目录进行文件的读写时,实际上实在NFS的服务器上进行。
10、服务器同意了客户端的请求,服务器端要求客户端使用file handle 0x75a18429进行目录的访问 (查看wireshark的封包详情)。
11、客户端尝试服务器端的NFS进程是否能连接上。
12、服务器回应可以连接。其实【11、12】完全没有必要,因为NFS一直处理连接的状态。
13、客户端要求查看文件句柄为0x75a18429的文件的属性。
14、服务器端为客户端提供了该文件系统的大小和空间使用率等属性,之后就可以在客户端看到这些信息了。
15、客户端要求查看文件句柄为0x75a18429的文件属性。
16、服务器为客户端提供该文件的属性。
利用portmap请求没有得到回复,这就说明很可能是防火墙相对端口进行了拦截;如果发现mount请求服务被拒绝,可以考虑检查共享目录的权限设置。

了解NFS的安全机制

NFS的安全机制主要包括对客户端的访问控制对用户的权限控制
a. 客户端的访问控制:通过IP地址实现。创建关键共享目录时可以指定哪些IP允许读写,哪些IP只允许读操作,哪些IP不给予任何权限。
b. 客户端的访问控制:下面借助试验来理解,试验场景【一个客户端上的用户admin在/code目录里新建了一个名为abc.txt 的文件,该文件的owner正常显示为admin。但是在另一台客户端上查看该文件时,owner却变成了nasadmin.】

我们关注一下第4个数据包。从上图中的Credentials中可以看到,用户在创建文件时并没有使用admin这个用户名,而是使用了admin的UID 501来代表自己的身份。而NFS协议是只认UID不认用户名的。当admin通过客户端创建了一个文件,那么UID 501就会被写到文件里面,成为了owner的信息。而当另一个客户端上的用户查看该文件的属性时,看到的就是UID 501。但是不同的客户端上UID值与其所对应的名称往往是不一致的。因此创建文件的客户端的UID 501表示的就是admin,但是换了客户端,UID就对应着nasadmin了。那么为了防止这样的问题,需要大家在实际的操作中,保证每个客户端的UID与用户名的映射是一致的。

了解NFS的读文件过程

筛选出NFS协议,研究NFS协议读取文件abc.txt的过程:

1、 客户端向服务器询问:我可以ACCESS0x75a18429吗【也就是进入/code】?
2、服务器端回应:允许进入。
3、客户端想要查看这个目录里的文件和文件的句柄。
4、服务器回应:客户端索要的信息【在wireshark封包详情中查看】。

可见abc.txt的file handle为0x056560e1

5、客户端询问file handle为0x056560e1的文件属性是什么。

6、服务器回应了该文件的权限、UID、GID以及文件的大小等信息。

7、客户端询问是否可以打开file handle为0x056560e1的文件。

8、服务器同意了请求,并给予了相应的权限。

9、从0x056560e1的偏移量为0的位置,也就是abc.txt文件的开头位置,读取(READ)131072字节的数据。

10、从0x056560e1的偏移量为131072的位置,再读取131072字节的数据。

148、服务器回应客户端,允许读取131072字节的数据。

288、同上。

这样,NFS就完成了文件的读操作。

了解NFS的写文件操作

将名为abc.txt的文件写入NFS共享文件夹的过程。首先依旧加入筛选条件nfs:

1、客户端向服务器发出请求,要求进入0x75a18429,也就是/code目录。

2、服务器接受请求。

4、客户端询问服务器,查找(LOOKUP)名为abc.txt的文件。因为在创建一个文件之前,需要首先检查一下是否有同名文件的存在。如果不存在同名文件,才能够继续写入,否则要询问用户是否覆盖原文件。

5、服务器回应没有这个文件。

6、客户端要求创建(CREATE)一个名为abc.txt的文件。

7、服务器答应了请求。在wireshark封包详情s面板中展开就可以找到文件的file handle为0x056560e1。

69、客户端要求从0x056560e1的偏移为0的位置,也就是abc.txt文件的开头,写入(WRITE)131072个字节。

104、服务器回应:我已经写完了。

130、客户端要求从0x056560e1的偏移为131072的位置,即abc.txt文件的开头,写入(WRITE)131072个字节。接下来的两个数据包同理。

302、服务器回复已经写入。下面两个数据包同理。

306、客户端询问,刚才所写的数据是否已经存盘,也就是COMMIT操作,只有经过COMMIT过的数据才算是真正的写好了。

307、服务器回应都保存好了。

308、客户端要求查看刚才所写入的文件的属性(GETATTR)。

309、服务器将文件的权限、UID、GID以及文件的大小等信息交给客户端。

由这个例子可以发现,写操作是多个WRITE Call连续发送过去的。其实我们刚才的读文件的操作也是如此。同时将多个请求一起发出,接下来等待回应的这种方法,比发一条回复一条,发一条回复一条的方式要更加有效率。特别是在高带宽高延迟的情况下,NFS的这种读写特性的优势就会非常的明显。对于写操作而言,如果我们在挂载的时候没有指定任何参数,那么就会采用默认的async(异步)写的方式。而与之相对应的是sync(同步)方式。如果在挂载时指定了sync参数,那么客户端就会先发送一个WRITE Call,等到收到Reply之后再发送下一个请求,也就是说,请求和回应是交替出现的。对于我们这个捕获文件而言,由于采用的是默认挂载方式,所以数据包的WRITE操作会有一个UNSTABLE,表示的是步的方式。如果是同步方式,则会出现FILE_SYNC的标志。