云谷分布式端口扫描与代理验证系统(一)简介

时间:2024-02-18 07:27:28

好长时间不写博客了。今天给大家带来一个很有价值也很有意义的东西的完整实现过程,这个东西就是

分布式端口扫描与代理验证系统

名字有点长,但是其实很容易理解,这个就是一个可以用来快速扫描免费代理的程序集合,只不过程序多了就成为了系统。本分布式扫描系统最终实测

单节点每天能够扫描5万个HTTP代理和3000个Socks5代理。

可以说效果还是相当不错的。

 

首先要解释的就是免费代理,就正常情况来说,我们会遇到的网络代理有HTTP代理和Socks4/5代理两大种类,Socks4代理年代久远,因此也以Socks5为主。 表面上看免费代理和我们很远,其实很近

比如IE浏览器就可以设置代理

image

 

QQ登陆也可以使用代理进行登陆

image

使用代理登陆以后,就能够隐藏自己的IP,躲过各类限制。实现类似刷票、群发邮件、群发信息等功能 。可以说,随着互联网的越发发达,代理的作用一定是越来越大的,即使过渡到IPV6以后,代理的概念也同样存在。 因为我对代理其实也是一窍不通,TCP原理学的太差,因此今天说讨论的就是如何找寻代理里面最简单的高匿名代理 ,说的简单点就是没有用户名密码的公开免费代理


下面是详细的实现过程--

目前市面上能够全自动扫描代理的系统也有人在卖,价格在3000-30000不等,那么我为什么要把整个实现过程写下来呢,主要有如下四点原因。


1、看不惯有些代理销售系统的代理有效率那么低却还在拿出来卖钱。
2、告诉大家看上去很难实现的功能其实只要你能坚持10-20个小时的Google百度,都可以实现。
3、进一步探索云谷分布式端口扫描与代理验证系统的效率提升点。
4、将系统真正的开源与商业化,既能满足普通大众的零星代理需求,又能为真正需要高时效高稳定代理的商业地方提供合理的收费服务

本篇是开头,在本文里面向大家介绍整个系统的结构和里面说用到的各类技术点

在本系统中,涉及到的主要技术有如下:
一、端口扫描
 

端口扫描的核心技术有两个

1、TCP SYN半连接扫描技术

2、IP地址段分拣技术

 

第一部分:TCP SYN半连接扫描技术

首先先给大家补充一下端口扫描的相关知识(以下扫描知识来源于网络)

常见的扫描类型有以下几种:

image

秘密扫描

秘密扫描是一种不被审计工具所检测的扫描技术。它通常用于在通过普通的防火墙或路由器的筛选(filtering)时隐藏自己。秘密扫描能躲避IDS、防火墙、包过滤器和日志审计,从而获取目标端口的开放或关闭的信息。由于没有包含TCP 3次握手协议的任何部分,所以无法被记录下来,比半连接扫描更为隐蔽。但是这种扫描的缺点是扫描结果的不可靠性会增加,而且扫描主机也需要自己构造IP包。现有的秘密扫描有TCP FIN扫描、TCP ACK扫描、NULL扫描、XMAS扫描和SYN/ACK扫描等。 

 

1)Connect扫描:

此扫描试图与每一个TCP端口进行“三次握手”通信。如果能够成功建立接连,则证明端口开发,否则为关闭。准确度很高,但是最容易被防火墙和IDS检测到,并且在目标主机的日志中会记录大量的连接请求以及错误信息。

TCP connect端口扫描服务端与客户端建立连接成功(目标端口开放)的过程:
① Client端发送SYN;
② Server端返回SYN/ACK,表明端口开放;
③ Client端返回ACK,表明连接已建立;
④ Client端主动断开连接。
建立连接成功(目标端口开放)如图所示

 

image

 

TCP connect端口扫描服务端与客户端未建立连接成功(目标端口关闭)过程:
① Client端发送SYN;
② Server端返回RST/ACK,表明端口未开放。
未建立连接成功(目标端口关闭)如图所示。

优点:实现简单,对操作者的权限没有严格要求(有些类型的端口扫描需要操作者具有root权限),系统中的任何用户都有权力使用这个调用,而且如果想要得到从目标端口返回banners信息,也只能采用这一方法。
另一优点是扫描速度快。如果对每个目标端口以线性的方式,使用单独的connect()调用,可以通过同时打开多个套接字,从而加速扫描。
缺点:是会在目标主机的日志记录中留下痕迹,易被发现,并且数据包会被过滤掉。目标主机的logs文件会显示一连串的连接和连接出错的服务信息,并且能很快地使它关闭。

 

2)SYN扫描:

扫描器向目标主机的一个端口发送请求连接的SYN包,扫描器在收到SYN/ACK后,不是发送的ACK应答而是发送RST包请求断开连接。这样,三次握手就没有完成,无法建立正常的TCP连接,因此,这次扫描就不会被记录到系统日志中。这种扫描技术一般不会在目标主机上留下扫描痕迹。但是,这种扫描需要有root权限。

 

image

 

端口开放:1、Client发送SYN  2、Server端发送SYN/ACK 3、Client发送RST断开(只需要前两步就可以判断端口开放)

端口关闭:1、Client发送SYN  2、Server端回复RST(表示端口关闭)

优点:SYN扫描要比TCP Connect()扫描隐蔽一些,SYN仅仅需要发送初始的SYN数据包给目标主机,如果端口开放,则相应SYN-ACK数据包;如果关闭,则响应RST数据包;

 

3)NULL扫描:

反向扫描----原理是将一个没有设置任何标志位的数据包发送给TCP端口,在正常的通信中至少要设置一个标志位,根据FRC 793的要求,在端口关闭的情况下,若收到一个没有设置标志位的数据字段,那么主机应该舍弃这个分段,并发送一个RST数据包,否则不会响应发起扫描的客户端计算机。也就是说,如果TCP端口处于关闭则响应一个RST数据包,若处于开放则无相应。但是应该知道理由NULL扫描要求所有的主机都符合RFC 793规定,但是windows系统主机不遵从RFC 793标准,且只要收到没有设置任何标志位的数据包时,不管端口是处于开放还是关闭都响应一个RST数据包。但是基于Unix(*nix,如Linux)遵从RFC 793标准,所以可以用NULL扫描。   经过上面的分析,我们知道NULL可以辨别某台主机运行的操作系统是什么操作系统,是为windows呢?还是Unix?

端口开放:Client发送Null,server没有响应

 

image

 

端口关闭:1、Client发送NUll   2、Server回复RST

 

image

说明:Null扫描和前面的TCP Connect()和SYN的判断条件正好相反。在前两种扫描中,有响应数据包的表示端口开放,但在NUll扫描中,收到响应数据包表示端口关闭。反向扫描比前两种隐蔽性高些,当精确度也相对低一些。

用途:判断是否为Windows系统还是Unix

4)FIN扫描:

与NULL有点类似,只是FIN为指示TCP会话结束,在FIN扫描中一个设置了FIN位的数据包被发送后,若响应RST数据包,则表示端口关闭,没有响应则表示开放。此类扫描同样不能准确判断windows系统上端口开发情况。

端口开放:发送FIN,没有响应

端口关闭:1、发送FIN  2、回复RST

 

5)ACK扫描:

扫描主机向目标主机发送ACK数据包。根据返回的RST数据包有两种方法可以得到端口的信息。方法一是: 若返回的RST数据包的TTL值小于或等于64,则端口开放,反之端口关闭,如图所示。

image

 

6)Xmas-Tree扫描:

通过发送带有下列标志位的tcp数据包

                                URG:指示数据时紧急数据,应立即处理。

                                PSH:强制将数据压入缓冲区。

                                 FIN:在结束TCP会话时使用。

正常情况下,三个标志位不能被同时设置,但在此种扫描中可以用来判断哪些端口关闭还是开放,与上面的反向扫描情况相同,依然不能判断windows平台上的端口。

端口开放:发送URG/PSH/FIN,没有响应

 

image

 

端口关闭:1、发送URG/PSH/FIN,没有响应   2、响应RST

 

image

 

XMAS扫描原理和NULL扫描的类似,将TCP数据包中的ACK、FIN、RST、SYN、URG、PSH标志位置1后发送给目标主机。在目标端口开放的情况下,目标主机将不返回任何信息。

 

7)Dump扫描:

也被称为Idle扫描或反向扫描,在扫描主机时应用了第三方僵尸计算机扫描。由僵尸主机向目标主机发送SYN包。目标主机端口开发时回应SYN|ACK,关闭时返回RST,僵尸主机对SYN|ACK回应RST,对RST不做回应。从僵尸主机上进行扫描时,进行的是一个从本地计算机到僵尸主机的、连续的ping操作。查看僵尸主机返回的Echo响应的ID字段,能确定目标主机上哪些端口是开放的还是关闭的。

 

上面介绍了扫描技术的基本知识,下面就要说说扫描技术的实现。

因为我无可避免的倾向于使用.NET来实现,因此在实现之初就一直在搜寻.NET的实现方式,可惜事与愿违,真正能够完美运行的代码始终找不到,不过虽然这样,还是要把在实现过程中的可行性方案做一个总结

 

1、Win32原生代码实现SYN扫描

2、.NET原生代码实现SYN扫描

3、Winpcap实现SYN扫描

4、基于Winpcap的PCap.net实现SYN扫描

5、基于Winpcap的SharpCap实现SYN扫描

 

其中1可以在网上找到大量实现代码,2可以找到实现的代码,但是只有一个不开源的成功案例,3、4、5在理论上是十分可行并且灵活但是我未能将最终代码实现。

而最终我选择的方案是

使用已经被广为赞颂的Win32原生S扫描器进行快速扫描,配合.NET管道技术,最终以.NET 控制台程序显示出来

至于2、3、4、5如何实现,还盼广大网友和爱好者和我继续交流,我也会利用业余时间早日钻研出来。

 

第二部分:IP地址段分拣技术

IPV4中的IP地址总数有40多亿,假设常见的代理端口数量大概有30个,则全部扫描一遍则是1200亿个机会,假设分布式系统每秒能够扫描100万个机会,那么也需要扫描33个小时才能扫完一遍,效率太低,而同样是IP地址,机房的IP能生产免费代理的机会肯定要远远高于家庭ADSL网络IP产生的机会。

所以,知道哪些IP段属于机房,属于数据中心,属于高校等等就显得异常重要。

那么,我们如何才能得知呢,经验当然是首要考虑的,因此在百度或者Google能搜索到大量的例如“全国IDC机房IP段”“美国VPS服务器IP段”等。不过经验地址往往存在着大量的重复和盲区,而世界IP地址的分配也不是一直不变的。所以,掌握世界IP地址的名称和地域划分,是最为靠谱的做法,通过研究发现,中国有纯真IP库,美国有GeoIP库,都是非常好的查找热门代理IP段的好办法。最终我总结了如下分拣流程

 

1)将IP数据库的所有数据录入数据库

2)根据关键词查找优秀代理IP段,关键词有:“IDC”,“机房”,“数据中心”,”代理“等等

3)将搜索出的IP地址段导入扫描数据库

 

二、代理验证

那么,扫描是第一步,只能知道哪些IP开放了哪些端口,那么在这个端口上面是否就有免费的代理向我们招手呢,这个就需要一一核实和验证。

在这一步,有两种代理需要分别验证,分别是HTTP代理和Socks5代理。同样的,我选择了.NET作为实现语言,经过大量的测试和研究,有如下3个技术点需要着重研究

1、.NET 4.0里的TASK

2、WebClient的Proxy

3、第三方组件Chilkat的Socks5验证

 

1).NET 4.0的TASK

像我这种懒人,在Win32环境下开发多线程的话就会选择Delphi的TThread。而之前也一直抱怨.NET 中的Thread空间不是特别的好用,现在好了,.NET 4.0的TASK真是一个好东西,各种特性都十分贴切于具体的时间场景,.NET 4.5以后,更是简化了很多代码,而经过实际的代码编写发现,确实能够在4核CPU的机器上稳定运行1000-5000个验证线程。按照5秒的超时时间,每个节点每分钟能够验证1万-5万个机会。

 

2)WebClient的Proxy

对于高匿名HTTP验证,在.NET里面最为简单的莫过于WebClient的代理下载了。设置Proxy属性后,在TASK超时时间内如果未能下载成功则无效。

 

3)第三方组件Chilkat的Socks5验证
.NET原生代码并不能支持Socks5代理的验证,经过多方搜寻,发现第三方的Chilkat组件是一个特别好的东西,代码简洁易懂,所以就选择了他作为验证组件。

 

 

三、分布式

在最初,本系统并没有考虑到分布式的实现,但是在实际的实操过程中,公司所在科技园的100M办公带宽以及一台思科三层交换机被我本地3台机器的同时扫描验证拖死,大量的连接数导致网卡和交换机无法承受其负荷,因此如何在各地不同的网络环境分别扫描,然后将结果汇总至服务中心则是一个非常好的解决方案。其核心有如下几点:

 

1、REST服务中心

2、扫描计划分配机制

3、验证计划分配机制

4、数据中心的建立

 

1)REST服务中心

不知道从什么时候其,REST风格的应用程序开始走火,特别是各个网站的开放平台兴起后,RESTFul的开发风靡全球,微软也不甘示弱,在WCF的REST实现太重被大量开发者诟病后,微软也推出了轻量级的解决方案ASP.NET Web API。在本系统中,我也是使用了这套方案,REST服务中心的建立,可以方便的进行跨平台跨系统跨网络的任务分配。

 

2)扫描计划分配机制

如何将IP段数据库中的数据进行有效的循环扫描,并保证高效、及时,这是一个算法问题,但同时我认为在初期经验的积累也很重要,因此我暂时还没有想到什么合适的算法,等到分布式系统稳定运行很久后,可以根据扫描验证结果进行数据分析,从而制订更为精密的算法。

 

3)验证计划分配机制

验证计划的分配和扫描计划的分配在数据层面有共同之处,但是也有不同之处,在验证环节,不同的机器、CPU个数、内存大小、网络带宽等都会影响到线程的开辟数以及效果,因此在大量的积累后,会有一个配置与分配数量的建议对照表。

 

4)数据中心的建立

从实测的结果来看,端口开放机会的数据表的数量大约为1天1000万,等到分布式系统上线后就将更加庞大,因此如何有效的查询数据、管理数据、分析数据在后期将是一个非常重要的话题,如何建立好ETL机制,如何加速数据库读取,如何合理的建立数据库索引、分区等都是重要环节。最终的形态则是一个端口扫描的数据中心。

 

四、展现系统与商业化

 

扫描出这么多东西来了,到底要干什么呢,当然是给大家用了,本系统的结果使用宗旨有如下两个

1、让普通用户能够免费使用扫描结果

2、让商业用户付费使用高效率的筛选扫描结果

 

下面我们将这两个宗旨分开讨论

第一部分:普通用户

普通用户只需要知道什么IP地址和端口可以用作代理。那么我设计了三个展现方式,一个是Web展现,二是桌面展示、三是移动客户端展示

1)Web展示的作用是能够方便用户无时不刻的获取代理IP

2)桌面展示的作用是既能获取代理IP,又能通过Proxycap等第三方软件或者在客户端内部直接实现对操作系统的代理权限的设置。

3)移动客户端的作用是在移动互联网越来越流行的今天也给移动用户一个代理的选择。

 

第二部分:商业用户

商业用户不仅仅是需要获取IP地址,而且他们也不只是需要获取代理IP地址。商业用户的实现是按照功能进行划分的,主要有如下功能

1、服务器漏洞检测

2、信息群发代理接口提供

3、代理的代理

 

1、服务器漏洞检测

服务器漏洞检测是很多管理员头疼的问题,事实上如果能够高效的循环扫描服务器的端口开放情况,并加以各类漏洞检测工具,就能提供强大的漏洞的检测报告,而分布式系统在其中又很好的充当了测试员的角色,在不同的网络环境下对服务器进行测试,这样的服务对于网络管理员和机房管理员来说无疑是一个好帮手。

 

2、信息群发代理接口提供

市面上有很多类似于QQ号批量注册、信鸽邮件群发、无敌论坛群发等各类软件,而这类软件都无一例外的提供了代理设置的功能,但是也无一例外的停留在客户端设置的层面,事实上,代理应该是从云端获取,既不用劳烦用户去过多的考虑代理是否有效,而是专注于付费获得这样的服务。而这也是本系统最为重要的服务实现。

 

3、代理的代理

目前市面上HTTP代理的价格为1元250个-500个,Socks5代理为1毛-5毛一条。而事实上,有效率仅为50%左右,非常低,而且大多时候都是人为稀释了,而分布式系统的特点就是反复扫描循环验证,其结果就是高纯度,高质量,因此将这部分代理卖给原有的HTTP代理销售商,是非常受欢迎的,而分布式代理系统同样可以扫描目前较为空缺的端口和地域,比如3128或者美国等,这也是一大优势。

 

 

五、Mono迁移扩展

SYN扫描方式有个巨大的缺陷,就是在Server 2008 以上的系统不能使用,如Server 2008 R2,Windows 7,Windows 8等都不能使用,因此对于分布式的推广存在很大的局限性。同样的,Linux服务器或者虚拟机其实也大量存在,如何有效的利用这些剩余资源也成为了本系统的一个课题之一,而另人激动的是,.NET的开源项目Mono已经支持到了.NET 4.0,因此,我们可以借助Mono将全部扫描验证节点程序移植到Linux系统。

不过,我还没做这个,哈哈,所以也希望有兴趣的朋友们可以一起加入到这个项目,实现这一移植。

 


本文为云谷分布式端口扫描与代理验证系统的第一部分简介,下面我会陆续将本系统的完整实现过程和相关代码展示给大家,同时也希望大家能够参与到这个项目的深度研究过程中来。

如果有志于将这个系统发扬光大的,甚至可以加入我的公司-南京云谷网络科技有限公司,如有任何问题,可以按照以下联系方式和我联系。交流QQ群:96222371

 

本文为原创文章,转载请注明出处:http://www.zhangrou.net

联系方式-QQ:133880123 邮箱:ryyd@zhangrou.net