📄 565.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>apue</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="15.htm">上一层</a>][<a href="566.htm">下一篇</a>]
<hr><p align="left"><small>发信人: cloudsky (小四), 信区: Security <br>
标 题: RPC/XDR/NFS系列之----远程过程调用 <br>
发信站: 武汉白云黄鹤站 (Wed Feb 23 17:28:42 2000), 站内信件 <br>
★ 鉴别机制 <br>
在/usr/include/rpc/auth.h中有如下内容: <br>
/* <br>
* Authentication info. Opaque to client. <br>
*/ <br>
struct opaque_auth { <br>
enum_t oa_flavor; /* flavor of auth */ <br>
caddr_t oa_base; /* address of more auth stuff */ <br>
u_int oa_length; /* not to exceed MAX_AUTH_BYTES */ <br>
}; <br>
#define AUTH_NONE 0 /* no authentication */ <br>
#define AUTH_NULL 0 /* backward compatibility */ <br>
#define AUTH_SYS 1 /* unix style (uid, gids) */ <br>
#define AUTH_UNIX AUTH_SYS <br>
#define AUTH_SHORT 2 /* short hand unix style */ <br>
#define AUTH_DES 3 /* des style (encrypted timestamps) <br>
*/ <br>
#define AUTH_DH AUTH_DES /* Diffie-Hellman (this is DES) */ <br>
#define AUTH_KERB 4 /* kerberos style */ <br>
RPC定义了多种针对rpc client的鉴别机制,其中比较常见的是AUTH_UNIX <br>
和AUTH_DES两种鉴别方式。鉴别信息的具体格式和解释不是由RPC本身定义 <br>
的,而是由具体的鉴别机制定义。 <br>
在/usr/include/rpc/auth_unix.h中有如下内容: <br>
/* <br>
* Unix style credentials. <br>
*/ <br>
struct authunix_parms <br>
{ <br>
u_long aup_time; <br>
char *aup_machname; <br>
__uid_t aup_uid; <br>
__gid_t aup_gid; <br>
u_int aup_len; <br>
__gid_t *aup_gids; <br>
}; <br>
AUTH_UNIX鉴别机制定义的鉴别信息如上,首先是时间戳(rpc client的本地时间),其次 <br>
<br>
是rpc client所在主机名,接下来是当前进行RPC调用的用户UID、GID以及辅GID,辅GI <br>
D <br>
可能有多个。 <br>
scz注:显然AUTH_UNIX的鉴别信息很容易伪造成功,基于这种鉴别的保护都是极其脆弱 <br>
的, <br>
的, <br>
很多古老的NFS攻击就是利用了这个鉴别机制的脆弱。 <br>
★ RPC请求报文的一个例子(协议分析软件抓包) <br>
下面的包是这样抓到的,在Linux Server上启动NFS SERVER,然后在 <br>
98上用Omni NFS Client只读mount一个逻辑盘上来,然后删除该盘上 <br>
的文件,自然会删除失败。同时在98上运行snifferpro2.6,就是 <br>
deepin上载到202.101.106.14上的那个呀,抓到的报文很多,其中一 <br>
个如下: <br>
数据链路层 <br>
aa bb cc dd ee ff 目标MAC = aa:bb:cc:dd:ee:ff <br>
00 00 00 11 11 11 源MAC = 00:00:00:11:11:11 <br>
08 00 IP <br>
IP层 <br>
45 00 <br>
00 90 IP报文总长度,包括IP Header,144字节 <br>
4e 16 00 00 20 <br>
11 UDP <br>
44 20 IP报文头部校验和 <br>
c0 a8 43 6a 源IP = 192.168.67.106 <br>
c0 a8 43 6c 目标IP = 192.168.67.108 <br>
UDP层 <br>
03 e9 源PORT = 1001 <br>
08 01 目标PORT = 2049 <br>
00 7c UDP报文长度,包括UDP Header,124字节 <br>
c6 09 UDP校验和 <br>
RPC层 <br>
80 00 00 00 RPC Transaction ID = 2147483648 <br>
00 00 00 00 RPC Type = 0 ( RPC CALL ) <br>
00 00 00 02 RPC Version = 2 ( 目前必须是2 ) <br>
00 01 86 a3 远程程序号 = 100003 ( NFS ) <br>
00 00 00 02 远程程序版本号 = 2 <br>
00 00 00 0a 远程过程号 = 10 ( Remove file ) <br>
00 00 00 01 使用AUTH_UNIX鉴别机制 <br>
00 00 00 1c AUTH_UNIX鉴别信息总长度28个字节 <br>
12 34 56 78 rpc client本地时间戳 = 305419896 <br>
00 00 00 03 rpc client所在主机名3个字节,不包括结束的\0 <br>
73 63 7a 00 rpc client所在主机名为 scz ,注意是asciiz串 <br>
00 00 01 f4 uid = 500 ( scz ) <br>
00 00 00 64 gid = 100 ( users ) <br>
00 00 00 01 总共一个辅GID <br>
00 00 00 64 gid = 100 ( users ) <br>
00 00 00 00 使用AUTH_NULL鉴别机制 <br>
00 00 00 00 AUTH_NULL鉴别信息总长度0个字节 <br>
NFS层 <br>
ca ba eb fe 2a 68 0e 00 04 30 1d 00 04 03 00 00 <br>
NFS File Handle = 0xCABAEBFE2A680E0004301D0004030000 这里不做任何XDR转换 <br>
<br>
04 03 00 00 2a 68 0e 00 a1 a5 5a 4c 00 00 00 00 <br>
00 00 00 09 NFS File Name 9个字节,不包括结束的\0 <br>
69 70 73 70 6f 6f 66 2e 63 00 NFS File Name = ipspoof.c,注意是asciiz串 <br>
63 00 应该是些填充字节 <br>
为了方便协议分析,我修改了98和Linux下的MAC地址。 <br>
[scz@ /home/scz]> id <br>
uid=500(scz) gid=100(users) groups=100(users) <br>
[scz@ /home/scz]> <br>
XDR表示一个变长数据结构时,总是以该数据项总长度开始,比如上面的asciiz串 <br>
以及struct authunix_parms结构本身的外部表示。一个这样的RPC请求报文很容 <br>
易伪造成功,在系列灌水的后面会介绍这方面的内容。 <br>
★ 其他问题(需要讨论) <br>
1. 引入端口映射器虽然解决了RPC Server使用动态端口的问题,但也加大了服务器 <br>
方负载。 <br>
2. rpc client可以把刚刚向远程portmapper查询获得的rpc server之端口进行高速 <br>
缓存。只是当rpc server崩溃并重启后,存在不一致性。 <br>
3. portmapper的概念可以扩展到rpc server以外的服务,但不推荐,也不现实。 <br>
4. 需要阅读RFC 1057,以了解rpc client如何指定是使用udp上的rpc server还是 <br>
使用tcp上的rpc server。这个问题与clnt_create函数有关否? <br>
5. 使用你的rpcinfo,加深理解。 <br>
6. 查阅CORBA( Common Object Request Broker Architecture )的资料,看看和 <br>
RPC什么关系。 <br>
scz注:corba的概念很多朋友是从java编程中接触到的,我对之完全不了解, <br>
如果你了解,请介绍一二。想不到三年后我会再次遇到这个概念, <br>
想想当初疯狂修理java的时光,感慨很多。 <br>
★ 相关RFC以及参考资料 <br>
RFC 1057 << RPC: Remote Procedure Call Protocol Specification Version 2 >> <br>
它是Sun Microsystems 公司定义的ONC RPC标准,描述了本文大多数概念 <br>
RFC 1831 <br>
新版本,这是一个建议标准。 <br>
<<solaris网络编程指南>> <br>
Douglas E. Comer & David L. Stevens <br>
<< Internetworking With TCP/IP Vol III >> <br>
W.Richard Stevens <br>
<< TCP/IP Illustrated Volume I >> <br>
scz < mailto: cloudsky@263.net > <br>
2000.02.22 20:00 (待续) <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="566.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -