1. 从一条告警说起Redis 应急响应到底在查什么凌晨两点收到一条告警某台对外提供缓存服务的机器 CPU 打满、连接数暴涨业务侧开始出现间歇性超时。登录上去第一眼看top一个redis-server进程占了 300% 以上的 CPUnetstat里一堆 ESTABLISHED 连接指向陌生地址。这种场景做过运维的人多少都遇到过——Redis 因为配置不当被外部利用进而被写入恶意内容、被当作跳板或者被拿来挖矿是应急响应里非常典型的一类案例。这篇内容围绕“日志分析 Redis 应急响应”这个主题展开把我在实际处置这类事件时的完整思路、排查路径、日志取证方法和加固手段梳理一遍。核心关键词是日志分析和Redis 应急响应前者是取证的手段后者是处置的目标。适合谁看一是刚接触安全运维、遇到 Redis 异常不知道从哪下手的朋友二是有一定 Linux 基础、想系统掌握应急响应流程的从业者三是对日志取证感兴趣、想把“从日志还原攻击链”这件事做扎实的技术人员。哪怕你之前没做过应急跟着下面的思路走一遍也能建立起一套可复用的排查框架。需要先说明一点Redis 应急响应的核心不是“删掉恶意文件就完事”而是通过日志和现场痕迹把入侵路径、驻留方式、影响范围这三件事搞清楚。很多人上来就kill进程、删文件结果证据没了攻击者怎么进来的、还有没有别的后门全都说不清。所以下面我会把“先取证、再处置”的顺序贯穿始终这也是整个处置流程里最容易被忽略、却最要命的一环。2. 应急响应的整体设计思路与取证顺序2.1 为什么坚持“先取证后处置”应急响应有个基本原则在没搞清楚状况之前任何破坏现场的操作都要谨慎。我见过太多案例运维一看到异常进程直接kill -9然后重启服务业务恢复了报告写“已处置”。结果过两天同样的告警又来一遍——因为攻击者留的定时任务、SSH 公钥、计划脚本一个都没清甚至kill掉的只是个幌子进程真正的驻留点藏在别处。所以我的处置顺序固定为现场保护 → 日志与痕迹采集 → 入侵路径还原 → 影响范围评估 → 清除与加固 → 复盘。这个顺序背后的逻辑是日志和进程状态是“一次性”的进程一杀、连接一断很多线索就永久丢失了而业务中断是可以短暂容忍的两害相权先保证据。具体到 Redis 场景需要优先采集的东西包括当前进程的完整命令行和启动参数、网络连接状态、Redis 的配置文件、Redis 自身的日志文件、系统层面的登录日志和命令历史、以及可疑的定时任务和启动项。这些内容构成了后面还原攻击链的“原材料”。2.2 日志分析在应急中的定位很多人把日志分析理解成“翻翻 access.log 找可疑 IP”这太窄了。在 Redis 应急里日志分析承担三个作用确认时间线、定位入口、发现横向痕迹。确认时间线通过 Redis 日志里的启动记录、配置重载记录、异常报错结合系统日志的登录记录把“攻击者什么时候进来的、做了什么”排出先后顺序。定位入口Redis 默认端口暴露在公网且无认证是最常见的入口但也可能是通过其他服务拿到的低权限 shell 再横向过来这时候系统日志和命令历史就更关键。发现横向痕迹攻击者进来后往往会尝试连接内网其他机器、下载工具、建立持久化这些动作会在日志和文件系统里留下痕迹。理解了这三层作用你就知道为什么不能只盯着一个日志文件看——单一日志只能给你一个视角多源日志交叉比对才能拼出完整画面。2.3 处置流程的整体框架把上面的思路落成可执行的框架大致是这样一条链路隔离与保护在不影响取证的前提下通过安全组或防火墙限制异常外联但保留现场。信息采集进程、网络、配置、日志、文件系统痕迹逐项落地保存。日志分析以 Redis 日志为主线系统日志为辅助还原时间线。入侵判定确认是否被入侵、通过什么方式、留下了什么。清除加固清理驻留点、修复配置、收紧访问控制。复盘归档形成记录补充监控规则。这个框架不是死的实际处置中经常需要来回跳——比如分析日志时发现一个新线索又得回去补采现场。但大方向不能乱尤其是“采集”必须在“清除”之前完成。3. 核心细节解析Redis 被利用的常见路径与日志特征3.1 Redis 未授权访问是怎么被利用的Redis 应急里最高频的成因就是未授权访问。默认配置下 Redis 监听所有网卡、没有密码如果安全组又放开了 6379 端口等于把大门敞开。攻击者连上来之后常见的利用手法有这么几种第一种是写入 SSH 公钥。攻击者通过CONFIG SET dir把 Redis 的工作目录改到目标用户的.ssh目录再CONFIG SET dbfilename authorized_keys然后把自己构造的公钥内容作为一个 key 写进去落盘后就变成了合法的登录凭证。这种手法隐蔽性强因为后续登录走的是正常的 SSH 认证日志里看起来就是一次普通登录。第二种是写定时任务。类似地把目录改到/var/spool/cron或者/etc/cron.d写入反弹脚本或者下载执行脚本实现持久化。第三种是主从复制利用。攻击者把自己的恶意 Redis 实例作为主节点让目标从节点去同步通过FULLRESYNC把恶意模块加载进目标进程进而执行系统命令。这种手法技术门槛稍高但危害更大因为它可以在不落盘的情况下拿到命令执行能力。第四种是直接写 WebShell 或恶意脚本到 Web 目录如果目标机器同时跑着 Web 服务这就直接变成网站被控。这几种手法的共同点是都会触发CONFIG SET操作都会改变工作目录或文件名都会产生文件写入。这些动作在 Redis 日志和配置变更记录里是有迹可循的。3.2 Redis 日志里该重点看什么Redis 的日志默认输出到配置文件里logfile指定的路径没配置的话可能输出到标准输出。日志里值得重点关注的行有这么几类启动与配置加载记录能看到 Redis 启动时加载的配置文件路径、版本、端口、是否开启保护模式。如果发现启动参数里带了异常的--dir或--dbfilename要警惕。CONFIG SET相关记录Redis 在较新版本里对CONFIG SET有审计日志取决于配置和版本如果看到dir、dbfilename、appendonly被频繁修改基本可以判定有人在动配置。BGSAVE/SAVE记录写文件落盘时会触发保存如果保存的目标路径异常比如指向.ssh或 cron 目录就是明确的入侵信号。异常连接与认证失败如果开了密码认证大量AUTH失败说明有人在爆破如果没开认证日志里可能看不到连接记录这时候就得靠系统层面的网络连接日志补位。需要提醒的是不同版本的 Redis 日志详细程度差别很大老版本对CONFIG SET的记录很有限。所以不能只依赖 Redis 日志必须结合系统日志、文件系统时间戳、进程信息一起看。3.3 系统日志与文件痕迹的交叉验证Redis 日志告诉你“有人动了配置”系统日志告诉你“谁在什么时候登录了、执行了什么”。两者交叉才能把时间线钉死。系统层面重点看这几处认证日志/var/log/secure部分发行版或/var/log/auth.log看有没有异常 IP 的 SSH 登录成功记录尤其是非工作时间的登录。命令历史各用户家目录下的.bash_history攻击者如果通过 shell 操作过可能留下下载、编译、执行命令的痕迹。注意历史文件可能被清理要看文件修改时间是否异常。定时任务/var/spool/cron/下各用户的任务、/etc/cron.d/、/etc/crontab重点看有没有指向陌生地址的下载执行脚本。SSH 授权文件~/.ssh/authorized_keys的修改时间和内容有没有多出来的公钥。临时目录/tmp、/dev/shm下有没有可疑的可执行文件这两个目录是恶意程序最爱待的地方。文件系统的时间戳是很好的辅助证据。用stat看关键文件的Modify和Change时间如果authorized_keys的修改时间和 Redis 日志里某次BGSAVE的时间对得上那基本就实锤了。3.4 一个容易被忽略的点配置文件的“合法”修改有些攻击者不会大改配置而是做“最小化”的修改比如只加一行requirepass设个弱密码或者只改bind让监听范围变化。这种修改看起来像正常运维操作很容易被放过。我的经验是把配置文件和版本库或备份做 diff任何非预期的差异都要能解释清楚来源。如果解释不了就按可疑处理。4. 实操过程从现场采集到攻击链还原4.1 现场信息采集的完整清单下面这套采集动作我在多次处置里反复用过基本能覆盖 Redis 应急需要的关键信息。建议在隔离网络但保留现场的前提下执行采集结果统一存到一个独立目录方便后续分析。先看进程和网络# 记录 Redis 进程的完整信息包括启动参数 ps -ef | grep redis cat /proc/$(pgrep -o redis-server)/cmdline | tr \0 # 记录当前所有网络连接重点看 6379 相关的 ss -antp | grep 6379 netstat -antp | grep 6379 # 记录进程打开的文件和网络句柄 lsof -p $(pgrep -o redis-server)/proc/pid/cmdline这个文件很关键它保留了进程启动时的完整参数。如果 Redis 是被攻击者用异常参数拉起来的比如指定了奇怪的--dir这里能直接看到。lsof则能看出进程当前打开了哪些文件有没有在往敏感目录写东西。再看配置和日志# 备份当前生效的配置文件 cp /etc/redis/redis.conf /tmp/evidence/redis.conf.bak # 定位实际使用的配置文件启动参数里通常有 grep -o \-\-config[^ ]*\|[^ ]*\.conf /proc/$(pgrep -o redis-server)/cmdline # 采集 Redis 日志 find / -name *.log -path *redis* 2/dev/null tail -n 500 /var/log/redis/redis-server.log /tmp/evidence/redis_tail.log配置文件的采集要注意采集的是当前磁盘上的文件不是内存里的配置。如果攻击者用CONFIG SET改了运行时配置但没写回文件磁盘上的配置看起来是正常的这时候就得靠CONFIG GET把运行时配置也导出来对比。# 导出运行时配置需要能连上 Redis redis-cli CONFIG GET * /tmp/evidence/redis_runtime_config.txt这一步经常被跳过但它恰恰能发现“内存配置和磁盘配置不一致”的情况而这种不一致本身就是强入侵信号。最后是系统层面的痕迹# 认证日志 cp /var/log/secure /tmp/evidence/ 2/dev/null cp /var/log/auth.log /tmp/evidence/ 2/dev/null # 定时任务 crontab -l /tmp/evidence/crontab_root.txt 2/dev/null ls -la /etc/cron.d/ /var/spool/cron/ /tmp/evidence/cron_list.txt 2/dev/null # SSH 授权文件 ls -la ~/.ssh/ /tmp/evidence/ssh_dir.txt 2/dev/null cat ~/.ssh/authorized_keys /tmp/evidence/authorized_keys.txt 2/dev/null # 临时目录可疑文件 ls -lat /tmp /dev/shm /tmp/evidence/tmp_list.txt 2/dev/null采集完这些手上就有了进程、网络、配置、日志、文件五类证据足够支撑后续分析。4.2 日志分析还原时间线的具体做法拿到日志后我的做法是先做“粗筛”再做“精读”。粗筛是把所有日志里和 Redis 相关的、和异常时间点相关的行先捞出来精读是逐条看这些行的上下文。以 Redis 日志为例先按关键词过滤# 找出配置变更、保存、异常相关的行 grep -Ei config|save|bgsave|dir|dbfilename|error|warning|accept /tmp/evidence/redis_tail.log如果日志里有CONFIG SET dir或CONFIG SET dbfilename的记录把这几行的时间点记下来然后去系统日志里找同一时间段的登录和命令执行记录。时间对齐是还原时间线的核心动作。举个典型的还原过程Redis 日志显示某时刻有一次CONFIG SET dir /root/.ssh紧接着有一次BGSAVE系统日志显示同一分钟有一个陌生 IP 的 SSH 登录成功authorized_keys的修改时间也落在这一分钟。三条线索指向同一个结论攻击者通过 Redis 写入了 SSH 公钥并用这个公钥登录了系统。这个链条一旦闭合入侵路径就清楚了。如果 Redis 日志信息不足老版本常见就退而求其次用文件时间戳反推。stat一下authorized_keys、cron 文件、/tmp下的可疑文件把修改时间排个序再和系统登录日志比对同样能还原出大致顺序。4.3 入侵判定与影响范围评估时间线还原出来之后要回答两个问题是不是真被入侵了以及影响范围有多大。判定入侵的证据优先级大致是异常的公钥或定时任务 运行时配置与磁盘配置不一致 异常的进程启动参数 大量认证失败 单纯的端口暴露。前两条基本可以直接定性后几条需要结合业务背景判断。影响范围评估则要看攻击者进来后做了什么有没有横向连接内网其他主机看网络连接记录和命令历史里的ssh、scp、curl记录。有没有下载额外的工具或恶意程序看/tmp、/dev/shm下的文件和命令历史里的wget、curl。有没有动过其他服务的数据看数据库、Web 目录的修改时间。有没有创建新的系统用户看/etc/passwd的修改时间和新增条目。这一步的目的是给后续清除划定范围——如果只清 Redis 相关的驻留点但攻击者还留了别的后门等于白干。4.4 清除与加固的落地操作清除的顺序是“先断持久化、再清文件、最后改配置”。断持久化指的是把攻击者留的定时任务、SSH 公钥、启动脚本先摘掉防止清除过程中被重新拉起。# 清理异常定时任务确认内容后操作 crontab -e # 逐条核对删除非业务条目 # 清理异常公钥先备份再清 cp ~/.ssh/authorized_keys /tmp/evidence/authorized_keys.bak # 编辑删除非授权条目 # 清理临时目录可疑文件确认非业务文件后 # 谨慎操作避免误删加固方面Redis 侧的核心动作是绑定内网地址、开启认证、禁用危险命令、以低权限用户运行。# redis.conf 关键加固项 bind 127.0.0.1 10.0.0.10 protected-mode yes requirepass 强密码 rename-command CONFIG rename-command FLUSHALL rename-command把CONFIG和FLUSHALL这类高危命令重命名或禁用能大幅降低被利用的风险。注意这个配置需要重启生效且重命名后运维脚本里如果用到这些命令要同步调整。系统侧则要收紧 SSH、检查安全组、补充监控。安全组只放行必要的源地址访问 6379这是最直接有效的一道防线。5. 常见问题与排查技巧实录5.1 排查过程中的典型卡点实际处置里最常卡住的地方不是技术难而是“信息对不上”。下面这张表是我整理的高频问题和应对思路基本都是踩过坑之后总结的。现象可能原因排查方向Redis 日志里看不到 CONFIG SET 记录版本较老或日志级别不够改看运行时配置与磁盘配置的差异用文件时间戳反推进程杀了又起来存在定时任务或守护脚本检查 cron、systemd、启动脚本authorized_keys 有异常但日志无登录记录公钥写入后尚未使用或登录走了其他通道结合文件时间戳和网络连接记录判断运行时配置和磁盘配置不一致攻击者用 CONFIG SET 改了内存配置导出 CONFIG GET 全量对比重点看 dir、dbfilename找不到恶意文件文件写在内存盘或被删除检查 /dev/shm、查看进程打开的文件句柄这张表里最值得说的是“运行时配置和磁盘配置不一致”这一条。很多人排查时只看磁盘上的redis.conf发现一切正常就下结论“没被改配置”结果漏掉了内存里的恶意配置。养成CONFIG GET对比的习惯能避免这类误判。5.2 几个实操心得心得一采集要快分析可以慢。现场信息是易失的进程状态、网络连接几分钟就可能变。所以采集动作要果断先把原始数据落盘分析可以事后慢慢做。我习惯写一个采集脚本一条命令把所有东西打包避免手忙脚乱漏项。心得二不要相信单一证据。一条CONFIG SET记录可能是运维自己改的一个陌生 IP 登录可能是合作方。任何单点证据都要找第二、第三个来源交叉验证证据链闭合了再下结论。这也是为什么前面反复强调多源日志比对。心得三清除前先想清楚“还会不会回来”。攻击者能进来一次说明入口没堵上。如果只清驻留点不改配置、不收安全组等于把门留着等人再进。所以清除和加固必须一起做加固没做完清除就不算完成。心得四留一份完整的处置记录。采集了什么、分析了什么、结论是什么、清除了什么、加固了什么全部记下来。一方面是复盘需要另一方面如果后续还有异常这份记录能帮你快速判断是“旧问题残留”还是“新问题”。5.3 关于日志留存的一个提醒Redis 日志默认可能只保留有限内容系统日志也有轮转策略。如果日志已经被轮转覆盖取证难度会陡增。所以日常就要把关键日志的留存周期拉长尤其是对外暴露的服务。这不是为了应急才做的事而是平时就该配好的基础工作。真到了出事那天你会发现“有日志可查”本身就是一种幸运。6. 从这次处置里沉淀下来的东西做完一次 Redis 应急最有价值的产出不是“问题解决了”而是把这次的经验变成下次能直接用的东西。我个人的习惯是每次处置完补三样一条监控规则、一份检查清单、一段复盘记录。监控规则方面针对 Redis 可以加这几条告警CONFIG SET操作告警、BGSAVE到敏感目录告警、6379 端口非白名单来源连接告警、Redis 进程启动参数变更告警。这几条覆盖了前面提到的主要利用手法成本不高但很实用。检查清单就是把第 4 节的采集项和排查项固化下来下次遇到类似情况直接照着走不用临场想。复盘记录则重点写“这次哪里判断慢了、哪里证据差点丢了”这些才是真正能提升下次处置效率的东西。最后分享一个小技巧如果你手上有多台 Redis 实例建议统一把rename-command CONFIG 配上同时把日志级别调到能记录配置变更的程度。这两件事做在前面真出事的时候日志里能直接看到“有人动了配置”排查起点会高很多。应急响应这件事功夫其实都在平时。
1. 从一条告警说起Redis 应急响应到底在查什么凌晨两点收到一条告警某台对外提供缓存服务的机器 CPU 打满、连接数暴涨业务侧开始出现间歇性超时。登录上去第一眼看top一个redis-server进程占了 300% 以上的 CPUnetstat里一堆 ESTABLISHED 连接指向陌生地址。这种场景做过运维的人多少都遇到过——Redis 因为配置不当被外部利用进而被写入恶意内容、被当作跳板或者被拿来挖矿是应急响应里非常典型的一类案例。这篇内容围绕“日志分析 Redis 应急响应”这个主题展开把我在实际处置这类事件时的完整思路、排查路径、日志取证方法和加固手段梳理一遍。核心关键词是日志分析和Redis 应急响应前者是取证的手段后者是处置的目标。适合谁看一是刚接触安全运维、遇到 Redis 异常不知道从哪下手的朋友二是有一定 Linux 基础、想系统掌握应急响应流程的从业者三是对日志取证感兴趣、想把“从日志还原攻击链”这件事做扎实的技术人员。哪怕你之前没做过应急跟着下面的思路走一遍也能建立起一套可复用的排查框架。需要先说明一点Redis 应急响应的核心不是“删掉恶意文件就完事”而是通过日志和现场痕迹把入侵路径、驻留方式、影响范围这三件事搞清楚。很多人上来就kill进程、删文件结果证据没了攻击者怎么进来的、还有没有别的后门全都说不清。所以下面我会把“先取证、再处置”的顺序贯穿始终这也是整个处置流程里最容易被忽略、却最要命的一环。2. 应急响应的整体设计思路与取证顺序2.1 为什么坚持“先取证后处置”应急响应有个基本原则在没搞清楚状况之前任何破坏现场的操作都要谨慎。我见过太多案例运维一看到异常进程直接kill -9然后重启服务业务恢复了报告写“已处置”。结果过两天同样的告警又来一遍——因为攻击者留的定时任务、SSH 公钥、计划脚本一个都没清甚至kill掉的只是个幌子进程真正的驻留点藏在别处。所以我的处置顺序固定为现场保护 → 日志与痕迹采集 → 入侵路径还原 → 影响范围评估 → 清除与加固 → 复盘。这个顺序背后的逻辑是日志和进程状态是“一次性”的进程一杀、连接一断很多线索就永久丢失了而业务中断是可以短暂容忍的两害相权先保证据。具体到 Redis 场景需要优先采集的东西包括当前进程的完整命令行和启动参数、网络连接状态、Redis 的配置文件、Redis 自身的日志文件、系统层面的登录日志和命令历史、以及可疑的定时任务和启动项。这些内容构成了后面还原攻击链的“原材料”。2.2 日志分析在应急中的定位很多人把日志分析理解成“翻翻 access.log 找可疑 IP”这太窄了。在 Redis 应急里日志分析承担三个作用确认时间线、定位入口、发现横向痕迹。确认时间线通过 Redis 日志里的启动记录、配置重载记录、异常报错结合系统日志的登录记录把“攻击者什么时候进来的、做了什么”排出先后顺序。定位入口Redis 默认端口暴露在公网且无认证是最常见的入口但也可能是通过其他服务拿到的低权限 shell 再横向过来这时候系统日志和命令历史就更关键。发现横向痕迹攻击者进来后往往会尝试连接内网其他机器、下载工具、建立持久化这些动作会在日志和文件系统里留下痕迹。理解了这三层作用你就知道为什么不能只盯着一个日志文件看——单一日志只能给你一个视角多源日志交叉比对才能拼出完整画面。2.3 处置流程的整体框架把上面的思路落成可执行的框架大致是这样一条链路隔离与保护在不影响取证的前提下通过安全组或防火墙限制异常外联但保留现场。信息采集进程、网络、配置、日志、文件系统痕迹逐项落地保存。日志分析以 Redis 日志为主线系统日志为辅助还原时间线。入侵判定确认是否被入侵、通过什么方式、留下了什么。清除加固清理驻留点、修复配置、收紧访问控制。复盘归档形成记录补充监控规则。这个框架不是死的实际处置中经常需要来回跳——比如分析日志时发现一个新线索又得回去补采现场。但大方向不能乱尤其是“采集”必须在“清除”之前完成。3. 核心细节解析Redis 被利用的常见路径与日志特征3.1 Redis 未授权访问是怎么被利用的Redis 应急里最高频的成因就是未授权访问。默认配置下 Redis 监听所有网卡、没有密码如果安全组又放开了 6379 端口等于把大门敞开。攻击者连上来之后常见的利用手法有这么几种第一种是写入 SSH 公钥。攻击者通过CONFIG SET dir把 Redis 的工作目录改到目标用户的.ssh目录再CONFIG SET dbfilename authorized_keys然后把自己构造的公钥内容作为一个 key 写进去落盘后就变成了合法的登录凭证。这种手法隐蔽性强因为后续登录走的是正常的 SSH 认证日志里看起来就是一次普通登录。第二种是写定时任务。类似地把目录改到/var/spool/cron或者/etc/cron.d写入反弹脚本或者下载执行脚本实现持久化。第三种是主从复制利用。攻击者把自己的恶意 Redis 实例作为主节点让目标从节点去同步通过FULLRESYNC把恶意模块加载进目标进程进而执行系统命令。这种手法技术门槛稍高但危害更大因为它可以在不落盘的情况下拿到命令执行能力。第四种是直接写 WebShell 或恶意脚本到 Web 目录如果目标机器同时跑着 Web 服务这就直接变成网站被控。这几种手法的共同点是都会触发CONFIG SET操作都会改变工作目录或文件名都会产生文件写入。这些动作在 Redis 日志和配置变更记录里是有迹可循的。3.2 Redis 日志里该重点看什么Redis 的日志默认输出到配置文件里logfile指定的路径没配置的话可能输出到标准输出。日志里值得重点关注的行有这么几类启动与配置加载记录能看到 Redis 启动时加载的配置文件路径、版本、端口、是否开启保护模式。如果发现启动参数里带了异常的--dir或--dbfilename要警惕。CONFIG SET相关记录Redis 在较新版本里对CONFIG SET有审计日志取决于配置和版本如果看到dir、dbfilename、appendonly被频繁修改基本可以判定有人在动配置。BGSAVE/SAVE记录写文件落盘时会触发保存如果保存的目标路径异常比如指向.ssh或 cron 目录就是明确的入侵信号。异常连接与认证失败如果开了密码认证大量AUTH失败说明有人在爆破如果没开认证日志里可能看不到连接记录这时候就得靠系统层面的网络连接日志补位。需要提醒的是不同版本的 Redis 日志详细程度差别很大老版本对CONFIG SET的记录很有限。所以不能只依赖 Redis 日志必须结合系统日志、文件系统时间戳、进程信息一起看。3.3 系统日志与文件痕迹的交叉验证Redis 日志告诉你“有人动了配置”系统日志告诉你“谁在什么时候登录了、执行了什么”。两者交叉才能把时间线钉死。系统层面重点看这几处认证日志/var/log/secure部分发行版或/var/log/auth.log看有没有异常 IP 的 SSH 登录成功记录尤其是非工作时间的登录。命令历史各用户家目录下的.bash_history攻击者如果通过 shell 操作过可能留下下载、编译、执行命令的痕迹。注意历史文件可能被清理要看文件修改时间是否异常。定时任务/var/spool/cron/下各用户的任务、/etc/cron.d/、/etc/crontab重点看有没有指向陌生地址的下载执行脚本。SSH 授权文件~/.ssh/authorized_keys的修改时间和内容有没有多出来的公钥。临时目录/tmp、/dev/shm下有没有可疑的可执行文件这两个目录是恶意程序最爱待的地方。文件系统的时间戳是很好的辅助证据。用stat看关键文件的Modify和Change时间如果authorized_keys的修改时间和 Redis 日志里某次BGSAVE的时间对得上那基本就实锤了。3.4 一个容易被忽略的点配置文件的“合法”修改有些攻击者不会大改配置而是做“最小化”的修改比如只加一行requirepass设个弱密码或者只改bind让监听范围变化。这种修改看起来像正常运维操作很容易被放过。我的经验是把配置文件和版本库或备份做 diff任何非预期的差异都要能解释清楚来源。如果解释不了就按可疑处理。4. 实操过程从现场采集到攻击链还原4.1 现场信息采集的完整清单下面这套采集动作我在多次处置里反复用过基本能覆盖 Redis 应急需要的关键信息。建议在隔离网络但保留现场的前提下执行采集结果统一存到一个独立目录方便后续分析。先看进程和网络# 记录 Redis 进程的完整信息包括启动参数 ps -ef | grep redis cat /proc/$(pgrep -o redis-server)/cmdline | tr \0 # 记录当前所有网络连接重点看 6379 相关的 ss -antp | grep 6379 netstat -antp | grep 6379 # 记录进程打开的文件和网络句柄 lsof -p $(pgrep -o redis-server)/proc/pid/cmdline这个文件很关键它保留了进程启动时的完整参数。如果 Redis 是被攻击者用异常参数拉起来的比如指定了奇怪的--dir这里能直接看到。lsof则能看出进程当前打开了哪些文件有没有在往敏感目录写东西。再看配置和日志# 备份当前生效的配置文件 cp /etc/redis/redis.conf /tmp/evidence/redis.conf.bak # 定位实际使用的配置文件启动参数里通常有 grep -o \-\-config[^ ]*\|[^ ]*\.conf /proc/$(pgrep -o redis-server)/cmdline # 采集 Redis 日志 find / -name *.log -path *redis* 2/dev/null tail -n 500 /var/log/redis/redis-server.log /tmp/evidence/redis_tail.log配置文件的采集要注意采集的是当前磁盘上的文件不是内存里的配置。如果攻击者用CONFIG SET改了运行时配置但没写回文件磁盘上的配置看起来是正常的这时候就得靠CONFIG GET把运行时配置也导出来对比。# 导出运行时配置需要能连上 Redis redis-cli CONFIG GET * /tmp/evidence/redis_runtime_config.txt这一步经常被跳过但它恰恰能发现“内存配置和磁盘配置不一致”的情况而这种不一致本身就是强入侵信号。最后是系统层面的痕迹# 认证日志 cp /var/log/secure /tmp/evidence/ 2/dev/null cp /var/log/auth.log /tmp/evidence/ 2/dev/null # 定时任务 crontab -l /tmp/evidence/crontab_root.txt 2/dev/null ls -la /etc/cron.d/ /var/spool/cron/ /tmp/evidence/cron_list.txt 2/dev/null # SSH 授权文件 ls -la ~/.ssh/ /tmp/evidence/ssh_dir.txt 2/dev/null cat ~/.ssh/authorized_keys /tmp/evidence/authorized_keys.txt 2/dev/null # 临时目录可疑文件 ls -lat /tmp /dev/shm /tmp/evidence/tmp_list.txt 2/dev/null采集完这些手上就有了进程、网络、配置、日志、文件五类证据足够支撑后续分析。4.2 日志分析还原时间线的具体做法拿到日志后我的做法是先做“粗筛”再做“精读”。粗筛是把所有日志里和 Redis 相关的、和异常时间点相关的行先捞出来精读是逐条看这些行的上下文。以 Redis 日志为例先按关键词过滤# 找出配置变更、保存、异常相关的行 grep -Ei config|save|bgsave|dir|dbfilename|error|warning|accept /tmp/evidence/redis_tail.log如果日志里有CONFIG SET dir或CONFIG SET dbfilename的记录把这几行的时间点记下来然后去系统日志里找同一时间段的登录和命令执行记录。时间对齐是还原时间线的核心动作。举个典型的还原过程Redis 日志显示某时刻有一次CONFIG SET dir /root/.ssh紧接着有一次BGSAVE系统日志显示同一分钟有一个陌生 IP 的 SSH 登录成功authorized_keys的修改时间也落在这一分钟。三条线索指向同一个结论攻击者通过 Redis 写入了 SSH 公钥并用这个公钥登录了系统。这个链条一旦闭合入侵路径就清楚了。如果 Redis 日志信息不足老版本常见就退而求其次用文件时间戳反推。stat一下authorized_keys、cron 文件、/tmp下的可疑文件把修改时间排个序再和系统登录日志比对同样能还原出大致顺序。4.3 入侵判定与影响范围评估时间线还原出来之后要回答两个问题是不是真被入侵了以及影响范围有多大。判定入侵的证据优先级大致是异常的公钥或定时任务 运行时配置与磁盘配置不一致 异常的进程启动参数 大量认证失败 单纯的端口暴露。前两条基本可以直接定性后几条需要结合业务背景判断。影响范围评估则要看攻击者进来后做了什么有没有横向连接内网其他主机看网络连接记录和命令历史里的ssh、scp、curl记录。有没有下载额外的工具或恶意程序看/tmp、/dev/shm下的文件和命令历史里的wget、curl。有没有动过其他服务的数据看数据库、Web 目录的修改时间。有没有创建新的系统用户看/etc/passwd的修改时间和新增条目。这一步的目的是给后续清除划定范围——如果只清 Redis 相关的驻留点但攻击者还留了别的后门等于白干。4.4 清除与加固的落地操作清除的顺序是“先断持久化、再清文件、最后改配置”。断持久化指的是把攻击者留的定时任务、SSH 公钥、启动脚本先摘掉防止清除过程中被重新拉起。# 清理异常定时任务确认内容后操作 crontab -e # 逐条核对删除非业务条目 # 清理异常公钥先备份再清 cp ~/.ssh/authorized_keys /tmp/evidence/authorized_keys.bak # 编辑删除非授权条目 # 清理临时目录可疑文件确认非业务文件后 # 谨慎操作避免误删加固方面Redis 侧的核心动作是绑定内网地址、开启认证、禁用危险命令、以低权限用户运行。# redis.conf 关键加固项 bind 127.0.0.1 10.0.0.10 protected-mode yes requirepass 强密码 rename-command CONFIG rename-command FLUSHALL rename-command把CONFIG和FLUSHALL这类高危命令重命名或禁用能大幅降低被利用的风险。注意这个配置需要重启生效且重命名后运维脚本里如果用到这些命令要同步调整。系统侧则要收紧 SSH、检查安全组、补充监控。安全组只放行必要的源地址访问 6379这是最直接有效的一道防线。5. 常见问题与排查技巧实录5.1 排查过程中的典型卡点实际处置里最常卡住的地方不是技术难而是“信息对不上”。下面这张表是我整理的高频问题和应对思路基本都是踩过坑之后总结的。现象可能原因排查方向Redis 日志里看不到 CONFIG SET 记录版本较老或日志级别不够改看运行时配置与磁盘配置的差异用文件时间戳反推进程杀了又起来存在定时任务或守护脚本检查 cron、systemd、启动脚本authorized_keys 有异常但日志无登录记录公钥写入后尚未使用或登录走了其他通道结合文件时间戳和网络连接记录判断运行时配置和磁盘配置不一致攻击者用 CONFIG SET 改了内存配置导出 CONFIG GET 全量对比重点看 dir、dbfilename找不到恶意文件文件写在内存盘或被删除检查 /dev/shm、查看进程打开的文件句柄这张表里最值得说的是“运行时配置和磁盘配置不一致”这一条。很多人排查时只看磁盘上的redis.conf发现一切正常就下结论“没被改配置”结果漏掉了内存里的恶意配置。养成CONFIG GET对比的习惯能避免这类误判。5.2 几个实操心得心得一采集要快分析可以慢。现场信息是易失的进程状态、网络连接几分钟就可能变。所以采集动作要果断先把原始数据落盘分析可以事后慢慢做。我习惯写一个采集脚本一条命令把所有东西打包避免手忙脚乱漏项。心得二不要相信单一证据。一条CONFIG SET记录可能是运维自己改的一个陌生 IP 登录可能是合作方。任何单点证据都要找第二、第三个来源交叉验证证据链闭合了再下结论。这也是为什么前面反复强调多源日志比对。心得三清除前先想清楚“还会不会回来”。攻击者能进来一次说明入口没堵上。如果只清驻留点不改配置、不收安全组等于把门留着等人再进。所以清除和加固必须一起做加固没做完清除就不算完成。心得四留一份完整的处置记录。采集了什么、分析了什么、结论是什么、清除了什么、加固了什么全部记下来。一方面是复盘需要另一方面如果后续还有异常这份记录能帮你快速判断是“旧问题残留”还是“新问题”。5.3 关于日志留存的一个提醒Redis 日志默认可能只保留有限内容系统日志也有轮转策略。如果日志已经被轮转覆盖取证难度会陡增。所以日常就要把关键日志的留存周期拉长尤其是对外暴露的服务。这不是为了应急才做的事而是平时就该配好的基础工作。真到了出事那天你会发现“有日志可查”本身就是一种幸运。6. 从这次处置里沉淀下来的东西做完一次 Redis 应急最有价值的产出不是“问题解决了”而是把这次的经验变成下次能直接用的东西。我个人的习惯是每次处置完补三样一条监控规则、一份检查清单、一段复盘记录。监控规则方面针对 Redis 可以加这几条告警CONFIG SET操作告警、BGSAVE到敏感目录告警、6379 端口非白名单来源连接告警、Redis 进程启动参数变更告警。这几条覆盖了前面提到的主要利用手法成本不高但很实用。检查清单就是把第 4 节的采集项和排查项固化下来下次遇到类似情况直接照着走不用临场想。复盘记录则重点写“这次哪里判断慢了、哪里证据差点丢了”这些才是真正能提升下次处置效率的东西。最后分享一个小技巧如果你手上有多台 Redis 实例建议统一把rename-command CONFIG 配上同时把日志级别调到能记录配置变更的程度。这两件事做在前面真出事的时候日志里能直接看到“有人动了配置”排查起点会高很多。应急响应这件事功夫其实都在平时。
