导读 在互联网行业里,如果你们的系统还没有被黑客们练过,说明你们的系统还不够成熟。在以往的工作经历中,大都做后端服务,较少经受到黑客们的光顾。但是自从 2014 年进入互联网金融行业之后,和黑客们打交道已经成了我们日常工作的一部分。

2015年应该是互联网金融行业受黑客攻击最多的一年,各互金公司都深受其害,其中网贷之家有一段时间被黑客攻击的太厉害,连续几天网站都无法打开。部分互金公司选择了出钱消灾,让极客们尝到了甜头,吸引了更多的黑客们跃跃欲试。

当然了我们也未能幸免,什么 DDOS攻击、SQL注入、寻找系统漏洞等几乎都被经历过了,有的黑客还比较好,应该是出于善意或者展示自己,将漏洞放到乌云上面或者漏洞盒子里面让厂商来修复。但更多的是一些黑产完全就是威胁、敲诈想捞一笔钱。

先看看下面这位吧:


 这个家伙潜伏到我们公司的客户群里面,冒充我们的客户代表将头像和资料替换成一样,然后给群里所有的客服发送信息,想让客服把公司内部的后台地址发给他,想通过这种方式来寻找突破口,当然了这个算是里面的小菜鸟吧。

DDOS攻击

DDOS攻击我们也是遇到了很多次,确实也没有比较好办法,最后都是通过一些笨办法来尽量的避免,先说说我们的经历吧。

有一次我正在敲代码,客服QQ又闪烁了起来,还没来得及打开查看信息,客服经理电话就直接打了过来,立刻就有了一种不祥的预感,说官网打不开了,后台也登录不了。

挂了电话,我在本机进行了测试果然不行,立刻准备登录 VPN 查看服务器各项指标,结果登录不上去,马上上楼找运维经理,他也登录不上,刚准备给机房打电话的时候,机房来电话了,说我们的一个 IP 正经历着 1G 多的流量访问,问我们是否正在做什么活动,话没有说完就说流量已经到 5G,不到一分钟之后流量已经到达 18G 之多。

紧急处理:

因为我们的机房和集团共用了一个宽带入口,结果陆续的集团上面反馈他们的网站、服务也都出现了问题,机房服务商害怕引起更大的冲击,直接把我们官网对外的 IP 封掉,集团的其它业务才慢慢都恢复了过来,我们也紧急的更换了外网 IP,重新切换了域名解析才恢复。

事后分析:

事后我们根据 apache 分析了日志,流量来自 N 多个不同的 IP 地址根本无法应对,因为这次攻击让领导们重视了起来,才将公司机房的网络和公司集团彻底分离,这样的话不管那方受到大流量攻击都不会相互影响。

我们也想了一些笨办法,因为上次我们更换了外网 IP 之后攻击也就停止了,那么我们认为肯定是针对我们外网来攻击的,所有我们就多准备了 6 个外网 IP,当监控到对某一个外网进行攻击的时候马上切换到另一个外网地址,就这样跟他们玩,可以起到非常有限的一点作用,如果黑客真的想跟我们玩,这个办法就像是小孩子捉迷藏。

周年庆的 DDOS 攻击

还有一次我们正在做周年庆活动,突然有人在QQ群里面给我们客服说了一句,叫你们的技术负责人来找我,然后我们的网站就挂了,我还保留了当时的一个截图如下:

完了之后客服就来找我,然后按照往常的策略处理完之后,我根据客服给我的QQ号码加上了那个人,开口就来吓我,我依稀记当年的对话如下:

黑客:你是平台的技术负责人吗?
我:算是吧
黑客:你信不信我可以让你们官网在5秒之内挂掉?
我:…(沉默,还真害怕又把官网搞挂了)
黑客:你们的官网漏洞很大
我:如果有好的建议请您赐教
黑客:你们的服务器是不是什么防护软件都没有装?
我:…(继续沉默,这会在想不会是那个安全厂商来推广产品的吧,当然我们基础的防护肯定有)
黑客:我们有非常多的肉鸡,想攻击谁,几秒之内肯定搞定
我:…
黑客:我们已经给很多互联网金融行业做了渗透测试,花点钱帮买你们平安,保证以后不会在出事情
我:…
黑客:免费的策略也有很多,比如360、百度云的安全产品可以免费低档10G左右的流量

……(中间省略)

黑客:我说了这多,你们也是不是给包烟钱,表示表示。

……
后来也和领导进行了商议,坚决不能给他们钱,不能助涨这种嚣张气焰,实在不行就报警!

曝光一下当年使用的假QQ号,刚查了下变了个头像和描述,如下:

后来我一直在想为什么 DDOS 攻击总是喜欢根据外网 IP 来攻击呢,慢慢好像是理解了。如果针对域名来攻击的话,那不就是攻击到域名商的服务器,一般域名商比较强大,黑客不太搞的定,也确实没有必要。当然记的前一段时间,某著名域名服务商被攻击,导致国外twitter等著名的互联网公司访问中断到达半天以上,还是很严重的。但是对于我们这些小公司,倒不至于搞这么大的动作。

到底如何正确的防止DDOS攻击:

● 第一种方案,隐藏服务器外网地址,服务器前端加 CDN 中转,免费的有百度云加速、360网站卫士、加速乐、安全宝等,如果资金充裕的话,可以购买高防的盾机,用于隐藏服务器真实 IP,域名解析使用 CDN 的 IP,所有解析的子域名都使用 CDN 的 IP 地址。此外,服务器上部署的其他域名也不能使用真实IP解析,全部都使用 CDN 来解析。
● 第二种方案,买一些安全产品来进行流量清洗,主要是阿里云、腾讯云这种大厂商提供的一种服务。
● 第三种方案,有很多的防火墙产品声称可以防止 Ddos 攻击,但是我个人使用感觉效果非常有限。

SQL注入

我们的官网使用的是 PHP 开发,因为框架比较老旧的原因,存在着一些 SQL 注入的点,我们发现了一些进行了修补,没想到还是被一些黑客找到了突破点,这块还是比较感谢一些黑客在漏洞盒子上面提交的 bug(如下图),最后我们根据提示进行了紧急修复,后来也在 WAF 防火墙配置了一些拦截 SQL注入的策略,起到双保险的作用。

我一直在想为什么 PHP 一般比较容易出现 SQL 注入呢,而 Java 较少暴漏出来 SQL 漏洞的情况,我估摸着有两方面的原因:
● 第一,PHP 一般前端使用较多,受攻击的机会更多一些,Java 一般做为后端服务攻击的可能性会比较少;
● 第二,PHP 框架较多而且很杂,很多早期的框架并没有特别考虑 SQL 注入的情况,Java 大量普及了 mybaits\hibernate 这种 orm 框架,框架本身对常见的 SQL 注入有防范的功能,但不是说 mybaits/hibernate 框架就没有被 SQL 注入的可能,大部分场景下是OK的。
另外参数化查询可以有效的避免 SQL 注入。

通过一段时间的学习,我发黑客一般先使用工具对网站做整体的扫描类似 Acunetix,在根据扫描出来的漏洞做个大概的分析,但是比较深入的漏洞都需要根据网站的业务在进行调整,比如 SQL 注入会根据页面的查询使用 sqlmap 等工具来进一步的渗透。当然我对这方面还是外行,描述的可能不够清晰。

短信攻击

验证码漏洞,我们当初有一个很小的失误,有一个程序员在 H5 的小网页中将发送短信验证码返回了前端,最后被 haker 发现了,利用这个漏洞可以给任意的用户重置登录密码。那一晚上我们几百多个用户收到了密码重置的短信,虽然黑客最终也没有改用户的密码,只是发短信玩了一把,但是对于平台来讲无形的价值(信誉度)损失不小。

短信攻击,现在的网站几乎都有发送短信或者短信验证码的功能,如果前端不做校验,haker会随便写一个for循环来发短信,一般系统的短信会进行全方位的防控,比如:
1、前端加验证(字符验证码,有的是拖拽的动画);
 2、后端根据用户或者IP加限制,比如用户一分钟只可以发送一条短信,忘记密码的短信一天只能发送10条、一个IP地址限制每天只能发送100条短信等。

如何防范

黑客攻击公司的网站未必完全是一件坏事,一方面说明了公司已经吸引到了很多人的关注,另一方对我们技术团队是一次检验,黑客有时候会给你带来完全不同的一种思路想法。但是被黑客攻击而影响了业务,那就不是一件愉快的事情了,如果攻击导致频繁的出现问题,对内对外都会造成大的影响,那就是严重的事件了。

安全防范是一个全面且持久的工程,也是需要在硬件和软件上都要投入的一件事情。

硬件方面

需要做好网络安全规划,机房常用的安全设备有:VPN服务器、防火墙、WAF防火墙。
● VPN服务器:主要用于运维人员通过口令可以登录到机房内网中进行日常运维工作,也可以用做不同机房网络互通,保证在特定的网络下信息传输安全。
● 防火墙 :外网访问进入机房的第一道大门,负责三层网络的安全检测,隔离内网和外网环境,外网为非信任区,内网为信任区。
 ● WAF防火墙:最重要的安全设备之一,WAF防火墙主要是对Web特有入侵方式的加强防护,如DDOS防护、SQL注入、XML注入、XSS等。属于应用层的安全防护,我们经常遇到的黑客攻击行为,主要就靠它的防护能力。

现在的防火墙技术更新特别快,以前的防火墙都是基于特征库来进行防护的,最新一代的防火墙可以根据平台的用户行为来检测分析是否为攻击行为。

软件方面

软件方面的防护主要有两方面,一方面使用证书保证传输层的数据安全,另一方面所有对外的接口都需要做好安全规划。
● HTTPS证书:在web服务器部署HTTPS证书,保证用户在交互的过程中数据没有被篡改。
● 网络规划:所有非必须的服务都不要开放外网访问,需要开放外网访问的服务器仅开放需要的端口,比如常用的80。和合作公司有数据交互或者接口调用的需求,需要绑定固定的外网访问地址。
 ● 技术选择:选择成熟的框架可以避免很多安全问题,早期的很多PHP框架根本就没有考虑SQL注入的相关问题,当初strust2的安全漏洞多少企业被坑。选择成熟稳定的技术体系可以避免很多低级的问题。

原文来自:

本文地址://q13zd.cn/internet-hacker-attack.html编辑:高军,审核员:逄增宝

本文原创地址://q13zd.cn/internet-hacker-attack.html编辑:public,审核员:暂无