简介这是一份面向Linux系统管理员、安全运维工程师及中级以上Linux学习者的实用安全加固指南聚焦操作系统层面的纵深防御实践。手册系统覆盖安装阶段安全配置、用户账号安全含密码策略、shadow机制、密码强度检测与全生命周期管理、网络服务安全包括inetd服务控制、Tcp_wrapper访问限制、hosts.equiv权限模型、NFS/tftp/sendmail等高危服务加固要点等核心模块内容结构清晰共16页PDF目录层级完整便于按需查阅与实操落地。资源为单文件PDF格式体积精简仅40KB即下即用适合作为现场应急参考或日常加固检查清单。目前已有1332人学习下载内容虽篇幅紧凑但知识点密度高涵盖从基础策略到典型服务防护的完整加固路径是提升Linux生产环境安全基线的可靠速查资料。1. 为什么一份《Linux安全加固手册》比十次应急响应更管用某公司运维团队在一次例行巡检中发现一台对外提供SSH服务的CentOS 7服务器已被植入隐蔽挖矿进程CPU持续满载却无明显日志告警溯源发现攻击者正是利用默认开启的root远程登录弱密码组合在37秒内完成入侵。这不是个例——据2024年公开漏洞平台统计Linux系统因基础配置疏漏导致的未授权访问类事件占全部可复现入侵路径的68.3%远超0day利用或APT投递。这份《Linux安全加固手册》不是教你怎么“封端口、关服务”的粗暴操作而是把内核参数调优、PAM策略链、SELinux上下文约束、审计规则粒度、服务最小化启动这五层防御拧成一条可验证、可回滚、可批量落地的加固流水线。它适合三类人刚接手生产环境的SRE新手避免凭经验瞎改、需要交付等保三级合规报告的项目负责人每条措施对应GB/T 22239-2019条款、以及想把安全左移到CI/CD中的DevOps工程师所有检查项均可脚本化。手册PDF本身只是载体真正值钱的是背后那套“改一行配置必须同步更新三处验证逻辑”的工程化思维。2. 从默认安装到基线达标五个不可跳过的加固层级Linux安全加固不是单点修补而是一套分层防御体系。我见过太多人只改SSH配置就以为万事大吉结果auditd没开、umask设错、systemd服务没加RestrictAddressFamilies等于给黑客留了四扇没锁的后门。下面这五层按生效优先级和影响范围排序缺一不可。2.1 内核参数硬限制用sysctl.conf堵住协议栈漏洞很多加固指南只提net.ipv4.ip_forward 0这种基础项但真正致命的是那些被忽略的内存与连接控制参数。比如vm.swappiness1能大幅降低swap泄露敏感内存的概率net.ipv4.tcp_syncookies1在SYN Flood时自动启用cookie机制而kernel.kptr_restrict2则彻底隐藏内核符号地址——这对防范ret2libc攻击是物理级屏障。# /etc/sysctl.d/99-security-hardening.conf vm.swappiness 1 net.ipv4.tcp_syncookies 1 kernel.kptr_restrict 2 kernel.dmesg_restrict 1 fs.suid_dumpable 0 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1注意kernel.dmesg_restrict1会禁止非root用户读取dmesg输出某些监控Agent可能因此报错。若需保留日志采集应配合journalctl --no-pager -u systemd-journald替代方案而非直接降级该参数。执行后必须运行sudo sysctl --system重载全部配置并用sudo sysctl -n kernel.kptr_restrict验证返回值为2。这里有个血泪经验不要在/etc/sysctl.conf里直接追加而要用独立.conf文件放在/etc/sysctl.d/下——这样便于按功能分类管理且systemd会按文件名顺序加载99-开头的最后加载确保覆盖默认值。2.2 PAM认证链重构让密码策略真正生效很多人以为/etc/pam.d/system-auth里加了pam_pwquality.so就完事了其实PAM模块的执行顺序和控制标志[successok defaultbad]才是关键。默认配置中pam_unix.so常位于pam_pwquality.so之前导致即使密码强度不达标系统仍会用旧密码通过认证。正确做法是将强度校验模块前置并强制失败时终止整个认证链。# /etc/pam.d/system-auth (仅关键行插入位置auth [defaultbad successok] pam_pwquality.so retry3 minlen12 difok3 maxrepeat2) auth [defaultbad successok] pam_pwquality.so retry3 minlen12 difok3 maxrepeat2 password requisite pam_pwquality.so retry3 minlen12 difok3 maxrepeat2参数说明minlen12强制12位以上注意pam_pwquality对Unicode字符计数有缺陷建议搭配enforce_for_root避免root绕过difok3新密码至少3个字符不同于旧密码非位置敏感maxrepeat2禁止连续3个相同字符如aaa非法aax合法执行后立即测试用passwd修改密码输入123456789012会被拒绝提示BAD PASSWORD: The password contains less than 3 different characters。若未生效用pamtester system-auth testuser authenticate调试模块链。2.3 SELinux策略收紧从permissive到enforcing的平滑过渡关闭SELinux是自废武功但直接切enforcing又容易导致服务崩溃。真实落地路径是先用setenforce 0临时切permissive模式收集/var/log/audit/audit.log中的AVC拒绝日志用ausearch -m avc -ts recent | audit2why分析原因再用audit2allow -a -M mypolicy生成自定义策略模块最后签名加载。# 收集最近1小时AVC日志并生成策略 sudo ausearch -m avc -ts $(date -d 1 hour ago %H:%M:%S) | audit2allow -a -M nginx_custom # 编译并加载 sudo semodule -i nginx_custom.pp # 永久启用enforcing sudo sed -i s/SELINUXpermissive/SELINUXenforcing/ /etc/selinux/config sudo setenforce 1关键点在于audit2allow生成的策略默认宽松允许所有相关操作必须人工审查.te文件删除dontaudit规则将allow语句细化到具体文件类型如httpd_sys_content_t而非file_type。否则等于开了个SELinux后门。2.4 systemd服务最小化砍掉90%的默认依赖systemctl list-dependencies --reverse multi-user.target能看到哪些服务被间接拉起。常见陷阱是avahi-daemon零配置网络服务和cups-browsed打印服务发现——它们监听UDP 5353端口且无身份验证是内网横向移动的黄金入口。加固原则所有非业务必需的服务一律mask而非disable。# 查看哪些服务被multi-user.target间接依赖 systemctl list-dependencies --reverse multi-user.target | grep -E (avahi|cups|bluetooth|ModemManager) # 永久禁用无法被任何unit激活 sudo systemctl mask avahi-daemon.service cups-browsed.service # 验证是否生效应显示masked状态 systemctl is-enabled avahi-daemon.service # 返回 masked提示mask比disable更彻底——disable只是不随启动运行但其他服务仍可手动start它mask则创建指向/dev/null的符号链接任何start请求都会失败。这是防止配置漂移的关键手段。2.5 auditd审计规则聚焦高危行为而非海量日志审计规则不是越多越好。/etc/audit/rules.d/下堆满-w /etc/shadow -p wa这类规则会导致磁盘IO暴涨且日志淹没真实攻击信号。应聚焦三类必审行为特权程序执行/usr/bin/sudo,/bin/bash、敏感文件变更/etc/passwd,/etc/shadow,/etc/sudoers、网络连接建立connect系统调用。# /etc/audit/rules.d/10-critical.rules -a always,exit -F path/usr/bin/sudo -F permx -k privileged_exec -a always,exit -F path/etc/passwd -F permwa -k identity_change -a always,exit -F path/etc/shadow -F permwa -k identity_change -a always,exit -F archb64 -S connect -F keynetwork_connect规则说明-k指定key字段便于ausearch -k network_connect快速检索-F archb64限定64位系统调用避免32位兼容层干扰connect系统调用捕获所有出站连接比单纯监控/proc/net/tcp更底层加载后用sudo auditctl -l确认规则已生效并用sudo ausearch -k privileged_exec -i | head -5验证sudo执行是否被记录。3. 避坑五个让加固半途而废的典型翻车现场加固不是改完配置就结束很多团队卡在验证环节甚至因错误操作导致服务不可用。以下是我在多个模拟项目X中反复踩过的坑按发生频率排序3.1 现象SSH登录后立即断开/var/log/secure显示pam_limits(sshd:session): unknown limit item nofile原因在/etc/security/limits.conf中添加了* soft nofile 65535但未启用pam_limits.so模块。CentOS 7默认/etc/pam.d/sshd中该模块被注释而Ubuntu 22.04则默认启用。解决编辑/etc/pam.d/sshd取消# session required pam_limits.so前的#并确保该行位于include common-session之后避免被覆盖。重启sshdsudo systemctl restart sshd。3.2 现象启用kernel.randomize_va_space2后Java应用频繁OOM或JVM崩溃原因ASLR地址空间布局随机化与某些JVM版本的-XX:UseLargePages参数冲突导致大页内存分配失败。解决优先升级JDK至11.0.18或17.0.6已修复该问题若无法升级则在JVM启动参数中显式禁用大页-XX:-UseLargePages而非降低ASLR等级。3.3 现象auditd服务启动失败journalctl -u auditd报错No rules found in /etc/audit/rules.d/原因auditd要求/etc/audit/rules.d/下至少有一个.rules文件但空文件或仅含注释的文件不被识别。解决创建最小有效规则文件echo -e 2 | sudo tee /etc/audit/rules.d/00-minimum.rules-e 2启用审计再执行sudo augenrules --load。3.4 现象systemctl mask某服务后systemctl list-unit-files | grep masked显示正常但ps aux | grep service_name仍能看到进程原因该进程并非由systemd启动而是由cron、rc.local或用户手动后台运行。mask只影响systemd管理的unit。解决用sudo ss -tulpn | grep :PORT定位监听进程再用sudo ps -o pid,ppid,cmd -p $(pgrep -f service_name)查父进程最终在/etc/cron.d/、/etc/rc.local或用户crontab中清除启动项。3.5 现象SELinux切换enforcing后Nginx无法绑定80端口ausearch -m avc -ts recent显示avc: denied { name_bind } for ... port80原因Nginx worker进程默认使用http_port_t类型但80端口在SELinux策略中属于http_port_t需额外赋予name_bind权限。解决不推荐直接semanage port -a -t http_port_t -p tcp 80可能破坏策略一致性而应加载httpd_can_network_bind布尔值sudo setsebool -P httpd_can_network_bind 1。该布尔值专为Web服务开放网络绑定权限设计。4. 自动化验证用三行命令跑完80%的手动检查项加固做完不验证等于没做。我给自己定的铁律是所有人工检查项必须能在30秒内用脚本复现。以下三个命令覆盖了最易遗漏的基线项已集成进某高校实验室的CI流水线每次代码提交后自动触发。4.1 内核参数合规性快检sysctl-check.sh#!/bin/bash # 保存为 /usr/local/bin/sysctl-check.shchmod x declare -A required( [vm.swappiness]1 [net.ipv4.tcp_syncookies]1 [kernel.kptr_restrict]2 [kernel.dmesg_restrict]1 [fs.suid_dumpable]0 ) for param in ${!required[]}; do actual$(sysctl -n $param 2/dev/null) if [[ $actual ! ${required[$param]} ]]; then echo [FAIL] $param: expected ${required[$param]}, got $actual exit 1 fi done echo [PASS] All kernel parameters compliant参数说明sysctl -n静默输出值避免带参数名的冗余文本2/dev/null屏蔽不存在参数的报错exit 1确保CI检测到失败时中断流程。该脚本可直接嵌入Ansible的command模块或Shell CI步骤。4.2 PAM策略有效性验证pam-tester.py#!/usr/bin/env python3 # 保存为 /usr/local/bin/pam-tester.pychmod x import subprocess import sys def test_password_strength(): # 测试弱密码是否被拒绝使用testuser账户 result subprocess.run( [sudo, pamtester, system-auth, testuser, authenticate], input123456\n123456\n, # 弱密码两次 textTrue, capture_outputTrue ) # 检查输出是否包含Password is too short等拒绝关键词 if too short in result.stderr or weak in result.stderr.lower(): return True return False if __name__ __main__: if test_password_strength(): print([PASS] PAM password strength enforced) else: print([FAIL] PAM password policy not active) sys.exit(1)注意需提前创建testuser账户sudo useradd -m testuser echo testuser:123456 | sudo chpasswd且确保pamtester已安装apt install libpam-tester/yum install pamtester。该脚本模拟真实用户修改密码场景比检查配置文件更可靠。4.3 服务暴露面扫描exposed-services.sh#!/bin/bash # 保存为 /usr/local/bin/exposed-services.shchmod x # 扫描所有监听IPv4的TCP端口排除已知安全端口22,443,80等 unsafe_ports$(ss -tln4 | awk $5 ~ /:[0-9]$/ {gsub(/:.*/, , $5); print $5} | sort -u | \ comm -23 (sort 22 80 443 8443 2222) (sort)) if [[ -n $unsafe_ports ]]; then echo [FAIL] Unsafe ports exposed: $unsafe_ports echo Detail: $(ss -tln4 | grep -E :($unsafe_ports)$) exit 1 else echo [PASS] No unsafe ports exposed fi逻辑说明ss -tln4列出所有监听IPv4的TCP端口awk提取端口号comm -23取差集排除白名单端口最终输出暴露的危险端口及详细监听进程。该脚本比nmap localhost更轻量且不依赖外部工具。5. 进阶技巧把加固变成可审计、可回滚、可继承的工程资产加固不能停留在“这次我改好了”而要沉淀为组织级能力。我在某跨平台系统项目中推行的三项实践让安全加固从救火行为变成了基础设施的一部分。5.1 用Git管理配置变更每个/etc/文件都是代码把/etc/目录纳入Git仓库不是噱头而是为了回答三个关键问题谁在什么时候改了什么这个改动影响了哪些服务如果出问题如何精确回滚我们采用etckeeperDebian系或git-etckeeperRHEL系作为基础但做了关键增强预提交钩子强制校验在.git/hooks/pre-commit中加入/usr/local/bin/sysctl-check.sh若检查失败则阻止提交分支策略隔离环境prod分支只接受CI流水线合并staging分支供测试验证dev分支供个人实验标签标记合规基线每次等保测评前打标签git tag -a cis-l3-2024q3 -m CIS Level 3 baseline for audit。这样当审计员问“请证明SSH配置符合等保要求”我们直接给出Git commit hash和git show hash:etc/ssh/sshd_config比截图更有说服力。5.2 构建加固镜像Docker与裸机统一基线容器镜像和物理机不该有两套加固标准。我们在构建基础镜像时将加固脚本作为RUN指令嵌入DockerfileFROM centos:7 COPY harden-system.sh /tmp/ RUN /tmp/harden-system.sh rm /tmp/harden-system.sh # 后续业务层指令...其中harden-system.sh内容与前述sysctl-check.sh逻辑一致但增加rpm -V校验关键包完整性如rpm -V openssh-server检查二进制文件是否被篡改。这样无论是K8s Pod还是物理服务器只要基于该镜像启动就天然具备同等安全水位。某导师曾质疑“容器里跑auditd有意义吗”我的回答是auditd在容器内监控的是容器进程行为而宿主机auditd监控的是内核事件二者互补而非重复。5.3 定义加固成熟度模型从Level 0到Level 4的演进路径我们不再用“已加固/未加固”二分法而是定义五级成熟度每级对应可测量的技术指标Level核心指标达标示例L0无主动加固sysctl -n kernel.kptr_restrict返回0L1基础配置生效SSH禁用root登录、密码策略启用、auditd运行中L2自动化验证覆盖CI中sysctl-check.sh和exposed-services.sh通过率100%L3变更受控可追溯/etc/目录Git提交率≥95%关键变更附Jira IDL4威胁驱动动态加固基于威胁情报自动更新iptables规则如封禁恶意IP段团队每季度自评目标三年内L3覆盖率从30%提升至100%。这个模型让安全投入变得可量化也避免了“加固就是改配置”的狭隘理解。最后说个私藏习惯每次完成一台服务器加固我都会在/root/hardening-log.txt里手写三行——改了哪三个最关键的点、用什么命令验证、如果回滚该执行什么。不是为了存档而是强迫自己思考“这个改动真的必要吗”。技术可以复制但这种克制的工程直觉得靠一次次亲手敲命令来长出来。希望帮到你。本文还有配套的精品资源点击获取
