摘要：最近了解了一些通过日志审计去实现检测网络入侵的方法，并且结合了自己能够接触到的东西提出一些常见的思路。

通过日志审计去对抗网络入侵确实是一个很直接也是个人感觉比通过流量分析等手段更有效的方法。

这里说的日志审计不是针对某个应用，而是把应用运行的系统包括在内。

日志审计的优点

第一：不用去考虑加密，解密。因为相比应用层，从流量上面也就是网络层上去抓ip数据包分析，不会吧不会吧，这都啥年代了还用明文传输，写个简单的加密解密又不会死。
第二：能够很详细的去统计出具体的应用运行的具体情况。比如说当nginx日志显示有个ip短时间大量访问同一个网页，这种就可以作为一个入侵特征
了。再比如说有人在爆破目录，必定产生大量404，又能够作为一个特征。

日志审计的缺点

第一：适配问题。不同的linux系统比如centos和ubuntu下的同一个应用输出的日志格式有差异，肯定要去针对一个不同版本的系统做不同的规则库。
第二：配置问题。日志审计高度依赖于应用自身的配置。比如nginx或者mysql，默认的日志都是要配置才有的，有的工作人员简单的安装上就完事了，根本没日志输出。
第三：有的应用也不能说流氓，日志直接内置展示，根本不给你接口导出日志，对付这种软件又是个问题。

---

下面是一个自己构想的针对ubuntu系统的网络入侵检测的实现（本人对centos无感），本着越简单粗暴的越可靠的原则构想。

现在主流的IDS其实核心都是两点：一个是针对流量的大小（比如：对流量自学习，平均出每天每个时间段的流量大概是多少，超过一定阈值就报警），一个是针对流量的内容（比如去根据特征库去匹配流量的特征，在端口镜像流量的情况的我感觉效果也就那样，应该是获取不到流量的具体内容的，不然要各种加密工具和隧道干嘛）。

在主机上以软件安装的形式IDS我没见过，360终端安全管理之类的应该不能划归到IDS之类吧。

首先设计一个IDS主控，然后在每台物理主机上面部署类似探针的东西，探针会定期向主控去发送消息，感觉把对日志解析的规则库放到探针上面，由探针以json的方式把每台主机的运行情况反馈给IDS会好点。

主控要实现的功能：

第一：主控位于流量的总入口，对全局起一个统计的作用，比如上面说的对流量的大小，流量特征的检测，。还有对本地的某个文件进行监控，当一个文件长时间没有改动过，然后突然被改动了，就报个警。
第二：主控上面要显示各个探针的状态，要能够调节探针的配置，并且下发给探针。

探针要实现的功能：

第一：识别不同的系统版本和应用版本。这样的话对规则库的实现会简单一点。
第二：监控每个应用的日志，观察日志里面是不是有恶意特征（再比如windows日志里面是不是出现大量4625事件），有的话就把事件上报为IDS主控。
第三：监控每台主机的网络连接情况。比如按照作用域来划分，应用域（所有给用户提供服务的主机）、用户域（所有用户的主机）、dmz域（比如在内网搭建的镜像仓库）。
当发现用户域里的某一个用户和其他用户连接过多，是不是在扫描。
内网环境下当发现应用域和用户域跟外网出口有网络连接，是不是被当成跳板了。当平常某个常见端口一直没被用过，突然接收到了连接，这个是不是入侵。
第四：监控每台主机的资源使用情况。比如cpu是不是过高了是不是可能被挖矿，然后进一步判断有没有和某些知名的矿池相连接。

总而言之要实现的功能：首先对攻击进行检测，检测不到被入侵后要及时防止数据外传。至于勒索病毒之类，正儿八经的隔离网，只要内网和外网的文件管控做的好，一般来说没什么大问题，保持更新的360对于这些东西大爷还是大爷。