raw_socketserver设计文档(1)

　　socket( PF_INET, SOCK_RAW, IPPROTO_TCP );
　　
　　在RedHat 6.1下这两种socket都可以正常建立，内核支持了的。但是对于Solaris 2.6，如果以root身份truss跟踪这两个函数，发现第二个socket建立的时候 内核不支持这种情况下指定IPPROTO_TCP，库函数本身做了处理：
　　
　　so_socket(2, 4, 6, "", 1) Err#98 EPROTOTYPE
　　stat("/dev/rawip", 0xEFFFFAC4) = 0
　　so_socket(2, 4, 6, "/dev/rawip", 1) = 4
　　setsockopt(4, 65535, 4105, 0xEFFFFBB4, 4) = 0
　　
　　从执行效果看，这样的处理和Linux下的意义不同了。
　　
　　如果考虑广泛兼容性，应该扔弃第二种socket，全部以IPPROTO_RAW方式出现。这样的话，理论上可以考虑不用TCP/UDP协议，但是涉及client/server模式，显然应该继
　　续使用TCP/UDP。从突破防火墙角度看，还是以鬼子的ACK方式为好。UDP通信被很多防火墙屏蔽，TCP也好不到哪里去。而且按照目前的设想，等于仅仅使用TCP的头部概 念，并没有使用TCP协议的超时、重传等机制，更没有有限状态机介入，为什么不使用UDP呢？还是应该从防火墙角度考虑这个设计选择，具体问题具体分析吧。现在的难点是完全使用IPPROTO_RAW，写没多大问题，读有了麻烦，又需要重翻UNP；此外， 丢包是毫无疑问的，因此必须尽量设计成无状态方式(NFS Server就是一个例子)，这 个也仅仅是说说，技术问题尚未可知。
　　
　　关于内核传递IP报文到一个raw_socket，有几点需要注意，我们分别探讨之：
　　
　　1) TCP/UDP报文(IP报文负载为TCP/UDP)"永远"不会传递给raw_socket。Stevens介绍
　　的时候以BSD家族为例。
　　
　　对于Linux显然已经不适用这个结论，socket( PF_INET, SOCK_RAW, IPPROTO_TCP )
　　就可以接收到TCP报文，Linux内核是给了这个机会的，此时正常的TCP协议层也会收到TCP报文(后面我们会写测试代码验证它)。于是造成潜在的安全隐患，在无需
　　数据链路层和网卡混杂模式介入的情况下，利用raw_socket监视发往本机的TCP报文。尽管只有root才可以创建raw_socket，但获得创建raw_socket的机会和获得完整root权限相比要大得多。对于Solaris系统，内核应该是没有支持
　　socket( PF_INET, SOCK_RAW, IPPROTO_TCP )方式，尽管以root身份执行库函数并没有报错(此时库函数自己做了其他处理)。
　　
　　对于Windows 2K，从backend拖回来的程序执行效果以及袁哥分析代码的结论看，2K可能支持socket( PF_INET, SOCK_RAW, IPPROTO_TCP )这种方式。抓包分析
　　backdoor的client/server通信，发现除了预料中的ACK，还夹带有RST，只能说明2K内核传递IP报文到raw_socket的同时传递给了正常的TCP协议层，RST是由正常
　　TCP协议层发出的。NT/9x估计没戏。
　　
　　考虑我们要达到的目的，如果内核不给这个机会(传递TCP报文到raw_socket)，意味着ACK方式破产。UDP自然也不用想了。虽然Linux可以，但我们希望得到一个更广泛兼容的backdoor。可以从数据链路层考虑这个问题，牵扯的问题更多，没有太大必要。
　　
　　2) 对于伯克利实现而言，内核一般处理了几种常见ICMP报文(3种，回应请求、时间戳请求、地址掩码请求)，其余未处理ICMP报文交给raw_socket。注意内核并没有
　　处理上面三种请求报文的应答报文，想想ping.c的实现，如果内核处理icmp echo reply，即使指定IPPROTO_ICMP，处于应用层的ping也没有机会得到应答报文。这里所说内核处理，都是指处理入IP报文，对于发送IP报文，基本上任
　　由应用程序处理的，所以ping可以发送自己的icmp echo request。
　　
　　Linux/Solaris的实现有差别，提供给应用层更多机会。内核处理了icmp echo request，同时会交给socket( PF_INET, SOCK_RAW, IPPROTO_ICMP )，不同于BSD

9 7 3 1 2 3 4 4 8 :