文武双全遭遇一起利用wordpress的pingback漏洞发起的DDOS攻击

爷保佑下,成功处理了这一起利用wordpress的pingback漏洞发起的DDOS攻击。下面跟大家分享下,解决这次DDOS攻击的全过程。

第一步:登录服务器查看服务器的状态

幸运的是我当时正在服务器上,马上使用linux的top命令查看系统负载,发现系统负载已经到5以上了。幸运的是,这个时候服务器还能连上,但是已经出现了很明显的卡顿。平时服务器最多使用3个php-fpm进程,现在4个进程全部高负载运行,nginx和php-fpm占用的内存都快吓死本宝宝了。 再使用free -m一看内容占用,平时只使用大概300多M的内存,全部曝掉了。2GB的Swap内存已经跑了700多M了,这就是系统负载那么高的原因,磁盘IO亚历山大啊。

明显感觉到是被人DDOS或者CC了,立刻使用命令关掉了nginx,服务器瞬间变成流畅无比。

第二步:下载并检查网站日志

立刻下载网站的访问日志和错误日志,打开访问日志一看,“呦西,果然被人攻击了”。日志截图如下,

[caption id="" align="aligncenter" width="750"]2015年8月14日文武双全个人网站被DDOS攻击的日志 2015年8月14日文武双全个人网站被DDOS攻击的日志[/caption]

日志把攻击者的特征记录的很明显,使用了翻墙到美国DataShack的服务器,然后发动了针对文武双全个人网站的DDOS攻击。让文武双全干感觉到意外的是,日志里竟然出现了非常奇怪的特征。大量的出现“wordpress”、“verifying pingback from”这样的日样,为文武双全寻找攻击的原因提供了最重要的信息。

第三步,搜索特征码查找攻击方式和解决方法

哈哈,这一次度娘给力了。使用百度搜索关键词“verifying pingbanck”,果然搜索到类似的攻击。搞笑的是我国台湾省的某地方政府网站,竟然也使用wordpress,而且也遇到了同样的攻击方式。如下图所示,

[caption id="" align="aligncenter" width="750"]我国台湾省某地方政府网站也曾遭受过类似的ddos攻击 我国台湾省某地方政府网站也曾遭受过类似的ddos攻击[/caption]

一看此文,文武双全就知道了,原来黑客是利用了wordpress自身的pingback漏洞。百度再次检索pingback是啥玩意,看了说明才恍然大悟。这次被攻击,原来是因为昨天文武双全开启了wordpress的pingback的功能所导致的。

第四步,解析wordpress的pingback漏洞并成功处理漏洞

如下图所示,所谓pingback漏洞实际上并不能算一个漏洞,他只是wordpress后台后台的一个功能而已。在wordpress后台的,设置–>讨论–> 栏目里。

[caption id="" align="aligncenter" width="719"]wordpress的pingback和trackback功能 wordpress的pingback和trackback功能[/caption]

这个功能就是在其他的wordpress博客引用文武双全个人网站的文章时,会想文武双全个人网站发送一个通知,就是所谓的pingback。很显然这个pingback和trackback一样,只是wordpress定义的一个函数。选择接受,相当于把函数变成了公共函数,外部可以访问。不接受,则意味着函数变成了私有函数,外部不能访问。

一旦开放,则意味着黑客可以访问这个公共函数。于是就可以通过代理服务器公共函数的访问地址,发动DDOS攻击了。当然,文武双全还没有看过pingback和trackback的源代码,以上内容纯属猜想,哈哈。仅凭着猜想,我还是做出了决定,把pingback功能取消。

对方的服务器在美国,我偷偷开启了nginx,应该会有一段时间的缓冲器,服务器才会彻底死掉。于是我偷偷打开了nginx,然后发现网站可以访问。立即登陆wordpress的后台,关掉了pingback的功能。立即去查看系统的负载,果然在慢慢降低。free -m命令查看内存,果然都释放掉了,网站前台打开的速度也恢复正常了。难道就这样不到一个小时就解决了,我自己都有点不太相信。

第五步,攻击者的代理服务器丢包严重

这算是本次事故的一个彩蛋吧,闲着没事文武双全ping了一下攻击者的服务器ip地址:192.187.118.162。发现丢包那是相当的严重啊,哎都是江浙沪电信限外网导致的。连黑客都受影响了,不然文武双全很有可能无法远程登录到服务器上去,哈哈。

[caption id="" align="aligncenter" width="568"]黑客ddos攻击所使用的美国服务器丢包严重 黑客ddos攻击所使用的美国服务器丢包严重[/caption]

高达37%的丢包,真是晕死了啊。这延迟还是蛮低的,比一般的美国服务器250ms的速度要快不少哈。要是以后稳定了,文武双全也想搞一台呢。

 

 

Continue reading »

2015年4月8日文武双全个人网站遭受到史上最严重攻击—流量超10Gb/秒DDOS攻击

,如果客户所在的服务器遭受到超过5Gb/秒的流量攻击,就会把这台服务器丢到黑洞中。然后2.5个小时以后,再放出来。

在这两天的时间内,攻击流量多次超过5GB,于是这两天文武双全个人网站几乎不能访问。刚从黑洞中出来,攻击马上又来,然后又被丢到黑洞中。阿里云盾显示,这两天被关到黑洞中的次数多达9次。

超10Gb/秒的历史最高记录

[caption id="" align="aligncenter" width="650"]2015年4月8日文武双全个人网站遭受到超过10G/秒的历史最大流量攻击 2015年4月8日文武双全个人网站遭受到超过10G/秒的历史最大流量攻击[/caption]

如图所示,在2015年4月8日13点57分05秒,文武双全个人网站再次被阿里云关到黑洞中。原因是攻击流量达到了10372Mb/秒,超过10Gb/秒的攻击流量已经创造了文武双全个人网站建站以来的最高历史记录了。

印象中,也是自2011年文武双全个人网站建站以来遭受到的最大流量记录。

面对这样的流量攻击我似乎无能为力

对于这次被攻击,文武双全简直就是无能为力。因为服务器直接进黑洞,连我自己都无法远程登录到服务器了。所有的流量都被屏蔽,交给阿里云的硬防系统进行拦截。

我的服务器里,关于此次攻击的信息少得可怜,在被攻击期间就没啥日志信息。

阿里云给了我被攻击期间的服务器流量的数据包

文武双全通过阿里云工单系统,拿到了被攻击期间服务器流量的数据包,文件名类似“ddos-20150408-ip地址.cap”。苦逼的是由于包太大,用wireshark这样抓包工具还无法打开。这要是用工具拆分,得拆成多少个。这样的数据包,似乎对我来说也没啥价值了。

下一步考虑阿里云的SLB负载均衡服务

阿里云对单台ECS云主机提供5Gb的防御,超过5Gb就进黑洞。事实上阿里云论坛,早就有这样的观点。用微型ECS云主机组集群,用SLB做负载均衡就能拥有数倍于5Gb的防御能力。

例如:用两台512MB内存,1MB带宽的微型阿里云主机做负载均衡,性能远远比单台1GB内存,2M带宽的阿里云主机要高。但是服务器抗攻击的能力,也提高到5Gb*2=10Gb。

所以,大型网站提高抗攻击的能力,尽量多台微型ECS云主机组SLB才是最强的方案。对文武双全个人网站来说,这样一个小博客,就没必要搞那么复杂的架构啦。

 

Continue reading »

网站安全哪家强,北京云锁来帮忙—内有专用安装包哦!

人都知道阿里云有一个云盾,可以防一定程度的DDOS攻击。但是阿里云防CC的功能并不是很强,而云锁刚好解决了这个问题。将云锁和阿里云云盾结合起来使用,可以有效的抵御各种网络安全攻击。

至于什么密码暴力破解、sql注入攻击、网站防盗链什么的,更是不在话下啦。

云锁为文武双全打包的专用安装包

windows版云锁下载地址

http://www.yunsuo.com.cn/files/yunsuo_agent_setup_014.exe

不会安装的,或者安装以后不会使用的,可以加文武双全后援会的QQ群: 222876737。我会在群里,帮大家解答使用过程中的各种问题。也能随时召唤云锁官方人员,给大家解决问题哦。

Linux版云锁下载地址

正在打包ing

云锁注意事项

1,安装前最好在线快照下服务器;

2,不能在线快照的也备份下网站数据;

3,配置服务器能够识别访客正确的IP地址;

4,最好别用CDN,实在不行将CDN的IP地址加到白名单先;

[caption id="" align="aligncenter" width="592"]云锁的防CC攻击能力突出 云锁的防CC攻击能力突出[/caption]

5,最好别用登陆防护,账号密码什么的,最好烂在自己肚子里。

Continue reading »

成功解决个人网站被webbench压力测试攻击的问题—webbench成功突破iptables防火墙

于美国的单一ip:198.2.218.18。此ip在nginx里留下了,23716次攻击记录,每秒钟的并发链接在58次。如图所示:

攻击的地址跟之前的也不一样,这一次主要攻击的是:

http://www.jicker.cn/category/emarkting  这个页面实际上是不存在的,应该返回404状态码的,但是文武双全的日志里竟然显示200;

http://www.jicker.cn/?s=a 这实际上是个查询页面,利用站内搜索查询所有包含“a”的页面,短期内大量的并发查询实际上对mysql是一个严峻的考验;

[caption id="" align="aligncenter" width="650"]文武双全个人网站被webbench压测攻击的日志 文武双全个人网站被webbench压测攻击的日志[/caption]

服务器被webbench压测下的状态

1,CPU没有被占满,nginx+php—fpm抗住压力;

[caption id="" align="aligncenter" width="397"]个人网站被webbench攻击下的内存占用并不高 个人网站被webbench攻击下的内存占用并不高[/caption]

2,内存占用低于50%,此次使用阿里云的VNC,可以登录服务器,没有发生内存溢出的行为;

3,带宽被占满,我3M的带宽,阿里云监控显示平均带宽占用为3.2M;

文武双全解决webbench攻击的方法

最简单的方法,是把ip用iptables封掉,但是攻击者只要换个ip依然可以用这种方法攻击你。于是我采取了另外一种方法,禁止webbench压力测试。

在网站配置文件中,加入如下代码:

if ($http_user_agent ~ “WebBench”) {
set $block_user_agents 1;
}

锁掉所有来自webbench的用户访问,解决问题了呢。当然,也可以用于屏蔽掉ApacheBench等压力测试工具的这种恶意攻击。

webbench成功突破iptables防火墙

攻击者可能是知道文武双全使用了iptables和nginx防CC攻击的module,来抵御DDOS和CC攻击。但是这次非常牛叉的是,虽然看似不起眼的只用了一个ip来攻击我,却能够成功的让iptables和nginx防CC攻击的module都失效了。

网络上查询了一番,我又学习到新的知识。原来webbench发送的是get命令,不管是cdn还是linux的防火墙,都不会把他当做ddos或者cc攻击来看待。所以他们都起不到防御作用。

事实证明,仅仅依靠iptables和nginx的module也并不是特别靠谱。能够穿透他们的攻击手段,还是非常的多的,还需要继续加强学习啊!

 

Continue reading »

2015年个人网站第二次被CC攻击总结—个人博客在攻击中茁壮成长

or: #ff0000;”>此次CC攻击的一些特诊总结

1,攻击者使用真实ip和代理ip混合攻击

这一次文武双全发现了一个有趣的现象,发动攻击的ip从原来单一的代理ip伪装蜘蛛,改变为由真实ip和代理ip混合攻击。这样,如果仅仅通过seo日志分析软件来分析日志的话,不能够将攻击者的ip全部封掉。攻击手段的变化,意味着攻击者了解了我之前的防御手段。想来他一定是看过我的博客了,O(∩_∩)O哈哈~。

2,攻击者每天用100个代理来发动攻击

文武双全个人网站的日志做了切割,可以看到每一天的网站的详细日志。通过日志分析,我发现一个搞笑的事情。就是攻击者每天只用100个代理来发动攻击,一个不多一个不少。如果我想把这些ip手动添加到iptables封掉,那么意味着我每天得手动封掉100个ip,我会被这个攻击者玩死。

哈哈,我确定这个攻击者看过我的博客,以及我之前写的防cc攻击的总结。可能他的真实ip,就在我的日志里。

CC攻击防御手段一:将服务器从nginx+apache切换成纯nginx了

为了节省资源,提高服务器抗并发的能力,我一怒之下将web服务器从nginx+apache给换成了纯nginx。事实证明,切换以后我的服务器的抗击打能力提高了很多。而且,我再也不用面对那个困扰我三年的。apache拿不到nginx真实ip的问题,再也不用去面对apache的优化问题了,我只需要配置好nginx和php就可以了。

nginx使用php-fpm跑php,除了cpu占用率会经常跑高之外,在抗并发的能力上面比我原来的nginx+apache强了不知道多少倍。切换web服务器之后的第一天,我就在qq签名里写下了“终身不娶apache,一生只爱nginx”的誓言。

CC攻击防御手段二:成功解决使用云盾后nginx无法获得真实ip的问题

服务器加入阿里云的云盾后,所有来访ip都会变成云盾的ip。这个时候如果开启iptables或者nginx的防CC的module,其实防的都是云盾的ip。就会变成,防火墙跟云盾自己打自己的情况。解决方法可以参考我另外一篇博客,成功解决个人网站加入阿里云云盾后,nginx无法获取真实ip的问题

[caption id="" align="aligncenter" width="639"]云盾检测到的攻击流量高达2.57Gb 云盾检测到的攻击流量高达2.57Gb[/caption]

老天保佑,我这一次终于解决了nginx服务器无法获取真实ip的问题。重新编译nginx,顺手还把nginx升级到最新的1.7.9版本。nginx日志里,全部都是真实ip了。这也意味着我的nginx防cc的module,可以真正发挥作用了。如果不解决掉这个问题,就会发生如图所示的搞笑事情。

CC攻击防御手段三:运用iptables和nginx防CC的module限制并发

攻击者已经了解了我之前手动封ip的策略,所以这个方法是彻底失效了。于是我一怒之下,清空了iptables手动封掉的600多个ip及ip段。这一次,哥转而使用了iptables和nginx防CC的module,通过限制并发链接的方法来防御CC攻击。

实际来看,在后期已经能够抗住几千的连接了,至少证明这条路走得通。

CC攻击防御手段四:将wordpress网站首页静态化

将web服务器从nginx+apache切换成纯nginx以后,我发现wordpress原来的缓存插件wp-super-cache无法使用了。只得将wp-super-cache缓存模式,从apache缓存模式切换成php缓存模式。重新调整了wp-super-cache的设置以后,基于php缓存模式的个人网站首页速度比原来慢了10ms。

CC攻击防御手段五:升级并优化php的配置,开启php加速opcache

升级完nginx后,我又把php的版本从5.3升级到最新的php5.6.5版本。但是我非常蛋疼的发现升级后的php,默认配置竟然没有开启opcache。跑到雪候鸟的博客,很巧的是鸟哥的博客更新了,还贴出了他的php最新版本的推荐配置。

[caption id="" align="aligncenter" width="642"]php开发者雪候鸟推荐的PHP的配置 php开发者雪候鸟推荐的PHP的配置[/caption]

^_^,php就这样被升级,并且稍微做了一点优化。上面三行是在php-fpm.conf,下面两段是在php.ini里修改。我在wdcp里,可找了一段时间。。。

这一次的CC攻击只持续了两天,但是这两天我过得极其漫长。最近一个月的三次CC攻击,我学到的东西太多太多了。在网站安全维护方面的能力,又得到了增强。不过很多东西都还只是刚刚接触,希望有机会能继续学习吧。

Continue reading »

wdcp环境下nginx升级到任意版本的脚本—附带识别cdn和云盾真实ip的功能

,用了各种cdn和阿里云的云盾的wdcp用户推荐使用哦。

wdcp下nginx升级脚本的下载和安装

nginx升级脚本的下载地址:http://www.jicker.cn/down/2015/2/nginx_up.sh

把脚本丢到服务器的/root目录,或者登陆服务器后,使用

wget  http://www.jicker.cn/down/2015/2/nginx_up.sh  命令下载;

然后执行命令 sh nginx_up.sh 1.7.9 ;   这里1.7.9你可以填写你想升级到的任意版本nginx的版本号,我反正是直接升级到目前最高的nginx1.7.9版本了。

个人建议:把服务器的nginx停掉再升级。我在nginx跑的时候升级,出现了两次升级完成后nginx.conf配置文件丢失的问题。。。我从老版本的nginx里复制了一份到升级后的nginx目录里,解决了这个问题。

脚本增加了http_realip_module的编译语句

http_realip_module语句可以识别使用各种cdn或者阿里云云盾后,nginx无法拿到访客真实ip的问题。在cdn日渐流行的当下,在linux安全软件日益普及的情况下,强烈建议使用nginx的时候,编译上该module。

具体的使用方法,请参考文武双全的另外一篇文章。http://www.jicker.cn/3773.html

 

Continue reading »

成功解决个人网站加入阿里云云盾后,nginx无法获取真实ip的问题

方帮助中心真恶心人

虽然阿里云官方的帮助中心有一个帖子,《常见应用服务器获取来访者真实IP的方法》,但是这篇文章竟然被弄到了负载均衡SLB栏目。我艹,之前我一直在云盾里找有关问题的解决方法,阿里云竟然在云盾里放了一篇在nginx日志里显示真实ip的文章。。。

nginx拿不到真实ip影响防CC和防DDOS

所有来访ip都被转发成云盾的ip,如果服务器遭受到CC攻击,实际上iptables和nginx的防CC和防DDOS的任何配置,都是在干云盾。。。自己打自己,服务器跟云盾干起来了。所以这就是为什么之前,文武双全只有取消掉云盾的解析,iptables和nginx的配置才能起作用的原因就在这里。

而只要加入云盾,基本上服务器就是挂掉的命运。CC攻击以及云盾和iptables互掐,必然让服务器死翘翘。nginx都拿不到真实ip,更不用说后端的apache了。

问题的关键在wdcp环境下nginx的编译安装

wdcp自身的nginx安装脚本和wdcp论坛上网友们提供的nginx升级脚本,都没有编译过多的module。默认编译安装的nginx,自然不具备识别真实ip的功能。文武双全解决这个问题的方法,就是自己修改了wdcp下nginx的升级脚本。重新编译了一下nginx,顺便升级到最新的nginx1.7.9版本。

[caption id="" align="aligncenter" width="597"]wordpress无法识别真实ip的问题终于解决 wordpress无法识别真实ip的问题终于解决[/caption]

困扰我三年的,wordpress后台无法显示评论者真实ip的问题迎刃而解,如图。nginx的日志里,终于能显示正确的访客ip。wdcp的后台,也很少看到云盾的ip了。

nginx识别cdn和云盾的真实ip靠的是http_realip_module

其实只要在编译nginx的参数后面加上 –with-http_realip_module,nginx就具备识别cdn和云盾真实ip的能力啦。当然,你还要在nginx.conf里添加必要的配置代码哦:

我使用的是阿里云云盾,下面是我的代码:

http{

set_real_ip_from 42.121.43.0/24;
set_real_ip_from 127.0.0.1;
set_real_ip_from 10.242.174.13;
real_ip_header X-Forwarded-For;

}

如果你使用的是诸如百度云加速之类的cdn,就把42.121.43.0/24的ip段及ip地址,更换为百度云加速的ip。关于wdcp下nginx升级到任意版本以及编译http_realip_module的脚本,我会在另外一篇文章中单独发出。

伪装攻击者真实ip的方法有很多很多,下面文武双全还要继续学习啊。X-Forwarded-For并不能识别到所有的真实ip貌似,以后再跟大家分享文武双全的学习心得吧。

 

Continue reading »

wdcp环境下利用iptables封ip及ip段的方法

就在本周文武双全个人网站再次遭受了CC攻击,详见《个人网站再次遭受CC攻击总结》。在这一次抵御攻击的过程中,文武双全惊奇的发现自己以前在wdcp后台封禁ip段的方法错了。wdcp后台的iptables使用说明,写的很容易让人误解。于是我觉得非常有必要,写一篇文章说说如何wdcp环境下利用iptables封ip及ip段。

Continue reading »

个人网站再次遭受CC攻击总结—wdcp环境下抵御CC攻击的方法

2014年底,文武双全个人网站刚刚遭受了一次CC攻击,详见文武双全个人网站遭遇严重CC攻击之总结 。2015年新年刚过,个人博客这又被攻击了。此次攻击是从2015年1月18日凌晨3点开始的,大约在2015年1月22日凌晨0点网站可以正常访问了。下面是此次应对CC攻击的总结,希望能够对大家以后防黑防CC有帮助。文武双全个人网站是在WDCP环境下和阿里云主机上,此文可能对以上用户有帮助。

Continue reading »