遭受刷验证码攻击后的企安建设规划感想

背景

公司上市不到两周,便遭受到了黑客攻击,其中笔者团队的验证码比较容易识别,攻击者通过ORC识别刷了10几万的短信,除了造成一笔资金开销外,也给服务器带来了很大的压力;

并且在阿里云的控制台当中每天都能看到很多攻击信息,却没有拦截,原因是没有购买WAF防火墙,售后也频繁催促购买其安全设施;所以技术负负责人也开始重视起安全问题来,笔者因为懂一些安全技术,所以老大希望笔者在这方面做一些规划指导,周末花了点时间根据公司的现状做了一下规划设想,下文便是当时的口述汇报,后来整理成了文字版,给读者做一些参考吧。

一、网络安全威胁

提到安全可能直觉上会想到安全漏洞,代码安全等问题,不过安全一般比直觉上的范围更广泛,主要有来自于六个方面:网络安全、主机安全、应用安全、数据安全、运维安全、法律风险等。

1.1 网络层

拒绝服务攻击,分布式拒绝服务攻击(DDoS),是最暴力、血腥、有效的攻击方式,可直接导致企业云上业务系统带宽堵塞。

DDOS攻击防御有两个核心点,首先是识别谁是恶意攻击,另外就是要有足够的带宽和服务器性能来处理这些请求,DDOS攻击是在太野蛮,应对的方法也比较被动,可以使用云平台的防DDOS产品,但也会有误伤,所以遇到这种攻击也只能使用这种无奈的处理来应对。

1.2 主机层

云主机入侵攻击,云主机是企业云上业务系统的重要承载,攻击者通过暴力破解或配置漏洞等缺陷入侵云主机,用以构建僵尸网络、窃取数据及敲诈勒索等。

主机层的风险通常是一些通用漏洞的风险,比如2016年心脏滴血事件全球的服务器都会受到此影响,因此到相对好处理,我们可以使用阿里云的安骑士产品,一键修复系统中的安全漏洞。

1.3 应用层

Web应用漏洞攻击,企业云上业务系统对外提供服务的诸多系统采用HTTP/S应用协议(Web),攻击者利用Web服务可能存在的诸多漏洞进行攻击,窃取业务系统数据或权限等。

应用层变更最为频繁,每家的应用特点都有一些差异,所以通常应用层受攻击的可能性最大,要防御此风险需要持续不断的进行跟进,比如对开发的安全意识,安全开发进行培训,对项目上线前的测试增加安全测试部分。

1.4 数据层

数据窃取或篡改云上业务系统数据在传输过程中经过互联网,可能被中途窃取或篡改,造成数据完整性和机密性受到影响。数据层相对范围比较广,比如代码是否泄漏,是否有数据泄漏,以及页面挂马,网站的留言的黄赌毒关键词筛选等,因为这些数据泄漏的途径会随着应用层的变化而变化,因此数据层也同样需要持续跟进。

1.5 运维层

运维人员违规风险操作企业云上业务系统需要内部人员进行运维操作,如何防范高风险的运维操作至关重要。

不过运维层的操作风险倒也是各个厂家的一些通用风险,因此解决方案也相对较多,比如使用堡垒机在可视化界面上分配权限,这个权限可以让一个账户指定开启多长时间,并且还可以全程监控,以及操作记录回查,因此风险不大。

1.6 合规层

国家等级保护2017年6月,国家网络安全法开始实施,企业安全建设不仅仅是内部驱动,同时也有法律驱动。

包括实名制,以及日至留存,制定相应的企业安全防护策略等。

二、安全制度

大多数人可能想到安全是从安全技术上来解决,实际上安全问题不仅仅靠的是技术层面,更多的是从制度上去解决的;

2.1 安全工程化

这里提一下SDL,SDL是英文字母的缩写,中文名称是安全开发生命周期,他是一套安全的生成流程。最开始来自于微软,在微软2004年以前windows系统和office中存在大量安全漏洞,为了解决这些问题提出了SDL,当使用了SDL之后office、windows的安全漏洞大量降低,后来被各个厂商推广。

SDL从 安全培训-》需求分析-》设计-》实施-》安全验证-》发布-》响应 这7个方面入手,每一个环节有相应的安全标准,不过微软标准版的SDL推广并不是很顺利,原因很多,但标准版SDL比较繁重是一个重要的因素,因此各家都有自己的一套SDL标准,在这方面我们也可以进行一些借鉴,制定一套自己的SDL标准,这个标准的制定一定要符合可执行可落地来为依据,可以参考我下面的落地实施部分。

2.2 对外沟通

2016年前以前,白帽子发现漏洞在乌云网报告,乌云网通知到各个公司,2016年7月之后乌云网关闭,一批白帽子被抓,导致白帽子发现漏洞不敢报告;不过后来各家开始组建自己的漏洞报告平台,2017年6月安全法出来之后,大部分公司要合规,因此大一些的公司通常都有自己的安全团队,比如教育行业好未来的应急响应中心;现在大家发现漏洞通常会报告给对应的平台的SRC;

比如教育行业的好未来SRC:http://src.100tal.com/

瓜子二手车的SRC:https://security.guazi.com/

以及更多的SRC平台,如下图

2.3 安全落地

上面提到了安全工程化,不过SDL的标准对于我们现阶段太过于理想,所以需要针对实际情况制定一些可落地的方案

安全编程规范

将一些可能带来安全风险的操作写入规范当中去,比如参数的输入输出,服务器的安全配置,以及代码的安全发布流程等。

安全培训

很多时候开发者并不重视安全,又或许对安全缺乏了解,比如系统中有哪些安全漏洞,漏洞的危害和原理是什么样的,怎么去防止这些漏洞等等,大部分开发者的安全意识还是很弱,和互联网技术不重视安全也有关系,可能一些开发者知道一些SQL注入、XSS,但是一深入去问一下,就不知所以然,而开发者对安全起了至关重要的作用,所以很有必要对开发者进行安全意识和安全基础技术的培训,这样才能从源头解决安全问题。

代码审计

这个不管是对于安全的角度还是对于减少BUG的角度都是很有必要的一个环节,对每个项目设定一个代码审计人员,可以对此这些审计人员组织一次代码审计指导;

安全测试

目前我们项目上线做了充足的功能测试,但是安全测试相对偏少,或者说并不全面,可以专门针对测试的人进行一些安全工具的测试的指导。

三、安全产品

阿里云提供的安全产品比较齐全,不过价格比较贵,而目前我们没有专门负责安全的人来维护,因此选择的安全产品方向为能直接提升安全,这样才能发挥最大价值,否则便成了手有宝刀,却无刀法,下面是三个必要的安全产品:

1. 安骑士

前面提到了主机安全,主机安全不会经常变动,因此应对的是一些通用风险,安骑士提供一键修复通用主机漏洞的能力,可以快速修补主机安全,避免人工去修复并不知道如何去修,或者修复不及时。

2. WAF防火墙

WAF防火墙对应的是应用层安全,可以针对一些代码级的安全漏洞做一些安全防护,应用层变化最大,因此必要性比较大,不过要注意的是WAF防火墙只能处理代码级的漏洞,而逻辑层的却无能为力,比如上次的刷验证码,防火墙则只能将频率非常高的IP封锁,但无法阻挡刷验证码的漏洞问题。

3. CA证书

CA证书的作用是HTTPS,是用来对传输过程加密,比如服务器提交数据到服务器过程不被攻击者拦截,又或者我们服务器的数据不被一些网络运营商插入广告等,因此重要性也是十分重要。

另外针对阿里云的安全产品较贵的,可以参考也可以参考其他家的安全产品,比如百度的云加速,就带有了WAF防火墙和防DDOS功能,地址为 su.baidu.com

四、新书推荐

如果对笔者的文章较为感兴趣,可以关注笔者新书《PHP Web安全开发实战》,现已在各大平台上架销售,封面如下图所示



作者:汤青松

日期:2018-11-13

微信:songboy8888

原文地址:https://www.cnblogs.com/tangqingsong/p/9951479.html

时间: 2024-11-06 03:38:44

遭受刷验证码攻击后的企安建设规划感想的相关文章

网站遭受大量CC攻击后的应对策略

上周开始我网站遭受了一大波CC攻击,到目前为止仍在继续,作为一个建站小白,我感觉压力好大,又有新的问题要挑战了! 服务器架设在腾讯云,CC攻击很凶猛,带宽瞬间占满,于是在腾讯云后台配置安全组关闭了80端口,流量瞬间下来了. 服务器上装的安全狗也疯狂报警.. 看来真正遇到问题时,安全狗也顶不住啊,在此鄙视一下. 攻击的IP来自境外的较多,基于程序狗的惯性思维,我想到了在腾讯云后台配置安全组规则,屏蔽这些IP访问. 于是第一步,分析IIS日志,提取IP. 日志数据量大,看来不写个软件搞不腚呀! 然后

务器遭受攻击后的一般处理过程

一.处理服务器遭受攻击的一般思路 系统遭受攻击并不可怕,可怕的是面对攻击束手无策,下面就详细介绍下在服务器遭受攻击后的一般处理思路. 1.切断网络 所有的攻击都来自于网络,因此,在得知系统正遭受黑客的攻击后,首先要做的就是断开服务器的网络连接,这样除了能切断攻击源之外,也能保护服务器所在网络的其他主机. 2.查找攻击源 可以通过分析系统日志或登录日志文件,查看可疑信息,同时也要查看系统都打开了哪些端口,运行哪些进程,并通过这些进程分析哪些是可疑的程序.这个过程要根据经验和综合判断能力进行追查和分

安全运维之:服务器遭受攻击后的一般处理过程

安全总是相对的,再安全的服务器也有可能遭受到攻击.作为一个安全运维人员,要把握的原则是:尽量做好系统安全防护,修复所有已知的危险行为,同时,在系统遭受攻击后能够迅速有效地处理攻击行为,最大限度地降低攻击对系统产生的影响. 一.处理服务器遭受攻击的一般思路 系统遭受攻击并不可怕,可怕的是面对攻击束手无策,下面就详细介绍下在服务器遭受攻击后的一般处理思路. 1.切断网络 所有的攻击都来自于网络,因此,在得知系统正遭受黑客的攻击后,首先要做的就是断开服务器的网络连接,这样除了能切断攻击源之外,也能保护

Linux服务器遭受攻击后的一般处理过程

安全总是相对的,再安全的服务器也有可能遭受到攻击.作为一个安全运维人员,要把握的原则是:尽量做好系统安全防护,修复所有已知的危险行为,同时,在系统遭受攻击后能够迅速有效地处理攻击行为,最大限度地降低攻击对系统产生的影响. 一.处理服务器遭受攻击的一般思路 系统遭受攻击并不可怕,可怕的是面对攻击束手无策,下面就详细介绍下在服务器遭受攻击后的一般处理思路. 1.切断网络 所有的攻击都来自于网络,因此,在得知系统正遭受黑客的攻击后,首先要做的就是断开服务器的网络连接,这样除了能切断攻击源之外,也能保护

使用Discuz!自带参数防御CC攻击以及原理,修改Discuz X 开启防CC攻击后,不影响搜索引擎收录的方法

这部份的工作,以前花的时间太少. 希望能产生一定的作用. http://www.nigesb.com/discuz-cc-attacker-defence.html http://bbs.zb7.com/thread-8644-1-1.html CC攻击确实是很蛋疼的一种攻击方式,Discuz!的配置文件中已经有了一个自带的减缓CC攻击的参数,在配置文件config.inc.php中: 1 $attackevasive = 0;             // 论坛防御级别,可防止大量的非正常请求

最近公司网站一直给人刷验证码,以及API接口。

最近这几天公司网站一直给人刷验证码,以及API接口.虽然可以使用iptables把它ip封了,但是那些人都是半夜来刷的,真可恶,同时有好几十个肉鸡过来刷,并且有时候有几个ip居然用iptables封不了,这几天疯狂了解相关的DDOS攻击原理信息,看能否找到有效的方法拦截.

PHP实现对短信验证码发送次数的限制(防机刷验证码)

PHP实现对短信验证码发送限制(防止机刷验证码) 对用户获取短信验证码的手机号.ip.和浏览器(使用唯一标识)进行限制.本文介绍的方法是对用户每天只能通过同一浏览器或同一ip地址获取验证码10次或者同一手机号只能获取3次短信验证码,三种限制为“或”关系,一条超限就不发验证码.方法是通过在服务器端将用户的手机号.ip.ur_r记录并写入文件,再通过读取文件记录判断用户请求发送验证码的次数来做限制.方法如下: 获取短信验证码页面: 1 <!DOCTYPE html> 2 <html>

比特币黄金(BTG)遭受51%双花攻击?——不亏

自2017年8月1日比特币现金(BCH)硬分叉之后,比特币硬分叉就已成为一种潮流,BTG.B2X.BCD.SBTC.BCHC等等诸多分叉币不绝于耳.然而其中却有一个另类,那就是BTG.其另类的主要原因在于,相对于其他分叉币,BTG并没有对比特币进行扩容,依然采用1M区块+SegWit设定.其主要改变在于挖矿算法,对ASIC矿机进行了限制,转而通过电脑GPU挖矿.总而言之,BTG的GPU挖矿设想,旨在解决比特币挖矿算力过于集中的问题,保证其去中心化的特性.然而现实却并没有想象中的美好,GUP挖矿依

服务器遭受攻击后的处理办法cc

其实防御CC攻击如同当初防御DDOS攻击本质上是一样的,这些攻击都是以消耗服务器资源为目的的.DDOS攻击的原理是针对TCP/IP协议的一项缺陷,当时设计者以为互联网使用者都是互联网的良民,不过现在的互联网环境可是要复杂的多. 两台机器通信要进行一个所谓的三次握手,首先是客户机发出一个请求 (SYN) ,服务器收到该请求后,填写会话信息表 (TCB,保存在内存中),并且向客户机反馈一个回应包 (SYN-ACK) ,此时连接处于 TIME_WAIT 状态,如果最终没有收到客户机的 ACK 信息包,