虽然现在的网站安全防护技术已经得到了很大的提升，但是相应地，一些网站入侵技术也会不断地升级、进化。如何建设网站，因此，企业在进行网站建设管理的时候，一定不可以轻视网站安全这一块，建议企业周期性、长期性地用一些基本方法来检测企业网站的安全性，确保网站顺利、正常地运营下去。
开源IDS系统有很多种，比较有名的系统有Snort、Suricata、Zeek等，我们选用Suricata是因为Suricata有多年的发展历史，沉淀了的各种威胁检测规则，新版的Suricata3与DPDK相结合，处理大级别的数据分析，Suricata支持Lua语言工具支持，可以通过Lua扩展对分析的各种实用工具。
Suricata与Graylog结合的原因，是因为在Graylog开源社区版本对用数据的数据处理量没有上限限制，可以扩展很多的结点来扩展数据存储的空间和瞬时数据处理的并发能力。Suricata在日志输出方面，可以将日志的输出，输出成标准的JSON格式，通过日志脚本收集工具，可以将日志数据推送给Graylog日志收集服务，Graylog只要对应创建日志截取，就可以对JSON日志数据，进行实时快速的收集与对日志数据结构化和格式化。将JSON按Key和Value的形式进行拆分，然后保存到ElasticSearch数据库中，并提供一整套的查询API取得Suricata日志输出结果。
在通过API取得数据这种形式以外，Graylog自身就已经支持了插件扩展，数据面板，数据查询前台，本地化业务查询语言，类SQL语言。通过开源IDS与开源SIEM结合，用Suricata分析威胁产生日志，用Graylog收集威胁事件日志并进行管理分析，可以低成本的完成威胁事件分析检测系统，本文的重点还在于日志收集的实践，检测规则的创建为说明手段。
Suricata经过多年发展沉淀了很多有价值的威胁检测规则策略，当然误报的情况也是存在的，但可能通过手动干预Surcicata的规则，通过日志分析后，迭代式的规则，让系统随着时间生长更完善，社区也提供了可视化的规则管理方案，通过后台管理方式管理Suricata检测规则，规则编辑本文只是简单介绍。Scirius就是一种以Web界面方式的Suricata规则管理工具，可视化Web操作方式进行管理Suricata规则管理。

在安全运营工作当中，经常需要系统日志、设备威胁事件日志、告警日志等，各种日志进行收集汇聚，具体分析，通过日志来分析威胁事件发生源头、相关联的人和资产关系，以日志数据的角度，来追究溯源威胁事件发生的过程和基本概括原貌。评估威胁事件产生危害的影响范围，关联到人与资产，采取顺藤摸瓜，将各种信息进行关联，无论是二维关系数据联系关联，还是大数据分析建模，数据的分类采集都是基础工作。
企业安全相关的各种日志数据，存放的位置、形式、大小、业务、使用人群都不同，如何根据不同业务规模的日志数据，采取相得益彰的技术形式进行合理的日志、聚合、分析、展示，就成为了一个课题，接下来，我们主要围绕这些相关的主题进行讨论分享，通过具体的日志聚合分析实践，让数据有效的关联，使其在威胁事件分析、应急事件分析响应过程中让数据起到方向性指引作用、起到探测器的作用，通过以上技术实践，让更多日志数据，有效的为企业安全运营提供更好的服务。
在实际工作当中，日志聚合分析工具种类繁多：ELK、Graylog、rk、Clickhouse、Superset等工具。我们以常用的日志数据使用场景为例子，结合这些工具的使用，向大家展示在实际数据工作中数据运营的情况，如何进行数据聚合分析，以提供实际的操作案例，能能直观的了解数据管理的工作流程，之后可以重复实践，不绕道走远路，着重给出日志分析工具使用的要点，快速上手掌握相关工具的使用，掌握日常日志数据实操及相关方法。
为了方便实践，尽量避免商业系统和设备在案例中的出现，以可以方便取材的开源项目为基础，展开案例的讲解，大家可以容易的在网上取材这些软件系统，在本地完成实践练习过程。本篇介绍入侵检测系统Suricata及威胁日志事件管理系统Graylog，通过对入侵检测系统的日志进行收集，来展现日志收集处理的典型过程。
开源IDS系统Suricata与威胁事件日志管理平台Graylog结合，对网络环境进行截取与日志收集分析统计，通过Suricata捕获输出的日志，经过Nxlog日志收集工具，将相关事件日志、告警日志、HTTP日志，通过Graylog进行日志聚合，对日志进行统计分析，分析网络环境中存在各种威胁事件类型，通过自定义Suricata的检测规则，控制入侵检测的策略，以及入侵检查系统的输出结果。

讨论回顾完上次整改的问题之后，理清了思路。然后我登录了网站查看一下原因，因为网站只有一个上传图片的地方，我进行抓包尝试，使用了repeater重放包之后，发现返回包确实没有返回文档上传路径，然后我又尝试了各种绕过，结果都不行。后苦思冥想得不到结果，然后去问一下这个云平台给他们提供的这个告警是什么原因。看了云平台反馈的结果里面查杀到有图片码，这个问题不大，上传文档没有执行权限，而且没有返回文档路径，还对文档名做了随机更改，但是为啥会有这个jsp上传成功了，这让我百思不得其解。
当我仔细云平台提供的发现webshel数据的时候，我细心的观察到了文档名使用了base编码，这个我很疑惑，都做了随机函数了还做编码干嘛，上次测试的时候是没有做编码的。我突然想到了问题关键，然后使用burpsuite的decoder模块，将文档名“1jsp”做了base编码成“MS5Kc1A=”，然后发送成功反馈状态码200，再不是这个上传失败反馈500状态码报错了。
所以，这个问题所在是，在整改过程中研发人员对这个文档名使用了base编码，导致文档名在存储过程中会使用base解析，而我上传文档的时候将这个后缀名.jsp也做了这个base编码，在存储过程中.jsp也被成功解析，研发没有对解析之后进行白名单限制。其实这种编码的更改是不必要的，毕竟原来已经做了随机数更改了文档名了，再做编码有点画蛇添足了，这就是为啥程序bug改一个引发更多的bug原因。

其实从开发的角度，如果要保证代码至少在逻辑方面没有明显的漏洞，还是有些繁琐的。举个简单的例子，如网站的数据检验功能，不允许前端提交不符合当前要求规范的数据（比如年龄文本框部分不能提交字母）。那么为了实现这个功能，首先开发者肯定要在前端实现该功能，直接在前端阻止用户提交不符规范的数据，否则用户体验会很差，且占用服务器端的资源。
但是没有安全意识或觉得麻烦的开发者就会仅仅在前端用Js进行校验，后端没有重复进行校验。这样就很容易给恶意用户机会：比如不通过前端页面，直接向后端接口发送数据：或者，前端代码编写不规范，用户可以直接在浏览器控制台中用自己写的Js代码覆盖原有的Js代码；或者，用户还可以直接在浏览器中禁用Js；等等。总之，前端的传过来的数据可信度基本上可以认为比较低，太容易被利用了。
而我的思路都是很简单的，就是关注比较重要的几个节点，看看有没有可乘之机。如登录、权限判定、数据加载等前后，对方是怎么做的，用了什么样的技术，有没有留下很明显的漏洞可以让我利用。像这两个网站，加载的Js文档都没有进行混淆，注释也都留着，还写得很详细。比较凑巧的是，这两个网站都用到了比较多的前端的技术，也都用到了sessionStorage。
SINE安全网站漏洞检测时必须要人工去审计漏洞和查找漏洞找出问题所在并修复漏洞，对各项功能都进行了全面的安全检测。
http://www.qdshtddzkj.com