又是一个风和日丽的下午,姜老师发了一张图。是一个系统进程的截图。赫然在目一个看起来命名很随便的一个进程名，很轻浮。
姜老师作为一个老江湖，怎么就能让这么一个不正经的程序在自己的主机上运行起来？
按理说我们这时候应该列出各种图表和操作命令系统截图，来溯源整个入侵的过程,辅助大家理解整个事件的前因后果。这也是“糖果的实验室”公众号，第二次写应急。奈何天太热，实在不爱动，空调和糖水都不能唤起来我躺起来的热情。在可能不是草长莺飞的日子，说一篇公众号。
用一个公众号来发各种富文本是一个很累的活儿，因此想用一个纯文字版的信息推送，来表述一个大概事件过程。
对于过往，已发表的文章大概可分成几类：一种就是非常写意的抽象概念，祖国山河，大好景色，沟帮子烧鸡，天一脚地一腿，这种情况下大家好像不太买账。对于一些虚头巴脑的概念，没有什么心得体会和收获的话，往往会对这种文章嗤之以鼻。说的越对，越虚，越没人爱听。
还有另一种纯工具实用主义类的介绍性文章，这里有大量的代码和对应的工具介绍，然而这种文章的回应也寥寥无几，一般都是好顶赞。但是还是要特别感谢朋友们的支持，默默的点击收藏的数量应该不是假的。
只有一种文章却受欢迎，就是文章要有故事，要有包袱，要有亮点。还要有解决方案。 就算这种场合，也有会在评论里说，他们不关心娱乐，说这口才不适合做什么什么的应该去说相声， 对看文章找错别字的朋友，只能不好意思了。
接着主题说，问题既然这么发生了，接下来如何应急呢？
按照传统的做法，我们会把系统上运行的所有的服务都看一遍。然后找到那种高危的程序，去重点关注一下。往往这种程序的特征也比较明显。会在某个时间段进行，大量的网络传输操作。占用内存和计算资源。
但是对于溯源来说，一定要看一下重要的正常服务。
比如nginx是否运行在超级用户环境下。
比如特定数据库是否开了一些敏感的服务。
还有就是系统版本是否过低。
使用的语言工具是否版本过低没有更新？
看看计划任务是否被篡改。
我要通过各种技术手段发现黑客是否在服务器上留下什么蛛丝马迹？
我们要找到黑客是从哪个途径入侵到服务器。经过一定的排查，最有可能出现的问题是出在网页服务器使用的电商系统版本过了。其实这个也不是排查的，是因为服务的使用者自己清楚。
通过网页的漏洞，经过一系列的提权，将木马程序植入到服务器。这是一种比较常见的入侵。特别是在各种云厂商的服务上。
其实每家云服务厂商都有自己的防护系统。但即使有这些防护系统，云主机被入侵的概率也是不小的。姜老师面临一个比较尴尬的局面就是。业务用了一个很老的电商软件。用软件提供的功能来，支撑他们的业务运转。但可能是因为一个祖传代码。不好进行更新和修改。
大家都知道这种祖传代码的威力。不敢动，不敢改。能维持正常运作就已经很不错了。你不知道过去的代码里加了多少的黑客技术。
工厂管这种项目叫做坑。谁负责谁就是坑长。
另外系统本身的版本也不高。运行的语言软件版本也不高。你从代码审计的角度，我们要去扫描一下代码是否被动过。
往往这种被入侵的事件发生的概率很高的。但是我们一般都有多少种途径来解决这种问题？像这种云服务。他们本身提供的防护系统不起作用。一般这时候的云服务使用者不会再另外构建一个自己的安全防护系统。
姜老师发现了主要的问题的进程。当下掉这个业务的主机。把不正经的程序拷贝到新的主机环境下。这个进程也是无法被杀掉。会不断的重启。可能短时间内我们无法对老的系统进行版本的升级。所以首要的任务要把老业务恢复生命。重新提供服务。但同时也面临着再次被入侵的风险。
我们通过系统运维手段发现了问题的进程。姜老师定位这是入侵，很有可能是在国外进行。所以，大体回忆起来我们整个应急过程是这样的。
首先排查掉，重点业务是否有漏洞的危险！如果都没有，是不是因为软件版本过老造成？版本老的软件本身可能存在一定的漏洞。而在境外的人会利用这个漏洞进行提权入侵。针对这一点，响应的一个办法就是将所有境外中国以外的服务请求全部关闭掉。
很明显，这个业务是一个地域性很强中文业务。不提供境外支付方式进行交易。大面积的订单都是在中国境内完成。所以姜老师可以把境外的所有请求都屏蔽掉。
其实姜老师的系统也不是完全没有防护。她本身可以在自己的nginx上进行安装waf模块进行拦截。现在比较清晰的一个黑名单就是。所有中国境外的IP可以全部屏蔽掉。
我们如何屏蔽掉境外的IP呢？怎么区分是境内的IP和境外的IP？我们可以通过开源IP库进行查表。然后封禁所有国外的请求。
某种程度上可以解决某些领域的黑客入侵。但是如果国外的黑客使用了国内的肉鸡。通过代理跳板的方式进行，目前还是没有办法解决这个问题。但这本身增加了他们入侵的难度和成本。
其实对于老的电商业务系统来说。定期进行扫描是不错的选择。但即使发现了有漏洞，如果没有及时解决。扫描也只是一个预警的功能。也有可能是一种老系统，未知的0day。一样可以攻击进来。所以也没有绝对的安全。安全本身和你投入防护成本也有关系。
但即使这样，我们也可以通过其他手段发现被入侵。我们常见的方法就是监控服务代码的变更。一旦是非开发人员进行代码改变。可以被系统所识别并报警。
其实扫描和代码审计，云服务厂商也可能会提供这种服务。但即使有这种服务也不一定会发现威胁。而业务，自己搭建的防护系统。其实相对更有针对性。因为业务指导自己的薄弱环节在哪里？担心自己哪里可能存在问题。这种问题是定制化的，不一定是通用的防护。系统可以解决的。
如果下次再有类似的入侵。找姜老师其中的麻烦。至少我们应该构建一个什么样的机制来完善自己的防护工作？
首先创建一个定时扫描的业务系统。通过定时或者不定时的方式对当前系统的漏洞，进行全方位的了解。对于一些显而易见的漏洞，不至于视而不见。当然可能会面临一个问题。就是上文所说的业务过分依赖于老版本的软件。并且后续升级维护有困难。即使在这样的前提条件下，也要保证系统安全。
除了扫描，另外一个重点就是文件监控。对非开发人员修改代码的行为，要进行跟踪确认。一旦发现有人在你的代码中动了手脚。你可以在这个节点发现异常行为。很不好意思，我们这里只是听纯文字版，不便于编辑，列出工具。
实在如果没有实时的文件监控。可以进行定期的后期审计文件扫描。
自动化的日志分析手段。当入侵发生后，对访问日志的分析，是一个不可或缺的过程。如果还停留在纯文本的操作模式。相对的效率呢，可能不是最快的。
所以我们通过类似于大数据的这些手段，把系统的日志进行实时分析，根据系统日志得出的结论进行下一步的判断。
其实地图炮貌似是一个不实用的东西。但如果像这次实践。有一个明确的需求点就是不希望老外来访问我们的国内一些网站。不是不欢迎老外，是不欢迎来捣乱的，老外黑客。
如果在入侵的当时，可以有自动化的日志分析手段。针对用户的请求IP。与开源IP库进行交互。取得IP所在地理位置信息。我们可以通过大数据的工具清晰的看到，访问者。的IP是在中国境内还是中国境外？
因为这是一篇纯文字吧，我们会基于这一篇纯文字版再出一版工具介绍。
说到防护工具。一种是我们基于日志的分析。一种是基于流量数据的分析。这个流量可以来自7层，也可以来自4层，简单说就是，HTTP还是Tcp。这种防护往往解决大流量攻击效果不太好。但是解决老系统的逻辑漏洞，进行查缺补漏还是有效的。
针对有限的攻击手段。也一样会有防卫手段。可能这次姜老师的系统。是因为电商软件版本太低，造成给别人有侵入的机会。但是也通过了日志审计，hids进程检查、代码扫描、IP限制、脚本限制等各种手段进行防御。
后期还对木马进行了分析。将木马放入沙箱，分析结果显示这是一个中威木马程序。对于所有挂在外网的服务来说，被扫描和被入侵的可能都是存在的。我们几乎每天都会面临这样的问题。
是否我们可以通过一种复合的手段，来尽可能的发现这种入侵行为？用一套相对通用的工具，给予像姜老师这样老江湖提供一个解决方案。
其实相对没有一种方法可以解决所有的问题的。如果有两个防护系统。我们重点应该看它的误报率和漏报率，还是看他能发现了什么。如果误报率很低，但是什么有用的威胁也没有发现，那这种系统还是比没有误报率高，能发现威胁的系统有用，误报率高我们可以想办法过滤，而什么有用威胁识别不到的系统，我们是没有办法。
如果文章有错别字什么的，还请您留言！我们希望可以和老姜的故事一起精进成长。符总和DK在这个事中仙人指了路。也不知道老姜现在有没有和小区里的大爷们在杀一盘。