# 网站安全(无条件遵守)(干货)
# @蓦然
# 背景:
2020-8-29,晚上蓦然刚洗澡了坐着刚下云顶,突然接到朋友的微信。发来一条消息,app打开出错了,让我上去看看(一看日志,报错表找不到了,立马登录数据库,发现被删光了)。朋友是刚成立的一家小公司,app刚让公司完成,运行一个月,由于都是小白,就用的宝塔linux面板建的站(可能开发公司为了简单吧)。不幸的是宝塔Linux面板利用pma爆破带来了致命的问题。
这次pma安全风险出现的起因是我们想给用户解决通过pma爆破带来的安全问题,然后在Linux面板7.4.2/Windows面板6.8.0 版本中加入了phpmyadmin安全访问模块,原理是通过面板进行访问phpmyadmin,而不是nginx/apache,但因在目录存放时存在一个致命逻辑漏洞,导致nginx/apache也可以访问到专门给面板使用的phpmyadmin目录,我们在做安全审计时将重心放在面板程序中,忽略了除面板外被访问的可能,从而导致了此事件的发生。初心是为了帮用户解决安全还有提升使用体验,最终却给用户带来了极大的困扰,是我们的锅。我们暂停两周新功能开发工作,再一次全面对的所有面板代码和接口做安全审计。
# 看我如何恢复:
第一眼去找数据库备份,哇,有捏。然后感觉恢复,网站好了,心情激动了,这么简单?朋友突然说用户名,密码登录不上去,我仔细一看备份时间2020-7-30,心想完啦完啦,这不是刚上线的数据吗?用户数据还是没了。 致命错误一:数据库没有每天备份。赶紧看看binglog开了没
show variables like 'log_bin';
哇,看到了希望(其实是宝塔面板里面安装mysql自动开启binglog)。
binglog 是一个二进制的日志文件。它主要是用来记录对mysql数据更新或潜在发生更新的SQL语句,并以"事务"的形式保存在磁盘中。
小心谨慎,怕错误操作二进制文件,先备份一个,哈哈在备份上操作那不就放心了。于是开干:
step 1:拷贝二进制日志文件:
cp /www/server/mysql/bin/mysqlbinlog/mysql-bin.000001 /home/
step 2: 然后二进制中时间恢复2020-08-01到2020-08-28的数据
/www/server/mysql/bin/mysqlbinlog --start-datetime="2020-08-01 00:00:00" --end-datetime="2020-08-28 00:00:00" mysql-bin.000001 > backup.sql
step 3: 最后将sql导入数据库中,恢复数据
2
3
4
5
6
7
欧里给,数据回来了捏。然后网站一切正常,此时已是凌晨三点,倒床就睡。
# 斗智斗勇:
没过几天,正在看“这就是gai舞”的时候,朋友说app打不开了,没有响应了。看到朋友心急如焚,我也不好意思不帮忙。(毕竟程序员解决问题之后,都是很享受的,哈哈)。看了下很多请求都是连接超时了,然后看了下服务器资源,带宽被拉满了,好奇问了下朋友,有这么多客户了吗?朋友说“刚上线呢,应该没这么多用户”。立马想到,被攻击了,然后看access.log,发现很多ip恶意搞事情,频繁去请求后台,这就是典型的CC攻击了。
CC(ChallengeCollapsar,挑战黑洞)攻击是DDoS攻击的一种类型,使用代理服务器向受害服务器发送大量貌似合法的请求。CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽,一直到宕机崩溃。
朋友说着急用,能不能最快的临时解决下,让项目运行着,不让客户丢失了。然后紧急分析访问日志,利用iptables去封禁ip段,来抵御小型攻击。
#先检查是否安装了iptables
service iptables status
#安装iptables
yum install -y iptables
#升级iptables
yum update iptables
#安装iptables-services
yum install iptables-services
#封禁可疑ip段
iptables -I INPUT -s 121.0.0.0/8 -j DROP
2
3
4
5
6
7
8
9
10
然后又临时提高了服务器带宽,这样操作之后,立竿见影,app可以用了,虽然还在攻击。因为有事情就没有管了。
好景不长,app又用不了,对方提高了攻击的力度。朋友说不差钱,一定要办掉他们。这么豪横,那就直接上WAF(Web应用防火墙Web Application Firewall)。开启了高频Web攻击ip自动封禁。根据日志分析,自定义了CC防护规则,限制单个IP对网站上特定路径(URL)的访问频率,超过了直接关小黑屋。
# 小插曲:
服务器端一定要校验客户端传递的数据。有个业务是这样的,用户每天完成一个小游戏后有积分奖励,积分奖励是后台配置的一定范围的随机数。然后他们后端同学想当然接受了,没有做校验,就被别人分析请求,伪造了数据,盗刷了很多积分。所以服务器端涉及到重要的数据,金钱,积分,这种一定要验证,(可能前端小伙伴验证了,后端小伙伴一定也要验证)。还有用户信息也不能通过前台传递,通过token直接去拿信息。
# 总结:
- mysql一定要开启binglog,其他数据库也是一样要开启相应的log。
- 数据库和项目做备份,数据库可以每天凌晨备份一次,保留三份最新的。项目可以一周备份一次,保留两份最新的就够用了。
- 开启WAF(web防火墙),根据自己的业务配置高频ip访问以及自定义CC规则。
- 后端对客户端数据验证,一律不要相信传递过来的数据,一定要验证,防止伪造。
- 还有DDOS攻击(上面没有写),可以买高防护的云服务器。
- 最好服务器软件搭建都自己配置,尽量不要用面板之类的,为了方便,也带来了风险。(比如这次的pma漏洞,他会做一些他觉得方便的事情)。
- 一些服务软件的默认端口一定要改,以免有些软件漏洞,被黑客扫描端口。
# 资料:
抱歉,我们的锅,关于PMA安全风险的致歉信 (opens new window) 云盾:Web应用防火墙文档 (opens new window)
# 一只拥有浪漫主义的务实程序员
东风夜放花千树。更吹落、星如雨。宝马雕车香满路。凤箫声动,玉壶光转,一夜鱼龙舞。 蛾儿雪柳黄金缕。笑语盈盈暗香去。众里寻他千百度。蓦然回首,那人却在,灯火阑珊处。