1、SDR是什么

字面意思,软件定义无线电。具体的可以在搜索引擎上看到。如果让我来简单的表述下那么就是。

SDR就是“电脑控制设置芯片参数,检波。”

 

2、RTL2832U+R820T电视棒是什么

USB DVB-T & RTL-SDR Realtek RTL2832U & R820T  这是螃蟹( Realtek)的一个芯片型号,原本是做电视棒芯片的。

后来被人发现这个芯片具有非常广的频率接收范围,然后就被用来做sdr应用了,rtl的sdr应用。

在这里看到一个表 https://gathering.tweakers.net/forum/list_messages/1524421/2

Tuner    Frequency range
Elonics E4000    52 - 2200 MHz with a gap from 1100 MHz to 1250 MHz (varies)
Rafael Micro R820T    24 - 1766 MHz
Fitipower FC0013    22 - 1100 MHz (FC0013B/C, FC0013G has a separate L-band input, which is unconnected on most sticks)
Fitipower FC0012    22 - 948.6 MHz
FCI FC2580    146 - 308 MHz and 438 - 924 MHz (gap in between)

那么RTL2832U+R820T接收的频率范围为 24 – 1766 MHz 非常给力啊。

 

3、驱动安装(第一步必须)

3.1、RTL2832U+R820T在windows上玩SDR驱动安装

玩sdr必须先通过这样的方式安装驱动支持,电视棒送的那个套件和驱动就不要管了!

高于等于Windows vista如 ,windwos 7、windows8.x使用

http://zadig.akeo.ie/downloads/zadig_2.1.0.exe

Windows XP 使用

http://zadig.akeo.ie/downloads/zadig_xp_2.1.0.exe

运行zadig>点击 Options > 勾选 List All Devices

img20140502001

Options》 List All Devices 勾选,就能看到所有设备了

选择RTL2832U > 点击 install Driver 即可,其他参数不要改动,我这里应为安装过了,所以是Reinstall Driver。

img20140502002

选择RTL2832U ,参数不用管,直接点 Install Device

 

驱动安装ok!

 

4、SDR软件

sdr的软件有很多款,如sdr#(sdrsharp)、WRplus、 HDSDR、SDR-RADIO-Pro_v2

我这里只推荐使用SDR-RADIO-Pro_v2,反正我喜欢这款,功能和界面最强。

4.1、SDR-RADIO-Pro_v2

http://v2.sdr-radio.com/Download.aspx下载。

2014年5月2日下载到的2.2最新版本为SDR-RADIO-Pro_v2.2b1735.exe,直接下一步下一步安装好。

安装好后桌面会出来三个图标,SDRConsole (V2)、SDRServer (V2)、SDR Data File Analyser。

SDR-RADIO-Pro_v2使用RTL2832U+R820T有2种方式,1、rtl-tcp搭桥方式和2、RTL扩展驱动直连,都需要三方扩展支持。

4.1.1、方法1使用rtl-tcp搭桥模式连接RTL2832U+R820T

下载rtl-sdr-release RelWithDebInfo.zip http://pan.baidu.com/s/11W6J0

运行rtl_tcp.exe 出现如下信息就表示ok。

img201405021

rtl_tcp

打开 SDRConsole (V2) 然后看图操作吧

SDR-RADIO-Pro_v2的使用慢慢琢磨吧。

4.1.2、方法2、RTL扩展驱动直连RTL2832U+R820T

下载 SDR-Radio.com.RTLUSB-20130209.zip

解压得到三个文件 libusb-1.0.dll 、rtlsdr.dll 、SDRSourceRTL2832U.dll。只需要复制rtlsdr.dll 、SDRSourceRTL2832U.dll这2个到

SDR-RADIO-Pro_v2的安装目录下即可。

打开 SDRConsole (V2)  后选设备和方法1相同,安装这2个dll后,下拉选择 里面除了RTL SDR (TCP)外,多了一个RTL SDR (USB) ,选他即可。

5、SDR# (SDR Sharp)

下载 http://sdrsharp.com/downloads/sdr-install.zip 解压后运行 install.bat

自动绿色安装生成目录sdrsharp 直接运行 SDRSharp.exe即可。

选择RTL-SDR / USB (注:同样支持RTL-SDR TCP 方式,方法如4.1.1), 配置参数勾选RTL AGC Tuner AGC,点击开始。

sdr# sdrsharp 使用rtl-sdr

sdr# sdrsharp 使用rtl-sdr

 

6、扩展资料

http://www.rtl-sdr.com/ rtl sdr资讯站,有大量的rtl sdr应用展示。

THE BIG LIST OF RTL-SDR SUPPORTED SOFTWARE 本篇文章介绍了好几款sdr软件配合RTL2832U+R820T使用

廉价软接收 RTL2832U+E4000/R820T 

把RTL2832改造成“专业”SDR接收棒

rtl-sdr, RTL2832电视棒追踪飞机教程(ADS-B)

 

官网的rpm二进制包是不是不够用啊!什么都编译安装是否很蛋疼,我反正是这么觉得的,没必要什么东西非要自己编译安装。

在对版本没有特殊需求,不需要改动源码的情况下,果断的yum的方式安装rpm包吧。

yum 方式安装rpm包 和 用rpm包管理器命令安装rpm包,区别是:yum 方式安装rpm包会解决包依赖关系,而rpm包管理器直接安装rpm包,不会解决包依赖关系。

 

RepoForge 源

 

CentOS7.x安装RepoForge 源

wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm
yum -y install rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

 

CentOS6.x安装RepoForge 源

取自己对应的版本,我这里是centos6.x x64

yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

试试安装一个比自带的top好用的 htop “任务管理器”。

yum -y install htop

 

EPEL 源

CentOS7.x安装EPEL 源

64位系统

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm
yum -y install epel-release-7-6.noarch.rpm
yum makecache
yum repolist
yum --enablerepo=epel info htop

 

CentOS6.x安装EPEL 源

32位系统

yum -y install https://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

64位系统

yum -y install https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

CentOS5.x安装EPEL 源

32位系统

yum -y install https://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

64位系统

yum -y install https://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

 

 

我们知道apache php mod的方式可以很方便的配置 open_basedir 限制各个站点的目录访问权限。

nginx + php-fpm fastcgi的方式需要这样做。

首先php的版本必须大于等于php5.3.3。

总限制 通过php-fpm.conf限制

在php-fpm.conf配置文件当中可以增加如下参数

env[TMP] = /tmp/
env[TMPDIR] = /tmp/
env[TEMP] = /tmp/
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f webmaster@qq.com
php_admin_value[open_basedir] = /home/wwwroot/:/tmp/:/var/tmp:/proc/
php_admin_value[session.save_path] = /tmp/
php_admin_value[upload_tmp_dir] = /tmp/
slowlog = /usr/local/php/var/log/$pool.log
request_slowlog_timeout = 3s

可以配置env,php_admin_value。

那么配置

php_admin_value[open_basedir] = /home/wwwroot/:/tmp/:/var/tmp:/proc/

就可以把整个php脚本的访问目录控制住了。

如果方法1 方法2 方法3未配置的情况下,那么open_basedir的值就为本设置的值,如果方法1 方法2 方法3设置了,那么就是新设置的值。

另外的我这里打开了php慢执行。

slowlog 写保存路径,request_slowlog_timeout写时间。

更多的请看php官网手册 http://www.php.net/manual/en/install.fpm.configuration.php

 

方法1 在nginx 配置 fastcgi_param参数

在nginx的 php配置中 或者 在  包含的 include fastcgi.conf 文件中加入:

fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";

$document_root php文档根目录,就是 nginx 配置项 root 配置的网站目录。

/tmp/目录需要有权限,默认放seesion的位置,以及unixsock。

/proc/ 可以让php查看系统负载信息。

本方法加的各个vhost 虚拟主机,都可以完美使用。都限制到自己的网站目录下。

非常推荐使用, 总限制 + 方法1 这样的组合配置方式!!!!!

方法2 在php.ini 中配置

在php.ini的末尾加入:

[HOST=www.iamle.com]
open_basedir=/home/wwwroot/www.iamle.com:/tmp/:/proc/
[PATH=/home/wwwroot/www.iamle.com]
open_basedir=/home/wwwroot/www.iamle.com:/tmp/:/proc/

本方法的弊端,如果有泛域名解析,比如 *.iale.com 。这个就不好控制。

 

方法3  网站根目录下增加 .user.ini  文件。

在php.ini中找到user_ini.filename 、 user_ini.cache_ttl 去掉前面的分号。

; Name for user-defined php.ini (.htaccess) files. Default is ".user.ini"
user_ini.filename = ".user.ini"

; To disable this feature set this option to empty value
;user_ini.filename =

; TTL for user-defined php.ini files (time-to-live) in seconds. Default is 300 seconds (5 minutes)
user_ini.cache_ttl = 300

 

在网站根目录下创建.user.ini 加入:

open_basedir=/home/wwwroot/www.iamle.com:/tmp/:/proc/

这种方式不需要重启nginx或php-fpm服务。

特别注意,需要取消掉.user.ini文件的写权限,这个文件只让最高权限的管理员设置为只读。

方法1设置后,.user.ini的设置就不起作用了。
关于.user.ini文件的详细说明:
http://php.net/manual/zh/configuration.file.per-user.php

BTSync 简介

BitTorrent Sync 是p2p方式的文件同步软件。
特点:无需服务端,全平台支持

Windwos平台的安装设置

下载:http://download-lb.utorrent.com/endpoint/btsync/os/windows/track/stable

运行BTSync.exe

“测试同步”这个文件夹的密匙为 AA7PQ3XCEA7AFEAGRPU6V7EY7PN4WYYDR

Mac OS X平台的安装设置

http://www.bittorrent.com/sync 下载btsync mac osx端

 

 Linux 平台的安装设置

centos为例

Tutorial – How to set up BitTorrent Sync on a Linux server to create a Dropbox-like syncing solution

Centos Init.d And Install Script

 

 

去年在《凌云》杂志上写过一篇关于DDoS攻防的文章,在线版本可以到官方网站http://storage.aliyun.com/aliyun_portal_storage/lingyun/lingyun-journal-2.pdf查看。当时因为篇幅的原因有些细节没有展开,加上时间过去了大半年,出现了许多新的流行的攻击方式,所以决定写一篇补遗。

一、DRDoS攻击

DRDoS(分布式反射攻击)最早在2004年左右就出现了,安全焦点上还有一份国外的代码,可以在http://www.xfocus.net/tools/200406/717.html下载查看。当时的DRDoS攻击不具备放大流量的能力,某种意义上说类似拿冲锋枪打墙,依靠反射回来的弹壳伤人,攻击力不升反降,因而并没有流行开来。

但是从2013年开始,DRDoS已经是互联网上最流行、最吸引眼球的DDoS攻击手段了,因为它附加流量放大属性,通过史无前例的海量流量击败了如日中天的云安全公司CloudFlare,引得大小黑客纷纷仿效。

DRDoS攻击的原理是黑客伪造成受害者的IP地址,向互联网上大量开放特定服务的主机发起请求,接收到请求的那些主机根据源IP地址将响应数据包返回给受害者。整个过程中,大量的无辜主机完全不知情,成为黑客攻击的帮凶。一般来说,黑客会使用响应包远大于请求包的服务来利用,这样才可以以较小的流量换取交大的流量去攻击,几十倍的放大攻击。能利用来做放大反射攻击的服务,常见的有DNS服务、NTP服务、SNMP服务、Chargen服务等等,甚至某些online游戏服务器也被利用来参与攻击。

1.1. 基于UDP的反射攻击

CloudFlare在2013年遭受的300Gbps的攻击属于DNS反射攻击,当时导致他们全网故障。在2014年2月,它们遭受了前所未见的400Gbps的攻击,黑客使用了NTP服务进行放大。

互联网上有非常多的时间服务器,通过NTP协议提供对时服务。但是它缺乏身份认证手段,可以被任意使用。更重要的是,NTP协议有一个指令monlist可以列举出最近同步过时间的600个主机列表,如下图:

1

攻击者发出的Monlist指令只有1个数据包,耗费几十个字节,而返回包多达几十个,耗费2000-3000字节甚至更大,达到约50倍的放大。越是繁忙的NTP服务器,这个放大倍数越大。

攻击者只需要100Mbps的请求流量,可以换来5Gbps的攻击流量,效率非常高。其它的DNS放大、SNMP放大、Chargen放大与NTP放大原理一致,只是使用的协议有区别,不一一描述。

1.2. 基于TCP的反射攻击

反射攻击利用的协议,一般同时具有3种特征:容易伪造源IP地址、无身份认证、响应包远大于请求包。因此,基于UDP的DNS协议、NTP协议、Chargen协议、SNMP协议成为首选。那么,是不是只有基于UDP的上层协议才能够用来做放大反射攻击,需要完成三次握手才能开始业务会话的基于TCP的上层协议就无法利用了?其实不是。

Chargen是一个常见的测试网络连通性服务,同时工作在UDP协议和TCP协议上。对于它监听的TCP端口,只要有客户端连上,就会源源不断的向客户端返回随机字符串,永不停止。可以想象,如果这个东西可以利用起来做攻击,无穷倍数的放大,是何等厉害。但是很遗憾,TCP不能伪造源IP地址,除非攻击者能够让攻击目标主动连接到Chargen的TCP端口去。

这种事情,恰好是代理协议做的事情!如果攻击目标是HTTP Proxy或者Socks5 Proxy,攻击者只需要连接上目标的代理端口,然后去访问Chargen服务并保持TCP连接不断掉就行了。以HTTP代理为例,直接连接target的3128端口,然后发出类似http://chargen_server.com:19这样的请求即可,socks5代理类似。

使用Chargen攻击代理服务器效果虽好,但是毕竟应用范围比较狭窄,一般的攻击目标都是网站。黑客的创意在这儿展露无遗,他们也有各种新奇的手法,比如利用Google的某些服务或者Wordpress之类的博客来做DDoS攻击。

Google有一个叫做FeedFetcher的爬虫,为Google Feed API提供后端支持,会定期抓取RSS以及其它各种数据,如他们的电子表格服务spreadsheet中的链接。当电子表格服务中存在内容=image(“http://example.com/image.jpg”)时,Google就会“派出”FeedFetcher爬虫去抓取这个图片并保存到缓存中以将其显示出来。

恶意攻击者会找一个较大的文件,给文件名附加上随机参数,使FeedFetcher多次抓取这个文件。也就是说,如果一个网站有一个10MB的文件,将以下列表输入到Google spreadsheet中,那么Google的爬虫就会抓取该文件1000次,使网站产生大量出站流量。

=image(“http://targetname/file.pdf?r=0″)

=image(“http://targetname/file.pdf?r=1″)

=image(“http://targetname/file.pdf?r=2″)

=image(“http://targetname/file.pdf?r=3″)

=image(“http://targetname/file.pdf?r=1000″)

如果是带宽比较小的站点,面对这种攻击时会非常痛苦。拦截会影响SEO效果,不拦截则需要付出更多的带宽租赁费用。

基于类似的原理,Wordpress博客的pingback功能也可以用来做反射攻击。PingBack是用来通知blog系统有文章被引用的一种手段。向

http://www.anywordpresssite.com/xmlrpc.php

提交POST请求, 数据格式如下:

<methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com/post.php?id=1</string></value></param><param><value><string>http://www.anywordpresssite.com/pst?id=111</string></value></param></params></methodCall>, 则服务器www.anywordpresssite.com会向http://victim.com/post.php?id=1发起GET请求。如果攻击者同时向大量的开启了pingback的blog系统提交请求,则有大量的GET请求涌向攻击目标,更多的更多细节可以参见http://drops.wooyun.org/news/1062

但是就我看来,pingback这样的反射攻击意义不大,因为流量和请求次数都没有被放大,如果单纯是为了隐藏自己,可以选择通过proxy的方式发起攻击。更好的做法应该是向某个开启了pingback的blog a发送大量的POST包(这里的POST包通过代理发起),让它去ping大量的blog,然后大量的http response会同攻击者发起的POST包一起淹没blog a,这才是优雅的反射放大攻击——付出的代价是这种攻击方式仅对有pingback功能的系统起作用。

1.3. DrDoS的防御

TCP的反射攻击有可能发生,但是危害程度远不如UDP,而且发起难度较大,需要很多诡异的条件配合。因此,防御上无需做过多考虑,将目光主要集中到基于UDP的反射放大攻击。

首先,我们需要足够大的带宽,没有带宽一切都枉然。一般的,带宽可以通过CDN的方式提供,将业务分散到不同地区的不同机房。

其次,从DRDos的本质知道,这种反射攻击数据包的源端口一定是固定的,NTP放大攻击源端口一定是UDP 123端口,DNS放大攻击源端口一定是UDP 53端口。这其实是一个很好的特征,也是攻击者不愿意却不得不留下的特征——有得到就有代价。在带宽足够的情况下,可以在网络边界部署ACL策略,禁止外网进来的源端口是UDP 123的报文,禁止外网进来的源端口是UDP 161的报文,禁止外网进来的源端口是UDP 19的报文,诸如此类。源端口是UDP 53的也可以过滤?也可以的,至少大部分IP地址可以无需请求外部的DNS服务。

这里涉及到一条防御准则,可以三层过滤的不要在四层做,可以在四层做的过滤不要到七层做。越往上,解析开销越大。

二、高级SYN Flood攻防

1.4. SYN Cookie、SYN Proxy

最常见的SYN Flood防御手段是SYN Cookie和SYN Proxy,它们原理简单,而且效果也非常好。

在正常情况下,服务器端接收到客户端发送的SYN包,会分配一个连接请求块(即request_sock结构)用于保存连接信息,然后发送SYN+ACK包给客户端,并将连接请求块添加到半连接队列中,没收到最后一个ACK的话就轮询重发SYN+ACK包。

对于启用了SYN Cookie的服务器,不会这样处理,它不维持任何连接信息, 而是将源IP、目的IP、源端口、目的端口、SYN序列号等信息进行hash运算,生成一个数字称之为cookie。服务端将这个cookie作为SYN+ACK包的ACK确认号发送给客户端,然后对这个IP发过来的后续ACK包的确认号进行验算,与Cookie吻合的说明是正确的报文,正常建立连接,而攻击的报文直接没有了任何后续动作,也没有额外开销。

SYN Proxy则是管家式的防御,它站在攻击者和目标服务器之间,伪装成目标服务器对所有的SYN报文进行应答,包括攻击者在内。当三次握手正确的建立起来后,就伪装成客户端IP地址与后端的目标服务器建立三次握手,然后转发数据,需要注意的是,TCP三次握手在这里变成了6次握手,而且两个握手内的ACK号肯定不一致,需要做一个修正。

SYN Cookie可以和SYN Proxy无缝集成,协同工作,提供更好的防御服务,基本上100%无误杀。那么使用这种防御手段,付出的代价是什么?

我们可以看到,SYN Cookie和SYN Proxy对每一个SYN包都会进行答复,如果攻击者发送1Gbps的报文过来,防御方会发送1Gbps的报文回去。10Gbps就10Gbps,100Gbps就100Gbps。问题是,企业网络禁得起这种折腾么?基本上,攻击流量达到一定程度,网络不攻自溃。

1.5. 随机丢包

对于过大的反弹流量的问题,安全厂商想出了许多新的办法,那就是在答复之前做一些测试,能轻易过滤的流量就不反弹了。最主要的是随机丢包策略,直接粗暴的丢弃SYN包,按照TCP协议正常的用户会在3秒内重发这个SYN包,攻击流量的源IP是伪造的,因此直接被丢弃了没有任何后续。

这个方案看起来对SYN Cookie之类技术是一个很好的补充,但是也有一些问题。首先,正常用户的体验受到影响,访问业务的速度变慢了。其次是某些高级攻击者可以利用这个手段,绕过防御,简单的说,同样的SYN包发两次有可能被判定为正常访问。一旦被防御设备加入白名单,后续的报文就直接漏过了。

1.6. 反向探测

除了SYN Cookie、Proxy技术之外,还有一种反向探测的技术,也是颇为流行。防御设备接收到SYN包时,回复一个ACK确认号错误的SYN+ACK报文。按照协议,客户端会发一个RST报文过来重置连接。攻击者一般是伪造源IP地址,没有人会帮他做这个应答,SYN包被直接过滤掉。

这个方案,在实际环境中会遇到一些问题。某些防火墙设备,包括iptables,会过滤掉ACK号错误的SYN+ACK包,导致正常用户的RST包发不过来而导致被误杀。因此,考虑到稳定可靠,防御设备回复的SYN+ACK包的ACK确认号需要满足某些特征,比如小于或者等于SYN确认号。

对于攻击者而言,他们可以通过tcp ping的方式扫描到真实存活的主机列表,然后使用这些IP地址作为源IP地址发起攻击,可以有效绕过这种防御手段。虽然一般的攻击是要伪造不存在的源IP以达到更好的效果,但是这里则要反其道而行之。

三、总结

总之,DDoS的防御和攻击都是一件非常精巧的事情。要优雅的攻击,优雅的防御。各种手法有符合常规的,也有要违背常规的。运用之妙,存乎一心。

四、后记

NTP攻击的图片来自网络,更多细节可以参见:

http://www.prolexic.com/kcresources/white-paper/white-paper-snmp-ntp-chargen-reflection-attacks-drdos/An_Analysis_of_DrDoS_SNMP-NTP-CHARGEN_Reflection_Attacks_White_Paper_A4_042913.pdf

基于Google的攻击来自freebuf,参见:

http://www.freebuf.com/articles/web/28273.html

原文来自阿里云产品博客

http://blog.aliyun.com/250

1.   DDoS攻击基础

DDoS(Distributed Denial of Service,分布式拒绝服务)攻击的主要目的是让指定目标无法提供正常服务,甚至从互联网上消失,是目前最强大、最难防御的攻击之一。

按照发起的方式,DDoS可以简单分为三类。

第一类以力取胜,海量数据包从互联网的各个角落蜂拥而来,堵塞IDC入口,让各种强大的硬件防御系统、快速高效的应急流程无用武之地。这种类型的攻击典型代表是ICMP Flood和UDP Flood,现在已不常见。

第二类以巧取胜,灵动而难以察觉,每隔几分钟发一个包甚至只需要一个包,就可以让豪华配置的服务器不再响应。这类攻击主要是利用协议或者软件的漏洞发起,例如Slowloris攻击、Hash冲突攻击等,需要特定环境机缘巧合下才能出现。

第三类是上述两种的混合,轻灵浑厚兼而有之,既利用了协议、系统的缺陷,又具备了海量的流量,例如SYN Flood攻击、DNS Query Flood攻击,是当前的主流攻击方式。

本文将一一描述这些最常见、最具代表性攻击方式,并介绍它们的防御方案。

1.1. SYN Flood

SYN Flood是互联网上最经典的DDoS攻击方式之一,最早出现于1999年左右,雅虎是当时最著名的受害者。SYN Flood攻击利用了TCP三次握手的缺陷,能够以较小代价使目标服务器无法响应,且难以追查。

标准的TCP三次握手过程如下:

l  客户端发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;

l  服务器在收到客户端的SYN报文后,将返回一个SYN+ACK(即确认Acknowledgement)的报文,表示客户端的请求被接受,同时TCP初始序号自动加1;

l  客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加1。

经过这三步,TCP连接就建立完成。TCP协议为了实现可靠传输,在三次握手的过程中设置了一些异常处理机制。第三步中如果服务器没有收到客户端的最终ACK确认报文,会一直处于SYN_RECV状态,将客户端IP加入等待列表,并重发第二步的SYN+ACK报文。重发一般进行3-5次,大约间隔30秒左右轮询一次等待列表重试所有客户端。另一方面,服务器在自己发出了SYN+ACK报文后,会预分配资源为即将建立的TCP连接储存信息做准备,这个资源在等待重试期间一直保留。更为重要的是,服务器资源有限,可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文,也就是拒绝新的TCP连接建立。

SYN Flood正是利用了上文中TCP协议的设定,达到攻击的目的。攻击者伪装大量的IP地址给服务器发送SYN报文,由于伪造的IP地址几乎不可能存在,也就几乎没有设备会给服务器返回任何应答了。因此,服务器将会维持一个庞大的等待列表,不停地重试发送SYN+ACK报文,同时占用着大量的资源无法释放。更为关键的是,被攻击服务器的SYN_RECV队列被恶意的数据包占满,不再接受新的SYN请求,合法用户无法完成三次握手建立起TCP连接。也就是说,这个服务器被SYN Flood拒绝服务了。

对SYN Flood有兴趣的可以看看http://www.icylife.net/yunshu/show.php?id=367,这是我2006年写的代码,后来做过几次修改,修改了Bug,并降低了攻击性,纯做测试使用。

1.2. DNS Query Flood

作为互联网最基础、最核心的服务,DNS自然也是DDoS攻击的重要目标之一。打垮DNS服务能够间接打垮一家公司的全部业务,或者打垮一个地区的网络服务。前些时候风头正盛的黑客组织anonymous也曾经宣布要攻击全球互联网的13台根DNS服务器,不过最终没有得手。

UDP攻击是最容易发起海量流量的攻击手段,而且源IP随机伪造难以追查。但过滤比较容易,因为大多数IP并不提供UDP服务,直接丢弃UDP流量即可。所以现在纯粹的UDP流量攻击比较少见了,取而代之的是UDP协议承载的DNS Query Flood攻击。简单地说,越上层协议上发动的DDoS攻击越难以防御,因为协议越上层,与业务关联越大,防御系统面临的情况越复杂。

DNS Query Flood就是攻击者操纵大量傀儡机器,对目标发起海量的域名查询请求。为了防止基于ACL的过滤,必须提高数据包的随机性。常用的做法是UDP层随机伪造源IP地址、随机伪造源端口等参数。在DNS协议层,随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外,还可以降低命中DNS缓存的可能性,尽可能多地消耗DNS服务器的CPU资源。

关于DNS Query Flood的代码,我在2011年7月为了测试服务器性能曾经写过一份代码,链接是http://www.icylife.net/yunshu/show.php?id=832。同样的,这份代码人为降低了攻击性,只做测试用途。

1.3. HTTP Flood

上文描述的SYN Flood、DNS Query Flood在现阶段已经能做到有效防御了,真正令各大厂商以及互联网企业头疼的是HTTP Flood攻击。HTTP Flood是针对Web服务在第七层协议发起的攻击。它的巨大危害性主要表现在三个方面:发起方便、过滤困难、影响深远。

SYN Flood和DNS Query Flood都需要攻击者以root权限控制大批量的傀儡机。收集大量root权限的傀儡机很花费时间和精力,而且在攻击过程中傀儡机会由于流量异常被管理员发现,攻击者的资源快速损耗而补充缓慢,导致攻击强度明显降低而且不可长期持续。HTTP Flood攻击则不同,攻击者并不需要控制大批的傀儡机,取而代之的是通过端口扫描程序在互联网上寻找匿名的HTTP代理或者SOCKS代理,攻击者通过匿名代理对攻击目标发起HTTP请求。匿名代理是一种比较丰富的资源,花几天时间获取代理并不是难事,因此攻击容易发起而且可以长期高强度的持续。

另一方面,HTTP Flood攻击在HTTP层发起,极力模仿正常用户的网页请求行为,与网站业务紧密相关,安全厂商很难提供一套通用的且不影响用户体验的方案。在一个地方工作得很好的规则,换一个场景可能带来大量的误杀。

最后,HTTP Flood攻击会引起严重的连锁反应,不仅仅是直接导致被攻击的Web前端响应缓慢,还间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务,增大它们的压力,甚至对日志存储服务器都带来影响。

有意思的是,HTTP Flood还有个颇有历史渊源的昵称叫做CC攻击。CC是Challenge Collapsar的缩写,而Collapsar是国内一家著名安全公司的DDoS防御设备。从目前的情况来看,不仅仅是Collapsar,所有的硬件防御设备都还在被挑战着,风险并未解除。

1.4. 慢速连接攻击

提起攻击,第一反应就是海量的流量、海量的报文。但有一种攻击却反其道而行之,以慢著称,以至于有些攻击目标被打死了都不知道是怎么死的,这就是慢速连接攻击,最具代表性的是rsnake发明的Slowloris。

HTTP协议规定,HTTP Request以\r\n\r\n结尾表示客户端发送结束,服务端开始处理。那么,如果永远不发送\r\n\r\n会如何?Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive,要求Web Server保持TCP连接不要断开,随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端,如a:b\r\n,导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作,服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求。

很快的,Slowloris开始出现各种变种。比如POST方法向Web Server提交数据、填充一大大Content-Length但缓慢的一个字节一个字节的POST真正数据内容等等。关于Slowloris攻击,rsnake也给出了一个测试代码,参见http://ha.ckers.org/slowloris/slowloris.pl。

2.   DDoS攻击进阶

2.1. 混合攻击

以上介绍了几种基础的攻击手段,其中任意一种都可以用来攻击网络,甚至击垮阿里、百度、腾讯这种巨型网站。但这些并不是全部,不同层次的攻击者能够发起完全不同的DDoS攻击,运用之妙,存乎一心。

高级攻击者从来不会使用单一的手段进行攻击,而是根据目标环境灵活组合。普通的SYN Flood容易被流量清洗设备通过反向探测、SYN Cookie等技术手段过滤掉,但如果在SYN Flood中混入SYN+ACK数据包,使每一个伪造的SYN数据包都有一个与之对应的伪造的客户端确认报文,这里的对应是指源IP地址、源端口、目的IP、目的端口、TCP窗口大小、TTL等都符合同一个主机同一个TCP Flow的特征,流量清洗设备的反向探测和SYN Cookie性能压力将会显著增大。其实SYN数据报文配合其他各种标志位,都有特殊的攻击效果,这里不一一介绍。对DNS Query Flood而言,也有独特的技巧。

首先,DNS可以分为普通DNS和授权域DNS,攻击普通DNS,IP地址需要随机伪造,并且指明服务器要求做递归解析;但攻击授权域DNS,伪造的源IP地址则不应该是纯随机的,而应该是事先收集的全球各地ISP的DNS地址,这样才能达到最大攻击效果,使流量清洗设备处于添加IP黑名单还是不添加IP黑名单的尴尬处境。添加会导致大量误杀,不添加黑名单则每个报文都需要反向探测从而加大性能压力。

另一方面,前面提到,为了加大清洗设备的压力不命中缓存而需要随机化请求的域名,但需要注意的是,待解析域名必须在伪造中带有一定的规律性,比如说只伪造域名的某一部分而固化一部分,用来突破清洗设备设置的白名单。道理很简单,腾讯的服务器可以只解析腾讯的域名,完全随机的域名可能会直接被丢弃,需要固化。但如果完全固定,也很容易直接被丢弃,因此又需要伪造一部分。

其次,对DNS的攻击不应该只着重于UDP端口,根据DNS协议,TCP端口也是标准服务。在攻击时,可以UDP和TCP攻击同时进行。

HTTP Flood的着重点,在于突破前端的cache,通过HTTP头中的字段设置直接到达Web Server本身。另外,HTTP Flood对目标的选取也非常关键,一般的攻击者会选择搜索之类需要做大量数据查询的页面作为攻击目标,这是非常正确的,可以消耗服务器尽可能多的资源。但这种攻击容易被清洗设备通过人机识别的方式识别出来,那么如何解决这个问题?很简单,尽量选择正常用户也通过APP访问的页面,一般来说就是各种Web API。正常用户和恶意流量都是来源于APP,人机差别很小,基本融为一体难以区分。

之类的慢速攻击,是通过巧妙的手段占住连接不释放达到攻击的目的,但这也是双刃剑,每一个TCP连接既存在于服务端也存在于自身,自身也需要消耗资源维持TCP状态,因此连接不能保持太多。如果可以解决这一点,攻击性会得到极大增强,也就是说Slowloris可以通过stateless的方式发动攻击,在客户端通过嗅探捕获TCP的序列号和确认维护TCP连接,系统内核无需关注TCP的各种状态变迁,一台笔记本即可产生多达65535个TCP连接。

前面描述的,都是技术层面的攻击增强。在人的方面,还可以有一些别的手段。如果SYN Flood发出大量数据包正面强攻,再辅之以Slowloris慢速连接,多少人能够发现其中的秘密?即使服务器宕机了也许还只发现了SYN攻击想去加强TCP层清洗而忽视了应用层的行为。种种攻击都可以互相配合,达到最大的效果。攻击时间的选择,也是一大关键,比如说选择维护人员吃午饭时、维护人员下班堵在路上或者在地铁里无线上网卡都没有信号时、目标企业在举行大规模活动流量飙升时等。

这里描述的只是纯粹的攻击行为,因此不提供代码,也不做深入介绍。

2.2. 来自P2P网络的攻击

前面的攻击方式,多多少少都需要一些傀儡机,即使是HTTP Flood也需要搜索大量的匿名代理。如果有一种攻击,只需要发出一些指令,就有机器自动上来执行,才是完美的方案。这种攻击已经出现了,那就是来自P2P网络的攻击。

大家都知道,互联网上的P2P用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据,使成千上万的真实IP地址连接过来,没有哪个设备能够支撑住。拿BT下载来说,伪造一些热门视频的种子,发布到搜索引擎,就足以骗到许多用户和流量了,但这只是基础攻击。

高级P2P攻击,是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器,然后推送给其他需要下载相同资源的用户,这样,一个链接就发布出去。通过协议逆向,攻击者伪造出大批量的热门资源信息通过资源管理中心分发出去,瞬间就可以传遍整个P2P网络。更为恐怖的是,这种攻击是无法停止的,即使是攻击者自身也无法停止,攻击一直持续到P2P官方发现问题更新服务器且下载用户重启下载软件时为止。

3.   总结

限于篇幅,DDoS攻击的介绍就写这么多,而且我也不愿意对这个做更进一步的阐述了——理解防御这么多已经够用了。

总的来说,DDoS攻击可以很灵巧,可以很优美。运用之妙,存乎一心。

原文来自阿里云产品博客

http://blog.aliyun.com/243