服务器漏洞扫描怎么做

SINE安全对网站漏洞检测具有的安全技术人员，而且完全不依靠软件去扫描，所有漏洞检测服务都是由我们人工去检测，比如对代码进行审计，以及都每个网站或APP的功能进行单的详细测试，如跨权限漏洞，支付漏洞绕过，订单价格被篡改，或订单支付状态之类的，或会员找回密码这里被强制找回等，还有一些逻辑漏洞，上传漏洞，垂直权限漏洞等等。
在安全运营工作当中，经常需要系统日志、设备威胁事件日志、告警日志等，各种日志进行收集汇聚，具体分析，通过日志来分析威胁事件发生源头、相关联的人和资产关系，以日志数据的角度，来追究溯源威胁事件发生的过程和基本概括原貌。评估威胁事件产生危害的影响范围，关联到人与资产，采取顺藤摸瓜，将各种信息进行关联，无论是二维关系数据联系关联，还是大数据分析建模，数据的分类采集都是基础工作。
企业安全相关的各种日志数据，存放的位置、形式、大小、业务、使用人群都不同，如何根据不同业务规模的日志数据，采取相得益彰的技术形式进行合理的日志、聚合、分析、展示，就成为了一个课题，接下来，我们主要围绕这些相关的主题进行讨论分享，通过具体的日志聚合分析实践，让数据有效的关联，使其在威胁事件分析、应急事件分析响应过程中让数据起到方向性指引作用、起到探测器的作用，通过以上技术实践，让更多日志数据，有效的为企业安全运营提供更好的服务。
在实际工作当中，日志聚合分析工具种类繁多：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原因。

多年以来，应用程序设计总是优先考虑功能性和可用性，很少考虑安全性。很多CISO表示，API安全性尤其不被重视，甚至完全被排除在安全设计流程之外。通常都是开发人员开发和部署完成后，在API投入生产且频繁遭受攻击后才亡羊补牢查找问题。安全性（包括API安全性）需要成为产品设计的一部分，并且应作为首要考虑因素加以实现，而不是事后填坑。
解决方法：审查应用程序的安全体系结构是迈向安全系统的重要步。请记住，API使攻击者能更地攻击或利用您的系统。设计安全性的目标是让API成为用户而非攻击者的工具。以上只列举了一些常见的API漏洞，总之，重要的是在软件开发生命周期的早期阶段就讨论安全问题。微小的改进就可以带来巨大的好处，避免API遭攻击造成的巨大和损失。

早上，我突然被客户告知，他部署在云平台的服务器被检测到webshell，已经查杀了，而且云平台检测到这个ip是属于我公司的，以为是我们公司做了测试导致的，问我这个怎么上传的webshell，我当时也是一脸懵逼，我记得很清楚这是我的项目，是我亲自测试的，上传点不会有遗漏的，然后开始了我的排查隐患工作。
巡检查杀首先，我明白自己要做的不是找到这个上传的位置是哪里出现的，我应该登上服务器进行webshel查杀，进行巡检，找找看是否被别人入侵了，是否存在后门等等情况。虽然报的是我们公司的ip，万一漏掉了几个webshell，被别人上传成功了没检测出来，那服务器被入侵了如何能行。所以我上去巡检了服务器，上传这个webshell查杀工具进行查杀，使用netstat-anpt和iptables-L判断是否存在后门建立，查看是否有程序占用CPU，等等，此处不详细展开了。万幸的是服务器没有被入侵，然后我开始着手思考这个上传点是怎么回事。
文档上传漏洞回顾首先，我向这个和我对接的研发人员咨询这个服务器对外开放的，要了之后打开发现，眼熟的不就是前不久自己测试的吗？此时，我感觉有点懵逼，和开发人员对质起这个整改信息，上次测试完发现这个上传的地方是使用了白名单限制，只允许上传jpeg、png等图片格式了。当时我还发现，这个虽然上传是做了白名单限制，也对上传的文档名做了随机数，还匹配了时间规则，但是我还是在返回包发现了这个上传路径和文档名，这个和他提议要进行整改，不然这个会造成这个文档包含漏洞，他和我反馈这个确实进行整改了，没有返回这个路径了。
SINE安全网站漏洞检测时必须要人工去审计漏洞和查找漏洞找出问题所在并修复漏洞，对各项功能都进行了全面的安全检测。
http://www.qdshtddzkj.com