DDoS那些事

【拯救赵明】活动链接：http://51ctoblog.blog.51cto.com/26414/300667

DDoS那些事

两年前，刚到新的工作岗位2个半月的样子，就越到了大麻烦。这个麻烦事情一直持续了近一个月，而且极有规律，让我疲惫不堪。究竟是怎么回事？且听我慢慢说来。

 

某个具体的tcp应用由3个服务器组成集群，使用公网ip地址做为集群的vip对外提供服务。整个应用的架构如图所示：

 

负载均衡器除了转发tcp 9000这个端口应用外，还负责其他应用的转发。一般情况下，tcp 9000端口的总转发连接数(ActiveConn)在6000以内，分摊到每个应用服务器，也就是每个机器平均承担2000个请求。但从2008年9月下旬某个星期六开始，监控系统一直告警，标明tcp 9000服务器的连接数过多，而且这3个服务器都是同样的报警。在监控系统nagios上，我设定的连接数报警阈值是—小于5000属于正常状态(ok)、大于5000且小于10000为警告状态（warnning）、大于10000则为异常严重状态(critical)—一直发送报警信息“Critical”。打电话联系程序维护人员，问他们近期有没有对程序做修改，他们回答说没有。

 

顾不得周末休息，打开个人计算机，远程连接某个应用服务器，很糟糕，基本上连接不上，每个应用服务器都如此。打电话给IDC机房的支持人员，让他们把KVM over IP帮我连在某个指定的服务器上，然后上去查看系统状态。检查的项目包括：

（1） 系统负载：top或uptime 指令，发现负载处于正常水平。

（2） 磁盘空间使用情况：df查看，一切正常；况且磁盘利用率有监控的。

（3） 检查系统日志/var/log/messages，看是否有内核方面的报错信息。经检查，确实有大量的错误日志被记录。

（4） 检查当前tcp状态。发现当然处于ESTABLISHED的数量已经超过20000，另外还有大量的TIME_WAIT及SYN_RECV。

 

把kvm连接到另外两个应用服务器，查看到的结果也是一样的。随着时间的推移，tcp连接状态越来越多，没过多久，就接到大量用户不能使用该网络服务的投诉电话。为了应急，我在征得相关人员的同意后，把三个应用服务器的服务乃至系统都重新启动一遍，结果还是一样。

 

接着,在登录负载均衡器上查看tcp状态，连接数已经达到100多万个。综合所得信息，初步得出结论：被人DDoS攻击了。

 

接下来的处理步骤如下：

（1） 每个应用服务器（freebsd）启用防火墙pf,限制每秒同一ip的连接数。

（2） 在负载均衡器启用iptables防火墙，限制限制每秒同一ip的连接数，同时汇总请求数最多的ip，把它加入黑名单。

 

处理后，效果并不明显，尽管我使用的是动态黑名单，但攻击源不断变换ip地址，反而使我的负载均衡器转发效率大大降低，直到完全不能访问。从统计出来的源地址看，单ip产生的请求数操作1000的不少，以至于我的很名单长达数百行。

 

再修改每个服务器的内核参数试试，包括负载均衡器，可是结果还是一样，一会就被堵死了。查看网络流量，仍然在购买的带宽范围内。令人奇怪的是，其他应用服务并为受到攻击，看来攻击者已经很了解该项服务，发动了非常有针对性的进攻。我跟程序开发人员一起，折腾了两天，依然不能解决问题。到星期天晚上10点，攻击自动停止。

 

下一个周末来临，攻击如期进行，于是先想到报警。我们的服务器放在天津塘沽，按天津网警提供的报警方式，在他的网站上填写信息提交，结果是个不能提交的死网站。打电话咨询idc服务商，他们建议我给北京的警察报警。电话打了，警察来了，也做了记录，询问了情况。当得知服务器不在北京时，他们又建议我给天津的网警打电话。如此看来，靠警察是解决不了问题的。

 

在朋友的介绍下，与某著名的安全厂商联系，并以最快的速度安排好相关事宜。然后我跟他们的技术工程师一起带着设备，去了天津塘沽。根据攻击的规律，我们在周末把防DDoS防火墙上线放置到服务器的前端进行保护。上午10点，攻击正式开始。从防火墙的管理界面，可以很清楚的看见连接数不断上涨，不须片刻，防火墙也红色醒目的显示方式报警，但却不能处理非法的包。这样折腾两天，毫无进展。对方于是建议更换更高级的设备进行测试，然后返回，等下一个周末再携带更强的设备进行测试。

 

第二次再去现场，虽然携带了更高端的设备，效果还是不佳。但令我不满的是，这个技术人员在中途离开了，说是回北京休假。因此我决定放弃这个厂商，另换一家。

 

百度谷歌很久发现一款防火墙宣传和评论都不错，然我觉得有炒作之嫌，本能的带有一定的排斥，但是迫于无奈我还是联系了这家公司，该公司恰巧总部也在北京。我将我的攻击遭遇对他们描述了一番，且表示不见得一定会买你家产品，但是希望可以测试。如果效果甚佳可以考虑购买事宜。对方毫不犹豫的答应第二天去现场测试，且表示效果满意后再进行商务交流。

 

又是一个没有黑白的周末，攻击如约而至，防火墙也是同上一家一样出现攻击警报，让我汗毛竖起，如果再搞不定真不知道要怎么办。厂家技术员很熟练的看了各项攻击参数告知有可能是盗链攻击，但具体细节还需要抓取数据包进行分析查看。技术员通过他们防火墙的管理界面抓取了我服务器接收的数据包，在数据包分析列表内，清晰的看到我服务器在被无数的ip访问，且都通过跳转访问。跳转路径有很多知名的网站。该不会是他们攻击我的吧，我和他们无冤无仇，紧张万分。

 

技术人员分析抓取的数据包，然后做了一些规则，技术人员说是针对我网站攻击特点设置的规则，具体没有细说。说有处理不了的攻击可以联系他们技术24小时qq，购买防火墙后才给我们培训。

 

我现在想的不是培训不培训了，只要可以防御住就可以，在规则生效后，的确看到防火墙的连接数越来越小。但是页面还是打开很卡，大约过了3分钟。页面打开越来越顺畅了。太好了，终于处理好了，折磨我的问题终于处理好了。

 

厂家技术对我解释到盗链就是别的网站盗取的了我的下载页面的连接，跳转盗取我的信息。导致无数的客户在下载我的页面，导致我带宽耗尽，出现拒绝服务现在。

终于，业务正常了。

 

对于第二个厂家我要说几句，不是为了宣传他们，而是他真正的帮我解决了根本问题。现在我的服务器正常服务都是多亏了他们。不过我相信遭遇过DDoS的人都应该知道这家公司，因为后来我遇到很多同行都用他家的防火墙。他就是 北京傲盾公司。

 

我来说下我的防火墙部署方案吧 ，其实真的很简单 简单到看图就明白了。

通过机房核心接入线路，直接接入我自己的三层交换机，交换机连接防火墙接口，防火墙再连接我的机柜交换机，其他都不需要设置，傲盾防火墙是透明模式，直接连就可以我的路由交换不需要做新的设置，默认接入就通。

 

DDoS那些事

两年前，刚到新的工作岗位2个半月的样子，就越到了大麻烦。这个麻烦事情一直持续了近一个月，而且极有规律，让我疲惫不堪。究竟是怎么回事？且听我慢慢说来。

 

某个具体的tcp应用由3个服务器组成集群，使用公网ip地址做为集群的vip对外提供服务。整个应用的架构如图所示：

 

负载均衡器除了转发tcp 9000这个端口应用外，还负责其他应用的转发。一般情况下，tcp 9000端口的总转发连接数(ActiveConn)在6000以内，分摊到每个应用服务器，也就是每个机器平均承担2000个请求。但从2008年9月下旬某个星期六开始，监控系统一直告警，标明tcp 9000服务器的连接数过多，而且这3个服务器都是同样的报警。在监控系统nagios上，我设定的连接数报警阈值是—小于5000属于正常状态(ok)、大于5000且小于10000为警告状态（warnning）、大于10000则为异常严重状态(critical)—一直发送报警信息“Critical”。打电话联系程序维护人员，问他们近期有没有对程序做修改，他们回答说没有。

 

顾不得周末休息，打开个人计算机，远程连接某个应用服务器，很糟糕，基本上连接不上，每个应用服务器都如此。打电话给IDC机房的支持人员，让他们把KVM over IP帮我连在某个指定的服务器上，然后上去查看系统状态。检查的项目包括：

（1） 系统负载：top或uptime 指令，发现负载处于正常水平。

（2） 磁盘空间使用情况：df查看，一切正常；况且磁盘利用率有监控的。

（3） 检查系统日志/var/log/messages，看是否有内核方面的报错信息。经检查，确实有大量的错误日志被记录。

（4） 检查当前tcp状态。发现当然处于ESTABLISHED的数量已经超过20000，另外还有大量的TIME_WAIT及SYN_RECV。

 

把kvm连接到另外两个应用服务器，查看到的结果也是一样的。随着时间的推移，tcp连接状态越来越多，没过多久，就接到大量用户不能使用该网络服务的投诉电话。为了应急，我在征得相关人员的同意后，把三个应用服务器的服务乃至系统都重新启动一遍，结果还是一样。

 

接着,在登录负载均衡器上查看tcp状态，连接数已经达到100多万个。综合所得信息，初步得出结论：被人DDoS攻击了。

 

接下来的处理步骤如下：

（1） 每个应用服务器（freebsd）启用防火墙pf,限制每秒同一ip的连接数。

（2） 在负载均衡器启用iptables防火墙，限制限制每秒同一ip的连接数，同时汇总请求数最多的ip，把它加入黑名单。

 

处理后，效果并不明显，尽管我使用的是动态黑名单，但攻击源不断变换ip地址，反而使我的负载均衡器转发效率大大降低，直到完全不能访问。从统计出来的源地址看，单ip产生的请求数操作1000的不少，以至于我的很名单长达数百行。

 

再修改每个服务器的内核参数试试，包括负载均衡器，可是结果还是一样，一会就被堵死了。查看网络流量，仍然在购买的带宽范围内。令人奇怪的是，其他应用服务并为受到攻击，看来攻击者已经很了解该项服务，发动了非常有针对性的进攻。我跟程序开发人员一起，折腾了两天，依然不能解决问题。到星期天晚上10点，攻击自动停止。

 

下一个周末来临，攻击如期进行，于是先想到报警。我们的服务器放在天津塘沽，按天津网警提供的报警方式，在他的网站上填写信息提交，结果是个不能提交的死网站。打电话咨询idc服务商，他们建议我给北京的警察报警。电话打了，警察来了，也做了记录，询问了情况。当得知服务器不在北京时，他们又建议我给天津的网警打电话。如此看来，靠警察是解决不了问题的。

 

在朋友的介绍下，与某著名的安全厂商联系，并以最快的速度安排好相关事宜。然后我跟他们的技术工程师一起带着设备，去了天津塘沽。根据攻击的规律，我们在周末把防DDoS防火墙上线放置到服务器的前端进行保护。上午10点，攻击正式开始。从防火墙的管理界面，可以很清楚的看见连接数不断上涨，不须片刻，防火墙也红色醒目的显示方式报警，但却不能处理非法的包。这样折腾两天，毫无进展。对方于是建议更换更高级的设备进行测试，然后返回，等下一个周末再携带更强的设备进行测试。

 

第二次再去现场，虽然携带了更高端的设备，效果还是不佳。但令我不满的是，这个技术人员在中途离开了，说是回北京休假。因此我决定放弃这个厂商，另换一家。

 

百度谷歌很久发现一款防火墙宣传和评论都不错，然我觉得有炒作之嫌，本能的带有一定的排斥，但是迫于无奈我还是联系了这家公司，该公司恰巧总部也在北京。我将我的攻击遭遇对他们描述了一番，且表示不见得一定会买你家产品，但是希望可以测试。如果效果甚佳可以考虑购买事宜。对方毫不犹豫的答应第二天去现场测试，且表示效果满意后再进行商务交流。

 

又是一个没有黑白的周末，攻击如约而至，防火墙也是同上一家一样出现攻击警报，让我汗毛竖起，如果再搞不定真不知道要怎么办。厂家技术员很熟练的看了各项攻击参数告知有可能是盗链攻击，但具体细节还需要抓取数据包进行分析查看。技术员通过他们防火墙的管理界面抓取了我服务器接收的数据包，在数据包分析列表内，清晰的看到我服务器在被无数的ip访问，且都通过跳转访问。跳转路径有很多知名的网站。该不会是他们攻击我的吧，我和他们无冤无仇，紧张万分。

 

技术人员分析抓取的数据包，然后做了一些规则，技术人员说是针对我网站攻击特点设置的规则，具体没有细说。说有处理不了的攻击可以联系他们技术24小时qq，购买防火墙后才给我们培训。

 

我现在想的不是培训不培训了，只要可以防御住就可以，在规则生效后，的确看到防火墙的连接数越来越小。但是页面还是打开很卡，大约过了3分钟。页面打开越来越顺畅了。太好了，终于处理好了，折磨我的问题终于处理好了。

 

厂家技术对我解释到盗链就是别的网站盗取的了我的下载页面的连接，跳转盗取我的信息。导致无数的客户在下载我的页面，导致我带宽耗尽，出现拒绝服务现在。

终于，业务正常了。

 

对于第二个厂家我要说几句，不是为了宣传他们，而是他真正的帮我解决了根本问题。现在我的服务器正常服务都是多亏了他们。不过我相信遭遇过DDoS的人都应该知道这家公司，因为后来我遇到很多同行都用他家的防火墙。他就是 北京傲盾公司。

 

我来说下我的防火墙部署方案吧 ，其实真的很简单 简单到看图就明白了。

通过机房核心接入线路，直接接入我自己的三层交换机，交换机连接防火墙接口，防火墙再连接我的机柜交换机，其他都不需要设置，傲盾防火墙是透明模式，直接连就可以我的路由交换不需要做新的设置，默认接入就通。

本文出自 51CTO.COM技术博客

两年前，刚到新的工作岗位2个半月的样子，就越到了大麻烦。这个麻烦事情一直持续了近一个月，而且极有规律，让我疲惫不堪。究竟是怎么回事？且听我慢慢说来。

 

某个具体的tcp应用由3个服务器组成集群，使用公网ip地址做为集群的vip对外提供服务。整个应用的架构如图所示：

 

负载均衡器除了转发tcp 9000这个端口应用外，还负责其他应用的转发。一般情况下，tcp 9000端口的总转发连接数(ActiveConn)在6000以内，分摊到每个应用服务器，也就是每个机器平均承担2000个请求。但从2008年9月下旬某个星期六开始，监控系统一直告警，标明tcp 9000服务器的连接数过多，而且这3个服务器都是同样的报警。在监控系统nagios上，我设定的连接数报警阈值是—小于5000属于正常状态(ok)、大于5000且小于10000为警告状态（warnning）、大于10000则为异常严重状态(critical)—一直发送报警信息“Critical”。打电话联系程序维护人员，问他们近期有没有对程序做修改，他们回答说没有。

 

顾不得周末休息，打开个人计算机，远程连接某个应用服务器，很糟糕，基本上连接不上，每个应用服务器都如此。打电话给IDC机房的支持人员，让他们把KVM over IP帮我连在某个指定的服务器上，然后上去查看系统状态。检查的项目包括：

（1） 系统负载：top或uptime 指令，发现负载处于正常水平。

（2） 磁盘空间使用情况：df查看，一切正常；况且磁盘利用率有监控的。

（3） 检查系统日志/var/log/messages，看是否有内核方面的报错信息。经检查，确实有大量的错误日志被记录。

（4） 检查当前tcp状态。发现当然处于ESTABLISHED的数量已经超过20000，另外还有大量的TIME_WAIT及SYN_RECV。

 

把kvm连接到另外两个应用服务器，查看到的结果也是一样的。随着时间的推移，tcp连接状态越来越多，没过多久，就接到大量用户不能使用该网络服务的投诉电话。为了应急，我在征得相关人员的同意后，把三个应用服务器的服务乃至系统都重新启动一遍，结果还是一样。

 

接着,在登录负载均衡器上查看tcp状态，连接数已经达到100多万个。综合所得信息，初步得出结论：被人DDoS攻击了。

 

接下来的处理步骤如下：

（1） 每个应用服务器（freebsd）启用防火墙pf,限制每秒同一ip的连接数。

（2） 在负载均衡器启用iptables防火墙，限制限制每秒同一ip的连接数，同时汇总请求数最多的ip，把它加入黑名单。

 

处理后，效果并不明显，尽管我使用的是动态黑名单，但攻击源不断变换ip地址，反而使我的负载均衡器转发效率大大降低，直到完全不能访问。从统计出来的源地址看，单ip产生的请求数操作1000的不少，以至于我的很名单长达数百行。

 

再修改每个服务器的内核参数试试，包括负载均衡器，可是结果还是一样，一会就被堵死了。查看网络流量，仍然在购买的带宽范围内。令人奇怪的是，其他应用服务并为受到攻击，看来攻击者已经很了解该项服务，发动了非常有针对性的进攻。我跟程序开发人员一起，折腾了两天，依然不能解决问题。到星期天晚上10点，攻击自动停止。

 

下一个周末来临，攻击如期进行，于是先想到报警。我们的服务器放在天津塘沽，按天津网警提供的报警方式，在他的网站上填写信息提交，结果是个不能提交的死网站。打电话咨询idc服务商，他们建议我给北京的警察报警。电话打了，警察来了，也做了记录，询问了情况。当得知服务器不在北京时，他们又建议我给天津的网警打电话。如此看来，靠警察是解决不了问题的。

 

在朋友的介绍下，与某著名的安全厂商联系，并以最快的速度安排好相关事宜。然后我跟他们的技术工程师一起带着设备，去了天津塘沽。根据攻击的规律，我们在周末把防DDoS防火墙上线放置到服务器的前端进行保护。上午10点，攻击正式开始。从防火墙的管理界面，可以很清楚的看见连接数不断上涨，不须片刻，防火墙也红色醒目的显示方式报警，但却不能处理非法的包。这样折腾两天，毫无进展。对方于是建议更换更高级的设备进行测试，然后返回，等下一个周末再携带更强的设备进行测试。

 

第二次再去现场，虽然携带了更高端的设备，效果还是不佳。但令我不满的是，这个技术人员在中途离开了，说是回北京休假。因此我决定放弃这个厂商，另换一家。

 

百度谷歌很久发现一款防火墙宣传和评论都不错，然我觉得有炒作之嫌，本能的带有一定的排斥，但是迫于无奈我还是联系了这家公司，该公司恰巧总部也在北京。我将我的攻击遭遇对他们描述了一番，且表示不见得一定会买你家产品，但是希望可以测试。如果效果甚佳可以考虑购买事宜。对方毫不犹豫的答应第二天去现场测试，且表示效果满意后再进行商务交流。

 

又是一个没有黑白的周末，攻击如约而至，防火墙也是同上一家一样出现攻击警报，让我汗毛竖起，如果再搞不定真不知道要怎么办。厂家技术员很熟练的看了各项攻击参数告知有可能是盗链攻击，但具体细节还需要抓取数据包进行分析查看。技术员通过他们防火墙的管理界面抓取了我服务器接收的数据包，在数据包分析列表内，清晰的看到我服务器在被无数的ip访问，且都通过跳转访问。跳转路径有很多知名的网站。该不会是他们攻击我的吧，我和他们无冤无仇，紧张万分。

 

技术人员分析抓取的数据包，然后做了一些规则，技术人员说是针对我网站攻击特点设置的规则，具体没有细说。说有处理不了的攻击可以联系他们技术24小时qq，购买防火墙后才给我们培训。

 

我现在想的不是培训不培训了，只要可以防御住就可以，在规则生效后，的确看到防火墙的连接数越来越小。但是页面还是打开很卡，大约过了3分钟。页面打开越来越顺畅了。太好了，终于处理好了，折磨我的问题终于处理好了。

 

厂家技术对我解释到盗链就是别的网站盗取的了我的下载页面的连接，跳转盗取我的信息。导致无数的客户在下载我的页面，导致我带宽耗尽，出现拒绝服务现在。

终于，业务正常了。

 

对于第二个厂家我要说几句，不是为了宣传他们，而是他真正的帮我解决了根本问题。现在我的服务器正常服务都是多亏了他们。不过我相信遭遇过DDoS的人都应该知道这家公司，因为后来我遇到很多同行都用他家的防火墙。他就是 北京傲盾公司。

 

我来说下我的防火墙部署方案吧 ，其实真的很简单 简单到看图就明白了。

通过机房核心接入线路，直接接入我自己的三层交换机，交换机连接防火墙接口，防火墙再连接我的机柜交换机，其他都不需要设置，傲盾防火墙是透明模式，直接连就可以我的路由交换不需要做新的设置，默认接入就通。