大杀器:惨遭黑客入侵，记一次服务器被攻击的应急行动！

　　大杀器:惨遭黑客入侵，记一次服务器被攻击的应急行动！

　　如果您的 PHP 服务器被黑了怎么办？这是我最近在处理 Linux Web 服务器时发现的一个问题。

　　当 PHP 服务器被黑客攻击时，会出现与服务器上运行的 wordpress 应用程序和特定用户代理无关的新 PHP 文件，所有流量都将重定向到另一个站点。

　　在第一次被黑之后，我禁用了他检测到的所有恶意文件并修复了重定向，直到服务器再次被黑。

　　为此，为了将这些应用程序转移到新设备上进行分析，我不得不在原创

系统上执行以下 3 条取证线索：

　　但需要注意的是，我的目的不是建立合法有效的保护机制，而是要确定：

　　拿到域名、IP和SSH证书后，开始采集

被黑的证据。

　　采集

证据

　　在连接到服务器之前，我记下了我的 IP，以确保稍后可以在日志中区分它。

　　然后通过 SFTP 连接，我无法成像，因为服务器的磁盘已安装并正在运行。所以我下载了所有我能拿到的日志文件和其他感兴趣的文件。

　　我复制了整个 /var/log/ 目录，并从与虚拟主机根文件相同的目录复制了 Apache 特定的日志文件，并复制了被黑的 PHP 应用程序，以及事件发生后不久的一些备份。

　　不幸的是，我没有管理员所做更改的备份，因此一些关键文件可能已被修改。

　　我启动了 Kali 并使用 portscan 端口扫描程序运行了 Nmap 扫描，我还安装了 WPScan。

　　

" />

　　由于服务器正在运行一个旧的 Wordpress 实例，并且该实例还执行了重定向，因此看起来 Wordpress 很可能是攻击的起点。

　　Wordpress 在被黑后一直在更新，WPScan 目前没有发现任何漏洞。portscan 为 FTP、SSH、HTTP 和 HTTPS 提供开放端口，这些在 Web 服务器上是不可能的。

　　我在 wp-content 目录下找到了所有 shell，这不知何故意味着 Wordpress 应用程序已损坏。

　　我还检查了 VirusTotal 以查看该站点是否在传播恶意软件，但一切似乎都很正常。

　　所以我决定通过控制台登录系统，但前提是我不知道服务器上的二进制文件是否被感染，所以为了减少取证的影响，我带了自己的静态链接二进制文件。

　　我从 busybox 下载了二进制文件 coreutil 并将它们上传到服务器上。我还通过 SLEUTH Kit 上传了 chkrootkit 和一个名为 mac-robber 的工具。

　　我使用静态二进制文件来检查系统，获取正在运行的进程列表，cronjob ...

　　netstat -tulpen

　　为了获得监控（tcp 和 udp）进程的列表，我没有涵盖 portscan 中的所有端口，所以这里的输出可能很有趣。

　　netstat -taupn

　　从服务器显示活动的传出连接（tcp 和 udp），但是，两个列表都没有显示可疑活动。

　　rootkit 用 chkrootkit 检查过，也没有发现任何东西。rkhunter 和 clamav 也没有产生任何异常。ClamAV（Linux 杀毒软件）也未能检测到 PHP Shell 和 Windows 木马。

　　尽管我尽了最大的努力，到目前为止，没有发现异常打开的端口，也没有发现异常运行的进程。所以我向管理员核实了 FTP 和 ssh 帐户，这看起来也很正常。

　　

" />

　　但我没有放弃，在使用mac-robber工具后，我采集

了服务器上创建和修改的文件信息（以后可以用来创建事件的时间线）：

　　./mac-robber / > /root/forensics/timeline.txt

　　到目前为止我采集

到的证据包括：

　　分析证据

　　由于我看到了攻击者放置的一些 web shell，经过分析我认为这些文件看起来很像 Xjrop.php、Nwfqx.php 或 Rwchn7.php，并且很可能驻留在常规应用程序文件中。

　　然而，还有一个名为 up.php 的文件具有类似的用途，但具有额外的源代码。虽然 Xjrop.php、Nwfqx.php 和 Rwchn7.php 是相同的，但 up.php 是另一个功能略有不同的 shell。使用 diff 命令比较文件：

　　diff Xjrop.php Nwfqx.php

　　或者通过他们的 md5sum 进行比较：

　　md5sum Xjrop.php

　　md5sum nwfqx.php

　　还有 2 个文件 bjrnpf.php 和 jemkwl.php，它们相同但与其他文件不同。一个可疑的可执行文件名为 windoze，我怀疑一些恶意软件正在从该主机分发。

　　我构建了这个文件的 md5sum 并检查了 VirusTotal 上的哈希值，注意到上传到 VirusTotal 上的文件可以被其他研究人员看到，因此是公开的。VirusTotal 认为这个文件是木马，所以我把它保存起来以供以后分析。

　　部分PHP Shell代码，如下：

　　事实:数据爆炸时代面临的困境及突破口

　　大数据时代，更核心的不是如何采集

数据，而是应该关注“数据应用”。数据产品的根应该是业务。本文作者结合自身经历，分析总结了数据时代面临的困难与突破口。一起来看看吧。

　　久违了，一年一度的双十一考试最近又临近了。还没忙完，突然想到总结一下自己的经验和全部门的经验。也就是说，我们会对2022年做一个年度总结，同时也希望分享一些在实际业务过程中遇到的问题场景，以及如何思考问题，如何落地，如何做效果评估。

　　在文章开始之前，让我添加一些背景知识。我所在的公司是互联网行业，性质是toB，产品是为企业服务的。首先感谢您的阅读，让我们开始吧。

　　一、情况

　　笔者所在部门成立于2020年，部门定位为基础数据服务部门。所谓基础数据服务，也是一种功能属性，比如销售部直属产能部门。我们最初构建它的初衷与大多数数据产品的愿景是一样的：“用数据赋能业务”。只有真正从事数据服务相关工作的同学才能理解这短短的7个字的含义。

　　从DT时*敏*感*词*始，大数据已经耳熟能详，数据冗余，海量数据让用户应接不暇。拥有数据从来都不是用好数据的理由，它只是基础。当然，我不是说数据采集

不重要，而是在大数据时代，我理解的核心不是如何采集

数据，重点应该放在“数据应用”上。再庞大的数据中心，数据产品的根也应该是业务。抛开业务数据，它只是DB中的一行明细，并不能给公司或业务带来收益。

　　整个公司的业务涉及到面向大量的上下游企业和商家，以及商家使用的第三方平台，比如上游平台：阿里、字节、拼多多等；下游物流：顺丰、京东、三通亿达等。我们需要为商家提供资源管理能力。这些资源包括但不限于交易数据、成本数据、进销存数据等。此时，第一笔订单的问题是系统打通了。从国内市场来看，需要接入的平台数量超过100家，物流服务商有数十家。综上所述，我们需要承接数据的“导入导出”，以及“导入导出”的业务拆解

　　1. 数据定义

　　根据业务定义，需要哪些数据源，如电商平台交易订单、物流承运快递订单、商品成本数据等。

　　2. 数据采集

　　指定数据源后如何获取，如开放API、私有数据交互协议等。

　　3.数据转换

　　数据来源的多样性导致数据格式的复杂性和数据形式的多样性，需要定义我们的标准数据结构。

　　4.数据存储

　　海量数据如何选择存储方式：

　　5.数据分析6。数据应用

　　用数据引导业务，反哺业务，解读业务价值，辅助业务进行效果评估。

　　7. 数据治理

　　需要对大量数据进行约定和标准化，建立数据亲缘关系；只有打造可持续发展的生态，才能打下坚实的基础，承载未来更多的业务量。

　　八、数据开放

　　如何打造数据可复用易用的生态，对外赋能更多商家和业务领域。

　　以上是对功能的简单拆解，拆解思路基本上是按人员划分的（团队建设的目标也是由以上节点组成）。功能描述完了，我们再来看看每个功能背后真正存在的问题。结合实际场景，让读者通过冰冷的文字感受到其中的价值或理念。

　　1）数据定义

　　此步骤分为两个阶段。第一阶段是团队建设的初期阶段。数据需求是企业的需求。驱动力来自于用户。我们将访问企业需要的数据。截至2022年11月，我们将接收并入371家上游平台和100多家下游服务商（快递公司、货代），获取他们分布在各个渠道的交易数据、商品数据、库存数据、价格数据、交易数据等为企业。

　　第二阶段是今年的状态。驱动力更倾向于团队自身，功能迭代、性能调优、存储成本降低，以及流式计算等存储&计算引擎的引入，提升自身系统的健壮性和稳定性。、及时性等

　　所谓数据定义，还是比较容易理解的。背后隐藏的问题是如何降低维护成本。做过接口开发的同学应该清楚维护接口的成本，尤其是当连接的外部系统数量增加到一定程度时。微调，或者字段语义的不确定性，都会对自己的业务产生不可逆的影响。

　　2）数据采集

　　采集面临的问题有渠道多样性、数据格式多样性等；渠道和格式的多样性意味着需要固定的人力进行长期维护，关注数据完整性和时效性等核心关键指标。

　　3）数据转换

　　ETL中比较复杂耗时的节点，在初期人力有限的情况下，接入一个通道获取一个通道的数据，然后对通道数据进行相应的转换，转换成需要的业务格式。

　　4）数据存储

　　相信每个互联网公司的同学都或多或少遇到过存储相关的问题（可能贵公司现阶段还没有暴露）。公司早期，数据量小，多样性小，不会遇到太大的write-read压力。

　　现阶段保留固定的数据进出，其实可以提高效率（对每一类访问的数据进行相应的转换，存储在指定的DB中，统一读取到指定的DB），相信这个阶段还不够我们会遇到成本压力。我们从一开始就采用了这种方法。随着市场的发展和扩大，我们将在20-21年面临数据量的爆发式增长。

　　为了迎合市场、产研部门，商家根据不同的需求，实施了不同的数据源接入。多样性几乎变得难以管理，多服务对DB的读写也面临着各种性能压力。保证读写时序又做了一次 大批量加锁的行为导致各种表死锁，每年的成本都是几千万。

　　5）数据分析

　　缺乏分析经验，处理不同格式的数据更是难上加难。数据存储量高得惊人，可惜都是冷数据，数据长期未能产生相应的价值。

　　

" />

　　6）数据应用

　　没有分析过程，就无从得知应用，团队成本也没有养成“用数据说话”的习惯。更多的企业决策更多地依赖于人员的经验，也就是所谓的“闭门造车”。经常听到学生脱口而出“我认为xxxx”“我认为客户应该是xxxx”。我们要善于利用数据来辅助我们做决策。

　　7）数据治理

　　大多数互联网企业可能没有经历过数据治理的过程，没有体会到数据治理带来的价值，更不明白为什么要在数据治理上投入大量的人力和财力。顾名思义，“治理”是一种通过一定渠道进行调节的机制。在日常操作中，可能会出现各种“不知道把数据存储在哪里”、“不知道从哪里获取数据”、“谁在使用这个数据”、“改变”这个数据的影响评估做不到”等等。

　　8）开放数据

　　这一步说起来可能不太现实。大部分公司内部都是由基础数据驱动的，做内部循环，增加自己的业务是一个理想的情况。构建生态和管理生态之间还有一段距离。当价值已经产生时，可以考虑将数据打包，丰富自己的开放生态，赋能更多的协同或上下游，提升整个行业。

　　9）价值

　　这一步算是补充条款，上面没有提到。相信这一段也能引起很多朋友的共鸣。要知道基础数据服务部门应该都有“如何创造价值”这个通病，无论是业务决策产品还是数据产品，难道只能被动接受业务部门的数据需求吗？

　　总是一味地服从别人的“你把xxx数据转化成xxxx输出给我”“我要xxxx，你需要清洗再提供给我”，数据的价值不止于此，在不冲突的情况下，do我们有突破做价值，也许把数据清洗出来提供给业务部门之后，我们也可以从数据的角度提供一个效果评估？这个评估结果也可以表示为一个值，一个影响业务走向的值。

　　2.如何思考解决方案

　　面对上面遇到的问题，需要解决的问题比较多，涉及的业务领域跨度也比较广。在人手有限的情况下，没有办法齐头并进。我们只能列出改造点，列出优先级和影响范围，划定Q1-Q4整个部门的目标。这些任务大多是内部驱动，同时需要维护来自业务团队的需求任务，所以经过部门的讨论，我们得到了一个60%外部需求，40%自驱动的节奏。

　　下面是一个简单的拆解过程：

　　拆卸过程分为五个简单步骤

　　简单概括为痛点，也可以理解为核心目标，是中短期内更急需解决或改善的（多围绕部门职能和核心价值观）。比如我们属于数据基础部，所以指标多是数据相关的。比较典型的是数据的几个特性：稳定性、时效性、完整性、易用性和成本。

　　1.稳定性

　　这里描述的是集群的稳定性。一个*敏*感*词*的商户群体，意味着会有一个*敏*感*词*的数据链路。为了减少宕机等稳定因素对业务的不可逆影响，也是业务的基石。

　　集群分布也可以拆解为Web集群（B/S架构网页）和任务集群（Job调度集群），在云资源逐渐增加的基础上，对集群做一定的“资源瘦身”。web集群比较好理解主要是监控高并发请求，以及一些核心业务操作（比如订单操作，报表操​​作多为DB增删改查操作）的稳定性，加入监控系统。这也是我们搭建的第一套监控系统，覆盖了整个部门涉及的整个业务。下面是监控系统设计的几个核心点：

　　这里简单介绍一下监控系统的心路历程。预警的目的不是为了预警，所以预警的内容必须是紧急的、可执行的。这个指标非常重要。很多监控系统的设计都是从一开始就拆解各种业务指标开始的，往往是几十个指标，还有一大堆告警。处理人员不知道该怎么做。

　　需要更加注意告警噪声的过渡性去除。告警不一定越多越好，也不一定越细越好。在合适的时间向合适的人报告最重要的内容是合理的；规则尽量贴近业务，脱离现实的报警只会给自己增添无穷的后患。

　　最后一个相信搭建过监控系统的同学也有同感（警报响起，时间长了人开始累了，疏于执行警报内容）。这时候引入其中一个支撑能力：值班系统，什么是值班（自动化值班）可以提取出统一的数据交互错误格式，也就是标准的异常代码。参与过界面开发的同学应该比较清楚，一个界面的响应信息一般有两层（code，msg）。msg为消息体，code为描述码；

　　比如code=200表示成功，code=500001表示业务出错，进一步细分可以实现二级代码，比如code=500001 & sub_code=9999表示系统宕机，需要调度系统重试。这是将代码映射关系抽象出来后，就可以建立自动化值班系统，根据代码定义的决策结果自动不间断“值班”，减轻产研人员对a的压力一定程度。

　　这里还有很多细节可以深挖。例如，AI机器人可以根据代码，从移动端接收产研人员的操作指令，完成权限分配、OA流程审批、资源购买等，或者根据预设完成线程分配代码，并调整任务集群的步频、步长、步幅等动作。

　　有了监控+值班，当然少不了预警系统，也就是所谓的消息分发系统。经值班系统自动处理后，仍有一些关键异常系统无法自动消化，需要人工干预。这时候就需要一个分发系统。

　　可对接多种消息渠道，如企业微信、钉钉、飞书、短信，甚至电话，可根据预警级别推送给可执行人员或群组（对应的接收群或接收群必须提前按照职责划分）人）预警通知需要建立固定的处理流程，个别高质量异常需要在驻留时间达到xx时建立问题，让越来越多的专业同学参与进来并协助处理。

　　2.及时性

　　基础数据业务不可避免要做的就是减少数据交互的时间消耗。内外系统交互的RT值需要降低整体数据链路的时间消耗。那么在调度资源不变的情况下怎么办，思路也比较清晰，“让资源在合适的时间合适的地方使用”服务器资源会有高负载和低负载的时间段，比如高频计算 白天，多个数据链路需要公共资源，因此我们可以将资源量化并区分业务或业务的优先级，将更多资源分配给更高质量的业务链路。

　　清晨负载下降后，可以对海量数据进行一些离线计算服务，比如日报、归档、*敏*感*词*业务数据重算等。可以在这些时间点做一些业务策略，可以放置一些数据审计流程，这样一方面不浪费资源，一方面可以提高整体链路的健壮性，另一方面另一方面，可以改善响应。

　　另一个减少时间消耗的想法是“瘦身”。这种瘦身，不仅是资源上的，也是企业上的。一些涉及到存储介质交互的业务，比如对数据库的读写操作，是否可以支持批处理，是否会有表锁，行锁等，是否会有大量的逐项更新操作在业务代码等；扣除业务细节，不断优化各种细节，实现良性循环。

　　3.诚信

　　这一步的背景是当有大量的数据入口时，大量的数据来自于上下游系统和服务商。不同的数据口径不容易维护，外部数据字典的变化会影响到我们自己的业务，比如反序列化等步骤。这时候，为了保证业务能够获取到完整的、结构良好的数据，我们可以封装一个统一的数据模型校验能力。根据我们抽象的业务模型（符合业务预期）验证实时数据。

　　如果担心性能压力，可以有选择地将一些比较工作做成异步操作，保证主链路的流畅。同时，如果比对了一些弯道数据，可以在第二步通过预警系统完成返场，人工介入确认情况。，更及时有效地感知数据变化，从而减少对业务系统的影响。

　　4. 易于使用

　　这一步需要更多的工程思维。在业务沉淀的过程中，更多的考虑如何抽象，如何封装统一的方法和接口，让内外部协同更好、更高效的使用数据。现在微服务的概念越来越流行，很多模块化、碎片化、服务化的系统更有利于后期的业务扩展和业务重构。

　　通过封装统一的数据接口，降低数据的使用门槛，通过模块的抽象，服务的设计，使系统获得高可用的后期空间。在此基础上，当业务系统需要使用数据时，可以更专注于赋能业务，而不必过多考虑数据的使用。

　　在此基础上建立数据治理体系，记录数据血缘关系的完整链路，方便我们后期追溯。更面向服务也降低了业务耦合度，降低了迭代带来的影响范围和灰度成本。

　　5.成本

　　最后一段是关于成本的。归根结底，降本增效的道路还需要继续走下去。尤其是在互联网行业，除了最昂贵的人力成本外，资源成本同样令人头疼，各种技术栈带来的成本更是数不胜数。

　　服务器资源成本、DB和数据仓库的存储成本、中间件和计算引擎带来的计算成本等存储成本都是主要的。针对这个问题，我们初步的方案是优化调度分配策略。调整了底层存储结构，即分库分表规则，合理分配数据和资源流量后，可以压缩更多空间使用，将低负载集群合理分配给更多业务，减少空闲集群. 频率。

　　当然，机器占用的空间不只是我们自己的事。早期的亚马逊云，由于其庞大的集群，闲置了很多资源，所以我们想到了租用一些云资源，提供一系列的云服务。这些高效的存储、计算能力可以为一些中小企业提供良好的基础，半管理和全管理服务将随之而来。总之，关键是要合理利用现有资源，实现更多的业务目标。

　　

" />

　　说了这么多，我也简单画了个草图来描述一下我们现在的这套系统架构图。内容不是很全面，但也总结了目前的基本分布。

　　自上而下可分为接口层，接口层通过API、导入、数据推送等技术手段完成对外数据的采集。

　　第二层是模型转换层，数据格式验证和模型验证位于此层。

　　第三层多为一些中间件服务，如消息队列、集中分布式缓存、丢失数据计算引擎、即席查询报表等。

　　第四层为业务层，按业务领域划分，如交易、商品、存货、财务等；它是按照服务来拆分的，比如交易服务：主要是处理交易数据，清洗交易数据等，商品服务，运输服务等。*敏*感*词*提供能力.

　　第五层为基础数据存储层，如关系型数据库Mysql、非关系型数据库MongoDB、数据仓库等。

　　在1-5层的基础上，提供内部网关，主要用于承载内部业务接口，并实现一些流控策略、风控策略、认证策略等，保证业务的稳定性和安全性。

　　五层以外有一个贯穿整个系统的外部网关，即外部内部数据的网关，可以通过外部开发者的身份进驻我们的平台，完成一些自身的开发数据获取工作-开发的系统。

　　调度中心是一个基于主从关系（Master-Slave）的自建调度集群，负责系统内部和外部部分资源的调度和分配。可以结合后续的日志服务和监控中心，完成一些自我健康策略，比如健康检测、心跳检测等，保证系统核心足够稳定。

　　监控中心和日志服务满足大部分环节的可移植性。通过封装内部接口，整个业务域可以低成本完成日志写入，包括业务日志、用户操作日志、用户行为日志，可以让业务低成本完成业务埋点，指定分析策略完成后续数据审核，并提供迭代数据支持。

　　三、效果评价及思路

　　了解了以上很多问题的解决方案后，我们再来看看效果评估部分。毕竟，没有利润就一文不值。在基于上述架构的系统上，我们目前每天处理近亿笔交易，每天产生的日志数据量达到EB级别。

　　之前经常遇到的机器高负载也得到明显改善，95%以上的调度集群全天保持稳定水位。在成本方面，则更为明显。在原有近千台机器的集群规模下，减重近80%。在成本方面，每年节省的成本可达数百万。最后，现有的面向服务的设计大大降低了我们的生产和研发成本，有利于我们快速的版本迭代，及时感知市场变化。

　　也提供了一些数据价值的思路，比如车品觉先生的五种数据价值：

　　1) 识别和连接值

　　2）描述值

　　①企业

　　②用户

　　③ 商品或服务

　　3）时间价值

　　①历史分析

　　②实时分析

　　4）预测值

　　① 用户预测

　　②单品预测

　　5）输出数据的值

　　① 电商店铺评分系统

　　好评数、好评率、描述匹配度、物流速度等。

　　② 金融信用评分模型

　　4.结束

　　聊到最后，我真的很想提出一个共识问题，基础数据服务的价值上限是多少？坦白说，经过这么多年的工作，我们并没有找到明确的答案，但实践证明，做好自己的数据规范，继续为业务输出价值，并不是终点。

　　随着DT时代的到来，越来越多成熟的技术栈和数据产品出现，ETL不再是一件让人头疼的事情，我们都将面临“数据爆炸”的现实，云计算、Metaverse、人工智能等领域不断扩张也给我们带来了很多挑战。在当前时代，每年的数据量增长超过50%。麦肯锡曾经提出过一句话：

　　如今，数据已经渗透到每一个行业和业务功能领域，成为重要的生产要素。随着新一波生产力增长和消费者剩余的到来，海量数据的挖掘和利用表明“大数据”已经存在于物理、生物、环境生态等领域，以及军事等行业、金融和通信。，但由于近年来互联网的发展，信息产业的发展引起了人们的关注。

　　抛开所谓的大数据杀熟，大数据是未来，开始看现在，数据不再稀缺，技术在大多数互联网行业永远不会成为商业壁垒，越来越出... the-box 先进的技术产品随处可见，数据分析模型随处可见，我们可以以极低的成本高效地获取我们想要的数据。

　　那么问题来了，价值是多少？有数据不代表会用，会用不代表能用好，用得好不代表能用出众！希望大家互相鼓励，抛开一些充满生活气息的低效内容，找到最适合自己业务的分析方法和数据，获得预期的结果，找到自己的“壁垒”才是核心。

　　增长也难以一蹴而就。现阶段确实很难在饱和的用户心目中做出现象级的产品。也希望每个人都能在自己的岗位上发光发热，热爱这个行业，得到自己想要的结果。.

　　本文由@足病原创发表于人人都是产品经理。未经许可禁止转载

　　题图来自Unsplash，基于CC0协议

　　本文观点仅代表作者本人，人人都是产品经理平台只提供信息存储空间服务。