尧图网页设计 
简介这份《网络安全技术》PDF文档资料面向备考信息安全、网络攻防相关课程的学生与自学者聚焦网络安全基础理论与常见考点梳理。内容以选择题、填空题和简答题形式覆盖社会工程学攻击、不可否认性、协议与服务脆弱性、嗅探器防护、防火墙风险策略、黑客攻击流程、缓冲区溢出、IP欺骗、对称与非对称密码算法、Kerberos认证、IPSec协议、恶意代码及防火墙拓扑等核心知识点并附有参考答案与解析思路便于对照复习与查漏补缺。资源包共1个PDF文件大小约205KB轻量便携适合在电脑或移动设备上随时翻阅。目前已有714人学习下载可作为课堂笔记补充、期末冲刺或认证考试前的快速自测材料帮助读者在有限时间内串联零散概念、强化记忆高频考点。1. 从一份《网络安全技术》PDF 说起为什么大多数人存了资料却搭不起防线很多人手里都躺着几份《网络安全技术》的 PDF可能是课程讲义、培训资料也可能是从某个技术群里顺手存下来的。存的时候雄心勃勃打开看了两章 TCP/IP 和密码学基础然后就再也没翻过。问题不在于资料不好而在于这类文档天然是「知识罗列」结构——它告诉你对称加密和非对称加密的区别却不告诉你一台刚上线的 Linux 服务器前 24 小时该关哪些端口、该看哪些日志。你真正需要的不是把 PDF 从头读到尾而是把它当成一张地图按图索骥地在自己环境里搭出一条能跑起来、能验证、能持续维护的防线。这篇内容面向的是手里有资料但不知道怎么落地的一线开发者和运维人员我会把《网络安全技术》里最核心的几块——资产梳理、访问控制、流量监测、日志审计——拆成可以照着做的步骤每一步都告诉你为什么这么做、参数怎么调、哪里容易翻车。2. 资产梳理与攻击面收敛先把家底摸清楚再谈防护2.1 为什么资产清单是安全技术的起点《网络安全技术》这类资料通常从密码学或者网络协议讲起但真正落到实操第一步永远是资产梳理。你连自己有多少台机器、跑了哪些服务、开了哪些端口都不清楚后面谈防火墙策略、入侵检测都是空中楼阁。常见做法是先做被动资产发现再做主动端口扫描两者交叉验证。被动发现靠流量镜像或者交换机 MAC 表主动扫描用 nmap 这类工具。我一般会先用被动方式跑一周拿到一份「实际在通信的 IP 列表」再用 nmap 对这份列表做精准扫描避免全网段盲扫触发告警。资产梳理的输出不是一张 Excel 就完事而是要形成三个东西IP-服务-负责人 的映射表、每个服务的暴露面评级、以及变更记录机制。没有变更记录三个月后这份表就废了。2.2 用 nmap 做精准端口扫描与结果解析假设你已经通过被动流量拿到了一份活跃 IP 列表存为alive_hosts.txt每行一个 IP。下面这条命令是我常用的扫描方式# -sS: SYN 半开扫描速度快且不易被应用层日志记录 # -sV: 服务版本探测用于判断具体中间件和版本 # -O: 操作系统指纹识别辅助判断补丁级别 # --scriptbanner: 抓取服务 banner补充版本信息 # -p-: 全端口扫描1-65535 # -T4: 时序模板内网环境可用公网建议 T2 避免丢包 # -oA: 同时输出三种格式方便后续解析 nmap -sS -sV -O --scriptbanner -p- -T4 -iL alive_hosts.txt -oA scan_result扫描完成后scan_result.xml可以用 Python 解析成结构化表格。下面这段脚本把 XML 里的 IP、端口、服务、版本提取成 CSVimport xml.etree.ElementTree as ET import csv tree ET.parse(scan_result.xml) root tree.getroot() with open(assets.csv, w, newline) as f: writer csv.writer(f) writer.writerow([ip, port, protocol, service, version]) for host in root.findall(host): ip host.find(address).get(addr) for port in host.findall(.//port): portid port.get(portid) proto port.get(protocol) svc port.find(service) if svc is not None: name svc.get(name, ) ver svc.get(version, ) writer.writerow([ip, portid, proto, name, ver])这段脚本的逻辑很直接遍历 XML 里每个 host 的每个 port 节点把服务名和版本号抽出来。参数上需要注意的是如果 nmap 没识别出版本version字段会是空字符串后续做暴露面评级时要把这类端口标记为「未知服务」优先人工确认。2.3 攻击面收敛的三个判断维度拿到资产表之后收敛攻击面不是简单地「关端口」而是按三个维度做判断暴露范围公网/内网/本地、服务必要性业务是否依赖、替代方案能否加认证或换协议。我一般会做一张表端口服务暴露范围必要性处置建议22SSH公网高改非标端口密钥登录fail2ban3306MySQL内网高绑定内网 IP强密码审计日志6379Redis内网中加密码rename-commandbind9200ES内网低加认证或仅本地监听这张表的用法是公网高必要性做加固公网低必要性直接关内网低必要性评估后关或加访问控制。Redis 和 ES 是血泪经验里翻车最多的两个默认无认证加上内网横向移动一旦边界被突破就是连锁反应。3. 访问控制与身份认证从「能连上」到「只能该连的人连」3.1 最小权限原则在主机层的落地方式《网络安全技术》里讲访问控制模型DAC、MAC、RBAC讲得很细但落到一台具体机器上核心就三件事谁能登录、登录后能干什么、干了什么有没有记录。Linux 环境下我一般按这个顺序做先禁用 root 远程登录再建普通用户并配置 sudo 白名单最后用 auditd 记录关键操作。# /etc/ssh/sshd_config 关键配置 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AllowUsers deploy ops MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2改完sshd_config后先别急着重启 sshd用sshd -t测试配置语法确认无误再systemctl reload sshd。翻车场景很常见配置写错导致 sshd 起不来如果当前会话断开就彻底连不上了。所以改之前务必保留一个已登录的会话不要退出。3.2 sudo 白名单与命令审计的配置普通用户建好后不要直接给 ALL 权限。按角色拆分 sudoers 文件放在/etc/sudoers.d/下每个角色一个文件# /etc/sudoers.d/deploy deploy ALL(root) NOPASSWD: /bin/systemctl restart app, /bin/systemctl status app # /etc/sudoers.d/ops ops ALL(root) /usr/bin/journalctl, /bin/netstat, /usr/sbin/ss这样 deploy 用户只能重启和查看 app 服务ops 用户只能看日志和网络状态。参数上注意NOPASSWD只给高频且低风险的操作涉及数据删除或配置变更的命令不要加。审计方面auditd 的规则我一般加这几条# 监控 sudoers 文件变更 -w /etc/sudoers -p wa -k sudoers_change # 监控 SSH 配置变更 -w /etc/ssh/sshd_config -p wa -k sshd_change # 监控用户添加和删除 -w /etc/passwd -p wa -k user_change -w /etc/shadow -p wa -k shadow_change-w指定监控路径-p wa表示监控写和属性变更-k是关键词用于后续 ausearch 过滤。这些规则加载后任何对关键文件的修改都会记录到/var/log/audit/audit.log配合ausearch -k sudoers_change就能快速定位变更人和时间。3.3 认证加固中容易忽略的边界很多人做完 SSH 密钥登录就以为认证加固结束了其实还有几个边界一是密钥的 passphrase很多人生成密钥时不设密码密钥文件泄露就等于密码泄露二是 authorized_keys 的权限必须是 600否则 sshd 会拒绝使用三是 sudo 的 timestamp_timeout默认 5 分钟内免密共享账号场景下要改成 0。另外如果环境里有 Web 管理后台认证加固要单独做强制 HTTPS、加验证码或 MFA、限制登录频率。这些在《网络安全技术》里可能归在应用安全章节但实操中往往和主机认证一起做因为攻击者不会区分你是哪一层被突破的。4. 流量监测与日志审计让异常行为留下痕迹4.1 用 tcpdump 和 Zeek 做轻量流量基线流量监测不一定要上全套 IDS先从基线做起。我一般在新环境上线第一周用 tcpdump 抓包分析出正常的通信矩阵哪些 IP 之间在通信、用什么协议、流量大小和时段分布。命令如下# 抓取 eth0 上非本机之间的流量每个包截取 128 字节写文件 # -i: 指定网卡 # -s: 截取长度128 足够分析头部 # -w: 写入 pcap 文件 # -C: 每个文件最大 100MB # -W: 最多保留 10 个文件循环覆盖 tcpdump -i eth0 -s 128 -w /data/pcap/traffic_%Y%m%d_%H%M%S.pcap -C 100 -W 10 -Z root not host 本机IP抓一周后用 Zeek 做协议解析和连接日志生成# Zeek 默认输出 conn.log、dns.log、http.log 等 # -r: 读取 pcap 文件 # local: 使用本地站点脚本 zeek -r /data/pcap/traffic_20250101_000000.pcap localZeek 生成的conn.log里每行是一条连接记录包含源 IP、目的 IP、端口、持续时间、字节数。用 awk 或 Python 做聚合就能得到通信矩阵。基线建立后任何不在矩阵里的新连接都值得看一眼。4.2 日志集中采集与关键字段解析日志审计的核心不是「存了多少日志」而是「出问题时能不能快速查到」。我一般用 rsyslog 或 filebeat 把关键日志集中到一台日志服务器至少包括SSH 登录日志、sudo 操作日志、Web 访问日志、数据库慢查询和错误日志。以 SSH 日志为例/var/log/auth.log里关键字段是时间、主机名、进程名、用户、源 IP、结果Accepted/Failed。用下面这条命令可以快速统计失败登录 TOP 10# 提取 Failed password 行取第 11 列源 IP排序计数 grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -10参数说明$(NF-3)是因为不同发行版日志格式略有差异从后往前数第 4 个字段通常是源 IP。如果格式不一致先用head -1看一行确认字段位置。这个统计结果配合 fail2ban 的封禁记录能快速判断是否在被暴力破解。4.3 从日志到告警的最小闭环日志存下来不告警等于没存。最小闭环是定义规则 → 定时查询 → 触发通知。规则不用多先加三条SSH 失败登录 5 分钟内超过 10 次、sudo 执行了非白名单命令、关键文件被修改。用 cron 每 5 分钟跑一次检查脚本命中就发邮件或 webhook。#!/bin/bash # check_ssh_fail.sh threshold10 count$(grep Failed password /var/log/auth.log | grep $(date %Y-%m-%d) | wc -l) if [ $count -gt $threshold ]; then echo SSH failed login count: $count | mail -s Security Alert opsexample.com fi这个脚本很粗糙但能跑起来。后续可以换成 ELK 或 Loki 做更精细的规则。关键是先有闭环再优化精度。5. 避坑与排查安全加固中最容易翻车的五个场景5.1 改 SSH 配置后连不上机器现象修改sshd_config后 reload当前会话断开重新连接提示 connection refused。原因配置语法错误导致 sshd 启动失败或者AllowUsers没包含当前用户。解决改配置前用sshd -t测试保留一个活跃会话不退出改完后新开窗口验证确认无误再关闭旧会话。如果已经连不上通过 console 或救援模式进入检查/var/log/auth.log和sshd -t输出。5.2 fail2ban 误封内网 IP现象内网跳板机或监控服务器突然无法 SSH 到目标机器。原因fail2ban 规则把频繁连接的内网 IP 当成暴力破解封了。解决在 fail2ban 的ignoreip里加上内网网段和已知跳板机 IP调整maxretry和findtime参数内网环境可以适当放宽。另外监控系统用的 SSH 账号建议单独配置不走密码认证避免触发规则。5.3 auditd 规则过多导致日志爆炸现象/var/log/audit/目录迅速增长磁盘告警。原因监控了高频写入的文件或目录比如/tmp或应用日志目录。解决auditd 规则只加关键配置文件和认证相关文件不要监控应用日志。用aureport --summary查看各规则命中次数命中过多的规则要么去掉要么加-F过滤条件缩小范围。同时配置max_log_file和num_logs做轮转。5.4 端口扫描被当成攻击行为现象nmap 扫描后目标机器上的 IDS 告警或者云厂商发来安全通知。原因扫描频率过高或使用了 aggressive 模板。解决内网扫描用-T2或-T3加--scan-delay控制速率公网扫描前确认有授权避免扫到不属于自己的 IP。云环境里很多厂商有主动探测机制扫描行为可能触发告警提前报备或使用厂商提供的资产发现工具。5.5 日志时间不同步导致排查困难现象多台机器日志时间不一致关联分析时对不上。原因NTP 未配置或时区不统一。解决所有机器统一配置 NTP 同步时区统一为 UTC 或业务所在时区。日志采集端做时间戳标准化存储时保留原始时间和标准化时间两个字段。这个坑在事后排查时最致命因为时间线错乱会导致整个分析结论跑偏。6. 把 PDF 变成可运行的检查清单一个持续验证的小技巧《网络安全技术》这类资料最大的价值不是读一遍而是拆成检查项定期跑一遍。我自己的做法是维护一个security_checklist.sh把前面几章的检查点串起来每月跑一次输出一份简版报告。脚本不需要多复杂核心是覆盖资产、认证、日志三个维度。#!/bin/bash # security_checklist.sh - 月度安全检查 report/tmp/security_report_$(date %Y%m%d).txt echo 资产与端口 $report ss -tlnp | awk NR1 {print $4, $6} $report echo SSH 配置 $report sshd -T 2/dev/null | grep -E permitrootlogin|passwordauthentication|maxauthtries $report echo 失败登录统计 $report grep Failed password /var/log/auth.log 2/dev/null | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -5 $report echo 关键文件变更 $report ausearch -k sudoers_change -ts this-month 2/dev/null | tail -5 $report echo 报告已生成: $report这个脚本的逻辑是先看当前监听端口有没有新增再看 SSH 关键配置有没有被改回去然后统计失败登录来源最后查关键文件变更记录。参数上注意ausearch的-ts this-month需要 auditd 服务正常运行如果没装 auditd 就跳过这段。脚本输出的是文本报告可以配合 diff 跟上个月的报告对比快速发现变化。几个使用上的细节一是脚本要在每台机器上跑可以用 Ansible 批量执行并收集报告二是报告不要只存本地集中存到日志服务器或对象存储保留至少 6 个月三是每月跑完后花 10 分钟看一遍 diff重点关注新增端口和新增失败登录来源。我自己的习惯是把这个脚本挂在 cron 里每月 1 号跑报告自动发到邮箱。有一次就是通过 diff 发现一台机器多了个 8080 端口查下来是开发临时起的测试服务忘了关虽然没造成实际影响但这种「意料之外的变化」正是安全检查要抓的东西。安全这件事没有一劳永逸靠的是定期检查、持续收敛把《网络安全技术》里的原则变成每月跑一遍的脚本比读十遍 PDF 都管用。希望帮到你。本文还有配套的精品资源点击获取 从PDF到实战：网络安全技术落地指南与月度检查清单
简介这份《网络安全技术》PDF文档资料面向备考信息安全、网络攻防相关课程的学生与自学者聚焦网络安全基础理论与常见考点梳理。内容以选择题、填空题和简答题形式覆盖社会工程学攻击、不可否认性、协议与服务脆弱性、嗅探器防护、防火墙风险策略、黑客攻击流程、缓冲区溢出、IP欺骗、对称与非对称密码算法、Kerberos认证、IPSec协议、恶意代码及防火墙拓扑等核心知识点并附有参考答案与解析思路便于对照复习与查漏补缺。资源包共1个PDF文件大小约205KB轻量便携适合在电脑或移动设备上随时翻阅。目前已有714人学习下载可作为课堂笔记补充、期末冲刺或认证考试前的快速自测材料帮助读者在有限时间内串联零散概念、强化记忆高频考点。1. 从一份《网络安全技术》PDF 说起为什么大多数人存了资料却搭不起防线很多人手里都躺着几份《网络安全技术》的 PDF可能是课程讲义、培训资料也可能是从某个技术群里顺手存下来的。存的时候雄心勃勃打开看了两章 TCP/IP 和密码学基础然后就再也没翻过。问题不在于资料不好而在于这类文档天然是「知识罗列」结构——它告诉你对称加密和非对称加密的区别却不告诉你一台刚上线的 Linux 服务器前 24 小时该关哪些端口、该看哪些日志。你真正需要的不是把 PDF 从头读到尾而是把它当成一张地图按图索骥地在自己环境里搭出一条能跑起来、能验证、能持续维护的防线。这篇内容面向的是手里有资料但不知道怎么落地的一线开发者和运维人员我会把《网络安全技术》里最核心的几块——资产梳理、访问控制、流量监测、日志审计——拆成可以照着做的步骤每一步都告诉你为什么这么做、参数怎么调、哪里容易翻车。2. 资产梳理与攻击面收敛先把家底摸清楚再谈防护2.1 为什么资产清单是安全技术的起点《网络安全技术》这类资料通常从密码学或者网络协议讲起但真正落到实操第一步永远是资产梳理。你连自己有多少台机器、跑了哪些服务、开了哪些端口都不清楚后面谈防火墙策略、入侵检测都是空中楼阁。常见做法是先做被动资产发现再做主动端口扫描两者交叉验证。被动发现靠流量镜像或者交换机 MAC 表主动扫描用 nmap 这类工具。我一般会先用被动方式跑一周拿到一份「实际在通信的 IP 列表」再用 nmap 对这份列表做精准扫描避免全网段盲扫触发告警。资产梳理的输出不是一张 Excel 就完事而是要形成三个东西IP-服务-负责人 的映射表、每个服务的暴露面评级、以及变更记录机制。没有变更记录三个月后这份表就废了。2.2 用 nmap 做精准端口扫描与结果解析假设你已经通过被动流量拿到了一份活跃 IP 列表存为alive_hosts.txt每行一个 IP。下面这条命令是我常用的扫描方式# -sS: SYN 半开扫描速度快且不易被应用层日志记录 # -sV: 服务版本探测用于判断具体中间件和版本 # -O: 操作系统指纹识别辅助判断补丁级别 # --scriptbanner: 抓取服务 banner补充版本信息 # -p-: 全端口扫描1-65535 # -T4: 时序模板内网环境可用公网建议 T2 避免丢包 # -oA: 同时输出三种格式方便后续解析 nmap -sS -sV -O --scriptbanner -p- -T4 -iL alive_hosts.txt -oA scan_result扫描完成后scan_result.xml可以用 Python 解析成结构化表格。下面这段脚本把 XML 里的 IP、端口、服务、版本提取成 CSVimport xml.etree.ElementTree as ET import csv tree ET.parse(scan_result.xml) root tree.getroot() with open(assets.csv, w, newline) as f: writer csv.writer(f) writer.writerow([ip, port, protocol, service, version]) for host in root.findall(host): ip host.find(address).get(addr) for port in host.findall(.//port): portid port.get(portid) proto port.get(protocol) svc port.find(service) if svc is not None: name svc.get(name, ) ver svc.get(version, ) writer.writerow([ip, portid, proto, name, ver])这段脚本的逻辑很直接遍历 XML 里每个 host 的每个 port 节点把服务名和版本号抽出来。参数上需要注意的是如果 nmap 没识别出版本version字段会是空字符串后续做暴露面评级时要把这类端口标记为「未知服务」优先人工确认。2.3 攻击面收敛的三个判断维度拿到资产表之后收敛攻击面不是简单地「关端口」而是按三个维度做判断暴露范围公网/内网/本地、服务必要性业务是否依赖、替代方案能否加认证或换协议。我一般会做一张表端口服务暴露范围必要性处置建议22SSH公网高改非标端口密钥登录fail2ban3306MySQL内网高绑定内网 IP强密码审计日志6379Redis内网中加密码rename-commandbind9200ES内网低加认证或仅本地监听这张表的用法是公网高必要性做加固公网低必要性直接关内网低必要性评估后关或加访问控制。Redis 和 ES 是血泪经验里翻车最多的两个默认无认证加上内网横向移动一旦边界被突破就是连锁反应。3. 访问控制与身份认证从「能连上」到「只能该连的人连」3.1 最小权限原则在主机层的落地方式《网络安全技术》里讲访问控制模型DAC、MAC、RBAC讲得很细但落到一台具体机器上核心就三件事谁能登录、登录后能干什么、干了什么有没有记录。Linux 环境下我一般按这个顺序做先禁用 root 远程登录再建普通用户并配置 sudo 白名单最后用 auditd 记录关键操作。# /etc/ssh/sshd_config 关键配置 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AllowUsers deploy ops MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2改完sshd_config后先别急着重启 sshd用sshd -t测试配置语法确认无误再systemctl reload sshd。翻车场景很常见配置写错导致 sshd 起不来如果当前会话断开就彻底连不上了。所以改之前务必保留一个已登录的会话不要退出。3.2 sudo 白名单与命令审计的配置普通用户建好后不要直接给 ALL 权限。按角色拆分 sudoers 文件放在/etc/sudoers.d/下每个角色一个文件# /etc/sudoers.d/deploy deploy ALL(root) NOPASSWD: /bin/systemctl restart app, /bin/systemctl status app # /etc/sudoers.d/ops ops ALL(root) /usr/bin/journalctl, /bin/netstat, /usr/sbin/ss这样 deploy 用户只能重启和查看 app 服务ops 用户只能看日志和网络状态。参数上注意NOPASSWD只给高频且低风险的操作涉及数据删除或配置变更的命令不要加。审计方面auditd 的规则我一般加这几条# 监控 sudoers 文件变更 -w /etc/sudoers -p wa -k sudoers_change # 监控 SSH 配置变更 -w /etc/ssh/sshd_config -p wa -k sshd_change # 监控用户添加和删除 -w /etc/passwd -p wa -k user_change -w /etc/shadow -p wa -k shadow_change-w指定监控路径-p wa表示监控写和属性变更-k是关键词用于后续 ausearch 过滤。这些规则加载后任何对关键文件的修改都会记录到/var/log/audit/audit.log配合ausearch -k sudoers_change就能快速定位变更人和时间。3.3 认证加固中容易忽略的边界很多人做完 SSH 密钥登录就以为认证加固结束了其实还有几个边界一是密钥的 passphrase很多人生成密钥时不设密码密钥文件泄露就等于密码泄露二是 authorized_keys 的权限必须是 600否则 sshd 会拒绝使用三是 sudo 的 timestamp_timeout默认 5 分钟内免密共享账号场景下要改成 0。另外如果环境里有 Web 管理后台认证加固要单独做强制 HTTPS、加验证码或 MFA、限制登录频率。这些在《网络安全技术》里可能归在应用安全章节但实操中往往和主机认证一起做因为攻击者不会区分你是哪一层被突破的。4. 流量监测与日志审计让异常行为留下痕迹4.1 用 tcpdump 和 Zeek 做轻量流量基线流量监测不一定要上全套 IDS先从基线做起。我一般在新环境上线第一周用 tcpdump 抓包分析出正常的通信矩阵哪些 IP 之间在通信、用什么协议、流量大小和时段分布。命令如下# 抓取 eth0 上非本机之间的流量每个包截取 128 字节写文件 # -i: 指定网卡 # -s: 截取长度128 足够分析头部 # -w: 写入 pcap 文件 # -C: 每个文件最大 100MB # -W: 最多保留 10 个文件循环覆盖 tcpdump -i eth0 -s 128 -w /data/pcap/traffic_%Y%m%d_%H%M%S.pcap -C 100 -W 10 -Z root not host 本机IP抓一周后用 Zeek 做协议解析和连接日志生成# Zeek 默认输出 conn.log、dns.log、http.log 等 # -r: 读取 pcap 文件 # local: 使用本地站点脚本 zeek -r /data/pcap/traffic_20250101_000000.pcap localZeek 生成的conn.log里每行是一条连接记录包含源 IP、目的 IP、端口、持续时间、字节数。用 awk 或 Python 做聚合就能得到通信矩阵。基线建立后任何不在矩阵里的新连接都值得看一眼。4.2 日志集中采集与关键字段解析日志审计的核心不是「存了多少日志」而是「出问题时能不能快速查到」。我一般用 rsyslog 或 filebeat 把关键日志集中到一台日志服务器至少包括SSH 登录日志、sudo 操作日志、Web 访问日志、数据库慢查询和错误日志。以 SSH 日志为例/var/log/auth.log里关键字段是时间、主机名、进程名、用户、源 IP、结果Accepted/Failed。用下面这条命令可以快速统计失败登录 TOP 10# 提取 Failed password 行取第 11 列源 IP排序计数 grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -10参数说明$(NF-3)是因为不同发行版日志格式略有差异从后往前数第 4 个字段通常是源 IP。如果格式不一致先用head -1看一行确认字段位置。这个统计结果配合 fail2ban 的封禁记录能快速判断是否在被暴力破解。4.3 从日志到告警的最小闭环日志存下来不告警等于没存。最小闭环是定义规则 → 定时查询 → 触发通知。规则不用多先加三条SSH 失败登录 5 分钟内超过 10 次、sudo 执行了非白名单命令、关键文件被修改。用 cron 每 5 分钟跑一次检查脚本命中就发邮件或 webhook。#!/bin/bash # check_ssh_fail.sh threshold10 count$(grep Failed password /var/log/auth.log | grep $(date %Y-%m-%d) | wc -l) if [ $count -gt $threshold ]; then echo SSH failed login count: $count | mail -s Security Alert opsexample.com fi这个脚本很粗糙但能跑起来。后续可以换成 ELK 或 Loki 做更精细的规则。关键是先有闭环再优化精度。5. 避坑与排查安全加固中最容易翻车的五个场景5.1 改 SSH 配置后连不上机器现象修改sshd_config后 reload当前会话断开重新连接提示 connection refused。原因配置语法错误导致 sshd 启动失败或者AllowUsers没包含当前用户。解决改配置前用sshd -t测试保留一个活跃会话不退出改完后新开窗口验证确认无误再关闭旧会话。如果已经连不上通过 console 或救援模式进入检查/var/log/auth.log和sshd -t输出。5.2 fail2ban 误封内网 IP现象内网跳板机或监控服务器突然无法 SSH 到目标机器。原因fail2ban 规则把频繁连接的内网 IP 当成暴力破解封了。解决在 fail2ban 的ignoreip里加上内网网段和已知跳板机 IP调整maxretry和findtime参数内网环境可以适当放宽。另外监控系统用的 SSH 账号建议单独配置不走密码认证避免触发规则。5.3 auditd 规则过多导致日志爆炸现象/var/log/audit/目录迅速增长磁盘告警。原因监控了高频写入的文件或目录比如/tmp或应用日志目录。解决auditd 规则只加关键配置文件和认证相关文件不要监控应用日志。用aureport --summary查看各规则命中次数命中过多的规则要么去掉要么加-F过滤条件缩小范围。同时配置max_log_file和num_logs做轮转。5.4 端口扫描被当成攻击行为现象nmap 扫描后目标机器上的 IDS 告警或者云厂商发来安全通知。原因扫描频率过高或使用了 aggressive 模板。解决内网扫描用-T2或-T3加--scan-delay控制速率公网扫描前确认有授权避免扫到不属于自己的 IP。云环境里很多厂商有主动探测机制扫描行为可能触发告警提前报备或使用厂商提供的资产发现工具。5.5 日志时间不同步导致排查困难现象多台机器日志时间不一致关联分析时对不上。原因NTP 未配置或时区不统一。解决所有机器统一配置 NTP 同步时区统一为 UTC 或业务所在时区。日志采集端做时间戳标准化存储时保留原始时间和标准化时间两个字段。这个坑在事后排查时最致命因为时间线错乱会导致整个分析结论跑偏。6. 把 PDF 变成可运行的检查清单一个持续验证的小技巧《网络安全技术》这类资料最大的价值不是读一遍而是拆成检查项定期跑一遍。我自己的做法是维护一个security_checklist.sh把前面几章的检查点串起来每月跑一次输出一份简版报告。脚本不需要多复杂核心是覆盖资产、认证、日志三个维度。#!/bin/bash # security_checklist.sh - 月度安全检查 report/tmp/security_report_$(date %Y%m%d).txt echo 资产与端口 $report ss -tlnp | awk NR1 {print $4, $6} $report echo SSH 配置 $report sshd -T 2/dev/null | grep -E permitrootlogin|passwordauthentication|maxauthtries $report echo 失败登录统计 $report grep Failed password /var/log/auth.log 2/dev/null | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head -5 $report echo 关键文件变更 $report ausearch -k sudoers_change -ts this-month 2/dev/null | tail -5 $report echo 报告已生成: $report这个脚本的逻辑是先看当前监听端口有没有新增再看 SSH 关键配置有没有被改回去然后统计失败登录来源最后查关键文件变更记录。参数上注意ausearch的-ts this-month需要 auditd 服务正常运行如果没装 auditd 就跳过这段。脚本输出的是文本报告可以配合 diff 跟上个月的报告对比快速发现变化。几个使用上的细节一是脚本要在每台机器上跑可以用 Ansible 批量执行并收集报告二是报告不要只存本地集中存到日志服务器或对象存储保留至少 6 个月三是每月跑完后花 10 分钟看一遍 diff重点关注新增端口和新增失败登录来源。我自己的习惯是把这个脚本挂在 cron 里每月 1 号跑报告自动发到邮箱。有一次就是通过 diff 发现一台机器多了个 8080 端口查下来是开发临时起的测试服务忘了关虽然没造成实际影响但这种「意料之外的变化」正是安全检查要抓的东西。安全这件事没有一劳永逸靠的是定期检查、持续收敛把《网络安全技术》里的原则变成每月跑一遍的脚本比读十遍 PDF 都管用。希望帮到你。本文还有配套的精品资源点击获取