企业官网建设流程全解析

简介：面向Linux系统运维人员与安全工程师的加固实操指南，从系统安装阶段的安全设置讲起，围绕用户帐号安全和网络服务安全两大主线展开。内容涵盖密码安全策略制定、弱口令检查、Password Shadowing机制、密码管理流程，并针对网络层给出服务过滤、/etc/inetd.conf配置、R服务安全限制、Tcp_wrapper访问控制及/etc/hosts.equiv文件管理等具体措施。资源为单一PDF文件，大小仅40KB，便于随时查阅或打印使用；正文共16页，目录结构清晰，按概述、安装、用户帐号安全、网络服务安全等模块组织，既适合初次接触Linux安全的入门者建立整体加固框架，也能帮助有经验的运维人员对照手册逐项自查、系统排查薄弱环节，形成从密码策略到网络访问控制的完整加固闭环。目前已有1332人学习浏览，是一份精炼实用的Linux安全基线参考。

1. LINUX安全加固：先想清楚要挡住谁，再打开手册

大多数 Linux 服务器出问题，不是被什么零日漏洞打穿，而是默认配置太宽松：SSH 开着 root 密码登录、rpcbind 这些没人记得的服务挂在公网、内核参数全部是出厂值。拿到的这份 LINUX安全加固手册，本质上是给系统做减法：把用不到的端口、账号、服务和隐患参数一个个收掉，让攻击者即使拿到一个普通执行权限，也很难提权、横向、持久化。它的使用对象很明确：负责生产服务器、云主机和物理机的运维、系统管理员，以及做攻防演练或 CTF 题时需要对目标环境做防御加固的安全工程师。我这篇不按手册的目录一章章念，而是按真正动手的顺序讲：先盘点、再收紧、最后验证，把参数含义和翻车点说透。

2. 加固前必做的三件事：资产盘点、基线选型与风险分级

很多人拿到手册直接就在生产机上敲命令，结果业务先跪了。我自己最早踩过这个坑，所以在讲具体加固项之前，必须先说清楚准备工作。Linux 安全加固不是一条条指令的堆叠，而是一套面向基线的收敛过程，动手之前，你得知道自己面对的是什么样的系统、按什么标准来收、先收哪里后收哪里。

2.1 资产盘点：先把跑着的服务、端口、内核版本摸清楚

第一步不是改配置，而是给这台机器做一次完整的“人口普查”。我在拿到一台新接管的服务器时，通常会用下面这组命令把基础信息捞一遍：

uname -a # 内核版本和架构，判断有没有安装非标准内核模块 cat /etc/os-release # 发行版版本，决定后续用 apt 还是 yum 装加固工具 ss -tulnp # 当前监听的所有 TCP/UDP 端口和对应进程 systemctl list-units --type=service --state=running # 所有正在运行的服务单元 ps -ef # 当前进程列表，后面会专门讲异常进程排查

这组命令的输出就是你的加固起点。uname -a和/etc/os-release决定了下文里的命令和源是否适用；ss -tulnp是确认暴露面的关键，公网 IP 的机器如果监听端口里有 0.0.0.0:3306 这类数据库端口，这就是第一个高优先级问题；systemctl list-units能让你发现一堆“装系统时自动带上、但根本没用”的服务，比如 avahi-daemon、cups、rpcbind，这些后面要逐个关掉。

盘点的目的不是把命令输出存个档，而是让你能给每个端口和服务回答三个问题：谁在用、是否需要对外、挂了会产生什么后果。回答不上来的服务，一律进入“待关闭”清单。

2.2 基线选型：用 CIS Benchmark 还是自建精简基线

确定有什么之后，要确定“加固到什么程度”。当前业内最常参考的 Linux 基线是 CIS Benchmark，它把加固项分成账号策略、SSH 服务、内核网络参数、文件权限、审计日志、防火墙等十几个域，每项都标注了对应风险和检测方法；国内单位也常按等保 2.0 里“主机安全”的测评项来对齐，通常要求身份鉴别、访问控制、入侵防范、审计记录。两种选型我都用过，实际做法是拿 CIS 的项作为底表，按业务能接受的牺牲程度删掉一批“会阻断现有流程”的项。

基线选型不需要一开始做到完美，但要有个清单。下面这张表是我给普通生产服务器定基线时最常用的分类方式：

建议不要直接照搬全套测评项，那是审计视角；落地时要从“最小可用”出发，先把表里标“中风险误伤”的项设计成可回滚配置，再逐步收紧。

2.3 风险分级与回滚准备：先改认证，再动网络

一台服务器上往往同时跑着数据库、Web 服务和内网对接进程，它们对停机或连接中断的容忍度完全不一样。我的处理顺序是先做安全收益最高、误伤最小的认证加固，再做系统内核参数，最后动防火墙和 SELinux 这类可能直接阻断业务的项。

动手以前，花十分钟做一份可回滚快照，这是 Linux 安全加固里的“后悔药”：

mkdir -p /root/backup/$(date +%F) cp -a /etc/ssh /etc/pam.d /etc/login.defs /etc/sysctl.conf /etc/sysctl.d /root/backup/$(date +%F)/ sysctl -a > /root/backup/$(date +%F)/sysctl_before.txt systemctl list-unit-files --state=enabled > /root/backup/$(date +%F)/enabled_services.txt

备份/etc下的关键配置目录，是因为后面每一步都在改这些文件；sysctl -a快照会在内核参数改坏时帮你还原到改动前的全部当前值；启用服务清单也是一个基线，后面排查新出现可疑服务时会用到。有了这个备份，后面第 6 章讲的回滚才算有据可依。

3. 账号与 SSH 加固：从口令到登录链路的完整收紧

账号是 Linux 系统安全的第一道门，也是最容易被忽视的门。很多加固手册的第一章就是口令策略和 SSH 配置，原因很简单：暴力破解、弱口令登录、离职员工账号未回收，是运维事故里出现频率最高的三件事。这一章我会把 PAM 密码策略、SSH 服务参数、sudo 权限回收串成一条完整的登录链路来改。

3.1 密码策略与 PAM 配置：把口令的“下线时间”管起来

口令策略不是单纯设一个复杂密码，而是要把密码的生命周期管理起来。先改/etc/login.defs里的四个参数：

# /etc/login.defs 修改后仅对新创建用户生效 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14

PASS_MAX_DAYS 90要求密码每 90 天必须更换，PASS_MIN_DAYS 7防止用户当天改完又立刻改回去以绕过历史记录，PASS_WARN_AGE 14是提前 14 天提醒用户到期。这三个参数共同保证口令有上限、有下限、有提醒。注意它对存量用户不生效，所以还要用chage -M 90 -m 7 -W 14 用户名对现有用户逐个设置，或者直接对/etc/shadow里所有账号统一刷一遍。

口令复杂度由 PAM 的pam_pwquality模块控制。在 CentOS/RHEL 系上是/etc/pam.d/password-auth和/etc/pam.d/system-auth，在 Ubuntu/Debian 系上是/etc/pam.d/common-password，加一行：

password requisite pam_pwquality.so retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1

这里的minlen=12控制最小长度 12 位；dcredit=-1表示必须包含至少 1 位数字，负号表示“必须包含”，后面三个参数同理，分别表示大写字母、小写字母、特殊符号。retry=3是允许用户最多失败 3 次重新输入。需要提醒的是：复杂度策略只拦新密码，存量弱密码还得靠后续的批量检查和chage强制过期来兜底。

如果你用的是国产 Linux（比如基于 openEuler、统信 UOS 的服务器），PAM 配置文件路径和pwquality模块名称基本与 RHEL 系一致，差异通常在/etc/pam.d/system-auth是否被单独链接，用ls -l /etc/pam.d/确认一下即可。

3.2 SSH 服务加固：禁用 root 登录前，先确认自己有钥匙

SSH 是服务器最常暴露给外网的服务，也是爆破和提权的第一入口。加固手册里最核心的一段配置集中在/etc/ssh/sshd_config：

# /etc/ssh/sshd_config 关键加固项，改完执行 sshd -t 再重载 PermitRootLogin no # 禁止 root 直接 SSH 登录，必须用普通用户 su 或 sudo PasswordAuthentication no # 禁用密码登录，只允许密钥认证 PubkeyAuthentication yes # 开启公钥认证 MaxAuthTries 3 # 每次连接最多尝试 3 次 LoginGraceTime 30 # 登录超时 30 秒 ClientAliveInterval 300 # 服务端每 300 秒检查一次客户端存活 ClientAliveCountMax 0 # 客户端无响应 1 次即断开 AllowUsers ops deploy # 只允许这两个用户从 SSH 登录

PermitRootLogin no和PasswordAuthentication no是收益最大的两项，但也是最容易把自己关在外面的两项。我的建议是分两步走：第一步先把自己的公钥写进~/.ssh/authorized_keys，用密钥能登录之后，再在sshd_config里把密码登录关掉。MaxAuthTries 3和LoginGraceTime 30用来限制暴力破解的连接频率，AllowUsers是账号白名单，把不需要登录的人挡在外面。

改完配置必须做两件事：sshd -t检查语法，然后systemctl reload sshd而不是 restart，因为 reload 不断开现有连接，避免重载失败把自己踢下线。任何一次 SSH 加固操作之前，我还会额外开一个临时 tmux 会话，防止网络波动和配置错误叠加在一起导致彻底失联。

3.3 sudo 权限回收与最小授权：把“万能钥匙”换成门禁卡

账号章节里最容易忽略的是 sudo。很多服务器上直接给研发账号ALL=(ALL) ALL，这和给攻击者发了一张万能卡没什么区别。加固的思路是收敛授权范围，用命令别名替代无差别的ALL：

# /etc/sudoers.d/webadmin 示例，由 root 执行 visudo -f 校验后生效 Cmnd_Alias WEBADMIN = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, \ /usr/bin/nginx -t, /usr/bin/tail -f /var/log/nginx/* webadmin ALL=(root) NOPASSWD: WEBADMIN

这段配置的含义是：webadmin用户只能在webadmin这台或这一组机器上、以 root 身份执行冒号后面限定的那几条命令，且不需要输密码。NOPASSWD只应用在限定命令上是可接受的，因为nginx -t做个语法检查不会伤到系统；但如果它是ALL，就必须要求输入密码，否则别人拿到这个账号等于拿到一台 root 级别的跳板机。

sudo 收紧之后，还要回头查两个地方。第一，grep -P '^[^:]+:[^:]+:0:' /etc/passwd，把所有 UID 为 0 的账号列出来，正常情况下应该只有 root 一个，多出来的就是隐藏管理员后门；第二，用getent group sudo（Debian/Ubuntu）或getent group wheel（RHEL 系）查看哪些用户拥有 sudo 资格，把不用的账号从组里移掉。最小授权这一步做完，提权攻击的可用路径就窄了大半。

4. 系统与内核加固：文件权限、内核参数与隐藏风险排查

账号和登录链路收紧了，攻击者直接进门的难度变大了，但还要防已经拿到普通权限的人就地提权、落地持久化。这一章做的是系统层加固：把文件权限和不可变属性管好，把内核里影响纵深防御的参数调对，最后用一组命令找出那些已经在系统里潜伏的异常。

4.1 关键文件权限与不可变属性：让攻击者改不了、写不动

Linux 权限模型中，最常被忽略的是“全局可写”和“属主不对”这两类问题。先跑一个全盘扫描：

find / -xdev -type d -perm -0002 -print 2>/dev/null # 查找全局可写目录 find / -xdev -type f -perm -0002 -print 2>/dev/null # 查找全局可写文件 find / -xdev -type f -nouser -o -nogroup 2>/dev/null # 查找属主或属组已删除的僵尸文件

第一类全局可写目录是攻击者放脚本、替换二进制文件的温床，常见的/tmp要保留可写，但通过修改/tmp挂载选项加nodev,nosuid,noexec来限制执行能力；第二类无主文件很容易被利用——因为 nobody 或某个已删除用户的文件，任何同名新用户都可能接管它。对这些文件的处理不做一刀切，逐个确认业务方是谁，确认为垃圾就删，确认为业务文件就chown给正确属主。

对确定不能动的关键文件，用chattr加不可变属性，这是很多运维手册里一笔带过但非常有效的防篡改手段：

chattr +i /etc/passwd /etc/group /etc/shadow # 加上写保护锁，root 也不能直接改 lsattr /etc/passwd # 查看是否带 ----i---------- 标记

+i是 immutable，加上之后文件连 root 都不能改写、不能删除、不能创建硬链接，对防止后门篡改账号文件很有用。但注意，chattr +i用在/etc/shadow上会导致你以后用useradd或passwd创建新用户时报错，改动前必须先chattr -i /etc/shadow解锁。我见过有人把整个/etc目录加了+i，结果 cron、日志轮转全部写入失败，这就是典型的加固翻车，所以不可变属性只建议加在最关键的少数几个文件上。

4.2 sysctl 内核参数：地址随机化与网络防欺骗的实测组合

内核参数加固主要解决两类问题：利用内存布局问题提权和利用网络协议特性发起扫描、欺骗、DoS。常见做法是在/etc/sysctl.d/下建一个独立配置文件，比如99-hardening.conf：

# /etc/sysctl.d/99-hardening.conf kernel.randomize_va_space = 2 # 开启 ASLR，地址空间随机化 kernel.kptr_restrict = 1 # 限制 /proc/kallsyms 暴露内核符号，防止被用来计算内核基址 kernel.dmesg_restrict = 1 # 限制 dmesg 读取权限 net.ipv4.conf.all.accept_redirects = 0 # 不接收 ICMP 重定向报文 net.ipv4.conf.all.accept_source_route = 0 # 丢弃带源路由选项的包 net.ipv4.conf.all.rp_filter = 1 # 开启反向路径过滤，杜绝源地址伪造 net.ipv4.tcp_syncookies = 1 # 开启 SYN cookies，缓解 SYN 洪泛 net.ipv4.icmp_echo_ignore_broadcasts = 1 # 忽略广播 ping

写入后执行sysctl --system重新加载，再用sysctl net.ipv4.conf.all.accept_redirects这类命令验证每一项的当前值是否已生效。每个参数我单独说明：kptr_restrict和dmesg_restrict是配合使用的，它们把内核符号地址和内核日志从普通用户视野里隐去，攻击者提权前最爱的信息源就被堵住了；rp_filter是反伪造的关键，尤其对公网服务器，它能拒绝那些源地址不在路由回程路径上的包；accept_redirects和accept_source_route则直接指向一种常见的中间人手法——向受害主机发送伪造的 ICMP 重定向来篡改它的路由表。

这块有一个经常踩的坑：很多服务器本身起着路由转发的作用，比如 Docker 宿主机的net.ipv4.ip_forward=1。如果你同时把accept_redirects或rp_filter改成激进值，容器和宿主机之间的通信可能变得时好时坏。所以内核参数也要按第 2 章盘点出来的角色来定，纯粹的 web 服务器可以全开，云原生节点要谨慎测试rp_filter对外挂容器网卡的影响。

4.3 异常进程、定时任务与登录后门排查

系统层加固最后要确认一件事：这台机器是不是已经被入侵过、留下了后门。Linux 提权和持久化的常见手法里，定时任务和系统服务是最容易被复用的载体。排查路径我一般固定为三条：

# 1. 检查所有定时任务，重点是 /etc/cron.* 目录里的系统级条目 cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ # 2. 检查正在运行的进程，关注名字被空格、中括号伪装的可疑进程 ps -eo pid,user,stat,cmd --sort=pid | awk '$3 ~ /^[A-Z]/ {print}' # 3. 检查最近启动的系统服务和端口监听是否有不明新增 systemctl list-units --type=service --state=running | grep -v -E 'systemd|dbus|ssh|nginx|mysql|redis' ss -tulnp | grep -v -E '127.0.0.1|::1'

定时任务里的坑是：某些后门不会写在/etc/crontab里，而是以/etc/cron.d/下带随机文件名的一条记录存在，所以ls -la看目录里有没有“面生”的文件比直接cat更有效。进程排查时，攻击者经常用一个可执行程序的副本伪装成[kworker]这类内核线程名，真正的内核线程名称都是带方括号且没有路径的，如果遇到/[kworker]/tmp/x这种组合就要立刻警觉。端口排查则关注监听在0.0.0.0上的非本地端口——反弹 shell 和代理后门通常长这样。

这节不追求一条命令找到所有后门，而是把“新出现的、没人认识的服务和端口”暴露出来。配合第 2 章备份的enabled_services.txt，凡是当前运行服务和备份基线不一致的，逐个拉出来审一遍，这就是加固题里排查隐藏风险的标准做法。

5. 服务与防火墙加固：常见翻车点排查与避坑路径

前两章把账号和系统层收紧之后，剩下的工作集中在网络暴露面：停掉多余服务、配置防火墙规则、处理好 SELinux 与业务之间的摩擦。这一章我会把操作步骤和真正的血泪教训放在一起讲，因为网络加固是所有加固动作里最容易让自己和业务一起翻车的环节。

5.1 先做服务收敛：把没在用的端口关掉，再做防火墙

防火墙规则只能拦截新连接，它拦不住本机已经监听的恶意端口。所以正确的顺序是先收敛服务，再配置防火墙。常见做法是先把那些“装系统时带上但没人用”的服务停掉：

systemctl disable --now avahi-daemon cups rpcbind 2>/dev/null systemctl stop --now telnet.socket 2>/dev/null ss -tulnp | grep -v -E 'sshd|nginx|mysqld|redis'

disable --now会同时做两件事：立刻停止当前进程，并且把开机自启动的符号链接从/etc/systemd/system的多用户目标目录下移除，这样重启后也不会再出现。服务收敛后，用ss -tulnp重新看一遍监听端口，排除sshd、nginx、mysqld、redis 这类确认真实业务需要的端口后，剩下的监听项要么补进防火墙白名单，要么回到第 4 章查进程。

5.2 防火墙规则落地：默认策略的最后一步才能设为 DROP

防火墙配置绝对是加固流程里维护事故率最高的操作。很多手册给出的规则写法是“先 DROP 再放行”，但直接执行会让你的 SSH 当场断掉。我推荐的顺序是先放行管理端口，再设置默认拒绝。以 firewalld 为例：

firewall-cmd --permanent --zone=public --add-service=ssh firewall-cmd --permanent --zone=public --add-service=http firewall-cmd --permanent --zone=public --add-service=https firewall-cmd --permanent --zone=public --change-interface=eth0 firewall-cmd --reload

第一步把 ssh、http、https 加为放行服务；第二步把 eth0 放入默认的 public zone；第三步 reload 使配置生效。之后再把默认 target 从default改成DROP。如果用的是 iptables，逻辑完全一致，但要特别注意规则的顺序：-A INPUT -j DROP必须放在所有放行规则之后，否则它会匹配所有数据包并直接丢弃。我的习惯是先用一个临时脚本放行ESTABLISHED,RELATED和自己当前的 SSH 连接，再在脚本末尾追加 DROP 规则，最后给脚本设置 30 秒的延迟执行——这样即使规则写错了，连接断开后 30 秒内规则自动恢复，人不会彻底失联。

这个 30 秒“后悔药”是我做网络加固时的保留技巧，也建议你把它写进自己团队的变更单里。对核心数据库端口（如 3306、5432），不要直接开放到 public zone，而要新建一个internal或自定义 zone，只放行指定内网网段。防火墙的价值不在于挡住所有 IP，而在于只让该来的流量进来。

5.3 避坑清单：五条运维里最常见的 Linux 加固翻车记录

加固命令本身不复杂，复杂的是那些“配置看起来对、服务却起不来”的瞬间。下面五条是我在处理 Linux 运维故障案例时多次遇到的高频问题，按现象、原因、解决的格式拆开说，希望你不需要再踩一遍。

现象一：改完 sshd_config，所有 SSH 连接都连不上了。原因：PermitRootLogin no和PasswordAuthentication no是在没有确认公钥可用的情况下同时启用的，密钥未部署成功或authorized_keys权限不对，导致唯一登录通道失效。解决：不要在远程会话里直接改禁用项，先用 tmux/screen 保持一个长会话；改完先sshd -t校验语法，再用systemctl reload sshd让现有连接不断；最后另开一个窗口验证新配置能登录，再关掉旧窗口。

现象二：防火墙规则一执行，服务器瞬间失联，机房只能靠带外管理重启。原因：在还没有任何放行规则时就把默认策略改成了 DROP，等于把自己家的钥匙在出门前扔了。解决：管理端口必须最先放行，且需要放行ESTABLISHED,RELATED让回程包能进来；生产环境用延时生效脚本做变更；所有入方向规则写完后，先iptables -L -n或firewall-cmd --list-all检查一遍，再决定是否让规则持久化。

现象三：按加固手册关闭了 ICMP 重定向，整个内网的机器互相 ping 不通了。原因：不只关了accept_redirects，还把net.ipv4.icmp_echo_ignore_all设成了 1，把 ICMP 全禁了。内网监控和多路径探测依赖一定能用。解决：只关accept_redirects和accept_source_route就够了，icmp_echo_ignore_all不要全局开启；想防探测可以只对公网接口开启，保留内网接口的 ICMP 能力。

现象四：给/etc/passwd加了chattr +i之后，系统升级、创建用户全部失败。原因：不可变属性锁死了关键文件，但 rpm/dpkg 在升级时需要对/etc/passwd做临时修改和替换，直接写入被拒绝。解决：chattr +i只用于最核心、极少变化的文件，且必须在系统升级和账号变更前chattr -i解锁；惯例上是把系统升级窗口与加固锁定窗口分开，升级前批量解锁，升级后重新锁定并做一次lsattr校验。

现象五：SELinux 设为 Enforcing 后，nginx 绑定非标准端口或读自定义目录直接启动失败。原因：SELinux 的布尔值和文件上下文没有跟随配置改动而更新。解决：先用ausearch -m avc -ts recent查看被拒事件，再用semanage port -a -t http_port_t -p tcp 8080放行 nginx 的非标准端口，对自定义目录执行semanage fcontext -a -t httpd_sys_content_t '/data/web(/.*)?'后restorecon -Rv /data/web。如果团队对 SELinux 不熟，我建议先用setenforce 0观察审计日志，确认没有 AVC 拒绝后，再在维护窗口内正式开启 Enforcing。

6. 验证你的加固结果：手动核查、基线扫描与回滚技巧

加固做完不等于结束，要能证明“我改了什么、效果如何、出问题怎么退回”。这一章是一套收尾习惯：先用手工命令核对关键项，再用扫描工具整体过一遍，最后把回滚路径说清楚。

6.1 手工核查清单

6.2 自动化扫描与回滚路径

手工核查之后，我一般会在测试环境跑一轮自动化基线扫描，最常见的是 Lynis，执行之前用apt install lynis或yum install lynis安装，装好后直接执行lynis audit system。扫描报告会给出一个 hardening index 分数，但分数高低不是重点，重点在报告末尾的“建议”列表——它会把每一项加固缺失标成suggestion或warning。我的习惯是：把分数前后对比当参考，把建议导致的操作风险逐条人工复核，宁可不追求满分，也不让一条建议把业务弄挂。

回滚路径靠第 2 章的备份实现：配置类文件直接用cp -a的备份覆盖回去，再systemctl restart对应服务；sysctl 参数用sysctl -f /root/backup/sysctl_before.txt恢复，或者手动改回99-hardening.conf后sysctl --system；如果改坏了 SSH，而备份也覆盖不了当前连接，就用机房/控制台的 VNC 或单用户模式把改动的配置行还原。这一套流程我用下来最大的心得是：每次加固必须把改动清单记在变更单里，倒不是给别人看，而是三个月后系统出问题时，你可以准确地说出“我改过哪六个参数”。

整套 Linux 安全加固我在线上环境前后推动过几十次，最有价值的不是扫描分数从 30 涨到 80，而是攻击者进来之后发现：账号是锁死的、端口是收敛的、内核提权路径是堵住的，最后只能灰溜溜退出去。希望帮到你。

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