DDOS攻击的解决方案

1、当网站遭遇DDOS攻击的解决方案及展望当网站遭遇DDO攻击的解决方案及展望更多：http:/che ngua 一、事件发生春节长假刚过完，WEB就出现故障，下午1点吃完回来，立即将桌面解锁并习惯 性的检查了 Web服务器。通过Web!务器性能监视软件图像显示的向下滑行的红 色曲线看到WEB出现问题了。根据上述的问题，我马上开始核查 Web!务器的日志，试试是否能检测到问题究 竟什么时候开始，或者发现一些关于引起中断的线索。 正当查询线索过程中。公 司首席运营官(CIO)告诉我，他已经接到客户的投诉电话，报告说无法访问他们 的网站。于是从台式机中敲入网站地址，试着从台式电脑访问他们的网站，但是

2、看到的只是无法显示此页面的消息。回想前几天也未对Web服务器做了任何改变也未对Web服务器做过任何改变，服 务器曾经出现过的性能问题。在 Web服务器的日志文件中没有发现任何可疑之 处，因此接下来我去仔细查看防火墙日志，和路由器日志。仔细查看了防火墙日志，打印出了那台服务器出问题时的记录。并过滤掉正常的流量并保留下可疑的记录。表中显示了打印出来的结果。源IP地址目的IP地址源端口号目的端口号协议757843717667519717753451171710.166

3、.166.166192.168.0168.89.11175178371766751971775295897172751733071766192.168.016.43.131758935717752238771766192.768.0.7519717192

4、.168.0.17565887171192.768.0.7521453717667519717975459877174756521271775529677175758745717667519717表一防火墙日志之后在路由器日志上做了同样的工作并打印出了看上去异常的记录攻击期间的路由器日志RouterLtfsh

5、ip cache flowIP packet size distribution (567238991 total packets):1-326496 128160192224256288320 352384 416448 000 - 984 002 .002.000 -000*000,000000.000 .000.000 .000*000480512544 5761034 15362048256030723584 40964608.000 * 000 002 .008,0(X) 002.000.000OQC).000 .000000IP Flow Switching Cache? 7823

6、134 bytes4799 active117234 inactivej1237463904added702311287 ager polls,0 flow alloc failuresActive flovs:timeoutin 30 iLLnnteBInactive flovs tiiaeout in 15 secondsLast clearcf statistics neverProtocolTotalFl oursPacketsBytesPacketsActive (Siec) Idle(Sec)卜 Flows/Sec/Flow/Pkt/Sec/Flow/FlowTCPT&ln

7、et229430.01450.00.111*7TCP-FT?1348200.014?0.02.413,7TCP-FTPD19830.01400.0Cl 211.3TCP_WW35630. 21381.5Cl 1乱2TCP-SMTP76820.01420.01,012,2TCP-X13920.01400.00.611.2TCP-BGP17820.01400.00. 211.5TCP-KTP29060.01400.06 111,2TCP-Frag1080.02260.01.415.7TCP-other4992871 CL 114065- 5O-428- 7UDP-DNS103450.01540.0

8、0,918,0UDP-NTP6290.01410.0517.8UDP-TFTP6210.02400.011.917.1UDP-Frag250.0134o.o :261.413*7UDP-other182921340 39.21414氐10. 512,0ICMP18934570.0106740.57.9jTLkisDJiJIGKP290.015690.014. E1鱼2IP-other70.021640.017. 716.9图一解释：IP packet sizedistributi on这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：98.4%的数据包的大小在33字节到6

9、4字节之间 （注意红色标记）。参数解释：IP packet sizedistributi on这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：98.4%的数据包的大小在33字节到64字节之间。Protocol协议名称Total Flows自从最后一次清除统计信息后，这种协议的信息流的个数。Flows/Sec每秒钟时间内出现这种协议的信息流的平均个数，它等于总信息流数/综合时间的秒数。Packets/Flow遵守这种协议的信息流中平均的数据包数。等于这种协议的数据包数，或者在这段综合时间内，这种协议的信息流数。Bytes/Pkt遵守这种协议的数据包的平均字节数（等于这种协

10、议总字节数，或者在这段综合 时间内，这种协议的数据包数）。B/Pkt，这一信息流中每个数据包的平均字节数Packets/Sec每秒钟时间内这种协议的平均数据包数（它等于这种协议的总数据包），或者这段 综合时间的总秒数。Active（Sec）/Flow从第一个数据包到终止信息流的最后一个数据包的总时间（以秒为单位，比如TCP FIN,终止时间量等等），或者这段综合时间内这种协议总的信息流数。ldle（Sec）/Flow从这种协议的各个非终止信息流的最后一个数据包起，直到输入这一命令时止的 时间总和（以秒为单位），或者这段综合时间内信息流的总时间长度。正常路由日志iouterl#sh ip cac

11、he flowIP packet size distributian (567238991 total packets):1-326496 12S 160 192 224 256 2S8 320 352 3B4 41S 448.000 .002 *002 .002 .000 ,000 .000 .000 ,000 ,000 .000 ,000 .000 .000480 512 &44 576 1024 1536 2048 2560 3072 3584 4096 4608.000 ,000 .002 .012 .006 .974 .000 .000 .000 .000 .000 .000

12、IP Flow Switching Cachej 529S42 bytes2092 activej 50378 inactiv&j 8S24 added32341 ager polls 0 flow alloc failuresActive flows timeout in 30 minutesInactive flews timeout m 15 secondslat clearing of statistics neverProtocolTotalFlowsFl ows/気匚Packets BytesPackets Active(Sec) Idle (Sec)/Flow/Pkt/S

13、ec/Fl ow/FlowTCPTelnet12430.01120.00. 11.7TCP-FTP34520.01230.01.46. 3TCP-FTPD77E0.01120,00, 22, 3TCP-WW324679051.21491,50.15.9TCP-SMP35320.01310.01.08.1TCP-K16920.01380.00.88. 2TCP-EGF3750.01320.00. 29. 5TCP-NUTP16740.01280*00.19. 2TCP-Frag1030.02230.01.011- 7TCF-other49626S0. 114162. 20. 534. 2UDfD

14、NS13420.01430.00.914.9UDPKEP3230.01330.010.012.6UDP-TFTP2780.02260.08.99.1UDP-Frag210.01290.0139. 58. 2UDFother56320. 211716 20. 51.9ICHP2456850.0106930,58.412,3IGMP210. o13873380.06. 215. 8IP-other70,016640.018.012. 3IP packet sizedistributi on这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：2%勺数据包的大小在33字节到64字节

15、之间。注意网站的访问量直线下降。很明显，在这段时间没人能访问他的Web服务器我开始研究到底发生了什么，以及该如何尽快地修复。、事件分析我的Web服务器发生了什么？很有可能攻击，那么受到什么样的攻击呢？从这一 攻击是对回显端口看，即是端口 7,不断发送小的UDP数据包来实现。攻击看似 发自两个策源地，可能是两个攻击者同时使用不同的工具。在任何情况下，超负荷的数据流都会拖垮Web服务器。然而攻击地址源不确定，不知道是攻击源本身 是分布的，还是同一个地址伪装出许多不同的IP地址，这个问题比较难判断。假如源地址不是伪装的，是真实地址，则可以咨询ARINI美国In ternet号码注册处，从它的“ wh

16、ois”数据库查出这个入侵1P地址属于哪个网络。接下来只需 联系那个网络的管理员就可以得到进一步的信息。那么假如源地址是伪装的，追踪这个攻击者就麻烦得多。若使用的是Cisco路由 器，则还需查询NetFlow高速缓存。NetFlow是Cisco快速转发(CEF)交换框架 的特性之一。为了追踪这个伪装的地址，必须查询每个路由器上的NetFlow缓存， 才能确定流量进入了哪个接口，然后通过这些路由器一次一个接口地往回一路追 踪，直至找到那个IP地址源。然而这样做是非常难的，因为在 WebServer和攻 击者的发起pc之间可能经由许多路由器，而且属于不同的组织。另外，必须在 攻击正在进行时做这些分

17、析。经过分析之后，将防火墙日志和路由器日志里的信息关联起来，发现了一些有趣的相似性，如表黑色标记处。攻击的目标显然是 Web服务器75，端口 为UDP 7,即回显端口。这看起来很像拒绝服务攻击 (但还不能确定，因为攻击 的分布很随意)。地址看起来多多少少是随意而分散的，只有一个源地址是固定 不变的，其源端口号也没变。这很有趣。接着又将注意力集中到路由器日志上。立刻发现，攻击发生时路由器日志上有大量的64字节的数据包，而此时Web服务 器日志上没有任何问题。他还发现，案发时路由器日志里还有大量的 “UDPother ”数据包，而 Web服务器日志也一切正常。这种现象与基于UD

18、P的拒绝服务攻击的假设还是很相符的。攻击者正是用许多小的UDP数据包对Web服务器的回显(echo 7)端口进行洪泛式 攻击，因此他们的下一步任务就是阻止这一行为。首先，我们在路由器上堵截攻击。快速地为路由器设置了一个过滤规则。因为源地址的来源很随机，他们认为很难用限制某个地址或某一块范围的地址来阻止攻击，因此决定禁止所有发给 75的UDP包。这种做法会使服务器丧失某些功能，如DNS但至少能让Web服务器正常工作。路由器最初的临时DOS访问控制链表(ACL)access-list 121 remark Temporary block DoS attack on web s

19、erver 75access-list 105 deny udp any host 75access-list 105 permit ip any any这样的做法为Web服务器减轻了负担，但攻击仍能到达 web,在一定程度上降低 了网络性能。 那么下一步工作是联系上游带宽提供商，想请他们暂时限制所有 在他的网站端口 7上的UDP入流量。这样做会显著降低网络上到服务器的流量。三、针对DOS预防措施对于预防及缓解这种带宽相关的 DoS攻击并没有什么灵丹妙药。本质上，这是- 种“粗管子打败细管子”的攻击。 攻击者能“指使”更多带宽，有时甚至是巨大 的带宽

20、，就能击溃带宽不够的网络。在这种情况下，预防和缓解应相辅相成。有许多方法可以使攻击更难发生，或者在攻击发生时减小其影响，具体如下：网络入口过滤网络服务提供商应在他的下游网络上设置入口过滤，以防止假信息包进入网络 （而把它们留在In ternet上）。这将防止攻击者伪装IP地址，从而易于追踪网络流量过滤过滤掉网络不需要的流量总是不会错的。这还能防止DoS攻击，但为了达到效果, 这些过滤器应尽量设置在网络上游。网络流量速率限制一些路由器有流量速率的最高限制。这些限制条款将加强带宽策略，并允许一个 给定类型的网络流量匹配有限的带宽。这一措施也能预先缓解正在进行的攻击， 同时，这些过滤器应尽量设置在网

21、络上游（尽可能靠近攻击者）；入侵检测系统和主机监听工具IDS能警告网络管理员攻击的发生时间，以及攻击者使用的攻击工具，这将能协 助阻止攻击。主机监听工具能警告管理员系统中是否出现DoS工具单点传送RPF这是CEF用于检查在接口收到的数据包的另一特性。如果源IP地址CEF表上不具有与指向接收数据包时的接口一致的路由的话，路由器就会丢掉这个数据包。丢弃RPF的妙处在于，它阻止了所有伪装源IP地址的攻击。针对DDO额防措施看了上面的实际案例我们也了解到，许多 DDoS攻击都很难应对，因为搞破坏的 主机所发出的请求都是完全合法、符合标准的，只是数量太大。借助恰当的ACL 我们可以阻断ICMPecho请

22、求。但是，如果有自己的自治系统，就应该允许从因 特网上ping你。不能ping通会使ISP或技术支持团队(如果有的话)丧失某些 故障排解能力。也可能碰到具有 Cisco TCP截获功能的SYN洪流：Router(c on fig)#ip tcp in tercept list 101Router(c on fig)#ip tcp in tercept max-i ncomplete high 3500Router(c on fig)#ip tcp in tercept max-i ncomplete low3000Router(c on fig)#ip tcp in tercept one-m

23、inute high 2500Router(c on fig)#ip tcp in tercept one-minute low 2000Router(c on fig)#access-list 101 permit any any如果能采用基于上下文的访问控制 (Co ntext Based Access Con trol,CBAC)，则 可以用其超时和阈值设置应对 SYN洪流和UDP垃圾洪流。例如：Router(c on fig)# ip in spect tcp syn wait-time 20Router(c on fig)# ip in spect tcp idle-time 60Router(c on fig)# ip in spect udp idle-time 20Router(c on fig)# ip in spect max-i ncomplete high 400Router(c on fig)# ip in spect max-i ncomplete low300Router(c on fig)# ip in spect one-minute high600Router(c on fig)# ip in spec