从运维角度看企业安全响应

个人简介

@rootsecurity
JSRC  平台白帽子
Linux Geek
关注OPS安全，基础架构安全
欢迎交流 

大纲

背景
厂商应该考虑什么
思路
安全应急的定位
安全应急切入点
安全应急实施流程
应急案例分享
心得体会

厂商应该考虑什么

服务器密码OPS组/开发人手一份？
系统初始化脚本没有自杀？
用户/密码
配置
开发能登陆线上服务器？
那些容易被忽略的开源监控系统？
sql注入修复没有？
任意执行命令关闭没有？
默认密码是否改了？

安全应急响应思路

定位
责任人
(开发/运维/安全负责人)
响应
WooYun平台
处理
安全部门评估危害级别
紧急流程上线

安全应急响应思路

切入点
运维安全
nginx畸形(%00)解析漏洞？
tomcat manager-gui弱口令？
域传送？
…
代码安全
struts2 命令执行（S2-005,S2-008,S2-016/017）？
dedecms/phpcms/*cms  sql injection …？
phpmyadmin setup.php SQL Injection？
…

安全应急响应思路

运维安全
开启了manager的tomcat   tomcat-users.xml
   <xml>
<role rolename="manager-gui">
<user username="tomcat" password="tomcat" roles="manager-gui"/>
   </xml>
上传war后缀的木马
使用java自带的jar打包war木马
jar czf * xxxx.war

安全应急响应思路

安全检测中发现用的最多的密码
1qaz2wsx/1QAZ2WSX/1QAZ2wsx(^*_)
1234qwerasdfzxcv
123,./
111111
admin
…
Fuzz下…

安全应急响应思路

实施流程
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
追踪日志


定位黑客

应急案例分享

姓名：丁洪*
年龄：24-25
QQ：276***221
籍贯：贵州周边
邮箱：h4***r@163.com
住址：北京市海淀区三义庙****
我们没有查水表，也没有送快递  

应急案例分享

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

当当网的安全架构

IP流量
IDS入侵检测系统
HTTP流量
HADOOP日志分析
格式化入库
OSSEC主机AGENT
C/S架构的部署方式
结合rsyslog自定义RULES

当当网的安全架构

ossec+analogi(php+mysql)
elasticsearch+logstash+kibana 
suricata+base
snorby+mysql(ruby+mysql)
port scan (nmap+php+mysql)
cansina+shell

当当网的安全架构

心得体会

安全的误区
片面对待，只做业务或者只做基础
只要不出安全事故，就天下太平
看不到漏洞的威胁/影响
安全的理解
没有永远/一劳永逸的安全
关注业内动态
企业应急响应的要求
宁可信其有，不可信其无。
用渗透思路去铺设安全的道路

心得体会

安全是一个整体
保证安全不在于地方有多强大
而在于薄弱的地方在哪里
网络边界需要认真对待
杜绝因为方便而造成不必要的弱口令