企业官网建设流程全解析

简介：面向Linux运维、系统管理员及安全入门者，这份PDF手册系统讲解Linux系统安全加固的核心要点，覆盖系统安装阶段的安全设置、用户帐号与密码策略、网络服务安全等环节，帮助读者建立从基础到进阶的加固思路。资源为单个PDF文件，大小约40KB，内容精炼但目录结构清晰，按「概述、安装、用户帐号安全、网络服务安全」等模块组织，便于快速定位和查阅。目前已有1333人学习下载。手册着重说明密码安全策略、密码强度检查、Password Shadowing机制、密码管理方法，以及服务过滤、/etc/inetd.conf、R服务、Tcp_wrapper、/etc/hosts.equiv等网络服务安全配置，并涉及NFS、Sendmail、finger、UUCP等常见服务的安全建议，既有概念解释也有操作指引，适合在系统上线或日常运维时对照自查，快速补齐安全短板。

1. 安全加固的本质：为什么默认安装的 Linux 是个靶子

拿到一台刚装好的 Linux，最反直觉的事实是：它默认开启的监听端口、信任机制和系统账号，每一项都是潜在入口。所谓安全加固，不是装个杀毒软件就完事，而是把系统从「隐式信任一切」改造成「显式允许少数」。这份 LINUX 安全加固手册的价值在于它把散落在账号、网络服务、内核参数、文件系统里的加固点串成了一条可落地的检查链。但照抄命令容易翻车：hosts.deny 里一行 ALL:ALL 可能让你连不上自己的服务器，chattr +i 锁完 /etc/passwd 之后 useradd 会直接报错。只有把每条加固命令背后的机制搞明白，才知道哪些该做、哪些要改、顺序怎么排。这篇文章就按手册的骨架，把每项加固从「结论」拆到「机制」。

2. 账号与认证：密码哈希、shadow 与 su 限制的层层设防

账号安全是所有加固的地基。攻击者拿到一个弱口令账号，比攻破一个内核漏洞省事得多。手册这一章看起来只是几条命令，实际上覆盖了密码生命周期的三个阶段：生成时要求复杂度，存储时把哈希藏起来，使用时限制谁能用 root。三个阶段对应三套完全不同的底层机制。

2.1 /etc/passwd 到 /etc/shadow：密码哈希为什么必须「藏」起来

早期 Unix 系统把用户名、UID、GID 和密码哈希全部放在 /etc/passwd 里，这个文件权限是 644，因为 ls -l、getpwnam 这类日常操作都要读取它做 UID 到用户名的映射。问题是哈希也跟着暴露了。拿到哈希的攻击者不需要在线猜密码，可以直接离线跑字典或暴力破解工具，速度只受限于 CPU 和 GPU。在线猜测会有失败次数限制和日志记录，离线破解毫无痕迹，这是本质区别。

shadow 机制就是把哈希从公开文件挪到 root 专属文件。现代发行版默认启用 shadow，但理解这个历史脉络才能看懂手册里这句「使用 shadow 来隐藏密文」的分量。下面这条手册里的检查命令值得逐段拆解：

awk -F: 'length($2)==0 {print $1}' /etc/shadow

-F: 指定冒号作为字段分隔符，/etc/shadow 每行是一个账号，$2 是第二个字段，即加密后的哈希串。length($2)==0 表示该字段为空，说明这个账号没有口令，任何人登录都不需要密码。这条命令把所有空口令账号打印出来，是加固后必须执行的验证动作。实际生产中还要配合 chage 查看口令有效期：

口令复杂度这块，手册说「至少 6 位并且包含特殊字符」是那个年代的基线。真正执行的机制是 PAM 的密码质量模块，它会检查长度、字符类别、是否与用户名相似、是否在字典里。现代建议至少 12 位，关键是让攻击者的离线破解成本远高于口令本身的价值。

2.2 su 的 PAM 认证链：为什么 wheel 组能独享 root

多人共用 root 密码是审计噩梦：出了事不知道是谁干的，人走了还得全员改密。wheel 组的思路是「不共享 root 密码，只共享 su 的资格」。它的实现完全靠 PAM 认证链，弄懂这条链就理解了 Linux 认证框架的设计。手册给出的配置是往 /etc/pam.d/su 头部加两行：

auth sufficient pam_rootok.so auth required pam_wheel.so group=wheel

PAM 按行序执行。第一行：root 执行 su 时，pam_rootok 直接判定成功，sufficient 意味着命中就跳过后续模块，所以 root 不受 wheel 限制。第二行：非 root 用户走到 pam_wheel，系统检查该用户是否属于 wheel 组，不属于则认证直接失败——注意是 required，失败即整体拒绝，连密码都不用输入。把管理员加入 wheel 组的命令是 usermod -aG wheel 用户名，-a 表示追加，避免覆盖用户原有的次要组列表。这是手册里没细说的坑，后面排查章会展开。

为什么这种「认证链」设计比单纯改 su 权限更优越？因为 PAM 模块可以自由组合。想要双因子就在中间插一个 pam_google_authenticator，想记录审计就在后面挂 pam_tty_audit。加固不是改一个配置，而是拼接一条你信得过的认证流水线。理解了这个，再看系统里 sudo 和 su 之争就清楚了：sudo 走的是另一个 PAM 栈加 sudoers 授权表，审计粒度更细，这也是为什么现代运维更倾向 sudo 而不是共享 root 密码。

2.3 空口令检查与不可变文件锁：把账号文件「焊死」

删系统账号也是这章的重点。userdel adm、lp、sync、halt、news、uucp、operator、games、gopher、ftp，这些账号平时不用，但它们是服务运行的身份载体。保留一个没有密码的 sync 账号，等于给攻击者留了一个可以切换身份的入口。特别说明 games 和 gopher：不用 X Window 就删，避免给无关服务提供执行身份。

账号清理完，最后一道保险是给密码文件上不可变标志：

chattr +i /etc/passwd chattr +i /etc/shadow chattr +i /etc/group chattr +i /etc/gshadow

这条命令的机制和 chmod 完全不同，属于文件系统 inode 层面的标志位，我放在第 4 章专门拆解。这里只需记住顺序：先建账号、改密码、配 wheel 组，全部完成后再锁。锁完之后任何进程——包括 root 自己——都改不了这几个文件，入侵者即使提权成功也没法清空密码、添加后门账号。

3. 网络服务收缩：tcp_wrapper、inetd 与最小监听面的取舍

网络服务是攻击面最集中的地方。一份加固手册用了最大篇幅讲服务安全，不是因为服务配置难，而是因为服务是系统默认对外开放的窗口。这一章的核心逻辑只有一句话：只开放需要的服务，其余的从监听端口上消失。

3.1 inetd 超级守护进程：按需拉起的服务模型

在 systemd 之前，Unix 管理杂项服务靠的是 inetd（后来是 xinetd）。它的模型很优雅：一个常驻进程同时监听多个端口，某个端口收到连接请求时，inetd 才把对应的服务进程拉起来，会话结束进程退出。好处是内存占用小、日志集中、访问控制统一；坏处是每次连接都有 fork 开销，慢速攻击可以拖垮进程调度。

/etc/inetd.conf 每行描述一个服务，格式是：服务名 套接字类型 协议 标志 用户 服务程序路径 参数。手册要求把注释符加到不需要的服务行首，改完重启 inetd 让配置生效。这里藏着第一个认知关键点：inetd 只管它托管的服务。像 httpd、sendmail、sshd 这类独立守护进程有自己的启动脚本，注释 inetd.conf 对它们毫无影响。所以「注释完端口还在」几乎必然发生，排查办法放第 5 章。

xinetd 作为增强版，把每个服务拆成 /etc/xinetd.d 下的独立文件，支持 only_from、no_access、per_source 这类更细的访问控制。今天的发行版里 inetd 系已经边缘化，但它的设计遗产还在：按需启动、集中管控、先裁决后转发，这套思路直接继承给了 tcp_wrapper 和后来的 socket 激活。

3.2 tcp_wrapper：先裁决、再转发的「二传手」机制

tcp_wrapper 是 Linux 安全加固史上最值得研究的中间层。它的实现思路是把真正提供服务的 daemon 换成它附带的 tcpd 程序，由 tcpd 先做访问控制，通过后才把请求转交给真正的服务进程。拿 telnet 举例，原来连的是 in.telnetd，配置后变成连 tcpd，tcpd 记录来源 IP 和时间，检查访问控制列表，通过则 exec 真正的 in.telnetd，拒绝则直接掐断连接。完全就是「二传手」。

访问控制由两个文件决定，匹配顺序极其重要：

# /etc/hosts.allow 先查 sshd: 192.168.1.0/255.255.255.0 .example.com # /etc/hosts.deny 后查 ALL: ALL

先查 allow，命中就放行，不再看 deny；再查 deny，命中即拒绝；两个文件都没命中，经典 tcpd 的默认行为是放行。这就是为什么手册强调要在 deny 里写 ALL: ALL 兜底——不写的话，遗漏的服务等于裸奔。allow 文件里常见的语法是「服务名: 主机名或 IP 列表」，支持网段和域名后缀匹配。

PARANOID 模式是手册里容易被忽略的点。它要求客户端的主机名反查 IP 必须与连接源 IP 一致，不一致直接拒绝。这能挡住一部分 DNS 投毒和源 IP 伪造，代价是 DNS 抖动或反向解析没配好时，正常用户也会被挡在门外。所以生产环境启用 PARANOID 前，先确认内部 DNS 的反向区域是完整的。配置完用 tcpdchk 检查语法，UDP 服务走 tcp_wrapper 时要用 nowait 选项，否则同一时刻的并发 UDP 请求会被串行处理。

今天很多服务——包括 sshd、sendmail——编译时已经带了 libwrap 支持，意味着它们即使不走 inetd 启动，也会读 /etc/hosts.allow 和 /etc/hosts.deny。这条知识在排查 SSH 突然连不上的问题时价值千金。

3.3 R 服务信任模型：为什么「+ +」是系统里最危险的两个字符

R 服务（rlogin、rsh、rcp）是那个年代远程管理的标准方案，但它的信任模型在今天是灾难。机制是这样的：系统有一个 /etc/hosts.equiv 文件记录「可信主机」，用户家目录下可以放 .rhosts 文件记录「可信主机+可信用户」。来源地址匹配且用户匹配，就直接免密登录。问题在于它信任的是「声称的来源」——TCP 源 IP 可以伪造，DNS 可以污染，于是手册反复强调的「+ +」就成了噩梦：它表示任何主机上的任何用户都可以免密访问系统，等于把门锁拆了。

加固方法分两级。不用 R 服务就彻底关闭：在 inetd.conf 注释 exec、login、shell 三个服务，删除 /etc/hosts.equiv，预生成 $HOME/.rhosts 并设置为 0000，防止用户权限提升后自助创建。必须用 R 服务时，在路由和防火墙上把 512、513、514 端口对外封死，只允许内网可信段访问，再用 tcp_wrapper 加一层白名单。SSH 之所以是更好的替代品，是因为它把信任对象从「来源 IP」换成了「私钥持有者」：伪造 IP 不再有用，没有私钥就过不了密钥验证。这就是为什么手册建议用 ssh 替代 telnetd、ftpd、pop 等明文服务——明文口令在网络上是可截获的，加密通道让嗅探失效，这是网络层信任模型的一次升级。

3.4 端口过滤清单：信息泄露与反射放大的重灾区

手册第 4.1 节给出了一张服务过滤清单，按风险类型可以分成三类：信息泄露、反射放大、直接溢出。这张表比命令更值钱，因为它解释了「为什么要过滤这些端口」：

过滤手段不只是关闭服务。手册特别指出：如果这些服务确实要开放，必须通过防火墙和路由把来源限制到信任 IP。配合 /etc/services 文件的不可变锁定（chattr +i），防止端口映射被篡改——攻击者改了 /etc/services 里的端口号，防火墙规则就会全部失效，这是「配置层面被调包」的典型手段。配置完成后，手册要求用网络扫描器从外部模拟入侵者扫描一遍，这是验证加固效果的必要闭环：你以为关了，扫描器会告诉你真相。

4. 内核参数与文件系统：关 ping、禁源路由、锁住不可变位

系统层加固的四个动作——关 ping、禁源路由、chattr 加锁、fstab 挂载选项——分别作用在 TCP/IP 协议栈、路由子系统、文件系统 inode 和 VFS 层。它们的共同点是：改的不是应用配置，而是内核行为。

4.1 关闭 ping：让主机在 ICMP 层隐身，但别迷信隐身

命令很简单：

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

写入这个值后，内核的 ICMP 处理路径不再对 echo request 返回 reply。效果是外部发 ping 探测时主机「无应答」，基础的网络扫描和主机发现工具会把它当成不存在的地址。持久化要写进 /etc/sysctl.conf，或者用 sysctl -w 在运行时设置：

sysctl -w net.ipv4.icmp_echo_ignore_all=1

必须说清楚边界：这只是让主机在 ICMP 层面静默，TCP 端口扫描照样能发现它。TCP 连接的存在性和端口开放状态不需要 ICMP 参与，nmap 的 -sS SYN 扫描直接和 80、443、22 端口握手就知道主机活着。所以关闭 ping 的价值是削减探测面、让自动化扫描脚本多一步麻烦，不是隐身术。监控系统如果只依赖 ping 判断存活，关掉这个参数后会把活着的机器报成宕机，这是运维事故的常见来源，第 5 章会讲解决方案。更精细的做法是在防火墙层只丢弃非信任来源的 echo request。

4.2 源路由与反向路径过滤：为什么回包路径也能被劫持

IP 源路由是 IPv4 协议里的一个选项，发送方可以在 IP 头里指定数据包到达目标后「应该沿哪条路径返回」。合法用途是网络排障，恶意用途就大了：攻击者可以指定回包路径绕过防火墙、访问本不可达的接口，甚至让本应直达网关的流量被中间节点截获。这就是为什么手册坚持要「禁止 IP 源路径路由」。

Linux 下的关闭方式写在 sysctl 里：

# 关闭源路由 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 # 开启反向路径过滤 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1

rp_filter 的机制值得一提：内核在收到一个数据包时，会查路由表确认「从该接口返回这个源地址」是否合理，不合理就丢弃。这能有效防范源 IP 伪造。但多网卡、非对称路由的机器上，rp_filter 的 strict 模式会误杀正常流量，此时要用 loose 模式（2）或针对具体网卡调整。这是一个典型的「安全与可用性」拉锯点：开太严，业务包被误丢；开太松，伪造源 IP 的扫描和探测就进来了。

4.3 chattr +i：比 chmod 000 更底层的不可变标志

普通权限模型有个众所周知的空洞：root 可以无视一切文件权限位，rwx 000 对 root 只是摆设。chmod 000 /etc/passwd 挡得住普通用户和入侵后的低权限进程，挡不住已经提权的攻击者。chattr +i 补上的正是这个漏洞。

机制在文件系统层：chattr 修改的是 inode 上的标志位，FS_IMMUTABLE_FL。VFS 在执行 write、unlink、rename、append 操作前会检查这个标志，只要置位就返回错误，即使进程有 CAP_DAC_OVERRIDE 能力也不能绕过。要改动只能先 chattr -i 解除标志，改完再锁回去。这等于给关键文件加了第二道锁，第一道锁是权限位，第二道锁在文件系统元数据里。

手册要求给 /etc/passwd、/etc/shadow、/etc/group、/etc/gshadow、/etc/services、/etc/hosts.equiv 全部加锁。代价是系统升级、用户管理这类合法操作也会被拦，所以正确姿势是分阶段：先完成所有账号和配置变更，最后统一加锁；要改动时先 chattr -i，操作完立即重新加锁，别让文件处于未保护状态过夜。

4.4 fstab 挂载安全：noexec 能挡住什么、挡不住什么

文件系统加固的另一个维度是挂载选项。在 /etc/fstab 里给特定分区加上限制，让即使有写入权限的目录也无法成为攻击者的执行平台。

# /tmp 目录禁执行、禁设备节点、禁 setuid tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev,size=512M 0 0 # /home 同样策略 /dev/sda3 /home ext4 defaults,noexec,nosuid,nodev 0 2

noexec 的机制是 VFS 层在 execve() 系统调用时检查挂载标志，禁止从该文件系统启动任何可执行文件。nosuid 会让 setuid 位失效，攻击者放置的带位程序变成普通文件。nodev 忽略设备文件，防止普通用户 mknod 出块设备访问底层磁盘。

一个高频误区必须划重点：noexec 挡不住「解释器显式读取脚本文件」。比如 noexec 分区上一个脚本，直接执行 ./evil.sh 会被拦，但运行 bash /mnt/evil.sh 能跑，因为这种模式下内核只检查 bash 能否执行，脚本只是被当作普通输入读进来。所以 noexec 不是万能沙箱，它提高的是直接放置二进制木马的成本，防不住带解释器的间接执行。这是设计取舍，不是 bug。

NFS 导出也有对应策略。手册提到用 exportfs -o access=engineering,ro=dancer 控制导出范围，用 ro、no_root_squash 等选项约束权限。showmount -e 可以自查本机导出了什么，配合只允许内网访问 111 和 2049 端口，能把 NFS 的暴露面压到最小。

5. 加固排查：照抄手册必翻车的五个经典场景

这一章是从血泪经验里挑出来的。每个场景都是真实故障：命令照手册抄了，系统也按预期「加固」了，结果翻车了。问题不在手册，在于没理解机制。下面按「现象 → 原因 → 解决」拆解。

5.1 hosts.deny 写入 ALL:ALL，SSH 当场断连

现象：在 /etc/hosts.deny 里加上 ALL: ALL 之后，新的 SSH 连接全部超时，已经建立的会话还活着，但一旦断开就再也连不上了。

原因：sshd 编译时带了 tcp_wrapper 的 libwrap 支持，连接建立前会读 hosts.allow 和 hosts.deny。ALL: ALL 是兜底拒绝规则，而 hosts.allow 里没有 sshd 的白名单条目，于是 SSH 也被拒绝，连密码验证环节都到不了。很多人以为 tcp_wrapper 只管 telnet 和 ftp，这是最大的误解。

解决：先给 hosts.allow 写好允许规则再动 deny：

# /etc/hosts.allow sshd: 192.168.1.0/255.255.255.0

改任何访问控制文件之前，先开一个 tmux 之类的长会话备用，断开也不受影响；改完用新终端验证一次，确认能连上再注销旧会话。血的教训是别在唯一的 SSH 会话里改访问控制，那是给自己断后路。

5.2 chattr +i 之后，useradd 报 Permission denied

现象：执行完 chattr +i /etc/passwd /etc/shadow，第二天新增用户时报错 passwd: Permission denied。

原因：useradd 要同时改写 /etc/passwd、/etc/shadow、/etc/group 三个文件，而 FS_IMMUTABLE_FL 标志把写操作全部拦截了，连 root 也不能例外。这是 4.3 节说的机制，很多人没意识到它会约束合法的用户管理操作。

解决：账号体系调整要在加锁之前完成。如果已经锁了，按顺序解锁再操作：

chattr -i /etc/passwd chattr -i /etc/shadow chattr -i /etc/group # 执行 useradd / passwd 等操作 chattr +i /etc/passwd chattr +i /etc/shadow chattr +i /etc/group

lsattr 可以查看当前文件的锁状态，养成操作前先 lsattr 的习惯能少踩很多坑。

5.3 关掉 ping 之后，监控系统判定主机「死亡」

现象：按加固手册执行 echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all，两个小时后监控平台发来大量主机宕机告警。

原因：监控探活脚本默认用 ping 判断主机存活。ICMP 无响应并不代表 TCP 服务不可用——web 服务和 SSH 都好好的，只是内核不再回复 echo 请求。监控系统把「不回应 ICMP」等同于「主机离线」，误报就产生了。

解决：监控探活改用 TCP 端口探测，比如对 22 端口做 TCP 连接判断。如果必须保留基于 ICMP 的监控，就不要用全局的 echo 1，改成防火墙规则按来源细分，只对非信任网段丢弃：

iptables -A INPUT -p icmp --icmp-type echo-request -s 监控网段 -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

优先保证监控通路，再谈隐藏探测面。这就是前面说的「隐身不等于安全」的落地取舍。

5.4 注释完 inetd.conf，端口却还在监听

现象：按手册把 /etc/inetd.conf 里不需要的服务全部注释，重启 inetd 后用 netstat -an 一看，23、25、80 端口还在 LISTEN。

原因：inetd.conf 只管它托管的那批服务。sendmail、httpd 这类 stand-alone 服务有独立的守护进程，根本不走 inetd；还有些服务在 xinetd.d 目录下有单独配置，inetd.conf 注释了它们也不会消失。netstat -an 只告诉你「端口开着」，不告诉你「谁开的」。

解决：用 ss 或 lsof 定位进程：

ss -tlnp | grep :23

输出会给出监听进程的 PID 和名称，顺着进程去停。还要用 chkconfig --list 或 systemctl 检查开机自启项，把不用的服务从启动序列里移除。记住：端口开放是表象，进程和启动项才是根源。

5.5 删了 hosts.equiv，老旧的 rsh 自动化直接崩

现象：加固时按手册删掉了 /etc/hosts.equiv 并设置 .rhosts 为 0000，第二天就有同事反馈调度任务全部失败，日志里是 remote: permission denied。

原因：内部某个遗留的自动化系统还在用 rsh/rcp 做跨机分发，它依赖 hosts.equiv 的信任关系完成免密登录。删掉信任文件等于切断了它的认证通路。

解决：先迁移到 SSH 密钥再删除信任文件。生成密钥、配置 authorized_keys、把批处理脚本里的 rsh 换成 ssh，确认新链路跑通后，才允许删除 hosts.equiv。这里的原则是「先立后破」：替代方案落地之前，旧机制不要动。加固是工程变更，不是清理现场。

6. 设计取舍：一台服务器到底需要「多硬」

把手册从头串一遍，会发现所有加固动作背后站着一对相反的安全哲学：默认允许还是默认拒绝。经典 tcp_wrapper 的设计默认是「没匹配就放行」，所以必须用 ALL: ALL 兜底；iptables 的默认链策略是 ACCEPT，所以要做端口过滤就要显式写 DROP。而加固手册做的事，本质上是把系统从隐式信任逐步改造成显式允许：关掉不用的服务，是显式允许那些保留的；wheel 组限制 su，是显式允许管理员；hosts.allow 白名单，是显式允许来源 IP。每一层收紧，都在用可用性换取安全性——关 ping 换来探测面上的安静，代价是丢掉 ICMP 监控；chattr +i 换来防篡改，代价是每次用户变更都要解锁；删 R 服务换来免密信任的根除，代价是老脚本全部要改造。

6.1 设计取舍：加固的时效性，背命令不如懂机制

手册有鲜明的时代印记：R 服务、sendmail、6 位密码、inetd.conf，今天的主流发行版基本都换了赛道。但机制是长寿的：PAM 认证链仍然是所有认证的骨架，tcp_wrapper 的决策模型仍然活在 libwrap 里，immutable 标志和 noexec 挂载选项依然是文件系统加固的核心手段。这就是为什么我读这类老手册的习惯是跳过命令，先读机制——命令会过时，但「把哈希藏起来、把信任白名单、把执行权限收窄」这些思路不会。拿一台新机器，我的习惯是先 ss -tlnp 把监听端口逐个过一遍，问自己这个端口该不该对外开放；然后按最小权限原则处理账号和服务，最后从外部用扫描器走一遍，确认加固后的状态和预期一致。从那以后我每次装机都强制走这一遍，踩坑的次数少了一大半。希望帮到你。

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