如何进入外网(如何进入外网看视频)

我在某教育公司负责公司整体安全，保护6000多万“熊孩子”的安全。一年半的时间从什么都没到现在的逐渐成型，此篇文章进行了一个总结，期间也碰到了的很多坑和坎，这里再次感谢帮助过我的朋友们，感谢 MottoInTeam 小伙伴。由于涉及到企业攻防，有些内容的细节部分这里不方便展开。

目录

0×01. 情况概述

0×02. 运维安全

0×03. 业务安全

0×04. 应用安全

0×05. 内部安全

0×06. 总结

0×01情况概述

公司产品主要是一款教育类 APP，后面我会分运维安全、业务安全、应用安全、内部安全和碰到的问题以及解决方法进行展开。如果你的公司像我一样只有一个人或者几个同学负责，我建议把重心都放在存在的安全问题上，比如业务场景中的薅羊毛，刷单等，用户模块的扫号，盗号，业务安全线的安全测试等。先处理这些直接会带来损失的安全问题再逐渐完善，一点点进行横纵向扩展。

0×02 运维安全

刚入职所在的公司因为没有安全部门，我是运维安全的岗位进入了运维部。我在原有的基础上又做了一些安全提升，这里提一点如果公司没有安全同学，对于运维同学而言，把控好安全基线也可以在一定程度上抵御一些攻击。

devops里的一些运维自动化工具比如 ansible, saltstack,puppet 等，以 ansible 为列在初始化的role里就规定安全的基线，如：SSH禁止ROOT登录、修改SSH默认端口、禁止密码登录、新建普通用户、设置别名把“rm -rf”类似命令进行替换等等。

保证交付给开发的机器都一样，比如软件的安装目录，由于历史原因有一些记录上的环境都是开发自己安装的，导致会出现很多个 nginx 目录，处理起来非常烦需要确定到底运行的是哪一个目录下的 nginx 才可以继续操作。当然建议公司使用堡垒机，上了之后对权限的管控对服务器的安全又可以提高一个保障，之前也调研过目前堡垒机情况，具体的可以细聊。

除了服务器，数据库的初始化也同样重要，初始化只给开发普通帐号并赋予对应权限，设置连接白名单不允许非名单机器进行连接，密码一律多位数复杂密码。

作为安全运维这块必须记录所以外网 IP 及对应端口，所以服务器对应的服务，由于每个公司情况不同，有些是安全部记录有些会是运维部把控，根据自己的情况来即可。

外网IP及对应开放端口

除了解析商那里的记录自己必须保存一份最新的，之前碰到过一个情况自己在做外网IP扫描的时候发现有一个IP开放了一个端口，爆破发现使用了弱密码，平台的内容会对公司造成影响，先停止这个转发通知开发进行整改。

对于这种情况有两点，一是严格把控要求外网IP的要求，对于一些敏感业务若没有经过安全测试不予提供外网访问。二是记录所有外网IP及开放端口情况，有相关自己平台的可以添加一页，没的话可以记录到 confluence 中即时更新。

服务器对应提供的服务

这些年爆出了大大小小一堆的漏洞，每次收到还都是下班以后orz。每一次高危的漏洞都是对安全人员的一次考验，就是和时间赛跑晚一点服务就可能被黑，这里主要讲一下我从收到漏洞预警到处理的一个流程。

获取漏洞信息

可以多订阅一些高质量的公众号，加一些相关的安全群尽量第一时间能知道哪个服务出了问题，收到的消息越早越是能给自己留多一点时间。

确定漏洞影响范围&严重性

收到信息之后就要确认漏洞的影响和范围，这个服务公司是否部署，部署的是测试环境还是生产环境，分别有多少台，漏洞的触发条件是否苛刻，造成的影响有多大等问题，如果自己无法判断漏洞严重性的话可以多和朋友交流沟通，不要盲目的去修复升级，某些版本升级好性能兼容性可能会出现问题。

对于影响范围之前也点到过必须记录服务器上部署的应用，在漏洞出现后可以快速定位而不是问开发你有没有部署xxx服务，我是记录在了运维的 CMDB 中。

内部测试

我举两个漏洞为列： 一个脏牛漏洞，一个应用漏洞。

脏牛漏洞的影响力不言而喻，除了本地使用容器服务的同学记得要把 baseimage 也做对应的升级。确定了严重性以后找出公网提供web服务的对应机器，先用长亭的方法做线上应急操作。然后找对应补丁对内网测试环境进行升级测试，由于是内核漏洞观测的时间比较长确定没问题在一点点的升级其他主机。

某应用漏洞，由于这个服务不对外提供服务所以紧急程度没有脏牛来的这么紧，同样的找一台测试机器安装高版本确定不受影响后让测试同学帮忙做压测，看新版和旧版性能差异，如果没问题就上一个下一个直至全部升级完成。

上线观测

这里切记，并不是上线就没事了，上线之后必须再做一次复测确定没有问题并持续观察服务稳定性，做好随时回滚准备。

0×03 业务安全

只要公司到一定规模了都会碰到这些情况：扫号，撞库，垃圾注册，刷单，刷券，羊毛党，竞品攻击，DDOS 等等。

先说 DDOS，根据一年的情况发现到年前年后，熊孩子开学，活动上线都是 DDOS的高发期，对于流量攻击我们选择了一家做流量清洗业务的公司帮助我们做恶意流量的清洗。

接着说一下对其他情况的处理，这些情况都是互联网公司常见的现象，只要规模上去了，有利益可以拿就会被攻击。想有效的去发现异常，阻断异常需要一个完善的风控平台，我讲一下我这边风控是怎么做的以及碰到的一些坑和对应接的方法。

做风控的坑与应对

首先要知道做风控是为了解决已经出现的安全问题并能即时的阻断，刚开始做不要盲目的模仿大公司的玩法，大公司有自己专门的团队去做这个，盲目的模仿不但没解决问题反而起到了反作用，一开始做也别想着可视化，可视化是在功能都成型了要向上级展示的时候在考虑的东西。找到出现的问题，溯源问题的原因，并采取对应的策略。

做风控必须要有数据，没有数据的支撑是无法做风控的。关于数据我的理解是这样：风控使用到的日志有别于 BI 日志和业务日志，安全日志是可分析异常用户行为，攻击趋势的增长情况，最后做到先于攻击者进行阻断保护系统安全稳定。在和公司相关同学沟通的时候他们也会问一些问题，我总结了下。

Q：安全日志 和 应用日志 以及 BI 日志 有什么区别？

A： 共同点：三者都是记录业务产生的动作行为。

不同点：应用日志本身只是查业务是否正常性能是否达到预期，切重于业务本身。

BI 日志根据事前埋点收集用户行为进行分析为各个部门提供相关数据分析，如事件漏洞，转换率等等。

安全日志主要记录安全相关信息，细化到哪一个用户在哪里用什么设备进行了什么动作并尝试了多少次，切重于业务安全。

Q：有了 BI 日志还需要安全日志嘛？

A：需要。首先 BI 日志目前没有涉及到公司所有业务，BI 的日志并不是为了安全而生更重要的是为其他部分提供数据支撑，从而更好的掌握用户需求。

安全日志和 BI 日志必然会产生交集，然而这并不冲突。对于风控策略而言安全日志是实时可查看的，第一时间可以知道当前时间的状态，BI 日志是事后进行统计数据广度更大，两者结合更能保障业务的安全。

Q：安全日志主要记录哪些内容？

A： 安全日志需要记录谁在什么时候用了什么东西干了什么结果是怎么样，等一连串用户纬度指标。

和相关同学都达成共识以后就可以开始执行了，我使用ELK对日志进行收集分析，logstash_agent 把安全日志 output 到 redis 中，再由一台 logstash_indexer 取 redis 中的数据 output 到 ES 集群中，最后通过 kibana 进行展示。

有了数据以后通过 kibana 的聚合就可以发现异常的问题了，由于牵涉到相关数据我就不截图了，以用户模块为例就可以有很多的判断纬度，仔细观聚合后的数据就可以发现对应的安全问题，那么这些纬度大部分都是基于行为的判断，除了行为的还有基于特征的，比如用户的手机号是否执行过欺诈行为，我测试过某安的反欺诈产品结果还不错。

以上这些都是不同的规则有基于行为的也有基于特征的，规则都是一个判断的纬度但不是触发了规则用户就一定不好，为了降低误杀率我们会给规则定分数，当一个用户总分到了阈值那么会直接对他做功能限制等操作，如果触发高危动作也会直接阻断，具体策略每个公司都不一样根据自己实际情况制定即可。

如果有人力的话也可以把日志导入到 Storm 里根据自己的需求用bolt去做一些统计，要高可用的话推荐用 flume+kafka+storm 的架构去处理。我现在是使用 Python 去进行分析处理，根据自己情况选择一个合适的即可。

当我这边的程序发现异常时会自动的给用户打上对应标签并同步到BI的系统中进行记录，同时为了不给客服同学带来压力这个标签也会同步到客服后台中方便她们进行查看。

羊毛党

讲一下羊毛党，有了风控数据我发现每天都会有恶意注册，反溯这些帐号以后发现这些号里都有我们的活动券，根据活动券内容确定是哪个活动，询问相关产品活动规则策略，询问开发活动页的校验机制并自己黑盒在测试下，确定不是因为漏洞导致的就开始做自己的提升，风控就是一个攻防的对垒。

对应措施：

提高注册门槛；机器识别，人机对抗，验证码机制；

修改产品策略；调整产品策略；

优化风控规则；异常情况短信认证；

对抗羊毛党是个长期的过程，随着你的机制升级了，他的机制也会随之升级，就是成本和利益的问题，那对于甲方来说就是不断提高自己的门槛增加攻击的成本，把实惠给到真正的用户上。

机器学习

现在也有很多安全、风控团队在分享的时候会讲到机器学习，通过设定的模型来判断异常用户，但是具体分享细节的比较少，由于公司里很多机器学习方面的科学家，向他们学习以后我这里把我用到的一些机器学习方法和大家分享一下。

我觉得在风控中机器学习的优势在于，基于大数据不断的提炼调优模型会越来越完善，可以通过训练后的模型找出一些规则没有命中的异常用户，在逐渐的完善规则。之前有看到过有同学用随机森林去判断异常流量的，我自己有一个模型是判断注册用户是否异常的，模型的分数如下：

可以看到模型跑出的分数很高，我的样本是根据规则判断的，所以最好的情况结果就是逼近规则，需要一直对模型进行迭代去提炼更多的规则，继续调优参数，让模型判断不单单限于几个限定的样本规则。

0×04 应用安全

由于只有一个人，SDL 在公司很难去推行，快速迭代的版本上线每次检测到的漏洞一问都已经上线了好几个月，这也是挺被动的一点。

开发的安全意识和水平都不一样，也出现过线上业务出现 SQL 注入的问题，我是搞过一次全员的技术分享，讲一下主流的一些 WEB 漏洞和一些逻辑漏洞，让开发有一个印象。

我主要这样做记录开放公网的 web 服务每周都用扫描器去跑一次，对于大版本的升级我会自己再测一次。

备注

项目地址： https://github.com/ysrc/xunfeng

Medicean Docker版本：https://github.com/Medicean/VulApps/tree/master/tools/xunfeng

Atiger77 Docker版本：https://github.com/atiger77/XunFeng_Docker

详细介绍 &&ubuntu 安装方法可以看:

http://www.mottoin.com/94253.html

公司主要的产品是app，对于移动端的反编译这块我不是很熟悉找了一家公司做过渗透测试，测试下来也会发现一些问题，和公司安卓的老司机交流以后确定修复方案。端的东西加固就是让攻击者恶心，真的要破解理论上都是可以的毕竟所有人都可以下载研究，只是增加攻击者的破解成本。

APP的反编译主要还是针对安卓，网络层面用https+ Pinning在一定程度上增加了抓包的成本（IOS市场将不再支持http协议的app，如果还没升https可以尽早升级）。

端的加固主要是保证apk不能被重打包，主代码做混淆，公共调用部分做人工混淆，so文件不允许被调用，不允许模拟器调试等等的加固手段。

APP的升级不像网站，修复漏洞以后测试过就可以上线（有些框架支持动态更新），移动端会有版本问题，用户用着有问题的版本除非系统大的升级否则不会让用户进行强更（太影响用户体验了会导致用户流失）。

对于APP的情况可以这么做，降低低版本的功能使用限制。对过低的版本使用人数也少的可以要求产品进行强制升级的操作。

数据存储

最后说一下数据存储问题，最近一直会流出被泄露的库有些库密码就是简单的Md5+salt，撞库一下就可以跑出大量的用户密码，无论是对企业还是用户都会造成伤害，有能力的话还是建议设计加解密服务专门有一台机器进行加解密计算，把用户的敏感信息（任何能联系上用户的信息都算敏感信息，不单单是密码）进行加密，这个我是没推成功，因为收益在不出事前很小甚至是没有，如果这个推送不动还可以推一下加密方案。

关于加盐每个用户应该使用随机盐的方式进行加密存储，目前大部分的公司都是使用固定盐的方式来生成每个用户的密码。这个改的话都需要和业务方进行深入沟通，如果在项目刚启动需求讨论的时候就提出会很好，一旦项目起来了再改会比较困难。

0×05 内部安全

内部安全说两方面，一个是内部访问的一些系统比如XX后台，这种可以查看到敏感信息的平台。另一个讲一下人员的安全意识和办公网的安全。

第一是内部的平台，重要的内部平台也需要做安全日志对于一些高危规则做到实时的报警，如果没有 WAF 的可以使用脚本简单模拟一下，比如单位时间内调用登录接口等行为做一个报警，设计到修改金额的面板必须做到实时的记录。含有查看用户信息功能的平台需要记录使用者的操作日志，方便做到审计，和开发同学确认做好权限把控，要对这些平台做好安全保障。

对于数据库而言可以做蜜罐表，一旦有触发也立刻报警。内网可以部几台低交互的蜜罐挂着，

第二个是人员的安全意识，入职这家公司以后做的就是内部安全的提升，统计了下第三方对外的平台然后社工了下几个同学一个个破掉他们的帐号并发出邮件告知（授权行为进去截个图就可以了）。然后要求对所以外网的一些平台都要求二次认证。

内部的话每次新同学入职都会加入网络安全，给他们讲讲一些常见的诈骗方法提高自身的安全意识。还有一个，定期扫github上的代码，发现有自家业务代码的直接让他下线，有时候也可以发现一些竞品公司写的代码，厉害了。

0×06 总结

我把这一年半的东西都简单概述了下，总结了几点：

没有老板支持一切都是吹牛逼；从上往下推和从下往上推是两个概念；

先做最紧急的需求，全部解决以后再考虑可视化；东西丑不重要 关键是管用，东西再好看解决不了问题也是白搭；

必要时可考虑商业化产品/合作，如堡垒机，渗透测试等；

统计公司相关资源如外网IP,机器部署服务，别到了漏洞爆发在去问开发你的机器有没有部署XX服务；

做好外部控制别忘记做内控，有时候内部安全事件比外面攻击更可怕；

多和公司老司机聊聊天，你碰到的一些坑他们可能也遇到过，一些架构上的设计、冗余、优化方案都可以多找他们讨论下；

每个人的精力有限不可能什么都面面俱到，多和公司的老司机交流有些东西他们可能都接触过了，没事找他们吃吃饭交易交易会有意想不到的收获，比如告诉你Strom的任务优先级控制，架构的选型问题，机器学习的一些玩法等等。

在没有人力的情况下不要一味地模仿大公司的玩法，找到自己公司出现的问题并着手解决，必要的时候可以借助外部的力量（前提是你公司有预算）。

“你之所以看不见黑暗，是因为有人拼命把它挡在你看不见的地方。”向所有做安全的好同志致敬。（本文作者：LionZ 转载请注明来自FreeBuf.COM）