应急响应技巧(前篇)

应急响应 2018-08-19

此篇主要是写一些自己在平时应急响应过程中遇到的一些安全事件中,总结的一些安全实用技巧。目前内容不是很多,实用主义至上,会不断补充新的内容。同时也会在后期补充一篇对应的安全加固文档。


作者:古月蓝旻

SSH弱口令篇

SSH弱口令导致系统沦陷在实际的环境中是非常常见的:
无论是使用常规方式暴力破解或者使用社会工程学字典,都可能完成对目标系统进行暴力入侵

顺便一提:如果是私钥文件泄漏造成的入侵会较为隐蔽,但亦可通过登录IP信息辅助判断

排查的时候,思路有以下几点:

系统命令

成功登录的记录看:last

里面会记录登录的用户、终端、源IP、登录时间、登录时长等信息,最近的登录信息会显示在最上方

失败登录的记录看:lastb

那么暴力破解的主要来源IP其实看这个就足够了

日志文件

一般看的日志文件为/var/log/secure

但是这个文件中记录的内容太多,我们需要一些小技巧辅助一下

一般secure文件是每周保存一次,一般保存当月的文件,如我上图所示,因此排查的时候,如知道暴力破解大致的时间可以直接去对应文件中查找,提高效率。

而查找的时候有以下关键字辅助我们

authentication failure:登录失败记录
Accepted password:密码方式登录成功记录
Accepted publickey:密钥方式登录成功记录

批量查找登录失败记录

cat /var/log/secure* |grep "authentication failure"

批量查找密码方式登录成功记录

cat /var/log/secure* |grep "Accepted password"

批量查找密钥方式登录成功记录

cat /var/log/secure* |grep "Accepted publickey"

一般这两种方式足以发现暴力破解攻击的登录用户、登录IP、登录时间时间等信息,前提是/var/log/secure,/var/log/wtmp等日志文件未被清除

SSH登录执行命令篇

一般攻击者入侵后,稍微谨慎一些的会在走的时候执行history -c命令清除自己的一些入侵痕迹,或者直接来一波export HISTSIZE=0不记录历史命令,关于history的更多技巧参见bash魔法堂:History用法详解

总之这种情况有时候会比较令人尴尬,但是也有一些技巧辅助以下
比如用户家目录下的隐藏文件.bash_history偶尔就能帮助我们排忧解难

/root/.bash_history
/home/user/.bash_history

如果攻击者一时不察忘记删除,我们还可以通过这些文件了解攻击者的所作所为

以及如果攻击者一开始只获取了普通权限帐号,通过提权方式获得root权限,临走时只删除了root下的操作,我们就可以从这个普通权限帐号的.bash_history中发现一些端倪

webshell篇

webshell方式获取目标站点相关权限在日常生活中也是比较常见,而此类入侵排查的思路往往是通过web服务器日志进行排查

  1. 确认目标服务器上的中间件种类:咨询客户或查看进程、端口
  2. 查看该中间件的配置文件,找到web目录和日志保存路径
  3. 确认webshell文件:咨询客户或自查

如果在web目录下找到了webshell文件,先使用stat命令查看该文件进入服务器的时间

然后查询对应web日志中,该webshell文件的访问记录判断攻击IP、上传时间。若该webshell使用GET方式执行命令还可以在记录中查到该webshell的具体操作,对该webshell频繁访问的IP大概率为攻击者IP

若最后攻击者删除了webshell,在web日志保留的情况下还是可以查到攻击者的相关信息,并结合该webshell第一个访问记录的上下文,大致可以判断何处为该web中间件的上传点,从而发现入侵途径。

redis篇

redis未授权访问漏洞作为前段时间非常火的攻击一直备受入侵者喜爱,由于redis的默认配置,redis绑定在0.0.0.0上,也就是面向全网开放,一旦攻击者发现即可通过redis的写权限添加crontab反弹shell或者~/.ssh/authorized_keys方式拿下系统,而redis往往运行权限比较高,因此拿下redis系统很容易就沦陷。

关于redis入侵的思路和文章参见小伙伴的一篇文章Redis未授权访问详解

那么针对redis有何排查思路呢?

  1. 确认目标主机上的redis运行用户、进程和端口信息,尤其关注端口处绑定IP是否为0.0.0.0
  2. 自己使用redis-cli -h ip -p port的方式,结合info命令看看是不是有结果,当然如果是弱口令也会被入侵使用-a命令后面可以跟着口令
  3. 查看/etc/redis.conf文件,看看#requirepass 一行是否启用了密码或口令是否为弱口令
  4. 查看/root/.ssh/authorized_keys中是否追加有特殊的记录
  5. 查看/var/spool/cron/user下是否有反弹shell的命令

mysql篇

mysql的问题也是在弱口令上,且mysql默认情况下可以使用system命令来执行系统命令,也算是入侵者比较喜欢的一种入侵方式

排查思路如下:

  1. 确认目标主机mysql的运行用户、进程和端口信息尤其关注端口处绑定IP是否为0.0.0.0
  2. 使用mysql -uroot -p空口令方式看能否直接登录,或者咨询客户是否为弱口令,进入之后看能否执行system命令
  3. 若为强口令,咨询客户或排查服务器中是否将mysql连接信息明文保存在相关配置文件中,考虑配置信息泄漏的可能
  4. 查看/etc/my.cnf配置文件,查看mysql错误日志的保存位置,有时其中会记录登录失败的记录

此为应急响应前篇,后篇会补充如struts2、weblogic、tomcat等java反序列化漏洞入侵排查的相关思路和方法。


本文由 古月蓝旻 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

还不快抢沙发

添加新评论