从运维角度看企业安全，从安全的视角看业务风险。

0x01背景

• 安全应急的定位
• 安全应急切入点
• 安全应急实施流程
  0x03心得体会:

定位：

责任人(开发/运维/安全负责人)

响应：

各大响应平台

处理：

安全部门评估危害级别

紧急流程上线

0x0303切入点：

运维安全：

nginx畸形(%00)解析漏洞？

tomcat manager-gui弱口令？

域传送？

代码安全：

struts2 命令执行？

shiro反序列化？

weblogic？

dedecms/phpcms/*cms sql injection等等的cms通杀？

phpmyadmin setup.php SQL Injection？

开启了manager的tomcat tomcat-users.xml

上传war后缀的木马

使用java自带的jar打包war木马

jar czf * xxxx.war

安全检测中发现用的最多的密码

admin/123456/admin123/123123/1qaz2wsx/1QAZ2WSX/1QAZ2wsx(^*_)/1234qwerasdfzxcv/111111

这样我们可以收集到自己的fuzz脚本中

0x004实施流程：

All of domains，包括主域名以及其他域名和子域名

注意公司出口，二级运营商互联出口

注意系统内核能否被提权

注意dig/nslookup的记录，特别是MX，TXT，NS

任何情况下不要随便用root/system启动任何服务

某些部门是否用rsync，puppet，salt等危险工具

某些部门是否在有公网ip的测试机上放一些demo程序

某些部门是否钻一些空子恶意利用端口白名单

dig demo.com TXT

“v=spf1 ip4:x.x.x.0/25 ip4:x.x.y.0/25 ip4:x.y.x.0/24”

“v=spf1 include:spf1.mail.demo.com –all”

dig demo.com NS

dig demo.com MX

例行扫描发现奇怪路径，目测为webshell

问题现象

分析/论证

溯源反制

连接shell的ip每次都不同

系统安全检查截获webshell

追踪日志

定位黑客（攻击者）

系统截获反弹端口的Perl脚本

0x005安全布防：

IDS入侵检测系统

IPS入侵防御系统

终端安全防护平台

waf防火墙/下一代防火墙

全流量威胁感知系统

等等等等.........  不是买盒子的（三沐），没有条件的朋友可以翻翻三沐以前推荐的开源基础防护能力等同商业化产品的部署文章。

0x006心得体会：

安全的误区

片面对待，只做业务或者只做基础

只要不出安全事故，就天下太平

看不到漏洞的威胁/影响

安全的理解

没有永远/一劳永逸的安全

关注业内动态

企业应急响应的要求

宁可信其有，不可信其无。

用渗透思路去铺设安全的道路。

安全是一个整体

保证安全不在于地方有多强大

而在于薄弱的地方在哪里

网络边界需要认真对待

杜绝因为方便而造成不必要的弱口令

杜绝测试期间开放的端口在网站正式上线的时候不关闭

杜绝测试期间开放的测试接口，测试账号等等的点位在正式上线的时候不关闭

杜绝采用旧版本的服务版本等等

原文始发于微信公众号（三沐数安）：从运维角度看企业安全，从安全的视角看业务风险。