3 、拒绝服务攻击的发展
由于我们防范手段的加强，拒绝服务攻击手法也在不断的发展。
Tribe Flood Network (tfn) 和 tfn2k
引入了一个新概念：分布式。这些程序可以使得分散在互连网各处的机器共同完成对一台主机攻击的操作，从而使主机看起来好象是遭到了不同位置的许多主机的攻击。这些分散的机器由几台主控制机操作进行多种类型的攻击，如
UDP flood, SYN flood 等。
操作系统和网络设备的缺陷在不断地被发现并被黑客所利用来进行恶意的攻击。如果我们清楚的认识到了这一点，我们应当使用下面的两步来尽量阻止网络攻击保护我们的网络：
A ）尽可能的修正已经发现的问题和系统漏洞。
B ）识别，跟踪或禁止这些令人讨厌的机器或网络对我们的访问。
我们先来讨论一下 B ），在 B
）中我们面临的主要问题是如何识别那些恶意攻击的主机，特别是使用拒绝服务攻击的机器。因为这些机器隐藏了他们自己的地址，而冒用被攻击者的地址。攻击者使用了数以千记的恶意伪造包来使我们的主机受到攻击。
"tfn2k" 的原理就象上面讲的这么简单，而他只不过又提供了一个形象的界面。假如您遭到了分布式的拒绝服务攻击，实在是很难处理。
解决此类问题的一些专业手段 ---- 包过滤及其他的路由设置
有一些简单的手法来防止拒绝服务式的攻击。最为常用的一种当然是时刻关注安全信息以期待最好的方法出现。管理员应当订阅安全信息报告，实时的关注所有安全问题的发展。：）
第二步是应用包过滤的技术，主要是过滤对外开放的端口。这些手段主要是防止假冒地址的攻击，使得外部机器无法假冒内部机器的地址来对内部机器发动攻击。
我们可以使用 Cisco IOS 来检查路由器的详细设置，当然，它也不仅限于 Cisco
的设备，但由于现在 Cisco 设备在网络中占有了越来越多的市场份额（ 83%
），所以我们还是以它为例子，假如还有人有其他的例子，我们也非常高兴你能提出您的宝贵信息。
登陆到将要配置的路由器上，在配置访问控制列表之前先初始化一遍：
c3600(config)#access-list 100 permit ip 207.22.212.0
0.0.0 .255 any
c3600(config)#access-list 100 deny ip any any
然后我们假设在路由器的 S0 口上进行 ACL 的设置，我们进入 S0 口，并进入配置状态：
c3600(config)#int ser 0
c3600(config-if)#ip access-group
100 out
通过显示 access-list 来确认访问权限已经生效：
c3600#sho
access-lists 100
Extended IP access list 100
permit ip
207.22.212.0 0.0.0.255 any (5 matches)
deny ip any any (25202
matches)
对于应该使用向内的包过滤还是使用向外的包过滤一直存在着争论。 RFC 2267
建议在全球范围的互连网上使用向内过滤的机制，但是这样会带来很多的麻烦，在中等级别的路由器上使用访问控制列表不会带来太大的麻烦，但是已经满载的骨干路由器上会受到明显的威胁。
另一方面， ISP 如果使用向外的包过滤措施会把过载的流量转移到一些不太忙的设备上。 ISP
也不关心消费者是否在他们的边界路由器上使用这种技术。当然，这种过滤技术也并不是万无一失的，这依赖于管理人员采用的过滤机制。
我们经常会听到设备销售或集成商这样的推脱之词，他们总是说使用 ACL 会导致路由器和网络性能的下降。
ACL 确实会降低路由器的性能并加重 CPU 的负载，但这是微乎其微的。我们曾经在 Cisco 2600 和 3600
系列路由器上作过实验：
以下是不使用和使用 ACL 时的对照表：
Test Speed w/o ACL (Mbps) w/ ACL (Mbps) w/o ACL
(total time) w/ ACL (total time) % change
Cisco 2600 100Mbps
-> 100 Mbps File transfers 36.17 Mbps 35.46 Mbps 88.5 90.2
2.50%
Cisco 3600 10Mbps -> 10Mbps File transfers 7.95 Mbps
8.0Mbps 397 395 0.30%
使用的路由器配置如下：
2 Cisco 3640 (64MB RAM, R4700 processor, IOS v
12.0.5 T)
2 Cisco 2600 (128MB RAM, MPC860 processor, IOS
v12.0.5T)
由表我们可以看出，在使用 ACL 前后对路由器性能的影响并不是很大。
4 、使用 DNS 来跟踪匿名攻击
也许大家仍旧保存着侥幸心理，认为这些互连网上给我们带来无数麻烦 DoS
漏洞或许随着路由器包过滤，网络协议升级到 IPv6
或者随时的远程响应等手段变得越来越不重要。但从一个具有责任感的网管的观点来看，我们的目标并不是仅仅阻止拒绝服务攻击，而是要追究到攻击的发起原因及操作者。
当网络中有人使用假冒了源地址的工具（如 tfn2k
）时，我们虽然没有现成的工具来确认它的合法性，但我们可以通过使用 DNS 来对其进行分析：
假如攻击者选定了目标 http://www.technotronic.com/，他必须首先发送一个
DNS 请求来解析这个域名，通常那些攻击工具工具会自己执行这一步，调用 gethostbyname()
函数或者相应的应用程序接口，也就是说，在攻击事件发生前的 DNS 请求会提供给我们一个相关列表，我们可以利用它来定位攻击者。
使用现成工具或者手工读取 DNS 请求日志，来读取 DNS
可疑的请求列表都是切实可行的，然而，它有三个主要的缺点：
1) 攻击者一般会以本地的 DNS 为出发点来对地址进行解析查询，因此我们查到的 DNS
请求的发起者有可能不是攻击者本身，而是他所请求的本地 DNS 服务器。尽管这样，如果攻击者隐藏在一个拥有本地 DNS
的组织内，我们就可以把该组织作为查询的起点。
2) 攻击者有可能已经知道攻击目标的 IP 地址，或者通过其他手段（ host, ping
）知道了目标的 IP 地址，亦或是攻击者在查询到 IP 地址后很长一段时间才开始攻击，这样我们就无法从 DNS
请求的时间段上来判断攻击者（或他们的本地服务器）。
3) DNS 对不同的域名都有一个却省的存活时间，因此攻击者可以使用存储在 DNS
缓存中的信息来解析域名。为了更好做出详细的解析记录，您可以把 DNS 却省的 TTL 时间缩小，但这样会导致 DNS
更多的去查询所以会加重网络带宽的使用。
在许多情况下，只要您拥有足够的磁盘空间，记录所有的 DNS 请求并不是一种有害的做法。在
BIND8.2 中做记录的话，可以在 named.conf 中假如下面的几行：
logging {
channel requestlog { file "dns.log" ；
} ；
category queries { requestlog ； } ；
} ；
【本站声明】本站刊载的部分内容全部来源互联网,对于此类文章本站仅提供交流平台，不为其版权负责。如涉及侵犯您的知识产权的文章，请联系我们，我们将尽快做出更正。并向您表示感谢！同时特别感谢对本站所有支持的网友。
