569.htm

unix高级编程原吗

  <br>
关于Mount协议，我们可以考虑自己写个程序调用MOUNTPROC_MNT过程 <br>
获取文件句柄，研究文件句柄是否可以猜测并由rpc client端自行制造。 <br>
  <br>
  <br>
★ NFS协议报文(用协议分析软件抓取) <br>
  <br>
我们在192.168.67.106上用NetXray3.03抓一切和192.168.67.108有关的UDP NFS报文 <br>
然后在192.168.67.107上执行了一个列目录的操作引发NFS报文的传输，得到下面的结果： <br>
  <br>
数据链路层 <br>
aa bb cc dd ee ff 00 00 21 d4 0b 92 08 00 <br>
  <br>
IP层 <br>
45 00 00 90 14 ef 00 00 40 11 5d 46 c0 a8 43 6b c0 a8 43 6c <br>
  <br>
UDP层，注意这里目标端口是2049(0x0801)，长度124字节(包括UDP Header) <br>
03 20 08 01 00 7c 0c 73 <br>
  <br>
RPC层，NFS是基于RPC的。总共116字节 <br>

14 f0 63 9c XID=0x14f0639c(351298460) <br>
00 00 00 00 RPC CALL报文 <br>
00 00 00 02 RPC版本号总为2 <br>
00 01 86 a3 远程程序号100003 <br>
00 00 00 02 远程程序版本号2( 100003 2 udp 2049 nfs ) <br>
00 00 00 01 远程过程号1(GetAttr) <br>
00 00 00 01 AUTH_UNIX鉴别机制 <br>
00 00 00 2c AUTH_UNIX鉴别信息总长度44个字节，从时间戳开始算 <br>
00 00 50 b0 rpc client本地时间戳(20656) <br>
00 00 00 12 client的主机名共18个字节 <br>
48 69 67 67 73 2e XX XX XX XX XX 2e 63 6f 6d 2e 63 6e 90 90 <br>
    higgs.xxxxx.com.cn，注意这里不要求是asciiz串，因为有长度字段， <br>
    90应该是填充字节。好象所有经XDR转换来的数据都以4字节为填充对 <br>
    齐单位。 <br>
00 00 01 f4 UID=500 <br>
00 00 00 64 GID=100 <br>
00 00 00 01 总共1个组 <br>
00 00 00 64 GID=100 <br>
00 00 00 00 使用AUTH_NULL鉴别机制 <br>
00 00 00 00 AUTH_NULL鉴别信息总长度0个字节 <br>
  <br>
NFS层，下面的数据全部是NFS File Handle，总共32个字节 <br>

ca ba eb fe 2a 68 0e 00 04 30 1d 00 04 03 00 00 <br>
04 03 00 00 2a 68 0e 00 a1 a5 5a 4c 00 00 00 00 <br>
  <br>
上面这个报文是一个由rpc client发起的RPC CALL报文，现在让我们简单猜 <br>
测一下这个NFS File Handle是如何组成的： <br>
  <br>
ca ba eb fe <br>
2a 68 0e 00 <br>
    显然这个数据0x000e682a = 944170，就是server端/home/scz/nfsexport <br>
    的i-node号 <br>
04 30 1d 00 <br>
04 03 00 00 <br>
04 03 00 00 <br>
2a 68 0e 00 同上，server端/home/scz/nfsexport的i-node号 <br>
a1 a5 5a 4c <br>
00 00 00 00 <br>
  <br>
scz注：要猜测一个NFS File Handle的编码方式，应该研究NFS Server Code。 <br>
       现在的问题是如何编程得到一个i-node号的生成号，反正我不知道，也 <br>
       不知道有什么工具可以让我看到这个i-node号的生成号，stat命令的显 <br>
       示中没有这个数据。 <br>
  <br>
  <br>
       根据以前讨论的结果，似乎只要拥有nfs server端的根文件句柄(export <br>
       出来的目录)，就可以做允许权限下的任意操作，那么第三者snoop到正在 <br>
       使用中的NFS File Handle，能否加以利用呢？句柄编码中是否含有client <br>
       端的IP信息？faint <br>
       还有，为了提高安全性，NFS SERVER可以限制句柄生命周期，我如何知道 <br>
       这种限制在当前实现中已经存在，句柄生命周期究竟多长，可以配置否？ <br>
  <br>
接下来的这个报文是由rpc server应答的RPC REPLY报文： <br>
  <br>
数据链路层 <br>
00 00 21 d4 0b 92 aa bb cc dd ee ff 08 00 <br>
IP层 <br>
45 00 00 7c 0c 84 00 00 40 11 65 c5 c0 a8 43 6c c0 a8 43 6b <br>
UDP层，注意这里源端口为2049 <br>
08 01 03 20 00 68 e3 43 <br>
  <br>
RPC层 <br>
14 f0 63 9c XID=0x14f0639c，rpc server从rpc client的请求报文复制该数据 <br>
00 00 00 01 RPC REPLY报文 <br>
00 00 00 00 status字段为0，表明Message Accepted <br>
00 00 00 00 使用AUTH_NULL鉴别机制 <br>
00 00 00 00 AUTH_NULL鉴别信息总长度0个字节 <br>

00 00 00 00 accept status字段为0，表明远程过程被成功调用并返回 <br>
  <br>
NFS层，下面的数据是依赖于GetAttr远程过程本身的 <br>
00 00 00 00 返回状态为0，OK <br>
00 00 00 02 是目录 <br>
00 00 41 ed 二进制111101101，rwxr-xr-x权限 <br>
00 00 00 02 Number of links = 2 <br>
00 00 01 f4 UID=500 <br>
00 00 00 64 GID=100 <br>
00 00 04 00 File Size       = 1024 <br>
00 00 10 00 File Block Size = 4096 <br>
00 00 00 00 File Device Number = 0 <br>
00 00 00 02 Num of File Blocks = 2 <br>
00 00 03 04 File System ID     = 772(0x0304) <br>
00 0e 68 2a File ID = 944170(0x0e682a) <br>
38 ba f6 bf 00 00 00 00 st_atime <br>
38 b9 95 c7 00 00 00 00 st_mtime <br>
38 b9 95 c7 00 00 00 00 st_ctime <br>
  <br>
可以在192.168.67.108上执行stat /home/scz/nfsexport，看看输出 <br>
结果和这里的报文信息什么关系。 <br>
  <br>
  <br>
★ 鉴别 <br>
  <br>
NFS系统依赖Mount协议提供的鉴别，nfs server本身不对nfs client的请求进行鉴别。 <br>
而Mount协议一般使用RPC的AUTH_UNIX/AUTH_NONE鉴别机制，前面提过，这些鉴别机制 <br>
本身存在安全问题。一旦nfs client获得了一个远程目录树的根句柄，就可以对该远 <br>
程目录树进行很多操作。 <br>
  <br>
早期NFS版本中，nfs server使用一种固定的方式创建32字节长的句柄。于是nfs client <br>
可以针对任意的nfs server端export出来的文件制造句柄，从而绕过Mount协议提供的 <br>
鉴别保护。 <br>
  <br>
★ NFS/Mount协议中可能存在的安全问题 <br>
  <br>
    1. 考虑编写一个程序，利用Mount协议获取server端的文件句柄，研究句柄可能 <br>
       的编码方式，以及当前是否使用着AUTH_UNIX鉴别机制。这个也可以通过协议 <br>
       分析软件达到目的，但我觉得还是编程更能锻炼你。 <br>
  <br>
       利用这个程序检查某个nfs server是否具有一定安全性。 <br>
       主要是指检查server端的i-node generation number是否随机化了。 <br>
       scz注：如此含混，只因为我对inode数据结构的C语言定义不了解，sigh <br>
  <br>
    2. 写一个程序，利用Mount协议提供的远程过程，获取nfs server端export出来 <br>

       的远程目录清单。实际上就是showmount -e 达到的效果，如果你觉得自己编 <br>
       写这个程序比较困难，可以找到showmount的源代码研究研究。 <br>
  <br>
    3. NFS版本3与2相比，句柄和magic cookie有了变化，句柄由固定大小的32字节 <br>
       变成可变大小最多64字节。版本3允许nfs server在大文件句柄(安全)和小文 <br>
       件句柄(高效)之间作出选择。 <br>
  <br>
★ 相关RFC以及参考资料 <br>
  <br>
RFC 1094 << NFS: Network File System Protocol Specification >> <br>
  <br>
Sun Microsystems 公司定义的NFS协议版本2和mount协议 <br>
  <br>
RFC 1813 << NFS Version 3 Protocol Specification >> <br>
  <br>
NFS协议的第3版 <br>
  <br>
Douglas E. Comer & David L. Stevens <br>
<< Internetworking With TCP/IP Vol III >> <br>
  <br>
W.Richard Stevens <br>
<< TCP/IP Illustrated Volume I >> <br>

  <br>
scz < mailto: [e-mail] > <br>
2000.02.29 11:50 (待续) <br>
  <br>
  <br>
  <br>
-- <br>
            我问飘逝的风：来迟了？ <br>
            风感慨：是的，他们已经宣战。 <br>
            我问苏醒的大地：还有希望么？ <br>
            大地揉了揉眼睛：还有，还有无数代的少年。 <br>
            我问长空中的英魂：你们相信？ <br>
            英魂带着笑意离去：相信，希望还在。 <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="15.htm">上一层</a>][<a href="570.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>