企业官网建设流程全解析

刚接触安全基线的时候，我也以为它不过是把网上流传的加固清单抄一遍：改改密码策略、关掉root远程登录、再删几个没用的服务，就完事了。后来被生产环境教育了几次，才意识到所谓“基线”不是一堆孤立命令的堆砌，而是一整套围绕“默认拒绝、最小权限、全程可审计”的配置哲学。照着这份汇总做一遍，你会把大部分常见入侵路径提前堵死，也让等保测评和内部审计不再需要临时抱佛脚。

这篇内容适合两类人：一类是刚接手服务器运维、想系统补齐安全功底的开发者；另一类是已经在做运维、但每次加固都靠网上零碎资料拼凑的同行。我会把Linux加固里最常用、也最容易被忽略的配置项拆开讲清楚，每条都告诉你为什么这么改、不这么改会出什么问题，以及我踩过的坑。

1. 安全基线到底在解决什么问题

1.1 安全基线不是“一条命令”，而是一套攻击面收敛策略

很多人对“基线”的理解停留在某个具体操作上，比如“把SSH端口改成2222”。但如果你只看某一个点，很快就会陷入猫捉老鼠的误区：今天改了SSH端口，明天发现vsftpd开着匿名访问；明天关了匿名访问，后天又发现某个web目录存在777权限。安全基线真正要解决的是系统在“默认状态”下的攻击面过大的问题。

新装好的Linux系统，为了易用性，默认打开了很多你根本用不上的能力：可能有空密码账号、有对所有人开放的SUID程序、有未做限制的内核包转发、有全开权限的家目录。生产环境要的是“只保留业务必需的通道，其余全部关闭”，而安全基线就是帮你完成这个收敛动作的标准作业程序。它把账号、权限、网络、日志这些维度统一成一份可反复对照的配置约定，这样才能在每次新装环境、每次版本升级之后，知道自己到底改过什么、还差什么。

1.2 一次加固的优先级该怎么排

加固不是改得越狠越好，改崩了业务比不加固更麻烦。我建议按下面这个优先级来：

1. 账号与认证策略（最容易被利用，改动风险相对可控）
2. 权限与文件系统（直接决定文件被破坏后的影响范围）
3. 网络服务与防火墙（决定谁能连进来、能访问什么）
4. 日志与审计（决定出事之后能不能回溯）

如果时间只够做两件事，我会先做账号和SSH加固，再做日志。你后面会发现，很多攻击行为最终暴露都是在日志里被发现的。

还有个原则值得挂在嘴边：能不改业务行为就不改，能先试运行就试运行。比如防火墙默认拒绝策略，在业务流量高峰前做完测试再应用；内核参数的调整，也要评估对既有连接的影响。切记，基线的目标是把风险降到可接受的范围，而不是把系统改成一个谁也连不上的铁疙瘩。

2. 账号与认证策略加固

2.1 密码策略与锁定阈值：别再把密码设置当摆设

账号口令是最直接、也最容易被暴力破解的一层防线。几乎所有发行版都提供了/etc/login.defs和 PAM 模块来约束密码行为，我见过很多服务器装完系统后就直接用默认值，密码永不过期、错误尝试不锁账号，结果就是弱口令加上无限重试。

先看/etc/login.defs里跟密码生命周期相关的参数：

PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14

这三个参数的意思是：密码最长使用90天必须更换；两次改密码之间的最短间隔是7天；到期前14天开始提醒。把 PASS_MIN_DAYS 设为7而不是0，是为了防止用户被要求改密码后立刻改回原来的密码，在配合密码历史记录时尤其有用。

然后看 PAM 侧的密码复杂度策略。在大多数带pam_pwquality的发行版中，/etc/pam.d/system-auth或/etc/security/pwquality.conf里可以配置类似下面的规则：

minlen = 14 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1

含义是密码至少14位，必须包含数字、大写字母、小写字母、特殊字符中的至少一种。dcredit = -1的写法是“至少有一类字符”，如果你设成dcredit = 1，意思反而变成了“最多允许1位数字”，千万别搞反。

针对登录失败锁定，我推荐在/etc/pam.d/system-auth和/etc/pam.d/password-auth里加入 pam_faillock 配置：

auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 account required pam_faillock.so

连续错5次锁定15分钟。这里有个细节：不要把even_deny_root_account直接加在 root 上，除非你确保自己有带外管理通道。root 账号被锁后，如果又关了远程登录，那就只能去物理控制台或者带外管理恢复了，容易把自己逼进墙角。

2.2 禁止root直接远程登录：最小权限的第一步

Linux 服务器最常见的错误配置就是开放 root 的 SSH 登录。root 账号名称是确定的，攻击者只要爆破这一个用户名，一旦成功就是最高权限。正确的姿势是：禁止 root 直接远程登录，日常操作用普通账号加 sudo 提权。

在/etc/ssh/sshd_config里确认这几个配置：

PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no

其中PasswordAuthentication no对安全性提升非常大，虽然推广初期会被同事抱怨，但它能直接消灭密码爆破这条路径。如果环境不允许完全关闭密码登录，至少要保证密码足够强壮，并配合前面说的失败锁定。

做了这个改动后，你需要为管理员准备一个有 sudo 权限的普通账号，并且把公钥放到该账号的~/.ssh/authorized_keys里。我个人建议给管理员账号设置独立的复杂密码，而不是所有机器用同一个，否则一旦某台机器被拖库，其他机器也跟着遭殃。

提示：修改sshd配置后，先用sshd -t检查语法，再平滑重载systemctl reload sshd。不要直接 restart，避免正在进行的SSH会话被切断。

2.3 清理无用账号和空密码账号

一个长期运行的服务器上，很容易积累一些没人使用但依然有效的账号。它们可能是测试时创建的，也可能是某个程序自动加的。审计账号是件枯燥但必要的事。

最直接的办法是看/etc/passwd里那些登录Shell不是/sbin/nologin或/bin/false的账号：

awk -F: '($7 != "/sbin/nologin" && $7 != "/bin/false"){print $1, $3, $7}' /etc/passwd

对确认不再使用的账号，用passwd -l 用户名锁定，而不是直接删除。锁定和解锁的成本都很低，万一误判还能恢复，而删除账号同时也会清掉它的家目录和文件，误操作后很难找回。

空密码是更危险的状况，要单独查：

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

正常情况下这应该没有输出。如果有，说明账号没有密码就能登录，危害极大，必须立刻passwd 用户名设置密码或直接锁定。这个检查建议写进定期巡检脚本里。

2.4 sudo权限收敛：不要给所有人一把万能钥匙

很多团队的习惯是把运维账号全部加到wheel组，给的就是完全sudo权限。这样用起来当然爽，但一旦某个人的账号被入侵，攻击者直接sudo su -就拿走整台机器。

权限收敛的思路是：按“最小够用”原则给sudo规则。在/etc/sudoers.d/下新增一个文件，举例：

cmnd_alias OPS_CMD = /usr/bin/systemctl status *, /usr/bin/systemctl restart nginx, /usr/bin/tail, /usr/bin/grep opsuser ALL=(ALL) NOPASSWD: OPS_CMD

这样opsuser只被允许执行查看服务和重启指定服务的命令，其他都需要输入密码或被拒绝。日常的常规操作使用普通权限，真正需要提权时才临时sudo。

另外定期用sudo -l查看当前用户能执行哪些命令，也应该是运维自检的一部分。你会发现有些规则是历史遗留，早该清理了。sudo日志在/var/log/secure或/var/log/auth.log里都有记录，发生问题时要记得先查这里。

3. 权限体系与文件系统加固

3.1 关键文件的权限收敛：别让口令哈希对所有人开放

LINUX 的权限模型是基础中的基础，但很多服务器上依然能看到不合理的文件权限。最典型的就是/etc/shadow和/etc/passwd。

/etc/passwd需要被所有用户读取（因为用户名和UID的映射是公开信息），但它不应该可写；/etc/shadow存放的是密码哈希，普通用户完全不该读。合理权限如下：

我在一次加固检查中遇到/etc/shadow权限是644，当时吓出一身冷汗。攻击者拿到这个文件后，直接离线跑哈希，速度快、动静小，防都没法防。

还有一个容易遗漏的点：SSH 私钥文件权限。私钥如果权限过大（比如644），OpenSSH 会直接拒绝使用。规范做法是私钥文件600、所在目录700，公钥文件可以644。

3.2 默认umask：新文件一出生就要“最小权限”

umask 决定了新建文件的默认权限。系统默认的 022 让新文件是644（rw-r--r--）、新目录是755，对大多数场景没问题，但如果你所在的业务需要更严格的隔离，可以提高到 027。

在/etc/profile或/etc/bashrc中添加：

umask 027

这样新目录是750，新文件是640，组内成员可读但不可写，其他用户一概不可读。这个设置对共享主机、多团队共用服务器的情况尤其有用。

不过要注意的是，umask 对 cron 任务、systemd 服务等非交互式环境不生效或受单独配置影响。曾经出现过某脚本交互登录时文件权限正常，但cron执行后生成的文件权限过大的问题，排查方法是在脚本内显式设置umask 027，不要依赖全局环境。

3.3 SUID/SGID排查：找出那些“隐形特权”

SUID/SGID 是Linux里最容易被忽视的权限隐患。一个带SUID位的程序，运行时会以文件属主的身份执行。如果有恶意程序被植入了SUID位，普通用户执行它，就能获得root权限。

定期扫描系统里所有带SUID/SGID的文件：

find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -ls

-xdev表示不跨文件系统，避免扫到挂载的、不受控的存储设备，效率也更高。

扫描结果里哪些是正常的？像passwd、ping、su、sudo这些系统自带的SUID程序通常属于正常情况。像find、vim、python这类不该有SUID位的程序，一旦出现就要警惕。处理方式是去掉SUID位：

chmod u-s /path/to/program

如果你担心误伤系统自带的SUID程序，建议先在一台测试机上扫描一遍，记录正常清单，再在生产环境对照排查。

3.4 关键目录挂载选项：给/tmp等可写目录上锁

/tmp、/var/tmp、/dev/shm这类目录是所有人都有写权限的，也是攻击者投放临时文件、执行脚本的高频位置。如果它们挂在根分区上，既方便了攻击者，也可能因为大量临时文件写满根分区而拖垮系统。

理想方案是把/tmp做成独立分区，并在/etc/fstab中加上限制：

/tmp /tmp xfs defaults,nosuid,nodev,noexec 0 0

每个选项的含义是：

• nosuid：禁用SUID位，防止在/tmp下执行提权程序
• nodev：不识别设备文件，防止挂载恶意设备
• noexec：禁止直接执行该分区上的二进制文件

noexec是双刃剑。有些软件安装包、脚本会把临时文件放在/tmp并直接执行，开启后可能报错。落地前先用mount -o remount,noexec /tmp试运行一段时间，确认没有影响业务再写进fstab。

/dev/shm同理，很多exploit利用它来创建可执行内存文件，加上noexec,nosuid,nodev能增加攻击成本。/home分区建议加nosuid,nodev，但要不要加noexec，取决于你的用户是否有在home目录跑脚本的需求，不建议一刀切。

4. 网络层与服务加固

4.1 sshd配置细化：入口要守得更严一些

SSH 是绝大多数服务器唯一会对外开放的通道，它的配置直接决定攻击者能不能摸到你的系统。除了前面提到的禁止root登录，还有几个细节值得处理。

网络层的超时设置很重要，能防止已经建立的空闲连接被僵尸进程占用：

ClientAliveInterval 300 ClientAliveCountMax 3

含义是每300秒向客户端发送一次心跳，连续3次无响应则断开。这能把部分被攻击者占用的空闲会话自动清掉。部分环境担心断掉正常用户的长连接，可以把ClientAliveCountMax调大，但不要不设上限。

再往下是协议与转发控制，如果业务确定不需要X11转发和TCP转发，可以关闭：

X11Forwarding no AllowTcpForwarding no

减少这些功能不是为了省那点资源，而是缩小“跳板”能力。默认情况下允许TCP转发，攻击者拿到一台机器后，可以通过它内网横向访问其他机器，关闭后这条路径就断了。

最后注意登录次数限制：

MaxAuthTries 3 LoginGraceTime 60

MaxAuthTries 限制单次连接内最多尝试认证3次，LoginGraceTime 限制登录超时时间60秒。这两个参数能有效降低密码爆破的效率和并发攻击的影响面。

4.2 停用用不到的服务：每个开放端口都是一扇窗

安装完系统后第一件事，应该是看看到底开了哪些服务、监听了哪些端口。很多发行版默认会启动一些平时根本用不到的服务，比如传统网络服务、打印服务、邮件服务等。

查看开机自启的服务：

systemctl list-unit-files --type=service --state=enabled

逐项确认哪些是业务依赖的。确认不需要的，停止并禁用：

systemctl stop 服务名 systemctl disable 服务名

在裁剪服务前，建议先查一下端口占用和依赖关系，防止误停关键服务导致业务异常。用ss -tlnp看当前监听端口和进程，确认每个开放端口的用途，再决定是否保留。

一个容易忽略的地方是 socket 单元。有些服务虽然服务本身没启用，但对应的.socket文件处于激活状态，接受网络请求后才拉起服务，比如某些远程登录 socket。检查时不要只看.service，还要注意.socket类的单元。

4.3 防火墙默认策略：从“放行常用”改为“默认拒绝”

很多服务器的防火墙策略是“默认放行，只封禁少数端口”，这在攻击面控制上是反的。安全基线的思路应该反过来：默认拒绝所有入站流量，只放行业务明确需要的端口。

在 firewalld 上，把默认区域的目标修改为 DROP，是最直接的做法：

firewall-cmd --set-default-zone=drop firewall-cmd --permanent --zone=drop --add-service=ssh firewall-cmd --permanent --zone=drop --add-port=80/tcp firewall-cmd --permanent --zone=drop --add-port=443/tcp firewall-cmd --reload

这样系统只放行SSH、HTTP、HTTPS，其余端口一律丢弃。用firewall-cmd --list-all --zone=drop查看最终生效的规则，避免出现“改了但没生效”的情况。

使用 iptables 的管理员也可以实现相同效果，核心规则就两条：

iptables -P INPUT DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT

先放行已建立连接和回包，再放行明确需要的端口，最后默认拒绝。注意别把--dport 22这条放在默认拒绝之后，否则顺序会出问题。

4.4 内核网络参数：从协议层面掐断“跳板”

内核网络参数的加固，很多人不重视，但它是防止服务器被当作跳板机、被利用做中间人攻击的关键。

写在/etc/sysctl.d/99-security.conf：

net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.ip_forward = 0 net.ipv4.conf.all.rp_filter = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1

逐条解释：

• accept_redirects = 0：不接受ICMP重定向报文，防止攻击者通过伪造重定向改变路由表
• send_redirects = 0：不发送重定向报文，减少信息泄露
• accept_source_route = 0：不接受带源路由选项的IP包，防止绕过路由策略
• tcp_syncookies = 1：开启SYN Cookie，缓解SYN Flood攻击。高并发服务器开启前要压测，个别极端场景下可能影响性能
• ip_forward = 0：不转发IP包，如果这台机器不做路由或NAT，必须为0
• rp_filter = 1：开启反向路径过滤，防止IP欺骗
• icmp_echo_ignore_broadcasts = 1：忽略广播地址的ICMP请求，避免被用于放大攻击

配置完执行sysctl -p /etc/sysctl.d/99-security.conf生效。生产环境改内核参数前，建议先记录原始值：

sysctl -a > /tmp/sysctl-before.txt

出问题能快速对比还原。

4.5 SELinux与AppArmor：别一上来就 disable

长期运维的老兵都听过一句话：遇到装不上、跑不起来、权限奇奇怪怪的问题，第一反应就是“SELinux害的”，然后setenforce 0甚至直接改配置永久禁用。这确实能解决眼前问题，但把系统的强制访问控制关闭了，等于把所有进程之间的互相访问都交给程序员自觉。

SELinux 不像你想象的那么难。遇到服务被拦截时，先看审计日志：

ausearch -m avc -ts recent

它会告诉你哪个进程、尝试访问哪个资源、被哪条策略拦住了。常见的问题比如Nginx想读某个目录，可以给目录设置正确的上下文：

semanage fcontext -a -t httpd_sys_content_t "/webroot(/.*)?" restorecon -Rv /webroot

再比如服务需要连接数据库端口，需要打开相应布尔值：

setsebool -P httpd_can_network_connect 1

能精确放行就不要全局关闭。如果团队对SELinux不熟，可以先把/etc/selinux/config里的模式设为permissive跑一段时间，只看告警不拦截，摸清业务到底需要哪些放行项后再切回enforcing。不要直接设为disabled，因为disabled后，重新开启需要重启系统，而且文件上下文可能已经错乱。

5. 日志审计与运维闭环

5.1 关键日志的开启与保存：让操作和入侵都留下痕迹

日志是安全事件发生后唯一的回溯依据。很多系统被入侵后，管理员第一反应是“我什么都查不到”，因为日志要么没开、要么已经被清掉了。

至少有这几类日志必须确认是开启的：

• /var/log/messages或/var/log/syslog：系统整体运行日志
• /var/log/secure或/var/log/auth.log：认证与sudo日志，记录谁登录过、谁执行了提权
• /var/log/cron：计划任务日志
• /var/log/boot.log：启动日志

在 rsyslog 配置中，确认authpriv.*和cron.*没有被注释掉。如果使用 systemd 的 journald，需要在/etc/systemd/journald.conf中限制它占用的磁盘空间，防止日志无限增长撑爆根分区：

SystemMaxUse=500M

500M对大多数场景够用了，也不需要日志全留在本机，更长时间的历史建议转发到远程日志服务器。

5.2 日志轮转配置：日志要留，但不能把磁盘塞爆

日志轮转是加固里最容易“漏做”的一项。系统默认配置通常能覆盖基本需求，但业务进程产生的日志如果不纳入轮转，就会无限增长。我就遇到过一次/var分区被某个Java应用日志写满，导致整个系统服务异常的事故。

修改/etc/logrotate.conf或logrotate.d下的文件，核心参数就这些：

daily rotate 30 compress delaycompress missingok notifempty

意思是：每天轮转一次，保留最近30份，轮转后压缩。delaycompress建议保留，它让上一次轮转的文件等下一个周期再压缩，避免有些进程还握着旧文件句柄导致压缩失败。

配置完可以用一条命令手动验证效果：

logrotate -vf /etc/logrotate.conf

-v会输出详细过程，-f强制轮转。如果配置有问题，这一步就能暴露出来，不用等真实轮转时才出状况。

5.3 时间同步：所有日志有效性的基础

时间不同步的服务器，日志基本等于废纸。试想一下，登录日志里记录的入侵时间是凌晨2点，但系统时间比真实时间慢了两小时，排查时就会浪费大量精力去对齐时间线。攻击者在两台服务器之间横向移动时，如果各机时间不一致，还原整个攻击路径会非常费劲。

在大多数发行版上，配置 chrony 并启用开机自启：

pool your-ntp-server iburst

配置后同步检查：

timedatectl status chronyc tracking

如果有多台服务器，建议统一指向公司内部的NTP服务，避免每台机器都依赖外部网络。时间同步的另一个隐含作用是对日志时间戳做“公证”，配合远程日志服务器，能确定事件发生的先后顺序。

5.4 配置变更管理：让每次加固都“可回滚、可追溯”

安全基线不是一次性活，配置会变、业务会变、人员会流动。如果每次加固都随手改文件，过半年回头看，谁也说不清哪条规则是谁在什么时候加的。

把/etc纳入版本管理是个高效做法。你可以用 etc 管理工具或直接用 git 管理/etc目录，定期提交变更。这里有一个关键的安全注意点：不要默认把带敏感信息的文件提交到远程仓库。比如/etc/shadow、服务私钥、证书文件之类的内容，一旦进入远程仓库就是扩大了泄露面。

建议的做法是：先建立忽略规则，排除敏感文件；每次变更前用cp -a 原文件 原文件.bak.日期做本地备份；变更后做一次diff对比并记录变更原因。坚持半年后，你会得到一份宝贵的变更历史，审计和排障效率会明显提升。

6. 常见问题与排查实录

6.1 改完SSH配置，结果把自己锁在门外了

这事几乎每个运维都经历过。问题通常出在：修改了sshd_config后，重新加载服务时网络断开，或者新配置语法虽通过了但把PermitRootLogin关了，而自己手头没有普通账号的公钥。

正确的操作顺序是：

1. 开启一个新的SSH连接，登录成功后保持开启
2. 在已登录的会话里修改配置
3. sshd -t检查语法
4. systemctl reload sshd重载
5. 用新连接测试登录是否正常
6. 一切正常后再关闭旧的连接

如果已经把自己锁在外面，还有几条自救路径：使用云平台或物理服务器的带外管理终端登录；通过管理口进入单用户模式，重新修改配置。切忌为了贪快直接重启生产服务器，重启带来的影响可能比暂时无法登录更大。

6.2 服务正常运行，但SELinux一直拦截导致功能异常

最常见的现象是Nginx装了、端口开了、防火墙也放行了，但浏览器访问始终报错，看系统日志也没有明显异常。此时第一反应应该看SELinux的审计日志：

ausearch -m avc -ts recent

它会给出类似“denied { read } for pid=xxx comm=nginx name=webroot”的信息。这类问题通常是文件上下文不正确，解决方案是用semanage fcontext和restorecon修正，而不是关闭SELinux。

如果审计日志里没有任何记录，再看看服务日志本身，确认是否真的是SELinux的问题。很多所谓的“SELinux问题”，最后发现是配置文件路径写错了、端口被占用或者目录不存在导致的误判。

6.3 防火墙规则守住了，但业务端口也进不去了

默认拒绝策略上线后，紧接着就是各种端口“忽然不通”的投诉。大多数情况下不是防火墙把端口拒了，而是你忘了在drop区域里放行对应的服务端口。

排查思路是按链路逐层确认：

• 先ping目标IP，确认网络通不通
• 再telnet 目标IP 端口或curl -v，确认端口是否能连通
• 最后firewall-cmd --list-all --zone=drop，确认防火墙规则里是否放行了这个端口

如果确认端口没有放行，添加规则：

firewall-cmd --permanent --zone=drop --add-port=8443/tcp firewall-cmd --reload

这里要提一个实际中经常踩的坑：规则的永久生效需要带上--permanent参数，而且修改后必须--reload。如果你只用了--add-port不加--permanent，那这条规则在重启或重载后就会消失，业务端口又会断掉。

6.4 加固后日志变多了，磁盘空间反而告急

开启更全面的日志记录之后，日志增长也会提速。曾经在一个业务量较大的服务器上，/var/log/messages一天能涨几个G，因为journald的默认策略没有限制存储上限。

这种情况处理分两步。第一步是临时清理释放空间：

journalctl --vacuum-size=200M

这个命令会把journal日志缩减到200M以内。第二步是修改/etc/systemd/journald.conf中的SystemMaxUse=500M并重启 journald，防止后续继续膨胀。

另外用du -sh /var/log/*排查一下是哪个日志文件异常增长。很多时候不是系统日志，而是某个应用没接logrotate，一直在同一个文件里追加写入，需要优先给这类应用配置轮转规则，而不是简单删除日志文件——删除正在被进程写入的日志，磁盘空间不会真正释放，必须重启进程或truncate才行。

我个人操作中的体会是，安全基线最大的价值不只是把几项配置设对，而是形成一套“默认安全”的思维习惯。每次新装服务器，第一反应不是急着部署业务，而是先按这份清单做一轮收敛；每次业务变更，都要回头核对基线是否被破坏。安全这件事，真正难的不是“做一次”，而是“每次都不走样”。如果你能把账号、权限、网络、日志这四块都打理清楚，再配合定期巡检和变更记录，这台服务器的安全基线就算真正立住了。