企业官网建设流程全解析

简介：《计算机系统安全与计算机网络安全》是一份PDF格式的学习参考资料，定位面向计算机专业学生、网络管理员及网络安全入门者，用于建立计算机系统安全与网络安全的基础知识框架。资源包仅包含1个PDF文件，大小约1.07MB，内容紧凑，便于下载后随时阅读。目前已有502人学习/下载，适合作为课程辅导、期末复习或技术培训的参考文献。

文档内容从计算机病毒的内涵、特点与检测清除方法入手，进而梳理计算机系统漏洞的主要类型与成因，并延伸到计算机网络安全的机密性、完整性与可操作性等特点。同时，针对操作系统漏洞、TCP/IP协议明文传输、黑客攻击方式及恶意破坏等现实威胁，给出了相应的分析与防范思路。读完这份材料，读者能够系统了解计算机系统安全与网络安全的常见风险点及相关检测、防护手段，为后续深入学习或安全配置实践打下基础。

1. 计算机系统安全与计算机网络安全：为什么分开讲、又必须合起来做

你在一个中等规模的公司做运维或安全岗，大概率经历过这样的翻车：内网一台 Windows 服务器中了勒索病毒，安全组查了一圈网络层访问控制，发现该封的端口都封了，但病毒还是从文件共享端口横向扩散到了财务网段。问题出在哪？出在只看了网络安全策略，没盯系统安全基线。计算机系统安全与计算机网络安全这两件事，经常被当成一份 PDF 的两个章节去背，但在真实攻击路径里，它们是一根链条上的两环——系统漏洞负责打开入口，网络通路负责扩大战果。这篇文章不重复教材里那些概念定义，直接讲清楚两者怎么分工、怎么各自落地、怎么在衔接处救火。适合手头有真实服务器和交换机要管的运维、安全工程师，也适合准备把安全基线从文档变成检查项的人。

2. 拆开两条防线：系统安全管主机内部，网络安全管流量通路

2.1 系统安全的对象与边界：进程、文件、账户、内核

系统安全面对的是一台主机的运行环境。攻击者拿到一台机器的立足点之后，后续动作几乎都发生在系统层：创建账户、写入启动项、替换二进制文件、加载内核模块、修改配置。这些动作的共性是——它们都在单台主机的边界之内，不涉及跨设备的流量。

所以系统安全的检查项，全部围绕主机的四大资源展开。第一是账户：系统里是否存在多余的高权限账户、默认口令账户、长期不用的幽灵账户。第二是文件：关键目录是否被写入异常文件，关键二进制是否被替换，日志文件是否被清空。第三是进程：是否有可疑进程在监听非预期端口，是否和父进程链异常。第四是内核与启动链路：启动项、计划任务、内核模块是否被注入。

以 Linux 系统为例，我一般会先做一次快速的账户和端口盘点。其核心指令是这几条：

# 列出所有能登录的账户，重点看 uid=0 的账户和空口令账户 awk -F: '($3 == 0) {print $1}' /etc/passwd # 检查是否有空密码账户，这类账户是系统安全里最直接的破绽 awk -F: '($2 == "") {print $1}' /etc/shadow # 列出正在监听的 TCP/UDP 端口，快速定位非预期服务 ss -tulnp

第一条命令查 uid 为 0 的账户，正常系统里应该只有 root。如果发现其他 uid=0 的账户，基本可以判定已经被留了后门。第二条命令查 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 服务器最常见的入口是 SSH，Windows 服务器最常见的是 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 retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 password sufficient pam_unix.so sha512 shadow nullok use_authtok password required pam_pwhistory.so remember=5

第一行要求新密码至少 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(load="imudp") input(type="imudp" port="514")

把日志实时转发到远程服务器后，即使主机上的日志被清理，远端还保留着原始记录。审计与日志这层是系统安全的最后屏障，也是唯一的后悔药——很多安全事件事后复盘，唯一的证据来源就是日志。

4. 网络控制实操：用分段、过滤和监控把网络安全落在一张拓扑图里

4.1 安全域划分：VLAN 规划与标记原则

网络安全的起点不是防火墙策略，而是网络分域。没有分域的网络，所有主机都在同一个二层平面里，任意一台被攻破的机器都能 ARP 扫描到整个网段。分域的核心手段是 VLAN 与网段划分。

常见的划分方式是按业务和信任等级拆开：办公网、服务器区、数据库区、外联区、管理网段各自独立 VLAN。VLAN 之间默认不路由，需要路由时用三层交换机或防火墙控制。

一个典型的中小规模 VLAN 规划可以参考下面这张表：

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 发现基线漂移后的两个处置习惯

第一个习惯是区分“正常变更”和“漂移”。业务在跑，配置不可能一成不变：上线新服务会新增监听端口，维护更新会修改命令目录下的文件哈希。巡检发现变更后，不要急着恢复基线，先核对变更记录，确认是否由正常的运维操作导致。如果是正常变更，就把基线文件更新到新状态。如果是未经记录的变更，就需要按安全事件处理，查清楚是谁改的、为什么改。

第二个习惯是保留变更前后的证据。很多安全复盘失败，根源在于改完之后没有留存“改之前”的记录。我在完成每次加固和策略变更后，会把变更前后的配置清单和巡检结果各存一份。两个月后回头看，这份历史归档比任何记忆都可靠。安全运维的本质是持续验证，不是一次性的项目交付——把巡检做成习惯，系统安全与网络安全这两套配置才能真正持续生效。希望这套方案帮到你。

本文还有配套的精品资源，点击获取