8 31

应急响应浅谈

应急响应浅谈

应急响应及应急响应中心

应急响应是安全从业者最常见的工作之一(系统被黑后紧急救火,PDR模型-防护、检测、响应中的三大模块之一)。很多人可能认为应急响应就是发现服务器被黑之后,登录上去查后门的那段过程。 其实应急响应的完整定义为:组织为了应对突发/重大信息安全事件的发生所做的准备,以及在事件发生后所采取的措施

通俗地讲,应急响应不应该只包括救火,还应包括救火前的一系列准备。如果在工作中忽略了准备部分,可能会出现以下几种情况:

  1. 不具备基本的入侵检测能力,平时检测不到入侵事件,更谈不上应急响应了。有可能被入侵成功很久了却浑然不知,攻击者可能早就在达成目标后悄然离去了;
  2. 能检测到入侵事件,但没有专门的应急响应小组,资产管理系统也不完善,安全工程师花了很长时间才找到对应的负责人,因进入响应时间太晚,攻击者可能在达到目标并擦除痕迹后全身而退了,或者进一步把其他关联的系统一并拿下了;
  3. 平时无应急响应技能及入侵检测工具包的积累,接到事件的工程师登录到服务器上绞尽脑汁敲了几行命令后,最后得出『经排查安全的结论』给部门Leader与业务部门了,但真实情况是真被入侵并植入后门了。

现在各大厂商都成立了相应的安全应急响应中心(SRC),用来接收外部白帽子的提交的漏洞与威胁情报,虽然叫应急响应中心,但是这里提交过来的漏洞与情报不需要每次都启动应急响应,需要根据漏洞的类型、危害级别判断。

安全应急响应中心是对自己安全团队所做的安全保障工作的补充,如果SRC发现的漏洞与入侵事件比例很高,安全团队就该好好反思下安全工作为啥只治标不治本、频繁地被动救火了。

指导原则及方法论

应急响应是既紧急又重要的工作,对工程师的技术与意识都有一定的要求,比如很多安全工程师接到业务系统被黑的情报后,可能会联系业务负责人要到服务器账户,然后登录到服务器中检查被渗透的痕迹与后门。这段时间非常宝贵,反映太慢可能会使一些本来可以快速平息的安全小事件发酵成造成重大的损失安全事故。

  • 对于应急响应,首先要了解应急响应的指导原则与方法论,只关注技术的话,可能会本末倒置。

    因信息安全事件的种类和严重程度各有不同,应急响应的处理方式也各不相同,比如DDOS、业务系统被入侵、钓鱼邮件的应急响应方式与过程肯定是不同的,被业内广为接受的应急响应模型与方法论有PDCERF模型与ITIL中的事件管理问题管理模块。

  • 其次要求应急人员有较高的入侵检测能力,否则在排查被入侵的系统时,上去查了半天啥也发现不了,最后给出的结论是安全的。

    笔者在第一份工作时,部门老大要求在进行代码审计与应急响应等依赖人员技术和经验的工作时,必须采用双人Check机制,最后汇总对比结果,防止遗漏。 入侵检测需要检测的项目很多,最好能整理出相应的自动化检测工具自动给出报告,这样不但可以提高工作效率,还可以弱化对应急响应人员技术水平的依赖。

PDCERF模型

8 28

用Docker制作一个高交互ssh蜜罐

概述

实现一个高交互的SSH蜜罐有方式有多种:

  • 可以使用现成的开源系统,如kippocowrie等,
  • 可以利用一些SSH库做2次开发,如https://github.com/gliderlabs/ssh
  • 也可以用Docker定制

市面上已经有这么多开源的SSH蜜罐了,我为什么还要再造个轮子呢,理由如下:

  • 部署这些系统要安装一堆的依赖,运维部署成本较高
  • 想要的功能没法添加,不想要的功能也没法删减
  • 如果要支持多种高交互的服务,必须用一堆开源的系统拼凑出一堆服务来,每种系统的后端DB不同,数据结构也各不相同,无法统一处理
  • 自研的系统部署简单,服务可自由扩展,数据格式可自由定制和统一,方便运维与运营

技术架构

笔者在之前的文章《自制攻击欺骗防御系统》中介绍过完整的架构,整个系统由以下几个模块组成:

  • Agent端,部署于服务器中的Agent,用于实时获取用户的访问日志并传递到检测端Server中,如果是恶意攻击,则会将流量重定向到沙盒中。目前支持的服务有:

    • WEB
    • FTP
    • SSH
    • Rsync
    • Mysql
    • Redis
    • Mongodb
  • Server端,攻击检测服务器,实时检测Agent传递过来的日志并判断是否为攻击者,并为Agent动态、实时地维护了一份攻击者的来源IP策略

  • Mamager端,策略管理服务器,有为Agent和server提供策略、攻击log统计、查看的功能

  • 高交互蜜罐系统及守护进程,高交互蜜罐系统由docker封装的一些服务组成,守护进程负责把仿真系统中产生的LOG的数据格式化后再传给Server端进行攻击检测与入库

本文只讲SSH高交互蜜罐的实现。

1 31

github泄露巡航系统开发

概述

github敏感信息泄露一直是企业信息泄露和知识产权泄露的重灾区,安全意识薄弱的同事经常会将公司的代码、各种服务的账户等极度敏感的信息『开源』到github中,github也是黑、白帽子、安全工程师的必争之地,作为甲方的安全工程师,我们需要一套可以定期自动扫描特定的关键字系统,以期第一时间发现猪队友同事泄露出去的敏感信息。

积极响应开源号召的同学请开自己业余的项目,公司的产品代码、各系统账户属于公司的资产,擅自对外界公布属于侵犯公司的知识产权的行为,是违法的,造成后果严重者,不仅会被公司开除,还需承担相应的法律责任。

接下来我们一起来看看如何写一款github泄露扫描系统。

功能需求

虽然写代码可以一把梭,但一把梭之前需要先把要写的功能清单列一下,我们的github扫描系统会实现以下功能:

  1. 双引擎搜索,github code接口搜索全局github以及本地搜索例行监控的repos
  2. 支持对指定的用户、仓库、组织进行监控
  3. 提供WEB管理界面,支持规则管理(github搜索规则及本地repos搜索规则)
  4. 支持github token管理和用户管理
  5. 扫描结果审核

已经完成的项目的地址为:https://github.com/xiaomisec/x-patrol

1 4

设计灵敏的蜜罐传感器

设计灵敏的蜜罐传感器

以前我写过一篇蜜罐设计的文章自制蜜罐之前端部分,https://xsec.io/2016/7/8/how-to-develop-a-honeypot.html,这个蜜罐的传感器实现的原理是设置iptables的LOG指令,将NEW,ESTABLISHED,RELATED三种状态的连接信息记录到syslog中,然后再通过rsyslog的转发机制发送到蜜罐server中进行检测:

exec.Command("/sbin/iptables", "-t", "nat", "-A", "HONEYPOT", "-p", "tcp", "-m", "state",
        "--state", "NEW,ESTABLISHED,RELATED", "-j", "LOG", "--log-prefix", "iptables_honeypot").Run()

tips:iptables的几种状态

ESTABLISHED:表示包是完全有效的,而且属于一个已建立的连接,这个连接的两端都已经有数据发送。
NEW:表示包将要或已经开始建立一个新的连接,或者是这个包和一个还没有在两端都有数据发送的连接有关。
RELATED:表示包正在建立一个新的连接,这个连接是和一个已建立的连接相关的。比如,FTP data transfer,ICMP error 和一个TCP或UDP连接相关
INVALID:表示这个包没有已知的流或连接与之关联,也可能是它包含的数据或包头有问题

这个蜜罐的弊端是只能检测到有状态的扫描尝试,比如对Server端支持的服务的攻击尝试,对于server端没有监听的端口的扫描尝试,传感器是检测不到的。于是笔者打算把数据捕获模块更换一下,用sniff本地网卡的方式替换掉以前的iptables的LOG指令。

实现原理

利用libpcap库监听本地指定网卡的数据,先过一次白名单,将白名单中的数据忽略,将不在白名单中的的IP 五元组信息通过http的方式发到server端进行检测、报警。

使用libpcap抓包的前置条件是安装并设置数据转发

# centos
yum install -y libpcap-devel
# Debian/Ubuntu
sudo apt-get install -y libpcap-dev
# OSX
brew install libpcap

# OSX
sudo sysctl net.inet.ip.forwarding=1
# FreeBSD
sudo sysctl -w net.inet.ip.forwarding=1
# Linux
sudo sysctl -w net.ipv4.ip_forward=1
pager.prev pager.next