简介《计算机系统安全与计算机网络安全》是一份PDF格式的学习参考资料定位面向计算机专业学生、网络管理员及网络安全入门者用于建立计算机系统安全与网络安全的基础知识框架。资源包仅包含1个PDF文件大小约1.07MB内容紧凑便于下载后随时阅读。目前已有502人学习/下载适合作为课程辅导、期末复习或技术培训的参考文献。文档内容从计算机病毒的内涵、特点与检测清除方法入手进而梳理计算机系统漏洞的主要类型与成因并延伸到计算机网络安全的机密性、完整性与可操作性等特点。同时针对操作系统漏洞、TCP/IP协议明文传输、黑客攻击方式及恶意破坏等现实威胁给出了相应的分析与防范思路。读完这份材料读者能够系统了解计算机系统安全与网络安全的常见风险点及相关检测、防护手段为后续深入学习或安全配置实践打下基础。1. 计算机系统安全与计算机网络安全为什么分开讲、又必须合起来做你在一个中等规模的公司做运维或安全岗大概率经历过这样的翻车内网一台 Windows 服务器中了勒索病毒安全组查了一圈网络层访问控制发现该封的端口都封了但病毒还是从文件共享端口横向扩散到了财务网段。问题出在哪出在只看了网络安全策略没盯系统安全基线。计算机系统安全与计算机网络安全这两件事经常被当成一份 PDF 的两个章节去背但在真实攻击路径里它们是一根链条上的两环——系统漏洞负责打开入口网络通路负责扩大战果。这篇文章不重复教材里那些概念定义直接讲清楚两者怎么分工、怎么各自落地、怎么在衔接处救火。适合手头有真实服务器和交换机要管的运维、安全工程师也适合准备把安全基线从文档变成检查项的人。2. 拆开两条防线系统安全管主机内部网络安全管流量通路2.1 系统安全的对象与边界进程、文件、账户、内核系统安全面对的是一台主机的运行环境。攻击者拿到一台机器的立足点之后后续动作几乎都发生在系统层创建账户、写入启动项、替换二进制文件、加载内核模块、修改配置。这些动作的共性是——它们都在单台主机的边界之内不涉及跨设备的流量。所以系统安全的检查项全部围绕主机的四大资源展开。第一是账户系统里是否存在多余的高权限账户、默认口令账户、长期不用的幽灵账户。第二是文件关键目录是否被写入异常文件关键二进制是否被替换日志文件是否被清空。第三是进程是否有可疑进程在监听非预期端口是否和父进程链异常。第四是内核与启动链路启动项、计划任务、内核模块是否被注入。以 Linux 系统为例我一般会先做一次快速的账户和端口盘点。其核心指令是这几条# 列出所有能登录的账户重点看 uid0 的账户和空口令账户 awk -F: ($3 0) {print $1} /etc/passwd # 检查是否有空密码账户这类账户是系统安全里最直接的破绽 awk -F: ($2 ) {print $1} /etc/shadow # 列出正在监听的 TCP/UDP 端口快速定位非预期服务 ss -tulnp第一条命令查 uid 为 0 的账户正常系统里应该只有 root。如果发现其他 uid0 的账户基本可以判定已经被留了后门。第二条命令查 shadow 文件里密码字段为空的账户这类账户在部分配置下有免密登录的可能。第三条命令ss -tulnp是日常排查端口最常用的工具输出里每一行都能看到进程名和 PID比旧的netstat更直观。系统安全的边界在于它只保证这台主机自己是干净的但管不了隔壁主机把恶意流量发过来。反过来网络安全管得住流量路径却管不住发起的进程是不是被篡改过。这两层必须配合后面章节会具体讲配合方式。2.2 网络安全的对象与边界地址、端口、协议、会话网络安全关注的不是单台主机的内部状态而是数据包在主机之间怎么流动。一个数据包从源 IP 出发带着源端口和目标端口经过交换机、路由器、防火墙到达目标 IP 的目标端口。网络安全的控制点就在这些设备的转发决策上。具体到落地网络安全由三块拼成。第一是分段把主机按业务角色和安全等级划分到不同的广播域或安全域阻断非必要的横向通路。第二是过滤在边界设备和主机侧防火墙设置访问控制策略只放行明确需要的业务流量。第三是监控通过流量镜像、NetFlow、日志分析知道网络里的流量是谁发起的、往哪里去、用什么协议。用 iptables 在 Linux 主机上做端口级过滤时最基础的做法是设置默认策略为 DROP再逐条放行白名单流量# 清空现有规则避免残留策略干扰预期 iptables -F # 设置默认策略丢弃所有入站流量放行出站和转发由后续规则决定 iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # 放行已建立的连接和回包流量这是状态防火墙的基础 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 放行本机回环口避免自身服务因为规则顺序问题失效 iptables -A INPUT -i lo -j ACCEPT # 只对外开放 22 和 80 端口来源限制为办公网段 iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/0 -j ACCEPT这里有一个常见误区很多人只写了放行规则忘记设置默认 DROP 策略结果防火墙等于没开。另一个误区是没写ESTABLISHED,RELATED规则导致外网回包全部被丢弃业务表现为只能发请求、收不到响应。网络安全的边界在于它控制流量是否被允许通过但控制不了流量到达目标主机之后目标主机上的服务是否有漏洞可以被利用。防火墙放行 80 端口后Web 应用的参数注入、文件上传缺陷防火墙是看不到的这些属于应用与系统层的职责。2.3 安全事件的归属判断先在系统层看进程再去网络层追流向实际排查安全事件时最忌讳一上来就去翻防火墙日志。正确顺序是先确认主机侧的事实再结合网络侧数据还原路径。举个例子内网一台数据库服务器被植入挖矿程序CPU 跑满。排查步骤应该是先在系统层确认是哪个进程占用的 CPU它的二进制路径在哪启动命令是什么父进程是谁。然后查这个进程的网络连接——它往哪些 IP 的哪些端口发包。最后再回到网络侧查这些目标 IP 的流量日志确认是否还有其他主机也在和这个矿池地址通信。这样做的理由是系统层能给出确定性的结论——进程、文件、账户这些实体是真实存在的网络层只给流量特征——IP、端口、协议都是可伪造的。如果先看网络层可能被一个伪造源 IP 带偏方向浪费大量时间。3. 主机加固实操把系统安全的检查项落成能复现的配置3.1 账户与登录安全sshd 与 PAM 的最小配置主机加固的第一步是收缩入口。Linux 服务器最常见的入口是 SSHWindows 服务器最常见的是 RDP。这两个入口如果使用默认配置等于把所有风险都暴露在网络面前。SSH 加固时我一般会改几个参数集中在/etc/ssh/sshd_config里# 禁止 root 直接登录管理员先登录普通账户再切换 PermitRootLogin no # 只允许特定用户组登录其他用户一律拒绝 AllowGroups sshusers # 禁用空密码登录 PermitEmptyPasswords no # 限制登录尝试次数防止暴力破解刷屏 MaxAuthTries 3这几个参数都改完后需要重启 sshd 服务。注意顺序先确认 AllowGroups 里的用户组确实存在并且当前管理员账户在这个组里再重启。否则一个参数错误所有远程登录都被拒绝只能去机房接显示器。这个翻车教训在第 5 章还会展开说。账户层面除了 sshd_config还要配合 PAM 做密码策略。我一般在/etc/pam.d/system-auth里加密码复杂度与历史记录限制password requisite pam_pwquality.so retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1 password sufficient pam_unix.so sha512 shadow nullok use_authtok password required pam_pwhistory.so remember5第一行要求新密码至少 12 位且必须包含数字、大写字母、小写字母、特殊字符中的至少三类。dcredit、ucredit、lcredit、ocredit这四个参数分别控制数字、大写、小写、特殊字符的扣分阈值负数代表至少出现多少个。第二行是正常的密码更新流程第三行禁止重复使用最近 5 次的历史密码。Windows 主机侧对应的是本地安全策略里的“密码策略”和“账户锁定策略”。密码最小长度设为 12 位账户锁定阈值设为 5 次错误锁定 15 分钟这两项是性价比最高的配置。值得注意的是Windows Server 的账户锁定默认是针对交互式登录和 RDP 登录的并不影响服务账户在后台使用的说明这个边界要心里有数。3.2 文件权限与关键目录保护用 find 查异常用基线比对圈变化系统安全的另一半是文件系统安全。攻击者拿到账户权限后通常会修改现有文件或写入新文件。如果文件权限配置得当即使进程被攻破能造成的破坏也相对有限。Linux 文件系统的加固重点有三个目录临时目录/tmp、启动目录/etc/init.d或者 systemd 的 unit 目录、以及日志目录/var/log。临时目录是所有用户都能写的容易被用来存放恶意脚本启动目录一旦被写入启动脚本就能实现恶意代码的持久化。检查异常文件的命令我常用这样一套# 查找 /tmp 下的可执行文件正常情况临时目录不该有可执行权限的文件 find /tmp -type f -perm /111 -exec ls -l {} \; # 查找最近 7 天内被修改过的系统命令提示排查是否为恶意替换 find /bin /usr/bin /sbin /usr/sbin -type f -mtime -7 -exec ls -l {} \; # 查找系统目录里拥有 suid 权限的文件suid 是系统安全中最敏感的权限位 find / -type f -perm /4000 -exec ls -l {} \;第一条命令查临时目录里的可执行文件正常业务如果不需要在 /tmp 下跑脚本这条命令的输出应该是空的。第二条命令查最近 7 天改过的系统命令如果服务器没做过更新出现新改动就要警觉。第三条命令查 suid 权限文件suid 意味着普通用户执行这个程序时会临时获得文件所有者的权限——一旦被利用可以直接提权。除了命令检查更可靠的做法是给关键目录做哈希基线。在系统刚装完、确认干净的时候为系统命令目录生成一个指纹文件之后定期比对# 生成基线记录命令目录下所有文件的哈希值输出到安全存储位置 find /bin /usr/bin /sbin /usr/sbin -type f -exec sha256sum {} \; /var/lib/secure/baseline.sha256 # 定期比对检查当前文件哈希与基线是否一致 sha256sum -c /var/lib/secure/baseline.sha256 --quiet基线文件必须存放在攻击者改不到的位置。放在/var/lib/secure下还不够——如果服务器被 root 权限攻破这个目录一样能改。常见做法是把基线文件拷贝到只读挂载的磁盘或者异机存放。基线的价值不在于事后查出所有问题而在于缩短排查时间哈希不一致的文件就是重点怀疑对象不需要大海捞针。3.3 审计与日志auditd 和 syslog 的启用参数很多服务器的系统安全配置做得不错但没开审计。没有审计的系统安全事件发生后只能靠回忆和运气去判断攻击路径。Linux 上最常用的是 auditd 审计服务。它比普通日志更细能记录哪个用户、哪个时间、对哪个文件做了哪类操作。最小配置如下# 安装并启动 auditd 服务 systemctl enable auditd systemctl start auditd # 监控 /etc/passwd 和 /etc/shadow 的写操作账户异常创建是后门迹象 auditctl -w /etc/passwd -p wa -k account_change auditctl -w /etc/shadow -p wa -k account_change # 监控系统管理命令目录的写操作 auditctl -w /usr/bin/ -p wa -k system_bin_change # 查看审计日志检查账户文件变更记录 ausearch -k account_change -ts recent-w指定监控路径-p wa表示记录写入和属性修改事件-k是给事件打的标签。后续用ausearch -k可以按标签快速检索。auditd 的日志文件默认在/var/log/audit/audit.log这个文件本身也要防止被删——攻击者清除日志是常见动作所以日志最好转发到远程日志服务器。远程日志转发用 rsyslog 实现配置比较简单# 在客户端 /etc/rsyslog.conf 中添加远程日志服务器地址 *.* 192.168.10.50:514 # 在日志服务器端开启 UDP 514 端口接收并关闭 DNS 反解提高接收速度 module(loadimudp) input(typeimudp port514)把日志实时转发到远程服务器后即使主机上的日志被清理远端还保留着原始记录。审计与日志这层是系统安全的最后屏障也是唯一的后悔药——很多安全事件事后复盘唯一的证据来源就是日志。4. 网络控制实操用分段、过滤和监控把网络安全落在一张拓扑图里4.1 安全域划分VLAN 规划与标记原则网络安全的起点不是防火墙策略而是网络分域。没有分域的网络所有主机都在同一个二层平面里任意一台被攻破的机器都能 ARP 扫描到整个网段。分域的核心手段是 VLAN 与网段划分。常见的划分方式是按业务和信任等级拆开办公网、服务器区、数据库区、外联区、管理网段各自独立 VLAN。VLAN 之间默认不路由需要路由时用三层交换机或防火墙控制。一个典型的中小规模 VLAN 规划可以参考下面这张表VLAN ID用途网段默认访问关系10办公终端192.168.10.0/24仅可访问业务端口20应用服务器192.168.20.0/24对外提供 Web 服务30数据库服务器192.168.30.0/24仅接受应用服务器访问99管理网段192.168.99.0/24仅运维终端可访问禁止业务流量进入VLAN 划分完成后三层交换机上要做 VLAN 间路由的访问控制。如果只有 VLAN 没有策略VLAN 之间还是能互相访问分域就只剩二层隔离的名义。真正的安全边界是三层策略。在实际项目中VLAN 规划最常被忽略的是管理网段。很多运维为了方便把设备和服务器的管理地址混在业务网段里。这样做一旦业务网段被攻破攻击者可以直接管理设备。管理网段应该独立存在并且只能允许运维终端的源地址访问。4.2 流量过滤iptables 有状态与无状态规则的取舍网络层过滤落地在 Linux 主机上最常用的是 iptables落地在设备上是 ACL。无论形式如何设计思路是一致的默认拒绝、白名单放行、最小暴露。前面 2.2 节已经展示了一个最小 iptables 配置这里再补充关于有状态与无状态规则的取舍。iptables 可以自己维护连接追踪表允许”已建立连接“的回包进来这需要加载nf_conntrack模块。有状态规则的好处是回包自动放行不需要为每一个临时端口单独开洞。缺点是连接追踪表占用内存在大量短连接场景下可能成为瓶颈。无状态规则的思路是只按五元组匹配不关心连接状态。优缺点正好反过来性能好但需要把可能的回包端口全部写清楚规则数量会膨胀。我给业务服务器做配置时通常用有状态规则作为主策略再叠加端口限制# 加载连接追踪相关模块 modprobe nf_conntrack # 默认拒绝一切入站流量 iptables -P INPUT DROP # 允许已建立连接的回包这是有状态规则的核心 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 允许来自办公网的 SSH 访问 iptables -A INPUT -s 192.168.10.0/24 -p tcp --dport 22 -j ACCEPT # 允许来自任意来源的 HTTPS 访问Web 服务需要暴露给外部 iptables -A INPUT -p tcp --dport 443 -j ACCEPT注意规则顺序ESTABLISHED,RELATED的放行规则必须放在新连接放行规则之前因为后续规则不会回看已经匹配过的流量。如果你把 443 的放行写在了前面而连接追踪规则在它后面第一次握手包被放行后回包会被默认策略丢弃因为回包没有匹配到任何规则。一个容易让人困惑的地方是 iptables 规则保存。iptables 命令改的是运行时配置重启后失效。要用iptables-save /etc/iptables/rules.v4保存并在开机脚本里用iptables-restore恢复。不少人在服务器上配好了防火墙重启后规则全没了还以为是配置没生效。4.3 流量可见性端口镜像与抓包验证安全策略配置得再完整如果看不见实际流量就无法验证策略是否生效。网络侧需要两个可见性工具交换机端口镜像用于让监控设备采集真实流量tcpdump 用于在主机侧抓包验证策略匹配情况。端口镜像的配置因厂商而异思科、华为、华三的命令各有差异。思科交换机上典型的配置是把某个业务端口流量镜像到监控端口# 在思科交换机上把 Gi0/1 端口的进向流量复制到 Gi0/24 监控端口 monitor session 1 source interface Gi0/1 tx monitor session 1 destination interface Gi0/24镜像端口后把安装了抓包工具的监控主机接到 Gi0/24 上就能看到该业务端口发出的全部流量。注意tx与rx参数tx只镜像出方向rx只镜像入方向需要双向流量时写both。监控端口不要接普通业务否则镜像流量和业务流量会互相干扰。主机侧抓包验证防火墙规则是否生效时我在目标主机上用 tcpdump 抓本机端口的流量# 在服务器上抓取 eth0 网卡的 80 端口流量验证防火墙是否放行了外部访问 tcpdump -i eth0 -nn port 80 -c 100 -w /tmp/http.cap-nn不做域名和端口反解加快解析速度也能避免抓包时产生额外 DNS 查询。-c 100限制抓包数量避免文件无限增长。-w保存为 pcap 文件之后用 Wireshark 分析。抓包在安全运维中的实际用途一是确认防火墙规则匹配是否符合预期——该放行的流量是否确实进来不该放行的流量是否确实被丢二是排查网络层面的丢包和重传——如果大量 TCP 重传说明链路质量或 MTU 设置有问题这往往是业务性能劣化但系统侧查不出原因的真凶。5. 系统安全与网络安全衔接时最容易踩的 4 个坑5.1 坑一防火墙放行了端口主机侧服务却暴露到了外网现象安全组在防火墙上只放行了办公网 IP 访问 3389但实际测试发现外网也能连上服务器 3389 端口。原因防火墙策略管的是跨越设备的流量但服务器本身如果是云主机安全组和主机侧防火墙是两层独立体系。很多运维只配置了云安全组的入方向规则忘了主机自身的防火墙处在关闭状态导致端口实际暴露。另一种常见情况是服务器上跑了多个服务安全组放行了 3389但服务器的其他服务如 1433、3306 也在监听 0.0.0.0安全组没有覆盖这些端口。解决在主机侧也建立最小化出站和入站策略。检查本机所有监听端口确认对外服务的绑定地址是内网 IP 还是 0.0.0.0。对于只在内网使用的服务监听地址应改为内网网卡 IP而不是对所有地址监听。这个检查应该在每次安全组变更后同步执行一遍。5.2 坑二系统时间不同步日志审计对不上号现象内网服务器被入侵需要把系统审计日志、防火墙会话日志和交换机日志关联起来还原攻击路径结果发现三者的时间戳相差几分钟到几十分钟事件顺序完全对不上。原因服务器和网络设备默认使用本地时钟没有配置 NTP 同步。设备长时间运行后时钟漂移会越来越大。审计日志、防火墙日志、交换机日志如果不在同一时间基准上关联分析根本无从谈起。解决在所有服务器和网络设备上启用 NTP 同步统一使用同一个时间源。Linux 服务器上配置 NTP 后可以用timedatectl验证同步状态。时间源的选择建议内网至少部署一台主时间服务器所有设备指向它这台时间服务器再对外同步。不要在每台设备上直接配置外网 NTP内网设备访问外网受限时会出现间歇性同步失败。网络设备上的 NTP 配置需要单独设置因为交换机通常没有timedatectl用的是ntp server命令。5.3 坑三加固操作一步到位把自己锁在门外现象按照安全基线的要求修改了 SSH 配置加入登录白名单和密码复杂度策略重启 sshd 服务后管理员自己也无法登录了。查看进程发现 sshd 在跑但登录总是被拒绝。原因改动 sshd_config 时AllowGroups指定的用户组不存在或管理员账户不在这个组又或者修改了PermitRootLogin no后管理员习惯用 root 直接登录但在配置修改前没有先创建普通管理员账户。PAM 配置里如果对pam_pwquality的选项写错还会导致密码修改流程完全不可用。解决在修改 SSH 和 PAM 配置前先执行两个预防动作一是确认自己的测试账户能够登录二是开启一个新会话并保持不退出用新会话去验证配置。我自己的习惯是在改完配置后不立刻重启 sshd而是先运行sshd -t做语法检查确认没有问题再重启。如果已经把自己锁在门外最可靠的后悔药是通过带外管理口登录或者让机房同事在本地终端操作。5.4 坑四安全策略做全了远程管理通道本身却不受控现象内网所有业务主机的系统加固都完成防火墙策略也收紧到位。但安全扫描时发现有一台服务器的远程管理端口可以从不属于管理网段的地址访问而且这个端口没有开启登录失败锁定策略暴力破解尝试可以直接打到这里。原因运维为了省事把远程管理端口直接放在业务 VLAN 里并且没有在防火墙上限制管理端口的源地址。管理通道的暴露范围比业务通道更大——业务端口至少面对的是特定协议管理通道往往开放了完整的登录接口攻击者不需要先攻破业务服务直接对管理端口爆破即可。解决远程管理端口必须单独划分管理网段且只能在防火墙上允许运维终端的固定 IP 访问。管理端口同时启用账户锁定策略和登录告警连续失败 5 次锁定一段时间每次失败登录都要触发告警。这个坑的教训是——最先被攻破的往往是运维自己留下的最方便的那扇门。把管理通道管住了系统安全和网络安全才算真正衔接上。6. 把两套安全状态合成一张巡检表验证系统与网络安全是否还在基线内6.1 检查清单从主机到网络设备逐项验证安全配置做完不意味着结束真正考验的是长期维护中配置是否还能保持有效。我把检查项固化成了两个区块主机侧和网络侧。主机侧每台服务器执行一遍同样的检查。网络侧在核心交换机上核对。主机侧巡检清单概括为账户是否有变化、端口是否有新增、关键文件哈希是否匹配基线、系统时间是否同步、日志是否有近期异常事件。网络侧的巡检是VLAN 间策略是否还是预期放行的路径、设备 NTP 是否有告警、镜像端口是否还在运行、关键链路的流量基线是否出现异常波动。之前提过的基线哈希校验命令在这里就是巡检的验证工具# 重新校验 key 系统目录是否与基线一致-q 让输出只保留差异项 sha256sum -c /var/lib/secure/baseline.sha256 --quiet | grep -v OK # 二次确认列出当前所有 TCP 监听端口逐个人工核对业务预期 ss -tuln | grep LISTEN巡检的节奏根据环境规模定。服务器数量少就每周跑一次数量多就放在配置管理平台上统一执行把结果输出成报表。不管是手工跑还是自动化跑都要留一份结果存档这样才能看出变化趋势。6.2 发现基线漂移后的两个处置习惯第一个习惯是区分“正常变更”和“漂移”。业务在跑配置不可能一成不变上线新服务会新增监听端口维护更新会修改命令目录下的文件哈希。巡检发现变更后不要急着恢复基线先核对变更记录确认是否由正常的运维操作导致。如果是正常变更就把基线文件更新到新状态。如果是未经记录的变更就需要按安全事件处理查清楚是谁改的、为什么改。第二个习惯是保留变更前后的证据。很多安全复盘失败根源在于改完之后没有留存“改之前”的记录。我在完成每次加固和策略变更后会把变更前后的配置清单和巡检结果各存一份。两个月后回头看这份历史归档比任何记忆都可靠。安全运维的本质是持续验证不是一次性的项目交付——把巡检做成习惯系统安全与网络安全这两套配置才能真正持续生效。希望这套方案帮到你。本文还有配套的精品资源点击获取
系统安全与网络安全：双线防御的落地实践与衔接技巧
简介《计算机系统安全与计算机网络安全》是一份PDF格式的学习参考资料定位面向计算机专业学生、网络管理员及网络安全入门者用于建立计算机系统安全与网络安全的基础知识框架。资源包仅包含1个PDF文件大小约1.07MB内容紧凑便于下载后随时阅读。目前已有502人学习/下载适合作为课程辅导、期末复习或技术培训的参考文献。文档内容从计算机病毒的内涵、特点与检测清除方法入手进而梳理计算机系统漏洞的主要类型与成因并延伸到计算机网络安全的机密性、完整性与可操作性等特点。同时针对操作系统漏洞、TCP/IP协议明文传输、黑客攻击方式及恶意破坏等现实威胁给出了相应的分析与防范思路。读完这份材料读者能够系统了解计算机系统安全与网络安全的常见风险点及相关检测、防护手段为后续深入学习或安全配置实践打下基础。1. 计算机系统安全与计算机网络安全为什么分开讲、又必须合起来做你在一个中等规模的公司做运维或安全岗大概率经历过这样的翻车内网一台 Windows 服务器中了勒索病毒安全组查了一圈网络层访问控制发现该封的端口都封了但病毒还是从文件共享端口横向扩散到了财务网段。问题出在哪出在只看了网络安全策略没盯系统安全基线。计算机系统安全与计算机网络安全这两件事经常被当成一份 PDF 的两个章节去背但在真实攻击路径里它们是一根链条上的两环——系统漏洞负责打开入口网络通路负责扩大战果。这篇文章不重复教材里那些概念定义直接讲清楚两者怎么分工、怎么各自落地、怎么在衔接处救火。适合手头有真实服务器和交换机要管的运维、安全工程师也适合准备把安全基线从文档变成检查项的人。2. 拆开两条防线系统安全管主机内部网络安全管流量通路2.1 系统安全的对象与边界进程、文件、账户、内核系统安全面对的是一台主机的运行环境。攻击者拿到一台机器的立足点之后后续动作几乎都发生在系统层创建账户、写入启动项、替换二进制文件、加载内核模块、修改配置。这些动作的共性是——它们都在单台主机的边界之内不涉及跨设备的流量。所以系统安全的检查项全部围绕主机的四大资源展开。第一是账户系统里是否存在多余的高权限账户、默认口令账户、长期不用的幽灵账户。第二是文件关键目录是否被写入异常文件关键二进制是否被替换日志文件是否被清空。第三是进程是否有可疑进程在监听非预期端口是否和父进程链异常。第四是内核与启动链路启动项、计划任务、内核模块是否被注入。以 Linux 系统为例我一般会先做一次快速的账户和端口盘点。其核心指令是这几条# 列出所有能登录的账户重点看 uid0 的账户和空口令账户 awk -F: ($3 0) {print $1} /etc/passwd # 检查是否有空密码账户这类账户是系统安全里最直接的破绽 awk -F: ($2 ) {print $1} /etc/shadow # 列出正在监听的 TCP/UDP 端口快速定位非预期服务 ss -tulnp第一条命令查 uid 为 0 的账户正常系统里应该只有 root。如果发现其他 uid0 的账户基本可以判定已经被留了后门。第二条命令查 shadow 文件里密码字段为空的账户这类账户在部分配置下有免密登录的可能。第三条命令ss -tulnp是日常排查端口最常用的工具输出里每一行都能看到进程名和 PID比旧的netstat更直观。系统安全的边界在于它只保证这台主机自己是干净的但管不了隔壁主机把恶意流量发过来。反过来网络安全管得住流量路径却管不住发起的进程是不是被篡改过。这两层必须配合后面章节会具体讲配合方式。2.2 网络安全的对象与边界地址、端口、协议、会话网络安全关注的不是单台主机的内部状态而是数据包在主机之间怎么流动。一个数据包从源 IP 出发带着源端口和目标端口经过交换机、路由器、防火墙到达目标 IP 的目标端口。网络安全的控制点就在这些设备的转发决策上。具体到落地网络安全由三块拼成。第一是分段把主机按业务角色和安全等级划分到不同的广播域或安全域阻断非必要的横向通路。第二是过滤在边界设备和主机侧防火墙设置访问控制策略只放行明确需要的业务流量。第三是监控通过流量镜像、NetFlow、日志分析知道网络里的流量是谁发起的、往哪里去、用什么协议。用 iptables 在 Linux 主机上做端口级过滤时最基础的做法是设置默认策略为 DROP再逐条放行白名单流量# 清空现有规则避免残留策略干扰预期 iptables -F # 设置默认策略丢弃所有入站流量放行出站和转发由后续规则决定 iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # 放行已建立的连接和回包流量这是状态防火墙的基础 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 放行本机回环口避免自身服务因为规则顺序问题失效 iptables -A INPUT -i lo -j ACCEPT # 只对外开放 22 和 80 端口来源限制为办公网段 iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/0 -j ACCEPT这里有一个常见误区很多人只写了放行规则忘记设置默认 DROP 策略结果防火墙等于没开。另一个误区是没写ESTABLISHED,RELATED规则导致外网回包全部被丢弃业务表现为只能发请求、收不到响应。网络安全的边界在于它控制流量是否被允许通过但控制不了流量到达目标主机之后目标主机上的服务是否有漏洞可以被利用。防火墙放行 80 端口后Web 应用的参数注入、文件上传缺陷防火墙是看不到的这些属于应用与系统层的职责。2.3 安全事件的归属判断先在系统层看进程再去网络层追流向实际排查安全事件时最忌讳一上来就去翻防火墙日志。正确顺序是先确认主机侧的事实再结合网络侧数据还原路径。举个例子内网一台数据库服务器被植入挖矿程序CPU 跑满。排查步骤应该是先在系统层确认是哪个进程占用的 CPU它的二进制路径在哪启动命令是什么父进程是谁。然后查这个进程的网络连接——它往哪些 IP 的哪些端口发包。最后再回到网络侧查这些目标 IP 的流量日志确认是否还有其他主机也在和这个矿池地址通信。这样做的理由是系统层能给出确定性的结论——进程、文件、账户这些实体是真实存在的网络层只给流量特征——IP、端口、协议都是可伪造的。如果先看网络层可能被一个伪造源 IP 带偏方向浪费大量时间。3. 主机加固实操把系统安全的检查项落成能复现的配置3.1 账户与登录安全sshd 与 PAM 的最小配置主机加固的第一步是收缩入口。Linux 服务器最常见的入口是 SSHWindows 服务器最常见的是 RDP。这两个入口如果使用默认配置等于把所有风险都暴露在网络面前。SSH 加固时我一般会改几个参数集中在/etc/ssh/sshd_config里# 禁止 root 直接登录管理员先登录普通账户再切换 PermitRootLogin no # 只允许特定用户组登录其他用户一律拒绝 AllowGroups sshusers # 禁用空密码登录 PermitEmptyPasswords no # 限制登录尝试次数防止暴力破解刷屏 MaxAuthTries 3这几个参数都改完后需要重启 sshd 服务。注意顺序先确认 AllowGroups 里的用户组确实存在并且当前管理员账户在这个组里再重启。否则一个参数错误所有远程登录都被拒绝只能去机房接显示器。这个翻车教训在第 5 章还会展开说。账户层面除了 sshd_config还要配合 PAM 做密码策略。我一般在/etc/pam.d/system-auth里加密码复杂度与历史记录限制password requisite pam_pwquality.so retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1 password sufficient pam_unix.so sha512 shadow nullok use_authtok password required pam_pwhistory.so remember5第一行要求新密码至少 12 位且必须包含数字、大写字母、小写字母、特殊字符中的至少三类。dcredit、ucredit、lcredit、ocredit这四个参数分别控制数字、大写、小写、特殊字符的扣分阈值负数代表至少出现多少个。第二行是正常的密码更新流程第三行禁止重复使用最近 5 次的历史密码。Windows 主机侧对应的是本地安全策略里的“密码策略”和“账户锁定策略”。密码最小长度设为 12 位账户锁定阈值设为 5 次错误锁定 15 分钟这两项是性价比最高的配置。值得注意的是Windows Server 的账户锁定默认是针对交互式登录和 RDP 登录的并不影响服务账户在后台使用的说明这个边界要心里有数。3.2 文件权限与关键目录保护用 find 查异常用基线比对圈变化系统安全的另一半是文件系统安全。攻击者拿到账户权限后通常会修改现有文件或写入新文件。如果文件权限配置得当即使进程被攻破能造成的破坏也相对有限。Linux 文件系统的加固重点有三个目录临时目录/tmp、启动目录/etc/init.d或者 systemd 的 unit 目录、以及日志目录/var/log。临时目录是所有用户都能写的容易被用来存放恶意脚本启动目录一旦被写入启动脚本就能实现恶意代码的持久化。检查异常文件的命令我常用这样一套# 查找 /tmp 下的可执行文件正常情况临时目录不该有可执行权限的文件 find /tmp -type f -perm /111 -exec ls -l {} \; # 查找最近 7 天内被修改过的系统命令提示排查是否为恶意替换 find /bin /usr/bin /sbin /usr/sbin -type f -mtime -7 -exec ls -l {} \; # 查找系统目录里拥有 suid 权限的文件suid 是系统安全中最敏感的权限位 find / -type f -perm /4000 -exec ls -l {} \;第一条命令查临时目录里的可执行文件正常业务如果不需要在 /tmp 下跑脚本这条命令的输出应该是空的。第二条命令查最近 7 天改过的系统命令如果服务器没做过更新出现新改动就要警觉。第三条命令查 suid 权限文件suid 意味着普通用户执行这个程序时会临时获得文件所有者的权限——一旦被利用可以直接提权。除了命令检查更可靠的做法是给关键目录做哈希基线。在系统刚装完、确认干净的时候为系统命令目录生成一个指纹文件之后定期比对# 生成基线记录命令目录下所有文件的哈希值输出到安全存储位置 find /bin /usr/bin /sbin /usr/sbin -type f -exec sha256sum {} \; /var/lib/secure/baseline.sha256 # 定期比对检查当前文件哈希与基线是否一致 sha256sum -c /var/lib/secure/baseline.sha256 --quiet基线文件必须存放在攻击者改不到的位置。放在/var/lib/secure下还不够——如果服务器被 root 权限攻破这个目录一样能改。常见做法是把基线文件拷贝到只读挂载的磁盘或者异机存放。基线的价值不在于事后查出所有问题而在于缩短排查时间哈希不一致的文件就是重点怀疑对象不需要大海捞针。3.3 审计与日志auditd 和 syslog 的启用参数很多服务器的系统安全配置做得不错但没开审计。没有审计的系统安全事件发生后只能靠回忆和运气去判断攻击路径。Linux 上最常用的是 auditd 审计服务。它比普通日志更细能记录哪个用户、哪个时间、对哪个文件做了哪类操作。最小配置如下# 安装并启动 auditd 服务 systemctl enable auditd systemctl start auditd # 监控 /etc/passwd 和 /etc/shadow 的写操作账户异常创建是后门迹象 auditctl -w /etc/passwd -p wa -k account_change auditctl -w /etc/shadow -p wa -k account_change # 监控系统管理命令目录的写操作 auditctl -w /usr/bin/ -p wa -k system_bin_change # 查看审计日志检查账户文件变更记录 ausearch -k account_change -ts recent-w指定监控路径-p wa表示记录写入和属性修改事件-k是给事件打的标签。后续用ausearch -k可以按标签快速检索。auditd 的日志文件默认在/var/log/audit/audit.log这个文件本身也要防止被删——攻击者清除日志是常见动作所以日志最好转发到远程日志服务器。远程日志转发用 rsyslog 实现配置比较简单# 在客户端 /etc/rsyslog.conf 中添加远程日志服务器地址 *.* 192.168.10.50:514 # 在日志服务器端开启 UDP 514 端口接收并关闭 DNS 反解提高接收速度 module(loadimudp) input(typeimudp port514)把日志实时转发到远程服务器后即使主机上的日志被清理远端还保留着原始记录。审计与日志这层是系统安全的最后屏障也是唯一的后悔药——很多安全事件事后复盘唯一的证据来源就是日志。4. 网络控制实操用分段、过滤和监控把网络安全落在一张拓扑图里4.1 安全域划分VLAN 规划与标记原则网络安全的起点不是防火墙策略而是网络分域。没有分域的网络所有主机都在同一个二层平面里任意一台被攻破的机器都能 ARP 扫描到整个网段。分域的核心手段是 VLAN 与网段划分。常见的划分方式是按业务和信任等级拆开办公网、服务器区、数据库区、外联区、管理网段各自独立 VLAN。VLAN 之间默认不路由需要路由时用三层交换机或防火墙控制。一个典型的中小规模 VLAN 规划可以参考下面这张表VLAN ID用途网段默认访问关系10办公终端192.168.10.0/24仅可访问业务端口20应用服务器192.168.20.0/24对外提供 Web 服务30数据库服务器192.168.30.0/24仅接受应用服务器访问99管理网段192.168.99.0/24仅运维终端可访问禁止业务流量进入VLAN 划分完成后三层交换机上要做 VLAN 间路由的访问控制。如果只有 VLAN 没有策略VLAN 之间还是能互相访问分域就只剩二层隔离的名义。真正的安全边界是三层策略。在实际项目中VLAN 规划最常被忽略的是管理网段。很多运维为了方便把设备和服务器的管理地址混在业务网段里。这样做一旦业务网段被攻破攻击者可以直接管理设备。管理网段应该独立存在并且只能允许运维终端的源地址访问。4.2 流量过滤iptables 有状态与无状态规则的取舍网络层过滤落地在 Linux 主机上最常用的是 iptables落地在设备上是 ACL。无论形式如何设计思路是一致的默认拒绝、白名单放行、最小暴露。前面 2.2 节已经展示了一个最小 iptables 配置这里再补充关于有状态与无状态规则的取舍。iptables 可以自己维护连接追踪表允许”已建立连接“的回包进来这需要加载nf_conntrack模块。有状态规则的好处是回包自动放行不需要为每一个临时端口单独开洞。缺点是连接追踪表占用内存在大量短连接场景下可能成为瓶颈。无状态规则的思路是只按五元组匹配不关心连接状态。优缺点正好反过来性能好但需要把可能的回包端口全部写清楚规则数量会膨胀。我给业务服务器做配置时通常用有状态规则作为主策略再叠加端口限制# 加载连接追踪相关模块 modprobe nf_conntrack # 默认拒绝一切入站流量 iptables -P INPUT DROP # 允许已建立连接的回包这是有状态规则的核心 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 允许来自办公网的 SSH 访问 iptables -A INPUT -s 192.168.10.0/24 -p tcp --dport 22 -j ACCEPT # 允许来自任意来源的 HTTPS 访问Web 服务需要暴露给外部 iptables -A INPUT -p tcp --dport 443 -j ACCEPT注意规则顺序ESTABLISHED,RELATED的放行规则必须放在新连接放行规则之前因为后续规则不会回看已经匹配过的流量。如果你把 443 的放行写在了前面而连接追踪规则在它后面第一次握手包被放行后回包会被默认策略丢弃因为回包没有匹配到任何规则。一个容易让人困惑的地方是 iptables 规则保存。iptables 命令改的是运行时配置重启后失效。要用iptables-save /etc/iptables/rules.v4保存并在开机脚本里用iptables-restore恢复。不少人在服务器上配好了防火墙重启后规则全没了还以为是配置没生效。4.3 流量可见性端口镜像与抓包验证安全策略配置得再完整如果看不见实际流量就无法验证策略是否生效。网络侧需要两个可见性工具交换机端口镜像用于让监控设备采集真实流量tcpdump 用于在主机侧抓包验证策略匹配情况。端口镜像的配置因厂商而异思科、华为、华三的命令各有差异。思科交换机上典型的配置是把某个业务端口流量镜像到监控端口# 在思科交换机上把 Gi0/1 端口的进向流量复制到 Gi0/24 监控端口 monitor session 1 source interface Gi0/1 tx monitor session 1 destination interface Gi0/24镜像端口后把安装了抓包工具的监控主机接到 Gi0/24 上就能看到该业务端口发出的全部流量。注意tx与rx参数tx只镜像出方向rx只镜像入方向需要双向流量时写both。监控端口不要接普通业务否则镜像流量和业务流量会互相干扰。主机侧抓包验证防火墙规则是否生效时我在目标主机上用 tcpdump 抓本机端口的流量# 在服务器上抓取 eth0 网卡的 80 端口流量验证防火墙是否放行了外部访问 tcpdump -i eth0 -nn port 80 -c 100 -w /tmp/http.cap-nn不做域名和端口反解加快解析速度也能避免抓包时产生额外 DNS 查询。-c 100限制抓包数量避免文件无限增长。-w保存为 pcap 文件之后用 Wireshark 分析。抓包在安全运维中的实际用途一是确认防火墙规则匹配是否符合预期——该放行的流量是否确实进来不该放行的流量是否确实被丢二是排查网络层面的丢包和重传——如果大量 TCP 重传说明链路质量或 MTU 设置有问题这往往是业务性能劣化但系统侧查不出原因的真凶。5. 系统安全与网络安全衔接时最容易踩的 4 个坑5.1 坑一防火墙放行了端口主机侧服务却暴露到了外网现象安全组在防火墙上只放行了办公网 IP 访问 3389但实际测试发现外网也能连上服务器 3389 端口。原因防火墙策略管的是跨越设备的流量但服务器本身如果是云主机安全组和主机侧防火墙是两层独立体系。很多运维只配置了云安全组的入方向规则忘了主机自身的防火墙处在关闭状态导致端口实际暴露。另一种常见情况是服务器上跑了多个服务安全组放行了 3389但服务器的其他服务如 1433、3306 也在监听 0.0.0.0安全组没有覆盖这些端口。解决在主机侧也建立最小化出站和入站策略。检查本机所有监听端口确认对外服务的绑定地址是内网 IP 还是 0.0.0.0。对于只在内网使用的服务监听地址应改为内网网卡 IP而不是对所有地址监听。这个检查应该在每次安全组变更后同步执行一遍。5.2 坑二系统时间不同步日志审计对不上号现象内网服务器被入侵需要把系统审计日志、防火墙会话日志和交换机日志关联起来还原攻击路径结果发现三者的时间戳相差几分钟到几十分钟事件顺序完全对不上。原因服务器和网络设备默认使用本地时钟没有配置 NTP 同步。设备长时间运行后时钟漂移会越来越大。审计日志、防火墙日志、交换机日志如果不在同一时间基准上关联分析根本无从谈起。解决在所有服务器和网络设备上启用 NTP 同步统一使用同一个时间源。Linux 服务器上配置 NTP 后可以用timedatectl验证同步状态。时间源的选择建议内网至少部署一台主时间服务器所有设备指向它这台时间服务器再对外同步。不要在每台设备上直接配置外网 NTP内网设备访问外网受限时会出现间歇性同步失败。网络设备上的 NTP 配置需要单独设置因为交换机通常没有timedatectl用的是ntp server命令。5.3 坑三加固操作一步到位把自己锁在门外现象按照安全基线的要求修改了 SSH 配置加入登录白名单和密码复杂度策略重启 sshd 服务后管理员自己也无法登录了。查看进程发现 sshd 在跑但登录总是被拒绝。原因改动 sshd_config 时AllowGroups指定的用户组不存在或管理员账户不在这个组又或者修改了PermitRootLogin no后管理员习惯用 root 直接登录但在配置修改前没有先创建普通管理员账户。PAM 配置里如果对pam_pwquality的选项写错还会导致密码修改流程完全不可用。解决在修改 SSH 和 PAM 配置前先执行两个预防动作一是确认自己的测试账户能够登录二是开启一个新会话并保持不退出用新会话去验证配置。我自己的习惯是在改完配置后不立刻重启 sshd而是先运行sshd -t做语法检查确认没有问题再重启。如果已经把自己锁在门外最可靠的后悔药是通过带外管理口登录或者让机房同事在本地终端操作。5.4 坑四安全策略做全了远程管理通道本身却不受控现象内网所有业务主机的系统加固都完成防火墙策略也收紧到位。但安全扫描时发现有一台服务器的远程管理端口可以从不属于管理网段的地址访问而且这个端口没有开启登录失败锁定策略暴力破解尝试可以直接打到这里。原因运维为了省事把远程管理端口直接放在业务 VLAN 里并且没有在防火墙上限制管理端口的源地址。管理通道的暴露范围比业务通道更大——业务端口至少面对的是特定协议管理通道往往开放了完整的登录接口攻击者不需要先攻破业务服务直接对管理端口爆破即可。解决远程管理端口必须单独划分管理网段且只能在防火墙上允许运维终端的固定 IP 访问。管理端口同时启用账户锁定策略和登录告警连续失败 5 次锁定一段时间每次失败登录都要触发告警。这个坑的教训是——最先被攻破的往往是运维自己留下的最方便的那扇门。把管理通道管住了系统安全和网络安全才算真正衔接上。6. 把两套安全状态合成一张巡检表验证系统与网络安全是否还在基线内6.1 检查清单从主机到网络设备逐项验证安全配置做完不意味着结束真正考验的是长期维护中配置是否还能保持有效。我把检查项固化成了两个区块主机侧和网络侧。主机侧每台服务器执行一遍同样的检查。网络侧在核心交换机上核对。主机侧巡检清单概括为账户是否有变化、端口是否有新增、关键文件哈希是否匹配基线、系统时间是否同步、日志是否有近期异常事件。网络侧的巡检是VLAN 间策略是否还是预期放行的路径、设备 NTP 是否有告警、镜像端口是否还在运行、关键链路的流量基线是否出现异常波动。之前提过的基线哈希校验命令在这里就是巡检的验证工具# 重新校验 key 系统目录是否与基线一致-q 让输出只保留差异项 sha256sum -c /var/lib/secure/baseline.sha256 --quiet | grep -v OK # 二次确认列出当前所有 TCP 监听端口逐个人工核对业务预期 ss -tuln | grep LISTEN巡检的节奏根据环境规模定。服务器数量少就每周跑一次数量多就放在配置管理平台上统一执行把结果输出成报表。不管是手工跑还是自动化跑都要留一份结果存档这样才能看出变化趋势。6.2 发现基线漂移后的两个处置习惯第一个习惯是区分“正常变更”和“漂移”。业务在跑配置不可能一成不变上线新服务会新增监听端口维护更新会修改命令目录下的文件哈希。巡检发现变更后不要急着恢复基线先核对变更记录确认是否由正常的运维操作导致。如果是正常变更就把基线文件更新到新状态。如果是未经记录的变更就需要按安全事件处理查清楚是谁改的、为什么改。第二个习惯是保留变更前后的证据。很多安全复盘失败根源在于改完之后没有留存“改之前”的记录。我在完成每次加固和策略变更后会把变更前后的配置清单和巡检结果各存一份。两个月后回头看这份历史归档比任何记忆都可靠。安全运维的本质是持续验证不是一次性的项目交付——把巡检做成习惯系统安全与网络安全这两套配置才能真正持续生效。希望这套方案帮到你。本文还有配套的精品资源点击获取
