中小企业如何部署入侵检测系统？

Posted 2023-04-25

随着网络技术的快速发展，如今的网络安全不再仅仅是靠防火墙或者个别安全社设备就可以完全抵御的，攻击手法和方式的多样化势必要求网络安全产品整合，协同工作。防火墙、杀毒软件、安全策略早已被大多数用户纷纷采用的，更出现了IPS、IDP等高端的安全产品，但笔者以为其实就中小企业而言入侵检测系统更能满足用户的需求。笔者始终认为，只有掌握了恶意软件或行为后，对症下药会更好的解决用户所遇到的威胁。 入侵检测的用途 虽然入侵检测系统(Intrusion Detection System，IDS)早已不再是什么神秘的神兵利器，但却可以在恶意行为发生时及时通告用户，此种检测手段非常适合于在防火墙的基础之上部署在中、小企业中，甚至对于要求更严格的大型企业网络也是适用的。现在用户都清楚一个事实，一台普通的计算机是以安装防火墙的方式来进行访问规则的设置，而对于企业网络来说，这是远远不够的。此时相对更加昂贵的IPS或IDP设备，入侵检测系统IDS已经可以胜任网络防护的重任，管理员只要留意网络通信的异常和警告稍加分析就可以判断是否有恶意行为的发生。通常笔者在实施企业级应用时，首先会考虑企业的实际需要，而IDS不论对于何种规模的网络都是适用的，IDS是建立在防火墙基础之上的一种很有效的防护手段。 入侵检测适用范围 虽然IDS和IPS之间的争论已经了结了很久，但是仍有不少用户在选择安全产品的时候存在错误或者说是模糊的概念。有人说IDS和IPS目前只适用于中大型网络，对于只有小型网络和若干IT工作人员的中小型企业来说，大型IDS入侵检测系统造价偏高而且还得投入工作人员全天候进行监控，相对来说并不划算。因此很多小型企业只能利用防火墙对其实现安全防护，这显然是不够的，这让很多入侵行为无法被防火墙及时发现并造成损失。曾经笔者在为一家中小企业处理做应急方案的时候就发现，由于防火墙自身规则的限制，使得企业无法防范来自内部的威胁，困此小型企业可以尝试使用小型网络产品或者利用外包商们专为中小型企业提供的检测和预警服务，在防火墙产品以备或防火墙无法满足现有安全需求时完善企业的安全机制。但是笔者还是强调任何设备都不是万能的守护神，而IDS应该是多层防御系统的一部份，这个防御系统中最重要的还应是安全管理。 如何部署入侵检测系统 如果企业在已拥有防火墙基础之上部署入侵检测系统，应首先评考虑目前的网络规模和范围以及需要保护的数据和基础设施等，由于IDS只是一种安全硬件，而且由于IDS在行为检测过程中可能会占用比较多的资源，这对于一个极小的网络来说会成为很大的负担，甚至会影响网络的使用性能。用户只有根据自身的需求进行评估后，才可以对相关的IDS或IPS进行评测考证，随后才能讨论IDS如何融入现有的安全策略中。 在小型企业中，配备好一个处理能力良好的防火墙会比完备的IDS更好控制，但是防火墙只能阻止已经被限制网络通信，并不能起到很好的防护效果。而对于IDS来说可以记录不必要的通信量，虽然有时不进行阻止，但在记录中发现不明规则的同时，可以利用防火墙新建策略对其进行阻止访问，所以防火墙与IDS是功能互补，相互依赖的。 通常恶意行为在入侵一台服务器时会先侵入较低保护的系统，然后通过提权获得更高的权限直至达到入侵目的。因此用户考虑是否部署IDS产品前，应对目前服务器中存储的信息进行风险分析，不仅要考虑数据安全性，也要考虑系统结构和低风险系统到高风险系统的可侵入性。 如果仅靠IDS是不会达到很好的防护效果的，用户要想IDS对网络起到很好的保护，那其设备必须安装在防火墙的两边以及网关处，让其检测无论是内部的还是外部的所有通信量，并将不同网段的检测结果进行对比，那样才能确定攻击的来源或者试图入侵的恶意代码。而对于内部攻击，可通过IDS入侵检测系统对内部网段可疑活动的检测，找到病源。当然IDS可能会产生误报，管理人员可以从恶意程序试探网络的通信数据中找到入侵的路径。 总结 随着黑客技术的提升，使得安全技术和产品必须更快的发展，以应对网络各种胁威。 参考技术A 　　如果企业在已拥有防火墙基础之上部署入侵检测系统，应首先评考虑目前的网络规模和范围以及需要保护的数据和基础设施等，由于IDS只是一种安全硬件，而且由于IDS在行为检测过程中可能会占用比较多的资源，这对于一个极小的网络来说会成为很大的负担，甚至会影响网络的使用性能。用户只有根据自身的需求进行评估后，才可以对相关的IDS或IPS进行评测考证，随后才能讨论IDS如何融入现有的安全策略中。
　　在小型企业中，配备好一个处理能力良好的防火墙会比完备的IDS更好控制，但是防火墙只能阻止已经被限制网络通信，并不能起到很好的防护效果。而对于IDS来说可以记录不必要的通信量，虽然有时不进行阻止，但在记录中发现不明规则的同时，可以利用防火墙新建策略对其进行阻止访问，所以防火墙与IDS是功能互补，相互依赖的。
　　通常恶意行为在入侵一台服务器时会先侵入较低保护的系统，然后通过提权获得更高的权限直至达到入侵目的。因此用户考虑是否部署IDS产品前，应对目前服务器中存储的信息进行风险分析，不仅要考虑数据安全性，也要考虑系统结构和低风险系统到高风险系统的可侵入性。
　　如果仅靠IDS是不会达到很好的防护效果的，用户要想IDS对网络起到很好的保护，那其设备必须安装在防火墙的两边以及网关处，让其检测无论是内部的还是外部的所有通信量，并将不同网段的检测结果进行对比，那样才能确定攻击的来源或者试图入侵的恶意代码。而对于内部攻击，可通过IDS入侵检测系统对内部网段可疑活动的检测，找到病源。当然IDS可能会产生误报，管理人员可以从恶意程序试探网络的通信数据中找到入侵的路径。

赛克蓝德日志分析软件(SeciLog)15年总结

    需求

    随着现代化企业的发展，企业对信息化的依赖程度越来越高，企业为了保障业务正常运行，需要部署大量的设备和软件系统：包括防火墙、入侵检测、扫描器、堡垒机、监控、OA、ERP、业务系统等；根据每家企业的情况不一样，部署的产品也会不一样，有用商业软件的，也有用免费软件的，甚至是开源软件的，可谓五花八门。在部署这么多系统后，会带来很多新的问题，常见的问题有如下几条：

•  每个系统都会有自己的界面，都有自己的告警，都有自己的报表，面对这么多的系统，对运维管理带来很大的挑战。

• 每个系统都是从自己的视角来看待问题，功能上相对独立，缺少融会贯通的能力，每当遇到问题的时候，需要从一台台设备中去登录，然后查看相关日志，效率低下。

• 每个系统中的日志格式都是不一样的，各有各的表达方式，就算同一件事情，表达的内容也是不一样的，这就给人员带来很大的困惑和学习成本。

• 每个系统中每天会产生大量的告警，企业中的运维人员相对较少，这就使很多的日志没有时间去查看，给系统的运行带来很大的隐患。

• 当一件事情发生的时候，在很多的系统中都有体现，但每个系统又相对对立，导致大量的重复告警，无法进行跨产品的事故分析。

• 每个系统的磁盘都是相对固定的，每当磁盘空间不够的时候，很多运维人员想到的第一件事就是删除日志，这就导致日志的丢失，万一发生问题，对事后的追溯和取证带来很大的困难。

• 企业中有不同岗位的人员，包括开发人员，运维人员，管理人员等等，每种人员对日志的要求是不一样的，开发人员更多的时候关注开发中遇到的异常日志，运维人员关注的是系统的告警日志，管理人员更多的是关注的业务日志。面对这么多的需求，现有的这种堆积木的方式很难满足。

    设计思想

        面对企业中这多问题的时候，我们就在思考如何解决这些问题。对于软件的使用，我们提出了极简原则，就是要让产品尽量的简单，包括安装简单，配置简单，使用简单，最好都是傻瓜式的，简单配置甚至不需要配置就可以使用的，但功能还要必须强大的。于是我们提出了两个集中，四个统一的设计思想。

• 集中收集：集中收集个系统中时时产生的海量日志；

• 集中存储：集中存储在一个可管理的分布式系统中；

• 统一查询：对各种日志提供统一的查询入口和规则；

• 统一分析：对收集上来的日志进行统一的分析；

• 统一预警：对日志进行时时关联分析，统一进行预警；

• 统一展示：对所有日志提供统一的展示方式。

    架构

    为了支撑我们的设计思想，我们对技术选型做了大量的研究。

    开发语言的选择，这块没有好坏之分，只是我从事了十几年的java开发，比较熟悉，所以选择java作为开发的语言。其次是技术的框架的选择，现在的产品开发很多时候不需要从头开发，要站在巨人的肩膀上做事情。

    框架的选择：java语言可选择的框架比较多，目前在日志领域最常用的流派有两组，一个是elasticsearch +logstash +kibana简称elk，一个是flume+kafka+storm。这两个选择都有大量的用户使用，也有各自的有点，在此不做过多的评价。但我个人认为这两种组合都有一个共同的缺点就是复杂，首先都是有几个组件，每个组件相对对立，通过不同的配置进行整合，需要经过多次下载、配置、整合、测试、使用，根据个人能力不同，少则一两天多多则一两周才能把环境搭建好，但这仅仅是第一步，后面的学习、使用、维护、开发都需要花费大量的时间和精力。根据我们自身的积累我们最终只选择了elasticsearch作为我们存储和搜索的核心组件。对日志采集分析和展示部分，我们自己进行了开发。

    最终的架构是我们自己的collect+elasticsearch+web，作为我们自己的主要技术架构组合，从最终的产品使用效果来看，我们的产品对大多数有一定经验的运维人员半个小时可以把环境搭建好，并可以使用。

    日志处理过程，系统先经过不同的协议收集，然后都日志进行格式化处理，接着是入库，最后是对日志进行关联分析，产生告警。

    主要功能

• 日志采集：系统能够支持多种协议进行日志采集，系统内置Syslog server、SNMP Trap server、FTP server、SSH client、Sftp client、ftp client、Oracle client、Mysql client、web upload。这些所有的能力来源于java丰富的库。

• 日志的格式化：这一部分是产品的核心功能，既要简单又要好用，所以抽象出了很多的维度，目前我们抽象出来的维度高达五十多个维度。 对常用日志格式的我们做的大量的适配工作，目前支持常用的标准日志，包括Linux、Windows、Ftp/Sftp、Nginx等中间件的标准日志、IIS的日志；我们还通过插件支持性能采集、Sniffer Mysql、Sniffer Http协议，Inotify文件修改的审计。对这些日志我们都做了很好的匹配，做到了开箱即食的效果，所以你不用关注这些是怎么实现的，极大的简化了产品的使用。

• 日志的分析：我们对预警的模型作了很多的抽象，我们可以分析单条事件的行为，多条事件的行为，先后事件的行为；我们还即将支持基于统计的日志分析和基于智能学习的日志分析。通过这些大量的模型，我们可以很好的支持业务、运维和安全的关联分析。再次我们举个例子来说明我们关联分析的效果。在做运维的都知道，cpu利用率是个很常用的指标，但这个指标比较敏感又和业务有一定的关系。那我如何来判断cpu利用率过高呢，我们希望的告警规则如下：在早上七点到九点之间，在连续的5分钟内cpu利用率超过80%5次以上，在其他时间，在连续的5分钟内cpu利用率超过60%5次以上进行告警。这是一个很实用的告警规则，但据我所知，能完成这种告警的产品不多，主要集中在几个大的siem品牌中，但他们的产品价格很高。

• 日志存储：我们基于比较新版本的elasticsearch进行开发，在使用到的api中我们基本上使用了最新的接口，这些接口在elasticsearch最新的2.1版本中继续支持，杜绝了产品废弃的接口，这些接口在官方的手册中明确提出在2.X版本后将废弃。这样我们的产品就很容易的升级到最新的版本中。

• 日志搜索：由于采用了elasticsearch，我们对日志搜索支持全文搜索，这些就像搜索引擎搜索一样方便。同时只是不同维度的精准搜索，都常用搜索可以保存起来进行下次的快速搜索。支持在搜索中直接查看IP的地区。对不同的维度可以自定义在列表中是否显示，极大的方便个性化的查看。

• 内置报表：系统内置常用的很多报表，包括WEB报表，防火墙报表，会话审计、登录报表等，对这些报表都支持二级甚至三级钻取功能，系统同时还支持自定义报表，基本满足大多数的需求。

    展望

    日志分析产品我们从15年4月份第一个版本上线到16年一月中旬，系统共升级了22个版本。极大的丰富了产品的内容，但由于时间比较短，很多地方做的不够精致，所以16年会对产品的友好性，稳定性方面继续加强。同时对产品的功能继续增加，包括基线检查、配置管理、单点登录这些运维中常用的功能进行扩充。同时会增加智能分析学习的能力。这样就更加增加产品统一管理的能力。