解决此类问题的一些专业手段----包过滤及其他的路由设置
有一些简单的手法来防止拒绝服务式的攻击。最为常用的一种当然是时刻关注安全信息以期待最好的方法出现。管理员应当订阅安全信息报告，实时的关注所有安全问题的发展。
第二步是应用包过滤的技术，主要是过滤对外开放的端口。这些手段主要是防止假冒地址的攻击，使得外部机器无法假冒内部机器的地址来对内部机器发动攻击。
我们可以使用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 00.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%
使用的路由器配置如下：
Cisco 3640 (64MB RAM, R4700 processor, IOS v12.0.5T)
Cisco 2600 (128MB RAM, MPC860 processor, IOS v12.0.5T)
由表我们可以看出，在使用ACL前后对路由器性能的影响并不是很大。
使用DNS来跟踪匿名攻击
也许大家仍旧保存着侥幸心理，认为这些互连网上给我们带来无数麻烦DoS漏洞或许随着路由器包过滤，网络协议升级到IPv6或者随时的远程响应等手段变得越来越不重要。但从一个具有责任感的网管的观点来看，我们的目标并不是仅仅阻止拒绝服务攻击，而是要追究到攻击的发起原因及操作者。
当网络中有人使用假冒了源地址的工具（如tfn2k）时，我们虽然没有现成的工具来确认它的合法性，但我们可以通过使用DNS来对其进行分析：
假如攻击者选定了目标www.technotronic.com，他必须首先发送一个DNS请求来解析这个域名，通常那些攻击工具工具会自己执行这一步，调用gethostbyname()函数或者相应的应用程序接口，也就是说，在攻击事件发生前的DNS请求会提供给我们一个相关列表，我们可以利用它来定位攻击者。
使用现成工具或者手工读取DNS请求日志，来读取DNS可疑的请求列表都是切实可行的，然而，它有三个主要的缺点：
攻击者一般会以本地的DNS为出发点来对地址进行解析查询，因此我们查到的DNS请求的发起者有可能不是攻击者本身，而是他所请求的本地DNS服务器。尽管这样，如果攻击者隐藏在一个拥有本地DNS的组织内，我们就可以把该组织作为查询的起点。
攻击者有可能已经知道攻击目标的IP地址，或者通过其他手段（host, ping）知道了目标的IP地址，亦或是攻击者在查询到IP地址后很长一段时间才开始攻击，这样我们就无法从DNS请求的时间段上来判断攻击者（或他们的本地服务器）。
DNS对不同的域名都有一个却省的存活时间，因此攻击者可以使用存储在DNS缓存中的信息来解析域名。为了更好做出详细的解析记录，您可以把DNS却省的TTL时间缩小，但这样会导致DNS更多的去查询所以会加重网络带宽的使用。
在许多情况下，只要您拥有足够的磁盘空间，记录所有的DNS请求并不是一种有害的做法。在BIND8.2中做记录的话，可以在named.conf中假如下面的几行：
logging {
channel requestlog { file "dns.log"; };
category queries { requestlog; };
};
打开： http://www.qqread.com/safe/i002503007.html
更多内容请看DoS 拒绝服务攻击专题、脚本攻击和防范、DDoS攻击防御与分析专题，或进入讨论组讨论。
有一些简单的手法来防止拒绝服务式的攻击。最为常用的一种当然是时刻关注安全信息以期待最好的方法出现。管理员应当订阅安全信息报告，实时的关注所有安全问题的发展。
第二步是应用包过滤的技术，主要是过滤对外开放的端口。这些手段主要是防止假冒地址的攻击，使得外部机器无法假冒内部机器的地址来对内部机器发动攻击。
我们可以使用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 00.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%
使用的路由器配置如下：
Cisco 3640 (64MB RAM, R4700 processor, IOS v12.0.5T)
Cisco 2600 (128MB RAM, MPC860 processor, IOS v12.0.5T)
由表我们可以看出，在使用ACL前后对路由器性能的影响并不是很大。
使用DNS来跟踪匿名攻击
也许大家仍旧保存着侥幸心理，认为这些互连网上给我们带来无数麻烦DoS漏洞或许随着路由器包过滤，网络协议升级到IPv6或者随时的远程响应等手段变得越来越不重要。但从一个具有责任感的网管的观点来看，我们的目标并不是仅仅阻止拒绝服务攻击，而是要追究到攻击的发起原因及操作者。
当网络中有人使用假冒了源地址的工具（如tfn2k）时，我们虽然没有现成的工具来确认它的合法性，但我们可以通过使用DNS来对其进行分析：
假如攻击者选定了目标www.technotronic.com，他必须首先发送一个DNS请求来解析这个域名，通常那些攻击工具工具会自己执行这一步，调用gethostbyname()函数或者相应的应用程序接口，也就是说，在攻击事件发生前的DNS请求会提供给我们一个相关列表，我们可以利用它来定位攻击者。
使用现成工具或者手工读取DNS请求日志，来读取DNS可疑的请求列表都是切实可行的，然而，它有三个主要的缺点：
攻击者一般会以本地的DNS为出发点来对地址进行解析查询，因此我们查到的DNS请求的发起者有可能不是攻击者本身，而是他所请求的本地DNS服务器。尽管这样，如果攻击者隐藏在一个拥有本地DNS的组织内，我们就可以把该组织作为查询的起点。
攻击者有可能已经知道攻击目标的IP地址，或者通过其他手段（host, ping）知道了目标的IP地址，亦或是攻击者在查询到IP地址后很长一段时间才开始攻击，这样我们就无法从DNS请求的时间段上来判断攻击者（或他们的本地服务器）。
DNS对不同的域名都有一个却省的存活时间，因此攻击者可以使用存储在DNS缓存中的信息来解析域名。为了更好做出详细的解析记录，您可以把DNS却省的TTL时间缩小，但这样会导致DNS更多的去查询所以会加重网络带宽的使用。
在许多情况下，只要您拥有足够的磁盘空间，记录所有的DNS请求并不是一种有害的做法。在BIND8.2中做记录的话，可以在named.conf中假如下面的几行：
logging {
channel requestlog { file "dns.log"; };
category queries { requestlog; };
};
打开： http://www.qqread.com/safe/i002503007.html
更多内容请看DoS 拒绝服务攻击专题、脚本攻击和防范、DDoS攻击防御与分析专题，或进入讨论组讨论。
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- DoS 拒绝服务攻击专题 (1215篇文章)
- 脚本攻击和防范 (2353篇文章)
- DDoS攻击防御与分析 (1480篇文章)
- ARP攻击防范与解决方案 (1702篇文章)
- DoS 原理及概述 (10篇文章)
- DDos原理 (20篇文章)
- 路由器安全设置 详解 (338次浏览)
- U盘病毒auto.exe的手工清除方法 (211次浏览)
- 安全与速度的较量：VPN路由器大比拼 (198次浏览)
- gdwli32盗号木马清除方法及专杀工具 (185次浏览)
- 网络分析软件:ARP病毒爆发了谁干的？ (92次浏览)
- 交换机及路由器如何更加安全 教你六大规则 (85次浏览)
- Javqhc木马清除方法及专杀工具 (85次浏览)
- 安全技巧：关于ARP病毒造成断网的处理方法 (81次浏览)
- ARP病毒新罪首 查杀处理有绝招 (80次浏览)
- 网络安全测试工具 为网络保驾护航 (77次浏览)
