网络技术是从1990年代中期发展起来的新技术，它把互联网上分散的资源融为有机整体，实现资源的全面共享和有机协作，使人们能够透明地使用资源的整体能力并按需获取信息。资源包括高性能计算机、存储资源、数据资源、信息资源、知识资源、专家资源、大型数据库、网络、传感器等。 当前的互联网只限于信息共享，网络则被认为是互联网发展的第三阶段。
拒绝服务攻击是一种遍布全球的系统漏洞，黑客们正醉心于对它的研究，而无数的
网络用户将成为这种攻击的受害者。TribeFloodNetwork,tfn2k,smurf,targa…还有许多的程序都在被不断的开发出来。这些程序想瘟疫一样在
网络中散布开来，使得我们的村落更为薄弱，我们不得不找出一套简单易用的安全解决方案来应付黑暗中的攻击。
由于我们防范手段的加强，拒绝服务攻击手法也在不断的发展。 TribeFloodNetwork(tfn)和tfn2k引入了一个新概念：分布式。这些程序可以使得分散在互连网各处的机器共同完成对一台主机攻击的操作，从而使主机看起来好象是遭到了不同位置的许多主机的攻击。这些分散的机器由几台主控制机操作进行多种类型的攻击，如UDPflood,SYNflood等。
操作系统和
网络设备的缺陷在不断地被发现并被黑客所利用来进行恶意的攻击。如果我们清楚的认识到了这一点，我们应当使用下面的两步来尽量阻止
网络攻击保护我们的
网络:
尽可能的修正已经发现的问题和系统漏洞。
识别，跟踪或禁止这些令人讨厌的机器或
网络对我们的访问。
我们先来关注第二点我们面临的主要问题是如何识别那些恶意攻击的主机，特别是使用拒绝服务攻击的机器。因为这些机器隐藏了他们自己的地址，而冒用被攻击者的地址。攻击者使用了数以千记的恶意伪造包来使我们的主机受到攻击。"tfn2k"的原理就象上面讲的这么简单，而他只不过又提供了一个形象的界面。假如您遭到了分布式的拒绝服务攻击，实在是很难处理。
有一些简单的手法来防止拒绝服务式的攻击。最为常用的一种当然是时刻关注安全信息以期待最好的方法出现。管理员应当订阅安全信息报告，实时的关注所有安全问题的发展。：） 第二步是应用包过滤的技术，主要是过滤对外开放的端口。这些手段主要是防止假冒地址的攻击，使得外部机器无法假冒内部机器的地址来对内部机器发动攻击。
对于应该使用向内的包过滤还是使用向外的包过滤一直存在着争论。RFC2267建议在全球范围的互连网上使用向内过滤的机制，但是这样会带来很多的麻烦，在中等级别的路由器上使用访问控制列表不会带来太大的麻烦，但是已经满载的骨干路由器上会受到明显的威胁。另一方面，ISP如果使用向外的包过滤措施会把过载的流量转移到一些不太忙的设备上。ISP也不关心消费者是否在他们的边界路由器上使用这种技术。当然，这种过滤技术也并不是万无一失的，这依赖于管理人员采用的过滤机制。
1．ICMP防护措施
ICMP最初开发出来是为了"帮助"
网络，经常被广域网管理员用作诊断工具。但今天各种各样的不充分的ICMP被滥用，没有遵守RFC 792原先制订的标准，要执行一定的策略可以让它变得安全一些。
入站的ICMP时间标记（Timestamp）和信息请求(Information Request)数据包会得到响应，带有非法或坏参数的伪造数据包也能产生ICMP参数问题数据包，从而允许另外一种形式的主机搜寻。这仍使得站点没有得到适当保护。
以秘密形式从主方到客户方发布命令的一种通用方法，就是使用ICMP Echo应答数据包作为载波。 回声应答本身不能回答，一般不会被
防火墙阻塞。
首先，我们必须根据出站和入站处理整个的"ICMP限制"问题。ICMP回声很容易验证远程机器，但出站的ICMP回声应该被限制只支持个人或单个服务器/ICMP代理（首选）。
如果我们限制ICMP回声到一个外部IP地址（通过代理），则我们的ICMP回声应答只能进入我们
网络中预先定义的主机。
重定向通常可以在路由器之间找到，而不是在主机之间。防火墙规则应该加以调整，使得这些类型的ICMP只被允许在需要信息的网际连接所涉及的路由器之间进行。
建议所有对外的传输都经过代理，对内的ICMP传输回到代理地址的时候要经过防火墙。这至少限制了ICMP超时数据包进入一个内部地址，但它可能阻塞超时数据包。
当ICMP数据包以不正确的参数发送时，会导致数据包被丢弃，这时就会发出ICMP参数出错数据包。主机或路由器丢弃发送的数据包，并向发送者回送参数ICMP出错数据包，指出坏的参数。
总的来说，只有公开地址的服务器（比如Web、电子邮件和FTP服务器）、防火墙、联入因特网的路由器有真正的理由使用ICMP与外面的世界对话。如果调整适当，实际上所有使用进站和出站ICMP的隐密通讯通道都会被中止。
2. SYN Flood防范
SYN Flood是当前最流行的DoS（拒绝服务攻击）与DdoS（分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。对于SYN Flood攻击，目前尚没有很好的监测和防御方法，不过如果系统管理员熟悉攻击方法和系统架构，通过一系列的设定，也能从一定程度上降低被攻击系统的负荷，减轻负面的影响。
一般来说，如果一个系统（或主机）负荷突然升高甚至失去响应，使用Netstat 命令能看到大量SYN_RCVD的半连接（数量>500或占总连接数的10%以上），可以认定，这个系统（或主机）遭到了SYN Flood攻击。遭到SYN Flood攻击后，首先要做的是取证，通过Netstat –n –p tcp >resault.txt记录目前所有TCP连接状态是必要的，如果有
嗅探器，或者TcpDump之类的工具，记录TCP SYN报文的所有细节也有助于以后追查和防御，需要记录的字段有：源地址、IP首部中的标识、TCP首部中的序列号、TTL值等，这些信息虽然很可能是攻击者伪造的，但是用来分析攻击者的心理状态和攻击程序也不无帮助。特别是TTL值，如果大量的攻击包似乎来自不同的IP但是TTL值却相同，我们往往能推断出攻击者与我们之间的路由器距离，至少也可以通过过滤特定TTL值的报文降低被攻击系统的负荷（在这种情况下TTL值与攻击报文不同的用户就可以恢复正常访问）。从防御角度来说，有几种简单的解决方法：
2.1缩短SYN Timeout时间:由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度 x SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下（过低的SYN Timeout设置可能会影响客户的正常访问），可以成倍的降低服务器的负荷。
2.2设置SYN Cookie:就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个IP地址来的包会被丢弃。可是上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。
2.3负反馈策略:参考一些流行的操作系统，如
Windows2000的SYN攻击保护机制：正常情况下，OS对TCP连接的一些重要参数有一个常规的设置： SYN Timeout时间、SYN-ACK的重试次数、SYN报文从路由器到系统再到Winsock的延时等等。这个常规设置针对系统优化，可以给用户提供方便快捷的服务；一旦服务器受到攻击，SYN Half link 的数量超过系统中TCP活动 Half Connction最大连接数的设置，系统将会认为自己受到了SYN Flood攻击，并将根据攻击的判断情况作出反应：减短SYN Timeout时间、减少SYN-ACK的重试次数、自动对缓冲区中的报文进行延时等等措施，力图将攻击危害减到最低。如果攻击继续，超过了系统允许的最大Half Connection 值，系统已经不能提供正常的服务了，为了保证系统不崩溃，可以将任何超出最大Half Connection 值范围的SYN报文随机丢弃，保证系统的稳定性。
所以，可以事先测试或者预测该主机在峰值时期的Half Connction 的活动数量上限，以其作为参考设定TCP活动 Half Connction最大连接数的值，然后再以该值的倍数（不要超过2）作为TCP最大Half Connection值，这样可以通过负反馈的手段在一定程度上阻止SYN攻击。
2.4退让策略:退让策略是基于SYN Flood攻击代码的一个缺陷，我们重新来分析一下SYN Flood攻击者的流程：SYN Flood程序有两种攻击方式，基于IP的和基于域名的，前者是攻击者自己进行域名解析并将IP地址传递给攻击程序，后者是攻击程序自动进行域名解析，但是它们有一点是相同的，就是一旦攻击开始，将不会再进行域名解析，我们的切入点正是这里：假设一台服务器在受到SYN Flood攻击后迅速更换自己的IP地址，那么攻击者仍在不断攻击的只是一个空的IP地址，并没有任何主机，而防御方只要将DNS解析更改到新的IP地址就能在很短的时间内（取决于DNS的刷新时间）恢复用户通过域名进行的正常访问。为了迷惑攻击者，我们甚至可以放置一台“牺牲”服务器让攻击者满足于攻击的“效果”（由于DNS缓冲的原因，只要攻击者的浏览器不重起，他访问的仍然是原先的IP地址）。
2.5分布式DNS负载均衡:在众多的负载均衡架构中，基于DNS解析的负载均衡本身就拥有对SYN Flood的免疫力，基于DNS解析的负载均衡能将用户的请求分配到不同IP的服务器主机上，攻击者攻击的永远只是其中一台服务器，一来这样增加了攻击者的成本，二来过多的DNS请求可以帮助我们追查攻击者的真正踪迹（DNS请求不同于SYN攻击，是需要返回数据的，所以很难进行IP伪装）。
2.6防火墙Qos:对于防火墙来说，防御SYN Flood攻击的方法取决于防火墙工作的基本原理，一般说来，防火墙可以工作在TCP层之上或IP层之下，工作在TCP层之上的防火墙称为网关型防火墙，网关型防火墙布局中，客户机与服务器之间并没有真正的TCP连接，客户机与服务器之间的所有数据交换都是通过防火墙代理的，外部的DNS解析也同样指向防火墙，所以如果网站被攻击，真正受到攻击的是防火墙，这种防火墙的优点是稳定性好，抗打击能力强，但是因为所有的TCP报文都需要经过防火墙转发，所以效率比较低由于客户机并不直接与服务器建立连接，在TCP连接没有完成时防火墙不会去向后台的服务器建立新的TCP连接，所以攻击者无法越过防火墙直接攻击后台服务器，只要防火墙本身做的足够强壮，这种架构可以抵抗相当强度的SYN Flood攻击。但是由于防火墙实际建立的TCP连接数为用户连接数的两倍（防火墙两端都需要建立TCP连接），同时又代理了所有的来自客户端的TCP请求和数据传送，在系统访问量较大时，防火墙自身的负荷会比较高，所以这种架构并不能适用于大型网站。（我感觉，对于这样的防火墙架构，使用TCP_STATE攻击估计会相当有效:）
工作在IP层或IP层之下的称为路由型防火墙，其工作原理有所不同：客户机直接与服务器进行TCP连接，防火墙起的是路由器的作用，它截获所有通过的包并进行过滤，通过过滤的包被转发给服务器，外部的DNS解析也直接指向服务器，这种防火墙的优点是效率高，可以适应100Mbps-1Gbps的流量，但是这种防火墙如果配置不当，不仅可以让攻击者越过防火墙直接攻击内部服务器，甚至有可能放大攻击的强度，导致整个系统崩溃。
在这两种基本模型之外，有一种新的防火墙模型，它集中了两种防火墙的优势，这种防火墙的工作原理如下所示：
第一阶段，客户机请求与防火墙建立连接：
第二阶段，防火墙伪装成客户机与后台的服务器建立连接
第三阶段，之后所有从客户机来的TCP报文防火墙都直接转发给后台的服务器
这种结构吸取了上两种防火墙的优点，既能完全控制所有的SYN报文，又不需要对所有的TCP数据报文进行代理，是一种两全其美的方法。近来，国外和国内的一些防火墙厂商开始研究带宽控制技术，如果能真正做到严格控制、分配带宽，就能很大程度上防御绝大多数的SYN攻击。
3.Smurf防范的几种方法
阻塞Smurf攻击的源头:Smurf攻击依靠攻击者的力量使用欺骗性源地址发送echo请求。用户可以使用路由路的访问保证内部
网络中发出的所有传输信息都具有合法的源地址，以防止这种攻击。这样可以使欺骗性分组无法找到反弹站点。
阻塞Smurf的反弹站点:用户可以有两种选择以阻塞Smurf攻击的反弹站点。第一种方法可以简单地阻塞所有入站echo请求，这们可以防止这些分组到达自己的
网络。如果不能阻塞所有入站echo请求，用户就需要让自己的路由器把
网络广播地址映射成为LAN广播地址。制止了这个映射过程，自己的系统就不会再收到这些echo请求。
阻止Smurf平台:为防止系统成为 smurf攻击的平台，要将所有路由器上IP的广播功能都禁止。一般来讲，IP广播功能并不需要。 如果攻击者要成功地利用你成为攻击平台，你的路由器必须要允许信息包以不是从你的内网中产生的源地址离开
网络。配置路由器，让它将不是由你的内网中生成的信息包过滤出去，这是有可能做到的。这就是所谓的
网络出口过滤器功能。
防止Smurf攻击目标站点:除非用户的ISP愿意提供帮助，否则用户自己很难防止Smurf对自己的WAN接连线路造成的影响。虽然用户可以在自己的
网络设备中阻塞这种传输，但对于防止Smurf吞噬所有的WAN带宽已经太晚了。但至少用户可以把Smurf的影响限制在外围设备上。通过使用动态分组过滤技术，或者使用防火墙，用户可以阻止这些分组进入自己的
网络。防火墙的状态表很清楚这些攻击会话不是本地
网络中发出的（状态表记录中没有最初的echo请求记录），因些它会象对待其它欺骗性攻击行为那样把这样信息丢弃。
4.UDP Flood防范
以前文提到的trinoo为例，分析如下：
在master程序与代理程序的所有通讯中，trinoo都使用了UDP协议。入侵检测软件能够寻找使用UDP协议的数据流(类型17)。
Trinoo master程序的监听端口是27655，攻击者一般借助telnet通过TCP连接到master程序所在计算机。入侵检测软件能够搜索到使用TCP (类型6)并连接到端口27655的数据流。
所有从master程序到代理程序的通讯都包含字符串"l44"，并且被引导到代理的UDP 端口27444。入侵检测软件检查到UDP 端口27444的连接，如果有包含字符串l44的信息包被发送过去，那么接受这个信息包的计算机可能就是DDoS代理。
Master和代理之间通讯受到口令的保护，但是口令不是以加密格式发送的，因此它可以被“嗅探”到并被检测出来。使用这个口令以及来自Dave Dittrich的trinot
脚本http://staff.washington.edu/dittrich/misc/trinoo.analysis，要准确地验证出trinoo代理的存在是很可能的。
一旦一个代理被准确地识别出来，trinoo
网络就可以安装如下步骤被拆除：
在代理daemon上使用"strings"命令，将master的IP地址暴露出来。
与所有作为trinoo master的机器管理者联系，通知它们这一事件。
在master计算机上，识别含有代理IP地址列表的文件(默认名"...")，得到这些计算机的IP地址列表。
向代理发送一个伪造"trinoo"命令来禁止代理。通过crontab 文件(在UNIX系统中)的一个条目，代理可以有规律地重新启动， 因此，代理计算机需要一遍一遍地被关闭，直到代理系统的管理者修复了crontab文件为止。
检查master程序的活动TCP连接，这能显示攻击者与trinoo master程序之间存在的实时连接。
如果
网络正在遭受trinoo攻击，那么系统就会被UDP 信息包所淹没。Trinoo从同一源地址向目标主机上的任意端口发送信息包。探测trinoo就是要找到多个UDP信息包，它们使用同一来源IP地址、同一目的IP地址、同一源端口，但是不同的目的端口。
在http://www.fbi.gov/nipc/trinoo.htm上有一个检测和根除trinoo的自动程序。
5.使用DNS来跟踪匿名攻击
从一个网管的观点来看，防范的目标并不是仅仅阻止拒绝服务攻击，而是要追究到攻击的发起原因及操作者。当
网络中有人使用假冒了源地址的工具（如tfn2k）时，我们虽然没有现成的工具来确认它的合法性，但我们可以通过使用DNS来对其进行分析：
假如攻击者选定了目标www.ttttt.com，他必须首先发送一个DNS请求来解析这个域名，通常那些攻击工具工具会自己执行这一步，调用gethostbyname()函数或者相应的应用程序接口，也就是说，在攻击事件发生前的DNS请求会提供给我们一个相关列表，我们可以利用它来定位攻击者。
使用现成工具或者手工读取DNS请求日志，来读取DNS可疑的请求列表都是切实可行的，然而，它有三个主要的缺点：
攻击者一般会以本地的DNS为出发点来对地址进行解析查询，因此我们查到的DNS请求的发起者有可能不是攻击者本身，而是他所请求的本地DNS服务器。尽管这样，如果攻击者隐藏在一个拥有本地DNS的组织内，我们就可以把该组织作为查询的起点。
攻击者有可能已经知道攻击目标的IP地址，或者通过其他手段（host,ping）知道了目标的IP地址，亦或是攻击者在查询到IP地址后很长一段时间才开始攻击，这样我们就无法从DNS请求的时间段上来判断攻击者（或他们的本地服务器）。
DNS对不同的域名都有一个却省的存活时间，因此攻击者可以使用存储在DNS缓存中的信息来解析域名。为了更好做出详细的解析记录，您可以把DNS却省的TTL时间缩小，但这样会导致DNS更多的去查询所以会加重
网络带宽的使用。
6.主机防范
所有对因特网提供公开服务的主机都应该加以限制。下面建议的策略可以保护暴露在因特网上的主机。
将所有公开服务器与DMZ隔离
提供的每种服务都应该有自己的服务器。
如果使用Linux（建议这样做），你就可以使用一个或几个"缓冲溢出/堆栈执行"补丁或增强来防止绝大多数（如果不能全部）本地或远程缓冲溢出，以避免这些溢出危及根的安全。强烈建议将Solar Designer的补丁包括在附加的安全特征中。
使用SRP（Secure Remote Password 安全远程口令）代替SSH。
限制只有内部地址才能访问支持SRP的telnet和FTP守护程序，强调只有支持SRP的客户端才可以与这些程序对话。如果你必须为公开访问运行常规的FTP（比如匿名FTP），可以在另一个端口运行SRP FTP。
使用可信任的路径。根用户拥有的二进制执行程序应该放置的目录的所有权应该是根，不能让全部用户或组都有写权限。如果有必要的话，为了强制这样做，你可以改变内核。
使用内置防火墙功能。通过打开防火墙规则，可以经常利用内核状态表。
使用一些防端口扫描措施。这可以使用Linux的后台程序功能或通过修改内核实现。
使用Tripwire 和相同作用的软件来帮助发觉对重要文件的修改。
7.电子邮件炸弹防护
对于保护电子件的安全来说，了解一下电子邮件的发送过程是很有必要的。它的过程是这样的，当有用户将邮件写好之后首先连接到邮件服务器上，当邮件服务器有响应时便会启动邮件工具，调用路由（这里指的是邮件的路由）程序Sendmail进行邮件路由，根据邮件所附的接收地址中指定的接收主机，比如： a@163.net里的163.net，与位于主机163.net电子邮件后台守护程序建立25端口的TCP连接，建立后双方按照SMTP协议进行交互第进，从而完成邮件的投递工作，接收方电子邮件接收邮件后，再根据接收用户名称，放置在系统的邮件目录里，如/usr/电子邮件目录的semxa文件中。接收用户同样使用邮件工具获取和阅读这些已投递的邮件。如果投递失败的话，这些邮件将重新返回到发送方。实际上电子邮件的发送过程要比这里所说的更为复杂些，在过程里将会涉及很多的配置文件。在现在的SMTP协议是一个基于文本的协议，理解和实现都相对比较简单些，你可以使用telnet直接登陆到邮件服务器的25端口（由LANA授权分配给SMTP协议）进行交互。
保护电子信箱邮件的信息安全最有效的办法就是使用加密的签名技术，像PGP来验证邮件，通过验证可以保护到信息是从正确的地方发来的，而且在传送过程中不被修改。但是这就不是个人用户所能达到的了，因为PGP比较复杂。
就电子邮件炸弹而言，保护还是可以做得很好的。因为它的复杂性不是很高，多的仅仅是垃圾邮件而已。你可以使用到http://semxa.kstar.com/hacking/echom201.zip E-mail Chomper（砍信机）来保护自己。但是目前就国内用户而言，大多用户所使用的都是免费的邮箱，像yeah.net、163.net、263.net等，即便是有人炸顶多也是留在邮件服务器上了，危害基本上是没有的。如果是用pop3接的话，可以用Outlook或Foxmail等pop的收信工具来接收的mail，大多用户使用的是
windows的Outlook Express，可以在“工具－收件箱助理”中设置过滤。对于各种利用电子邮件而传播的Email蠕虫病毒和对未知的Emai蠕虫病毒你可以使用防电子邮件病毒软件来防护。
另外，邮件系统管理员可以使用“黑名单”来过滤一些垃圾信件。对于不同的邮件系统，大都可以在
网络上找到最新的黑名单程序或者列表。
8.使用ngrep工具来处理tfn2k攻击
根据使用DNS来跟踪tfn2k驻留程序的原理，现在已经出现了称为ngrep的实用工具。经过修改的ngrep可以监听大约五种类型的tfn2k拒绝服务攻击(targa3,SYNflood,UDPflood,ICMPflood和smurf)，它还有一个循环使用的缓存用来记录DNS和ICMP请求。如果ngrep发觉有攻击行为的话，它会将其缓存中的内容打印出来并继续记录ICMP回应请求。假如攻击者通过ping目标主机的手段来铆定攻击目标的话，在攻击过程中或之后记录ICMP的回应请求是一种捕获粗心的攻击者的方法。由于攻击者还很可能使用其他的服务来核实其攻击的效果（例如web），所以对其他的标准服务也应当有尽量详细的日志记录。
还应当注意，ngrep采用的是监听
网络的手段，因此，ngrep无法在交换式的环境中使用。但是经过修改的ngrep可以不必和你的DNS在同一个网段中，但是他必须位于一个可以监听到所有DNS请求的位置。经过修改的ngrep也不关心目标地址，您可以把它放置在DMZ网段，使它能够检查横贯该
网络的tfn2k攻击。从理论上讲，它也可以很好的检测出对外的tfn2k攻击。
在ICMPflood事件中，ICMP回应请求的报告中将不包括做为tfn2kflood一部分的ICMP包。Ngrep还可以报告检测出来的除smurf之外的攻击类型（TARGA,UDP,SYN,ICMP等）。混合式的攻击在缺省情况下表现为ICMP攻击，除非你屏蔽了向内的ICMP回应请求，这样它就表现为UDP或SYN攻击。这些攻击的结果都是基本类似的。
9.有关入侵检测系统的建议
由于许多用来击败基于
网络的入侵检测系统的方法对绝大多数商业入侵检测系统产品仍然是有效的，因此建议入侵检测系统应该至少有能重组或发觉碎片的自寻址数据包。下面是部分要注意的事项：
确信包括了现有的所有规则，包括一些针对分布式拒绝服务攻击的新规则。
如果遵循了ICMP建议项，许多ICMP会被阻塞，入侵检测系统触发器存在许多机会。任何通常情况下要被阻塞的入站或出站的ICMP数据包可以被触发。
"任何"被你用防火墙分离的
网络传输都可能是一个潜在的IDS触发器。
如果你的入侵检测系统支持探测长时间周期的攻击，确信没有把允许通过防火墙的被信任主机排除在外。这也包括虚拟专用网。
如果你能训练每个使用ping的用户在ping主机时使用小数据包，就可能设置入侵检测系统寻找超29字节的Echo和Echo应答数据包。
网络的神奇作用吸引着越来越多的用户加入其中，正因如此，网络的承受能力也面临着越来越严峻的考验―从硬件上、软件上、所用标准上......，各项技术都需要适时应势，对应发展，这正是网络迅速走向进步的催化剂。
……