单枪匹马搞企业安全建设

“企业安全建设”一直是安全圈内研讨的热点话题。大公司有专业的安全团队，而中小公司由于人员不足，资金紧张，精力有限，技术水平参差不齐等等原因，始终处于劣势，更容易受到黑客攻击。

那么中小企业在企业安全建设过程中如何实现自我突破呢？

目前系统性分享企业安全建设的文章比较稀缺，之前有两位同行（atiger77,晓风）已经无私的分享过了自家的企业安全建设的经验，笔者都多次反复细读，确实获益匪浅。

笔者恰好也是“一个人的安全部”，所以对文章中描述的经历和场景感同身受，但是笔者在企业安全建设之路上，和两位同行有不同的一些思考和落地实践，也取得一些小成果，并深深认识到：随着企业规模的扩大，要想做好安全的各个方面，光靠一个人是搞不定的，必须要依靠第三方平台，笔者所开展的部分安全工作都依赖于阿里云的云盾系列产品，这绝不是打广告和做宣传，而是确实满足某些安全需求，借此整理分享出来，给有需要的同行参考，希望大家多多指导。

对本篇文章有任何问题都可加我微信一起探讨，部分涉及敏感细节的就不展开。

先说一点,企业的安全建设是在救火阶段之后开始的，如果在救火阶段，最重要的工作就是解决能直接造成资金损失的安全问题。

笔者目前就职在国内一家宠物用品的电商公司，公司规模人数在500+，业务线10+，服务器（没有虚拟机,全部是ECS）数量 40+（之前两位同行所在公司服务器有1000+，内陆和沿海在公司规模差不多的情况下，这个数字竟然会差那么多），覆盖的渠道有WAP,PC, APP,微信。

接下来会从以下几个方面来做详细介绍：

资产梳理

资产其实一个比较泛的概念，大致包括实体资产和虚拟资产，实体资产主要指(服务器，路由器，交换机，waf等），虚拟资产主要指（域名，证书等），在跟很多安全同行交流后发现资产梳理，由于历史原因，管理不当等种种原因，感觉落地比较困难，这里重点对域名和waf说明下：

域名是所有资产中比较重要的。

第一步：梳理使用中的域名，一般公司都会有多个域名的情况，整理一份最完整的域名列表

第二步：逐一对每一个域名进行子域名扫描，查看每个子域名是否有直接解析到真实服务器ip，如果有，则必须要做相应的处理，不然容易导致未授权访问和敏感信息泄露。这里推荐使用seay的子域名挖掘机来自测。

第三部：排查每个子域名是否为敏感业务的后台，如有，则可以考虑更换子域名的复杂度，比如admin.xx.com很容易被猜解到为后台系统登录地址。

waf对于中小企业来说，自建和维护的成本太高，所以不建议自行搭建，最简单、有效的方法是使用第三方云waf，笔者在搭建自家waf的时候，调研了很多产品，总的来说，如果没资金可以考虑使用云加速，加速乐这两个产品，这2个产品都有免费的版本提供，基本足够，免费版中还提供了CDN加速服务，唯一的缺点就是不支持HTTPS，不过毕竟是免费的，另外就是国内几大云服务商的waf，自家选择的是阿里的WAF,功能比较丰富，另外有较好的技术支持，具体的详细功能就不介绍了，完全可以满足大中型企业的需求。

服务器上的服务：

对于所有服务器的外网IP、端口所跑服务，必须有一份详尽的记录，建议专人来记录，并实时更新，之所以要记录，就是为了降低未授权访问及敏感信息泄露的风险。巡风扫描系统可以用来辅助做一部分周期性扫描工作，也可以使用自研扫描脚本来完成周期性扫描工作，然后将扫描结果实时推送到钉钉。

再说一点，之前阿里云没有经典网络和VPC之分，巡风出来之后，有黑客大规模使用巡风在经典网络中乱扫，然后阿里云出一个安全组的产品，类似防火墙功能，建议将ECS全部迁入VPC,并设置合理的安全组策略。

运维安全

远程登录，是运维日常管理中至关重要的一环，每天都有黑客在对可能是服务器ip的ip地址发起大规模的ssh暴力登录，如果你的服务器的ssh是采用密码登录，并且密码安全强度不够高，就很容易被黑，所以必须形成统一的安全规范

第一步：禁止root直接登录，禁止使用账户密码登录，全部使用密钥登录

第二步：适当sudo授权，根据需要，给角色授权,不能给开发较高的权限

第三步：权限回收，所有远程登录全部走堡垒机，一般的堡垒机都有操作日志记录和录像回放，方便后期安全问题排查和追责。具体的堡垒机的选型可以私聊。

代码上线流程也是比较关键的，目前持续集成的概念很火，但是不建议中小企业完全照搬大公司的玩法，可以根据自己的实际情况选型，重点说下静态代码扫描：建议周期性对上线的代码进行安全扫描，将一些高危漏洞和敏感函数通过扫描发现，防止提交上线后，发生安全事故，目前国内使用比较多的是sonar和cobra，sonar是一个对代码质量进行审查的工具，cobra是专门做源代码审计的工具，支持大多数主流语言，但扫描规则比较弱，存在有一定的误报，两者都可以集成到上线发布系统中，可以根据实际情况进行选择。

3.代码审计

代码审计对减少线上问题和bug是至关重要的，目前国外付费的价格高得用不起，国内免费、好用的代码审计工具比较少，而且普遍存在误报比较高，所以很难使用一款工具就能满足所有需要，笔者简要的说明下自己的调研实践情况：

应用安全

周期性安全测试：需要专门对核心业务和营销活动进行周期性的安全测试，防止刷单、薅羊毛、恶意注册等相关问题，当然一个人确实精力有限，而且由于开发的安 全意识参差不齐，可能会不断上线有安全问题的功能，所以可以考虑选择类似阿里先知的众测这种模式，见效快，毕竟人多力量大。

业务风控：

需要比较熟悉目前所开放的业务，建立自家的用户信征体系，根据实际情况，增加规则判断，哪些规则可以来作为判断呢？ 以注册模块为例，排查使用同一个手机号注册的情况，查询去重就可以发现哪些手机有重复注册的情况，可以对这些用户进行信誉减分。再举个栗子，羊毛党一般都有多个小号，利用小号来获取优惠券和低价抢购资格，可以对收货地址（省-市-区-详细地址）去重查询，刷选出羊毛党（不同多个的账号，但却使用了同一个收货地址），然后对这些用户进行信誉减分，这些情况还是有很多，需要根据自家的业务进行梳理，然后制定一系列规则，一旦用户触碰到规则，就对其减分，当用户的信誉分低到一定的程度，比如基础分80，触发一个规则扣5分，当用户信誉分降到60以下，就对该用户进行访问限制，最简单粗暴的可以直接封号或禁止访问，如果不这么粗暴，也可以对部分功能进行限制，比如一天只能下一次单，取消低价抢购资格等等，可以做成精细化控制。

手机风控：

这里详细讲下手机风控，因为很多公司的业务在注册的时候都需要手机号注册，目前国内有多家手机验证码接收平台，运作原理就是出租一些卡商的手机卡号给羊毛党，然后羊毛党或黑客可以利用这些手机号去网站或者app上注册多个账号，获取优惠券和低价抢购资格，中小企业很难去验证手机号的安全性，这里提供2种的解决方案，

a.Api的形式：调用第三方接口，来判断该注册手机号的信誉分

b.waf的形式：根据阿里的大数据，自动拦截掉风险值偏高的手机号的请求

建议使用阿里云的waf，带有自动拦截风险系数较高的手机号的功能，当用户请求走到waf的时候，会利用阿里大数据对该手机号进行综合信誉分判断，并得出一个分值，分值越高，风险系数越高，可以设置拦截的分数阈值，如果设置拦截分数为80分，那么所有过waf的手机号的风险系数高于80的会被直接拦截掉，该请求不会落到服务器上，如果你使用api接口的形式，原理也是得出一个风险系数分值，但是如果攻击者写脚本来暴力攻击，会对服务器造成很大的压力，使用阿里waf的话，直接在waf层就拦截了，所有请求不会落到真实服务器上，对服务器来说，是最佳选择！

弱口令排查:

如果用户使用弱口令导致被暴力破解，企业也是有一定责任的，应该在用户输入的登录密码进行密码强度验证，但由于历史原因，并不是所有的注册入口都验证了密 码强度，所以所有注册入门比较增加密码强度验证，另外建议整理一份弱口令字典，写一个接口，在用户登录的时候，调用验证用户的口令强度，如果是123456等弱口令，让用户修改弱口令之后才能登录，减少用户使用弱口令的情况。

日志分析:

日志对于安全来说很重要，特别是nginx服务器的访问日志，笔者曾经自己搭建elk日志系统，从搭建、日志采集，到部署调优，花费了相当长的时间，而且服务运行的过程中，经常出现不稳定的情况，以及从2.2升级到5.0的时候也出现很多不稳定的情况，慢慢也发现绝大多数安全人员对于这套架构部署和维护很难驾驭，而且这套架构也存在一些弊端：

每台nginx服务器上都要去部署logstash采集器，logstash采集日志会会消耗不少nginx服务器资源，一般来说，标准的生产环境:php+nginx或者java+tomcat,另外还需要去写shell脚本来定时切割日志，将日志分存，进档

Es在并发接收logstash丢过来的json格式日志，有时由于网络原因，存在丢包情况，另外存在无法正确解析的情况，有人建议有redis的队列做缓存，实践效果不佳

elk搭建不难，但是Es本身的维护，调优需要具备较专业的知识，kibana的查询数据过大的话经常会导致超过，然后需要重启处理

基于以上问题，笔者调研几款第三方云产品

日志易，需要安装agent来收集日志，不过同样需要安装到每台nginx服务器上,但统计报表比较简单。

阿里云日志服务,logtail组件（类似logstash）在高并发的场景下，比logstash的性能要好，资源占比少，另外配合阿里的elasticsearch产品，可以完全替代自建的elk系统，而且如果需要日志查询，可以使用类似sql查询方式比kibana的Lucene更友好，最重要的是阿里已经与elastic官方合作了！

移动安全：

对于移动安全，笔者涉略不多，故将移动的安全全部基于阿里云的移动安全产品来完成，定期将安卓包上传，扫描，下载输出安全报告，反馈给移动开发的同事，进行修复和优化。但对app的核心业务，笔者会跟PC，wap一样定期进行安全测试，当然会稍微麻烦一点，使用代理工具进行抓包追踪，或者直接安装安卓模拟器来替代手机，因为手机一段时间不操作会进行锁屏状态，很麻烦，而安卓模拟器则不会锁屏，可以跟测试PC端一样方便，苹果模拟器也差不多，具体模拟器选型可以私聊。

内网安全

办公账号弱口令：统计下内部oa,erp系统,发布系统,客 服系统，后台系统，邮件系统等使用的账号数量，并做个详细记录，逐一排查哪些员工账号存在弱口令。普遍很多员工抱怨，公司有太多系统，要记太多密码记不 住，确实对人来说，那么多账号，不愿去记，也记不住那么多系统账号，这里分享下笔者的方法：每个人入职只有一个密码，通用所有系统。肯定有人说这样会有隐 患，其实可以这样，这个密码是由数字+大写字母+小写字母+特殊符号，然后每个人从4种类型中，每种类型选2个，然后自由排序，组成一个8位的密码。那么这个密码可以用作这个人在公司的终身密码，通用公司所有系统，也很难被破解。

重点说下企业邮箱安全：

大家都知道企业邮箱里有太多的秘密了，工资，公司通讯录等等，敏感信息比比皆是，笔者自研了一个暴力破解脚本，从人事处拿到所有人的邮箱地址后，开始逐一 爆破弱口令，如果爆破成功，直接找到对应人让他修改。一般来说第三方的企业邮箱都有一些安全机制，高频尝试暴力登录，会封ip或者限制访问，需要采取一些hack手法，具体操作可以私聊。

等级保护测评

随着安全法的落地，测评工作也是必不可少，配合测评机构逐步进行，对测评出的问题，按需完善即可。由于我们是ECS，有阿里做后盾，所以评测流程比较顺利。

安全培训：

这个可以根据实际情况来做，如果有分享会，可以定期分享一些安全知识，提高开发的安全意识，就笔者所在的公司来说，开发的安全的意识普遍不高，对安全的认识 停留在初级阶段，对其中安全漏洞的成因不了解，导致开发过程中会出现不少的安全问题，如果没时间培训，也可以订阅安全牛、i春秋的课程推荐给开发同事学习，当出现安全事故之后，需要把还原整个安全事件，让所有的开发了解，避免下次范同样的问题，当然也可以设置惩罚机制，根据自己的情况去做，深入的话也可以私聊。

威胁情报搜集

其实一个人精力有限，时时刻刻去盯爆出来的0day很难，建议多订阅一些高质量的公众号，时常关注0day的预警，一旦发现及时修复漏洞，最好不要用第三方的产品如discuz，phpcms等，因为不定时就报0day，如果非要用，也建议把周期性去排查是否有新版本，及时升级补丁。另外对于github上的敏感信息泄露，建议使用脚本去周期性的扫描，或者使用携程云的github扫描功能，如果发现自家代码，必须找到对应人强制下线。

安全应急中心

对于一个人的安全部，有人说意义不大，但笔者觉得，还是有必要的，很多白帽子，在发现安全问题之后，其实是想找一个渠道反馈给官方，如果企业有反馈渠道即 应急响应中心话，白帽还是很乐意去提交的，如果官方没有渠道，那么基本只能提到补天这种平台，这就会导致获取安全问题滞后，甚至被黑！当然自家实在没有应 急中心的，建议时常去补天看看是否有自家漏洞，尽快认领修复！

要做好企业安全建设，对一个或几个安全人员来说，确实不是一件易事，因为安全涉及的东西比较多，随着企业业务的扩展，安全需要为其保驾护航，随之而来的工 作增多，先解决掉存在的问题，再一步步横纵向扩展，建立起多层防御机制，就能减少被攻击的风险，另外不要存侥幸心理，细扣每个细节，用有限的精力把安全做好！

结语：

感谢atiger77，晓风两位的无私分享,以及其他开源产品的开发者，并附上两位同行的文章链接
atiger77 http://www.freebuf.com/articles/security-management/126254.html
晓风 https://xianzhi.aliyun.com/forum/topic/1568/
巡风系统 https://github.com/ysrc/xunfeng
cobra https://github.com/wufeifei/cobra
sonar https://www.sonarqube.org/
rips http://rips-scanner.sourceforge.net/
seay源代码审计工具 www.cnseay.com闭站了，去百度搜吧！
携程云安全 https://security.ctrip.com/
号安 https://hao.secboot.com/
云加速 https://su.baidu.com/
加速乐 https://www.yunaq.com/jsl/