今天的公有云出现之前，存储日志最好的方法是将日志与生成它们的主机分开存储。如果主机被攻击，分开存储的日志可以被保存下来。

       在像AWS这样的云服务提供商中，你的账户的存储服务保存着你的活动日志。但是对一个账户权限的充分信任可能会导致日志破坏并对IR团队造成严重影响。这就相当于日志存储在单个被攻击的机器上：一旦日志的访问限制被覆盖，日志就可以被篡改和删除。然而在AWS中，删除和编辑日志与用rm -rf擦除日志是不同的。

       在AWS术语中，日志的服务叫CloudTrail（云资源调用记录服务）。把当前批处理文件中的活跃日志，以不同的时间间隔传递到一个预定义的S3桶，会产生一条记录。（日志的传递占用20分钟）。

       如果一个攻击被发现，日志中会记录很多有用的审计跟踪信息，所以需要经常收集CloudTrail日志。当攻击者访问了一个账户后，日志是对攻击行为的唯一的公共记录，是大多数AWS防御的基础。如果你还没有为自己的账户开启该服务，现在就停止阅读去开启它。

    Daniel Grzelak在他之前的博客中，探讨了日志存储在S3后的一些有趣结果。例如，当一个文件到达某个S3桶时会触发一个事件。一个函数，或AWS Lambda服务，可以监听该事件并在日志到达时马上删除日志。然而日志会继续正常到达（除非日志在到达过程中丢失）。

       如果攻击者获得删除旧副本的权限，那么给S3桶（一旦被重写就会保持较旧的副本）添加“版本控制”是无用的。版本化的桶的确可以选择多因素认证（“MFA-delete”）来保护版本化的选项不被删除。不幸的是，只有AWS的root用户（唯一拥有所有S3桶的账户）可以配置版本化，所以在root访问受到严格限制时不太容易在标准配置中启用。

       无论如何，在空的日志桶中查找日志必然会触发警告。这让攻击者面临一个紧迫的问题：怎样能既擦除攻击痕迹，又能让剩下的日志可用和可读呢？答案是修改Lambda服务来检查每个日志文件，在用干净的日志文件重写之前，删除所有脏日志条目。

       但需要注意的是：在修改日志时，Lambda本身会生成更多的活动记录，反过来给日志增加很多脏条目。解决的方法是在日志消毒器（log-sanitiser）的名字上添加一个独有的标签（比如策略名，角色名和lambda），这些标签可以像其他脏日志条目一样被删除，使得日志消毒器可以删除自己的痕迹。在下列代码段中，任何包括thinkst_6ae655cf的角色、lambda或策略都会被从日志中删除。

       以上看起来是一个完整的解决方案，除了AWS Cloudtrail服务还提供日志验证功能（专门用来减少日志在传递后发生变化）。日志跟踪会定期的传递一个（签名的）摘要文件，证明过去时间间隔内传递的所有日志文件的内容。如果日志文件的摘要被篡改，则验证失败。

       乍一看，日志验证功能阻止了对踪迹的篡改攻击；lambda会在传递后修改日志，而摘要根据修改之前的日志内容计算得到。所以内容和摘要不会匹配。

       每个之前的摘要文件都会被新的摘要覆盖。这产生了一个开始于当前日志的日志验证链，并链接到之前的链上。如果之前的摘要文件被修改或丢失，则下一个摘要文件验证会失败（但之后的摘要仍是有效的）。这样做的目的是明确的：当日志被篡改时，应该显示AWS命令行日志验证产生了一个错误。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)