以下是第二周周五学习内容的详细展开聚焦系统日志的分析、筛选与安全事件溯源。今天的所有操作都围绕/var/log展开你将亲自动手提取入侵痕迹、统计攻击行为真正体验从“学命令”到“做防御”的转变。第二周·周五日志查看与筛选——journalctl、tail、grep、awk 在 /var/log 中的应用 今日学习目标达成效果能说出Linux 下至少 4 种关键日志文件的路径及作用如/var/log/auth.log、/var/log/syslog、/var/log/nginx/access.log、/var/log/messages能使用tail动态监控日志文件的最新写入并配合-f选项实时跟踪能熟练使用journalctl查看 systemd 系统日志按时间、服务、优先级过滤能结合grep、awk和管道对日志进行精细筛选与统计如提取指定时间段的失败登录、统计某一 IP 的访问次数能从 auth.log 中提取所有失败登录尝试记录并判断是否存在暴力破解行为能完成测试题查看最近 20 条系统日志、统计 auth.log 中 “Failed password” 出现次数能从安全角度解释日志分析在应急响应、入侵检测、合规审计中的核心作用。 一、日志文件体系系统运行的黑匣子Linux 系统中绝大多数日志集中存放在/var/log目录下遵循传统的 syslog 协议或 systemd-journald 的统一管理。不同的发行版可能略有差异但以下关键日志文件必须熟悉日志文件主要记录内容安全用途/var/log/auth.log(Debian/Ubuntu) 或/var/log/secure(RHEL/CentOS)认证相关事件所有用户登录本地、SSH、sudo 提权、认证失败等暴力破解检测、异常登录溯源、权限提升监控/var/log/syslog(Debian/Ubuntu) 或/var/log/messages(RHEL/CentOS)系统全局日志各种系统服务、内核消息异常服务崩溃、硬件错误、资源耗尽报警/var/log/nginx/access.log或/var/log/apache2/access.logWeb 服务器的访问记录每行一次请求攻击行为分析SQL注入扫描、路径爆破、IP 追踪/var/log/nginx/error.logWeb 服务器错误日志发现错误注入、后门访问异常、服务漏洞探测/var/log/faillog记录用户登录失败次数可能为二进制快速查看账户锁定状态/var/log/lastlog所有用户最后一次登录的时间和来源检查未授权登录/var/log/audit/audit.log审计守护进程的详细事件若开启合规审计、敏感文件操作追踪journalctl(systemd 系统)统一日志系统整合内核、启动、服务等日志按时间、服务精准查询比 grep 更高效安全视角攻击者在渗透成功后通常会尝试清理日志文件因此日志是否完整、权限是否严格、是否被篡改是调查的关键。防御人员必须会分析日志才能还原攻击链、确定入侵范围和损失。 二、tail 与日志动态监控tail用于查看文件的末尾几行最常搭配-f选项实时监控日志的追加内容。基本用法tail/var/log/auth.log# 默认显示最后 10 行tail-n20/var/log/auth.log# 显示最后 20 行测试题一基础tail-f/var/log/auth.log# 跟踪文件新写入会实时显示CtrlC 退出tail-F/var/log/auth.log# 与 -f 类似但当文件被轮转重命名后会继续追踪新文件更健壮实时监控多个窗口打开两个终端一个执行tail -f /var/log/auth.log另一个用ssh尝试登录故意输错密码观察实时刷新的“Failed password”信息。测试题一解答查看最近 20 条系统日志以 syslog 为例tail-n20/var/log/syslog或使用journalctl -n 20后续详解。 三、journalctl现代化日志查询利器在 systemd 系统中journalctl提供强大的查询功能日志存储可能为二进制不直接依赖纯文本文件但通常仍会同步到 syslog。最常用的命令# 查看所有系统日志相当于遍历全部服务输出journalctl# 显示最近的 20 条日志测试题一的替代解journalctl-n20# 从最新的开始显示实时跟踪类似 tail -fjournalctl-f# 查看本次启动以来的日志journalctl-b# 查看指定服务的日志如 sshdjournalctl-ussh# 按时间过滤例如查看过去1小时的日志journalctl--since1 hour agojournalctl--since2026-08-04 10:00:00--until2026-08-04 11:00:00# 按优先级过滤0 emerg ~ 7 debugjournalctl-perr# 合并多个条件查看sshd服务且优先级为err以上的日志journalctl-ussh-perr# 输出为 JSON 或更可读的格式方便脚本处理journalctl-ojson-pretty安全实战模拟一次 SSH 登录失败然后快速定位。# 终端1实时监控认证日志journalctl-ussh-f# 终端2故意错误登录sshrootlocalhost你将看到类似Failed password for root from 127.0.0.1 port ...的记录。用 journalctl 而非直接文件的好处是可以跨服务、精确到微秒。 四、grep 在日志分析中的高级用法日志分析的本质是“大海捞针”grep是最基本的筛子。今天我们结合正则表达式和上下文功能。1. 基础筛选# 提取所有包含 Failed password 的行grepFailed password/var/log/auth.log2. 显示行号、上下文、统计-n显示行号便于后续定位-C 3显示匹配行的前后各 3 行Context看清失败前的连接和失败后的处理-B 2前 2 行-A 3后 3 行-c统计匹配行数测试题二解答统计 auth.log 中 “Failed password” 出现次数grep-cFailed password/var/log/auth.log这条命令直接返回数字如42表示失败登录尝试 42 次。如果一天内数千次几乎可以断定遭遇暴力破解。3. 正则与扩展使用-E启用扩展正则表达式或egrep。提取所有失败登录的 IP 地址基础手法grepFailed password/var/log/auth.log|grep-oE[0-9]\.[0-9]\.[0-9]\.[0-9]|sort|uniq-c|sort-nr这条管道链会统计每个 IP 的失败次数降序排列一眼看出攻击源。4. 过滤时间段日志行通常包含时间戳如Aug 4 10:15:30可用 grep 正则匹配grep^Aug 4 10:/var/log/auth.log|grepFailed password 五、awk文本处理利器当我们需要提取日志中的特定字段并进行计算时awk是不可替代的。awk默认以空格或 Tab 分隔字段$1$2… 依次表示字段。1. 打印指定列# 打印 auth.log 的第1列月和第2列日以及第3列时间awk{print $1, $2, $3}/var/log/auth.log2. 条件过滤并输出字段# 找出所有包含 Failed password 的行并打印第1、2、3、9、10、11字段通常对应时间、用户、IP等视实际格式awk/Failed password/ {print $1,$2,$3,$9,$11}/var/log/auth.log由于不同系统日志格式有差异建议先用head查看样例行再确定字段位置。Ubuntu 的 auth.log 格式类似Aug 4 12:34:56 server sshd[1234]: Failed password for root from 192.168.1.100 port 22 ssh2则$1月$2日$3时间$4主机名$5进程…$9用户名$11来源 IP。灵活调整。3. 统计与数组# 统计每个IP的失败登录次数awk/Failed password/ {count[$11]} END {for (ip in count) print ip, count[ip]}/var/log/auth.log这是经典的 awk 统计模版不需要管道多次调用效率高。✍️ 六、动手实践日志分析实验室所有实践假设你有一个标准的 Ubuntu/Debian 系统auth.log 可用如果是 CentOS 请用/var/log/secure代替。实践 1实时监控 SSH 认证失败打开终端执行tail -f /var/log/auth.log或journalctl -u ssh -f另开一个终端故意用错误的账号密码 SSH 本机ssh fakeuser127.0.0.1观察实时输出的日志注意 “Failed password” 和 “Connection closed” 记录停止监控再用grep提取刚才的失败记录grep Failed password /var/log/auth.log | tail -5实践 2提取所有失败登录记录生成报告# 生成一个失败登录汇总文件grepFailed password/var/log/auth.log~/failed_logins.txt# 查看前10行head~/failed_logins.txt# 统计总次数wc-l~/failed_logins.txt实践 3暴力破解检测# 统计每个IP的失败次数并仅列出失败超过5次的IP判断为可疑扫描grepFailed password/var/log/auth.log|grep-oE[0-9]\.[0-9]\.[0-9]\.[0-9]|sort|uniq-c|awk$1 5 {print $2, $1}如果输出中有大量来自同一 IP 的记录则表示该 IP 正在尝试暴力破解。实践 4使用 journalctl 完成测试题# 查看最近20条系统日志journalctl-n20# 统计 Failed password 次数在journal中journalctl|grep-cFailed password实践 5模拟日志清理与权限检查# 检查日志目录权限ls-ld/var/log# 确保只有 root 有写权限常见为 drwxr-xr-x 或更严格# 攻击者可能尝试 echo /var/log/auth.log 或使用 shred 擦除日志防御者需设置文件属性 a (仅追加) 七、课后测试题与解析测试题 1查看最近 20 条系统日志的命令有哪些请写出两种方法。参考答案方法一使用 tail 直接查看 syslog 文件Ubuntu 下为/var/log/syslogtail -n 20 /var/log/syslog方法二使用 journalctljournalctl -n 20若系统使用 journald第二种会统一显示所有服务的最新日志更全面测试题 2统计 /var/log/auth.log 中 “Failed password” 出现次数写出命令并解释如何通过该次数判断是否遭受暴力破解。参考答案grep -c Failed password /var/log/auth.log该命令返回一个数字。如果短时间内例如1小时或1天内该数字异常高比如数千次且来自少数几个外部 IP则极有可能服务器正在遭受暴力破解攻击。防御人员应进一步提取攻击源 IP并采取临时封禁、加强密码策略或限制登录尝试等措施。如果次数极少个位数可能是用户误输入密码。附加思考如果系统使用journalctl如何完成相同统计journalctl | grep -c Failed password或者journalctl -u ssh | grep -c Failed password。✅ 今日学习效果自检清单我能说出至少 3 种常用日志文件的路径和记录内容我会使用tail -f实时监控日志并识别出新写入的失败登录我可以用journalctl -u ssh或journalctl -n查询日志我能用grep和管道提取失败登录记录并统计 IP 的出现次数我成功从 auth.log 中提取了所有 “Failed password” 行并统计了总数我理解日志分析对于暴力破解检测和应急响应的重要性我意识到保护日志文件完整性权限、append only是安全基线之一⚠️ 阶段避坑重点不要直接使用grep读取整个大日志文件而不做优化可以使用grep配合--include、-r递归但避免在/var/log下无差别搜索所有文件否则可能包含二进制日志导致乱码。对于超大日志先考虑使用tail、journalctl --since缩小范围。不要忽视日志轮替文件如auth.log.1、syslog.2.gz是旧的压缩归档必要时使用zgrep搜索压缩文件zgrep Failed password /var/log/auth.log.2.gz。权限问题普通用户可能无法读取/var/log/auth.log通常只有 root 和 adm 组可读分析时记得加sudo。不要为了“方便”而把日志文件权限改成 777这会严重破坏审计安全。注意日志格式的差异不同发行版日志格式不同awk提取字段前先用head观察样例行避免出现空的统计结果。不要只依赖一种工具journalctl虽然强大但如果 journald 日志存储量过大或被攻击者清空文件形式的日志可能是最后凭证两者应结合使用。明天周六我们将进行第二周综合实验配置一个简单的 Web 服务 (nginx)查看端口和日志。届时你将综合使用本周学到的所有命令——安装 nginx、确认进程监听、查看访问日志与错误日志并分析日志中的异常请求正式将 Linux 基础运维能力转化为安全分析能力。请确保今天的日志分析操作已经熟练明天会直接应用到 Web 服务器的日志上。 【八个月网安课程】第二周·周五：日志查看与筛选——journalctl、tail、grep、awk 在 /var/log 中的应用
以下是第二周周五学习内容的详细展开聚焦系统日志的分析、筛选与安全事件溯源。今天的所有操作都围绕/var/log展开你将亲自动手提取入侵痕迹、统计攻击行为真正体验从“学命令”到“做防御”的转变。第二周·周五日志查看与筛选——journalctl、tail、grep、awk 在 /var/log 中的应用 今日学习目标达成效果能说出Linux 下至少 4 种关键日志文件的路径及作用如/var/log/auth.log、/var/log/syslog、/var/log/nginx/access.log、/var/log/messages能使用tail动态监控日志文件的最新写入并配合-f选项实时跟踪能熟练使用journalctl查看 systemd 系统日志按时间、服务、优先级过滤能结合grep、awk和管道对日志进行精细筛选与统计如提取指定时间段的失败登录、统计某一 IP 的访问次数能从 auth.log 中提取所有失败登录尝试记录并判断是否存在暴力破解行为能完成测试题查看最近 20 条系统日志、统计 auth.log 中 “Failed password” 出现次数能从安全角度解释日志分析在应急响应、入侵检测、合规审计中的核心作用。 一、日志文件体系系统运行的黑匣子Linux 系统中绝大多数日志集中存放在/var/log目录下遵循传统的 syslog 协议或 systemd-journald 的统一管理。不同的发行版可能略有差异但以下关键日志文件必须熟悉日志文件主要记录内容安全用途/var/log/auth.log(Debian/Ubuntu) 或/var/log/secure(RHEL/CentOS)认证相关事件所有用户登录本地、SSH、sudo 提权、认证失败等暴力破解检测、异常登录溯源、权限提升监控/var/log/syslog(Debian/Ubuntu) 或/var/log/messages(RHEL/CentOS)系统全局日志各种系统服务、内核消息异常服务崩溃、硬件错误、资源耗尽报警/var/log/nginx/access.log或/var/log/apache2/access.logWeb 服务器的访问记录每行一次请求攻击行为分析SQL注入扫描、路径爆破、IP 追踪/var/log/nginx/error.logWeb 服务器错误日志发现错误注入、后门访问异常、服务漏洞探测/var/log/faillog记录用户登录失败次数可能为二进制快速查看账户锁定状态/var/log/lastlog所有用户最后一次登录的时间和来源检查未授权登录/var/log/audit/audit.log审计守护进程的详细事件若开启合规审计、敏感文件操作追踪journalctl(systemd 系统)统一日志系统整合内核、启动、服务等日志按时间、服务精准查询比 grep 更高效安全视角攻击者在渗透成功后通常会尝试清理日志文件因此日志是否完整、权限是否严格、是否被篡改是调查的关键。防御人员必须会分析日志才能还原攻击链、确定入侵范围和损失。 二、tail 与日志动态监控tail用于查看文件的末尾几行最常搭配-f选项实时监控日志的追加内容。基本用法tail/var/log/auth.log# 默认显示最后 10 行tail-n20/var/log/auth.log# 显示最后 20 行测试题一基础tail-f/var/log/auth.log# 跟踪文件新写入会实时显示CtrlC 退出tail-F/var/log/auth.log# 与 -f 类似但当文件被轮转重命名后会继续追踪新文件更健壮实时监控多个窗口打开两个终端一个执行tail -f /var/log/auth.log另一个用ssh尝试登录故意输错密码观察实时刷新的“Failed password”信息。测试题一解答查看最近 20 条系统日志以 syslog 为例tail-n20/var/log/syslog或使用journalctl -n 20后续详解。 三、journalctl现代化日志查询利器在 systemd 系统中journalctl提供强大的查询功能日志存储可能为二进制不直接依赖纯文本文件但通常仍会同步到 syslog。最常用的命令# 查看所有系统日志相当于遍历全部服务输出journalctl# 显示最近的 20 条日志测试题一的替代解journalctl-n20# 从最新的开始显示实时跟踪类似 tail -fjournalctl-f# 查看本次启动以来的日志journalctl-b# 查看指定服务的日志如 sshdjournalctl-ussh# 按时间过滤例如查看过去1小时的日志journalctl--since1 hour agojournalctl--since2026-08-04 10:00:00--until2026-08-04 11:00:00# 按优先级过滤0 emerg ~ 7 debugjournalctl-perr# 合并多个条件查看sshd服务且优先级为err以上的日志journalctl-ussh-perr# 输出为 JSON 或更可读的格式方便脚本处理journalctl-ojson-pretty安全实战模拟一次 SSH 登录失败然后快速定位。# 终端1实时监控认证日志journalctl-ussh-f# 终端2故意错误登录sshrootlocalhost你将看到类似Failed password for root from 127.0.0.1 port ...的记录。用 journalctl 而非直接文件的好处是可以跨服务、精确到微秒。 四、grep 在日志分析中的高级用法日志分析的本质是“大海捞针”grep是最基本的筛子。今天我们结合正则表达式和上下文功能。1. 基础筛选# 提取所有包含 Failed password 的行grepFailed password/var/log/auth.log2. 显示行号、上下文、统计-n显示行号便于后续定位-C 3显示匹配行的前后各 3 行Context看清失败前的连接和失败后的处理-B 2前 2 行-A 3后 3 行-c统计匹配行数测试题二解答统计 auth.log 中 “Failed password” 出现次数grep-cFailed password/var/log/auth.log这条命令直接返回数字如42表示失败登录尝试 42 次。如果一天内数千次几乎可以断定遭遇暴力破解。3. 正则与扩展使用-E启用扩展正则表达式或egrep。提取所有失败登录的 IP 地址基础手法grepFailed password/var/log/auth.log|grep-oE[0-9]\.[0-9]\.[0-9]\.[0-9]|sort|uniq-c|sort-nr这条管道链会统计每个 IP 的失败次数降序排列一眼看出攻击源。4. 过滤时间段日志行通常包含时间戳如Aug 4 10:15:30可用 grep 正则匹配grep^Aug 4 10:/var/log/auth.log|grepFailed password 五、awk文本处理利器当我们需要提取日志中的特定字段并进行计算时awk是不可替代的。awk默认以空格或 Tab 分隔字段$1$2… 依次表示字段。1. 打印指定列# 打印 auth.log 的第1列月和第2列日以及第3列时间awk{print $1, $2, $3}/var/log/auth.log2. 条件过滤并输出字段# 找出所有包含 Failed password 的行并打印第1、2、3、9、10、11字段通常对应时间、用户、IP等视实际格式awk/Failed password/ {print $1,$2,$3,$9,$11}/var/log/auth.log由于不同系统日志格式有差异建议先用head查看样例行再确定字段位置。Ubuntu 的 auth.log 格式类似Aug 4 12:34:56 server sshd[1234]: Failed password for root from 192.168.1.100 port 22 ssh2则$1月$2日$3时间$4主机名$5进程…$9用户名$11来源 IP。灵活调整。3. 统计与数组# 统计每个IP的失败登录次数awk/Failed password/ {count[$11]} END {for (ip in count) print ip, count[ip]}/var/log/auth.log这是经典的 awk 统计模版不需要管道多次调用效率高。✍️ 六、动手实践日志分析实验室所有实践假设你有一个标准的 Ubuntu/Debian 系统auth.log 可用如果是 CentOS 请用/var/log/secure代替。实践 1实时监控 SSH 认证失败打开终端执行tail -f /var/log/auth.log或journalctl -u ssh -f另开一个终端故意用错误的账号密码 SSH 本机ssh fakeuser127.0.0.1观察实时输出的日志注意 “Failed password” 和 “Connection closed” 记录停止监控再用grep提取刚才的失败记录grep Failed password /var/log/auth.log | tail -5实践 2提取所有失败登录记录生成报告# 生成一个失败登录汇总文件grepFailed password/var/log/auth.log~/failed_logins.txt# 查看前10行head~/failed_logins.txt# 统计总次数wc-l~/failed_logins.txt实践 3暴力破解检测# 统计每个IP的失败次数并仅列出失败超过5次的IP判断为可疑扫描grepFailed password/var/log/auth.log|grep-oE[0-9]\.[0-9]\.[0-9]\.[0-9]|sort|uniq-c|awk$1 5 {print $2, $1}如果输出中有大量来自同一 IP 的记录则表示该 IP 正在尝试暴力破解。实践 4使用 journalctl 完成测试题# 查看最近20条系统日志journalctl-n20# 统计 Failed password 次数在journal中journalctl|grep-cFailed password实践 5模拟日志清理与权限检查# 检查日志目录权限ls-ld/var/log# 确保只有 root 有写权限常见为 drwxr-xr-x 或更严格# 攻击者可能尝试 echo /var/log/auth.log 或使用 shred 擦除日志防御者需设置文件属性 a (仅追加) 七、课后测试题与解析测试题 1查看最近 20 条系统日志的命令有哪些请写出两种方法。参考答案方法一使用 tail 直接查看 syslog 文件Ubuntu 下为/var/log/syslogtail -n 20 /var/log/syslog方法二使用 journalctljournalctl -n 20若系统使用 journald第二种会统一显示所有服务的最新日志更全面测试题 2统计 /var/log/auth.log 中 “Failed password” 出现次数写出命令并解释如何通过该次数判断是否遭受暴力破解。参考答案grep -c Failed password /var/log/auth.log该命令返回一个数字。如果短时间内例如1小时或1天内该数字异常高比如数千次且来自少数几个外部 IP则极有可能服务器正在遭受暴力破解攻击。防御人员应进一步提取攻击源 IP并采取临时封禁、加强密码策略或限制登录尝试等措施。如果次数极少个位数可能是用户误输入密码。附加思考如果系统使用journalctl如何完成相同统计journalctl | grep -c Failed password或者journalctl -u ssh | grep -c Failed password。✅ 今日学习效果自检清单我能说出至少 3 种常用日志文件的路径和记录内容我会使用tail -f实时监控日志并识别出新写入的失败登录我可以用journalctl -u ssh或journalctl -n查询日志我能用grep和管道提取失败登录记录并统计 IP 的出现次数我成功从 auth.log 中提取了所有 “Failed password” 行并统计了总数我理解日志分析对于暴力破解检测和应急响应的重要性我意识到保护日志文件完整性权限、append only是安全基线之一⚠️ 阶段避坑重点不要直接使用grep读取整个大日志文件而不做优化可以使用grep配合--include、-r递归但避免在/var/log下无差别搜索所有文件否则可能包含二进制日志导致乱码。对于超大日志先考虑使用tail、journalctl --since缩小范围。不要忽视日志轮替文件如auth.log.1、syslog.2.gz是旧的压缩归档必要时使用zgrep搜索压缩文件zgrep Failed password /var/log/auth.log.2.gz。权限问题普通用户可能无法读取/var/log/auth.log通常只有 root 和 adm 组可读分析时记得加sudo。不要为了“方便”而把日志文件权限改成 777这会严重破坏审计安全。注意日志格式的差异不同发行版日志格式不同awk提取字段前先用head观察样例行避免出现空的统计结果。不要只依赖一种工具journalctl虽然强大但如果 journald 日志存储量过大或被攻击者清空文件形式的日志可能是最后凭证两者应结合使用。明天周六我们将进行第二周综合实验配置一个简单的 Web 服务 (nginx)查看端口和日志。届时你将综合使用本周学到的所有命令——安装 nginx、确认进程监听、查看访问日志与错误日志并分析日志中的异常请求正式将 Linux 基础运维能力转化为安全分析能力。请确保今天的日志分析操作已经熟练明天会直接应用到 Web 服务器的日志上。