新装服务器需针对性配置防火墙与SELinux：firewalld按需开放业务端口（如http/https），禁用宽泛规则；SELinux必须设为enforcing模式并校准上下文，二者协同实现“能否进入”与“进入后能做什么”的纵深防御。
新装的服务器系统，防火墙和 SELinux 不是“开了就行”，而是要根据实际用途做针对性配置：该放的端口放开、该拦的流量拦住、该限制的进程锁死。默认开启但未调优，反而可能造成服务不通或权限报错，安全没提升，运维先头疼。
防火墙：按需开放，拒绝默认全通
CentOS/RHEL 8+ 和 Rocky/AlmaLinux 默认启用 firewalld；Ubuntu/Debian 默认用 UFW（底层仍是 iptables/nftables）。关键不是关或开，而是明确“谁需要访问什么”。
- 安装后立即检查状态：
systemctl status firewalld（RHEL系）或ufw status verbose（Debian系） - 只开放业务必需端口，例如 Web 服务只需：
firewall-cmd --permanent --add-service=http --add-service=https，然后firewall-cmd --reload - 禁止直接开放全端口或使用
--add-port=1-65535/tcp这类宽泛规则；如需调试，临时加规则并设超时（--timeout=300），完成后及时清理 - 若服务器位于企业内网且已有边界防火墙，可停用本地 firewalld：
systemctl disable --now firewalld，避免策略冲突
SELinux：启用强制模式，不跳过策略校准
SELinux 默认在 RHEL/CentOS 系统中已安装，但常处于 permissive（仅记录不拦截）或被误设为 disabled。真正起效必须运行在 enforcing 模式，并配合正确上下文。
- 确认当前状态：
getenforce查模式，sestatus -v看详细策略加载情况 - 临时切换到 enforcing：
setenforce 1；永久生效需编辑/etc/selinux/config，将SELINUX=enforcing，保存后重启 - 不要为图省事设为
disabled—— 重启后无法热启，且失去对 Web、数据库、NFS 等服务的进程级隔离能力 - 部署服务后若遇“Permission denied”但文件权限正常，大概率是 SELinux 上下文不匹配，用
ls -Z查标签，restorecon -Rv /path修复，或按需用semanage fcontext定义新规则
协同防护：防火墙管“能不能进”，SELinux 管“进来后能干什么”
二者不是替代关系，而是纵深防御的两层：
- 防火墙拦住非法 IP 的 SSH 暴力尝试、扫描请求、非业务端口连接；它失效时，攻击者可能拿到 shell
- SELinux 在攻击者获得低权限 shell 后继续起作用：比如限制其无法读取
/etc/shadow、不能加载恶意内核模块、不能 bind 到非标准端口、无法篡改 Nginx 静态目录外的文件 - 典型组合场景：firewalld 允许 22 端口入站 → 攻击者爆破成功登录 → SELinux 限制其 shell 进程类型（
user_t）无法执行mount、chroot或写入系统 bin 目录
初始配置后的必验动作
配完不是终点，要验证是否真正生效：
- 用另一台机器 telnet 或 curl 测试开放端口是否可达，未开放端口是否被拒（拒绝响应比超时更安全）
- 执行
ausearch -m avc -ts recent查看最近是否有 SELinux 拒绝日志；若有高频拒绝且属合理操作，说明需调整策略而非关闭 SELinux - 模拟低权限用户尝试敏感操作（如
sudo cat /etc/shadow），确认被 SELinux 或 sudo 权限双重拦截 - 重启服务器后再次运行
getenforce和firewall-cmd --state，确保配置持久化无遗漏
