阅读： 104
文章目录
0X00 引言如果有时间请往下看看，或许会有“干货”
0X01 关于设备部署好吧，对于工程老司机来说，IDS的部署还能玩的出什么花样。是的，没有让各位失望，我也觉得确实没什么花样，但是我还是想说一说。
原则一：旁路部署肯定是没跑了，在纵深防御体系里最好是能部署在边界防火墙之后，WAF（如果有的话）之前。这样的位置可以使得IDS设备发挥最大的效能，又不至于浪费太多精力。 原则二：加密的流量肯定是检测不了的，确保给IDS设备的流量是解密过后的 原则三：流量是要双向的哦，因为很多规则的检测是需要依靠回包来判断的，如果部署的时候只给了单向的流量，到时候大量入侵行为无法检测到的时候就会很尴尬。以上都是关于IDS部署非常通用的基本准则了，本文当然不会止步于此。一般我们和客户在进行IDS部署方案的时候客户都会询问其他人是怎么部署的话，区域是怎么划分的等等。下面就说说金融行业在以上部署原则上一般还会遵循那些要求。
金融行业原则一：所有来自互联网的流量均应经过IDS检测进行安全防护，这里的互联网指的是客户通过互联网来访问对外提供的服务。 金融行业原则二：所有来自行外第三方合作单位的流量应经过IDS检测进行安全防护，这里的第三方一般指的是那些银行之间的结算，或者是各种三方支付之类的流量，这些流量一般都有专门的入口，不会从互联网的入口进入。一般会称做外联网 金融行业原则三：所有来自分行及其它区域访问数据中心服务器区的流量应经过IDS进行安全防护 金融行业原则四：入侵检测系统应能检测所有经过被检测边界的流量，通常情况下，选择网络数据流必经的网络关键节点进行部署。如果在每个区域都能找到核心的汇聚点的话当然最好。有些区域可能没有单一的汇聚点，可以在汇聚层找到几个能覆盖住整个区域流量的点也是可以的。 0X02 关于告警监控一般情况下对于一个金融机构来说，数据中心两地三中心基本是跑不了的，有的甚至是三地四中心这样的奢华套餐。
全网下来怎么也得十几二十几台IDS检测设备，每天告警量少了的也得上百万条告警。这样就给实时监控带来了很大的挑战。对于全网IDS告警集中监控，可以通过分层的方法，一步一步把我们关注的需要处理的告警剥离出来。
首先通过规则过滤，把我们不关注的告警信息先屏蔽掉，当前入侵检测领域的告警类别分为五大类：拒绝服务类攻击事件、获取权限类攻击事件、信息收集类攻击事件、可疑网络活动类事件、网络监控类功能事件。其中后三类告警类别的事件，在实时监控中并不是我们关注的重点，在实时监控中拒绝服务类和获取权限类的告警事件是我们重点要关注，并且需要处理的。如果仅仅是按照大类来区分，还是无法把告警事件的类型降低可管理的范围内，那么接下来我们可以采用仅关注或者仅不关注的机制来进一步的达到目标。
仅关注：只实时关注筛选出来的告警规则，没筛选出来的不实时关注。 仅忽略：只实时关注没有筛选出来的告警规则，筛选出来的不实施关注。这两种方法对于不同的场景会有不同的好处，举个例子。对于工作用的终端，我们既可以采取仅让用户安装那些软件来做限制，也可以采取仅不让用户安装那些软件来做限制。如果你能很容易的判断那些告警是你需要实时关注的，可以采取仅关注策略来过滤告警规则是很轻松的。如果你没有办法判断那些告警是需要实时关注的，但是你可以很明确的指出那些告警是非常确定不需要关注的，那么仅忽略的方法则更适合你。
接下来就可以更进一步的操作了。这里我想说的是，如果在你的网络环境中，还有WAF这样的设备存在的话，那我建议web相关的检测规则，类似sql注入或者xss这样的就直接忽略是最好的选择。毕竟这两类的告警误报率实在是太高了，既然有了专门针对web业务的防护设备，对于IDS这样针对系统和应用级的入侵检测设备，还是让它更专注的做它更擅长的事吧。毕竟漏洞利用类的告警检测对于IDS设备来说误报率还是极低的。
如果暂时网络中还没有WAF类产品，关于sql注入和xss类攻击也需要IDS来抗的话。这里就涉及到第二次过滤了
其实大家知道，对于sql注入或者xss类攻击主要的检测点在URL上的参数。因为研发同学在开发过程中不管是有意无意还是其他什么原因导致在传递参数的时候加入了很多符合攻击特征的内容，导致IDS设备在检测时候会出现“误报的情况”。针对这种情况当然最好的方式就是修改检测规则了，但是最好的方式有时候往往也是最坏的方式。因为这些特征是符合攻击特征的，如果把这些修改掉的话，一旦真的攻击来了的话就无法检测出来了。所以这个时候在我们的告警平台上再进行多一层的过滤，也就是上图中提到的黑白名单过滤。通过对sql注入和xss这类告警的url进行二次判断，来规避误报。具体灰名单的机制请见下图：
初始状态黑名单和白名单的池子是空的状态，所有告警全部报灰名单告警。通过梳理灰名单告警的URL去重，对筛选后的日志进行分析，判断是否是误报，如果不是误报，那么提取告警特征后更新黑名单，类似union 、group by之类的非常严重的特征直接更新到黑名单中。后需要有此类告警直接报黑名单。如果判断是误报的话，那么如果是非客户业务特征导致的，就要联系后台研发同事看是否可以对规则进行优化。如果是由于客户业务特性导致的，就需要通过和客户确认后进行白名单更新，后续再出现此类告警就不会实时弹窗提示，避免占用实施监控人员的精力来处理此类告警。
接下来就是告警处理了：
通过前两层的过滤后，这时候出现的告警基本上都是需要实时处理的了。毕竟IDS自己没有阻断功能，这是时候就需要配合防火墙来达到阻断的效果，类似IDPS的感觉，就是通过IDS和防火墙达到IPS的效果。
在平台上还需要创建一些封禁规则，这些封禁规则的主要元素就是，什么类型的告警在多长时间内达到多少条就达到封禁标准。一旦达到封禁标准系统就是自动提示，这个时候监控人员只需要确认一下是否封禁即可，当确认了以后监控平台会自动和防火墙联动进行IP地址的封禁，达到入侵防御的效果。
0X03 关于IP地址这一部分一般是大家很少和客户沟通的，至少在以前我在和客户讨论IDS实施方案涉及后续运维的时候事没有提到过的。但却也是想要做好告警分析很核心的一部。这一块涉及的主要是内外网IP地址的转换。说的直白一点就是IP地址业务映射表。不出意外在流量穿过防火墙或者负载均衡的时候都会进行地址转换。所以我们需要知道告警的目的IP地址对应的都是那些业务，尤其是外联网或者核心网区域，全部都是私网地址的情况更是多如牛毛，这个时候如果没有办法第一时间确定IP地址，可能无法有效的对告警进行分析确认。另外，很多时候，网络会对源IP地址也进行了转换。这个时候需要在IDS设备上开启x-forword字段的转换功能，不然看到的就全部都是内网IP地址，就没有办法进行封禁了。除此之外会有一种可能就是防火墙或者负载均衡设备在配置了地址转换后没有开启x-forword字段填充，导致IDS设备虽然开启了x-forword字段的转换功能但是在互联网区域还是偶尔可以看到源地址是内网IP地址的告警，这时候就需要有和网络确认修改相关配置的机制来确保配置的更新。
0X04 关于规则库更新大家都知道入侵检测设备是依靠规则库进行工作的，势必就会涉及到规则库升级的工作。一般情况下会有两种更新机制：
定时更新，根据设备规则库升级包的发布时间来（这个时间频率基本是固定的）。每当发布了规则库就进行升级。 不定时更新，这种方式并不向第一种一有规则库升级包就升级，而是对每次发布的升级包就行评估，更新的规则库插件是否是自己关注的，只有在自己关注的情况下才升级，如果更新的规则库升级包里没有自己关注的漏洞的话，则不进行升级。对于常规的设备升级，一般情况下建议都是放在晚上6点之后非业务高峰期进行。关于这一点不要问为什么，也不接受反驳。
除了以上常规的规则库升级以外，另外最常见的还是互联网高危漏洞爆发的应急升级。
一般在互联网高危漏洞爆发后，我们的研发会在8小时内紧急出升级包，在获取规则升级包以后进行设备的升级，并验证检测规则的有效性。在整个高危漏洞应急过程中，获取到规则升级包之前可以配合客户做一些业务取证方面的工作。在IDS设备升级完以后，则可以把精力更多的放到全网的漏洞摸底上面。
0X05 关于告警分析上面介绍了一些方法和手段使得我们可以实时的对有效的入侵告警进行检测和处理。那么非实时的告警该如何进行分析那？很多时候我们的同学在刚开始接触告警日志分析的时候都会出现一个问题就是面对一大堆告警不知道如何下手，不知道该做些什么。在我看来告警分析不外乎就是说清楚你面前的这些告警都是什么，是否可以分类，有哪些特征，以及最重要的是：为什么会是这样？的一个说明。下面就简单的分享几个思路：
每天的告警需要分类统计，进行趋势和对比分析。如果出现了指数级别的差异，则需要具体分析给出原因。可能的原因：遭受到扫描、攻击，又或者新增业务导致的大量误报等等。总之要给出一个合理的解释，需要具体问题具体分析。没有无缘无故的爱也不会有无缘无故的恨，一切皆有原因。 每类的告警需要分类统计，进行趋势和对比分析。如果出现了指数级别的差异，则需要具体分析给出原因。 每周的TOP10告警对比分析。旨在获取个性化环境中，不同告警规则的比重。对于波动比较大的需要重点关注。 每周TOP10源IP地址进行分析回溯（通过威胁情报平台来展开横向的调查），对于TOP10的目的IP地址进行重点脆弱性排查。以上是关于非实时告警可以进行分析的一些方向，如果有精力的话可以横向继续展开进行。如果精力有限的话，也可以先把实施告警的监控运营做好，非实时的告警分析可以慢慢足步的开展。相信我，深入下去你会发现很多有价值，有意思的东西。
0X06 关于设备部署优化当我们的设备将要或者已经处于一个高负荷状态下时，就应该考虑增加设备的数量，或者替换更高性能的设备了。这个工作可以每年年底的时候进行（一般年底前会计划第二年的采购相关事宜）。建议通过梳理客户的网络结构，业务情况来进行。比如说：客户的网络比较一年前发生了那些变化，业务情况发生了那些变化，流量情况发生了那些变化。结合我们设备的工作情况，给出一个具体的优化建议。新增的区域该增加多少设备，消失的区域可以替换下来多少利旧的设备。当前设备的性能是否还能良好的工作，以及估算后面几年业务流量的增加情况是否可以覆盖等等。给出具体的优化方案
0x07 最后写到这里，我才发现。对于IDS来说好像真没有太多值得的写东西。希望没有浪费大家太多的时间。
在整个纵深防御体系中，IDS设备处在防火墙之后，WAF之前。旁路接收解密后双向的镜像流量来检测系统级别的入侵告警。
可能在众多的安全设备当中，IDS设备算是在部署方面最“简单”不过的了。但是如何在一个庞大的网络当中合理的规划好逻辑区域，使得不同的IDS能刚刚好的检测各自区域的告警成为当前一个安全交付人员最大的挑战。因为如果区域划分的不好，势必就会出现不同区域的告警在同一台设备上，这时候单台设备的告警在分析的时候就会多了很多干扰的因素而失去本身区域所具有的代表性。
当我们把IDS设备部署到网络当中去，最重要的就是监控告警并且进行相应的处理。上面也讲到了通过各种手段和方法使得告警层层过滤，最终把有效的告警展现在我们面前，配合防火墙进行封禁。在这一步中设备的告警准确性就是我们最关注的了，通过特有的黑白名单机制把误报消除后可以让我们没有后顾之忧的处理那些黑名单告警。因为IDS设备是依靠规则进行工作的，所以需要按需就行规则库的升级。上面也提到可以定制升级，也可以不定时升级。具体方式也取决于不同客户的不同特点。
除此之外，我们还需要定时的对告警数据进行分析。当前网络安全领域什么最有价值，当然是数据了。守着每天几百万的告警数据，不进行分析的话，那可真实暴殄天物。上面也给大家分享了一些关于告警分析的思路以及原则，希望可以抛砖引玉。
当前面的我们都已经做好了，最后的最后就是涉及到整体IDS设备的部署优化了。只有做到对客户网络环境、业务环境、以及我们IDS设备的运行情况了如指掌，就可以根据具体的变换对IDS设备进行部署优化。真正做到从软件到硬件，从物理到逻辑的不断优化，不断提高。
最后，让我们共同期待，经过我们每个人实施过的IDS，在线上运行的每一分钟都发挥它最大的价值。
