攻击在凌晨两点左右开始，那时我正好还在工作，所以我才有机会迅速的抓取到一部分的洪水攻击的信息。这次攻击使Verio （我们的网络提供商）的集合路由器将攻击数据挤满了我们的两条T1 。我们的网站服务器因为这次攻击而无法处理其它合法的请求。我们被完全的炸下了网。
我们以前就曾遭受过UDP 和ICMP 洪水攻击，这些攻击其实都可以由被攻击者入侵的主机、zombie 工具及Windows 系统简单的实现，我们也被一些经典的SYN 洪水攻击过。所以当我查看了一下那些显示我们是被SYN/ACK 数据攻击的攻击数据包后，眉毛跳了一下。毕竟这些事实并不重要，就像我以前说的那样，一个SYN/ACK 包只是一个SYN 数据包带了一个ACK标记。任何有限权制作"raw socket"的人都可以制作出这种数据包来 —— 不管他是恶意的还是无意的。 
真正的惊讶是当我看到这些发起攻击的地址 ： 

...

...

此处省略了近200个攻击的网络地址 

我们看起来是在被超过200 多个网络核心基础设施路由器攻击. 
发生什么事了？ 
看到这些分别来自Verio 、Qwest 、和 Above.net 的洪水数据包，我想它们都是完全合法的SYN/ACK 连接回应包，它们显示了一个TCP 源端口：179 。换句话说，就像一个网页服务器的数据包会从HTTP 的80 号端口返回一样，这些数据包是从"BGP"的179 号端口返回的。 
BGP 是中介路由器支持的"边界网关协议"（Border Gateway Protocol ）。 路由器使用BGP与他们的邻居进行即时的信息交流来交换他们的" 路由表" ，这是为了通知它们彼此路由器可以在哪个IP 范围进行转交。 
BGP 的细节并不重要，重要的是每个良好连接（高宽带）的中介路由器都会接受在他们179端口上的连接。换句话来说，任何一个SYN 数据包到达一个网络路由器上后都会引出一个该路由的SYN/ACK 回应包来。

我突然知道什么会一定发生….. 
这些被利用来攻击的两百台主机不可能全存在安全问题，甚至可能没有任何一台有安全问题。 
我认识到它们只不过全是一些普通的的TCP 服务器，它们是在认为我们想建立一个TCP 连接到它们自带的BGP 服务的情况下才向grc.com 发送SYN/ACK 数据包的。 
换句话说，一个恶意的入侵者在其他的Internet 角落里利用带有连接请求的syn 数据包对网络路由器进行洪水攻击。这些数据包带有虚假的IP 地址，这些地址都是grc.com 的。这样以来，路由器认为这些Syn 数据包是从grc.com 发送来的，所以它们便对它们发送SYN/ACK数据包作为三次握手过程的第二个步。 

恶意的数据包其实就被那些被利用的主机“反射”到了受害者主机上。这些被反射的数据包返回到受害者主机上后，就形成了洪水攻击。

阻拦反射攻击 
我们有一些好消息，这种攻击看起来可以很简单的阻拦。因为我们自己不是网络服务提供商，以我们从来没有任何连接到远程带有BGP 服务的路由器上的需要。这样以来，我便要求Verio去阻拦任何从BGP 服务端口179 发起的入站数据。因为这个恶意攻击者的SYN 数据包的目标是网络上中介路由的179 号端口，任何反射的数据包也应该会从那个端口发出。 
Verio 的工程师加了一个filter 到提供我们网络服务的集合路由上，它用来阻拦（丢弃）任何从179 端口发来的数据包。从179 号端口发送来的数据包洪水立即停止了。 
但我们并没有回到Internet 上。 
一个刚从网上抓到的数据包显示我们现在正被一群全新的网络服务器攻击。因为这第二群攻击是在我们阻拦了从179 端口发送来的攻击以后才出现的，所以这第二拨攻击没有办法跟第一拨的攻击力相比。 
我们现在正在被从端口22 (Secure Shell), 23 (Telnet), 53 (DNS), 和80 (HTTP/Web)上发送来的SYN/ACK 数据包攻击。这其中还有一些从端口4001 (代理服务器端口)和6668(IRC 聊天)发送来的数据包。 
很可惜的是，因为这第二波攻击完全出乎我的意料，所以我没有抓到这第二波攻击的完整的数据包来作为取样。不过，我先前在第一波攻击中所抓到一些日志有展现一些非BGP 所发出的SYN/ACK 包。 
这是一小部分先前从HTTP(网页服务)端口80 上所发出SYN/ACK 攻击数据包的样本 

这蜂拥而来的SYN/ACK 数据包和一些非路由的网络服务器告诉了我们，任何用于普通目的TCP 连接许可的网络服务器都可以用做数据包反射服务器。当我看到我们光阻拦从BGP 端口传来的数据是远远不够的，我开发了一套更全面的解决方案来对付这种攻击。这套方案我们会在下面讨论。 
在装置好对付反射攻击的filter 后，我们立即就可以重新返回网上了。经过我不可以监控在装置filter 后的攻击状况，但看到下面的这些信息还是让我冒了一阵冷汗… 
直到攻击停止，Verio 的路由丢弃了将近十亿(1,072,519,399)的恶意SYN/ACK 数据包。 
我是在认识我到没有抓到第二波非BGP 的数据包后才联系Verio ，从而得知这个数据的。我想要重新装备我们的防御系统，好让我们继续遭受攻击，这样才能抓到那些我先前没有收集到的 
资料，但当我这样做的时候，攻击已经停止了。

反射攻击的防御及预防 
通过Internet 进行交流的电脑一般都可以被分为两类：客户端及服务端。这两个角色可以随着环境转换（例如一个网页服务器可能会是一个邮件服务器的客户端），不过大部分的TCP 连接都意味着一个客户端和服务端的关系。客户端一般会从一个高数位的端口发起连接到服务端上处于监听状态的底数位端口上。 
因为任何反射的SYN/ACK 数据包必须要弹到一个TCP 服务器上，并且因为几乎所有的服务端口都在1 到1023 这个范围之内，阻拦所有在服务端口范围之内入站的数据包会防止大部分的攻击造成的阻塞。不过这样做有产生一些问题….. 
保护服务器 
首先，这次对grc.com 的攻击包含了从端口4001 和6668 来的SYN/ACK 数据包。所以，如果从这些端口发出的数据太多的话，这些特殊的高数位服务端口也需要被阻拦。在阻拦高数位端口的入站数据包存在一个问题，那就是一些合法的客户端的端口所发生的数据可能也会被我们设置的filter 给拦截掉。 
第二个问题是如果我们只是简单的拦截所有从1024 以下端口发送的数据的话，那么像当一个在blanket filter 后的服务器作为客户端的话，它将无法和其它服务器进行交流。就像我们刚才举的例子一样，当一个网页服务器作为一个SMTP 服务器的客户端时，这个情况就会变的非常复杂。因为远程SMTP 服务器的数据包会试图从SMTP 服务器的25 号端口返回，这时它就会被我们设置的反反射攻击的filter 给拦截掉。为了解决这个问题，我们需要在配置文件里设置例外端口，这样才可以让合法数据包正常通过。 
保护客户端 
这里有一些坏消息。客户端主机，例如那些典型的终端用户，将无法被保护。因为多数的客户端在大部分时间里都是连接到远程的服务器端上的，这些服务器端很可能会被利用来攻击这些无辜的客户端。