首页 / 资讯动态 / centos系统服务器漏洞修复安全方案

centos系统服务器漏洞修复安全方案

CentOS系统进入停止维护阶段后,安全风险呈指数级上升。内核漏洞、软件包陈旧、配置缺陷成为攻击者最常利用的突破口。修复方案的核心思路必须从被动打补丁转向主动加固与持续监控,重点解决源失效、内核未更新、服务暴露面过大、访问控制薄弱以及日志审计缺失这五大类问题。

彻底解决YUM源失效与软件包依赖

CentOS官方源已归档,直接执行yum update会报错。第一步必须切换到可靠的社区维护源,Vault源是官方归档,适合历史版本锁定;而AlmaLinux或Rocky Linux的源则能提供持续更新的软件包,适合需要跟进修复的场景。执行前先完整备份/etc/yum.repos.d/目录。以CentOS 7为例,更换为Vault源的操作如下:

mkdir /etc/yum.repos.d/backup
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/
cat > /etc/yum.repos.d/CentOS-Base.repo << 'EOF'
[base]
name=CentOS-$releasever - Base
baseurl=http://vault.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1
[updates]
name=CentOS-$releasever - Updates
baseurl=http://vault.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1
EOF
yum clean all && yum makecache

如果服务器需要长期运行且无法重装,建议原地迁移至AlmaLinux。迁移脚本由AlmaLinux官方提供,执行前务必对重要数据做全量快照。迁移命令是curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh && bash almalinux-deploy.sh。迁移完成后立即执行yum update -y,将内核及所有系统组件升级到最新版本。这步能解决大部分已知高危漏洞,比如脏管道、SACK Panic等内核级缺陷。

内核参数加固与网络层防护

内核参数直接决定了系统对网络攻击的抵抗能力。编辑/etc/sysctl.conf文件,加入以下参数并执行sysctl -p使其生效。这些配置能有效防御SYN Flood、IP欺骗和ICMP重定向攻击。

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 3

其中tcp_syncookies开启SYN Cookie防护,防止半连接队列耗尽;rp_filter开启反向路径过滤,阻止IP地址欺骗;randomize_va_space设置为2启用完整的地址空间布局随机化,大幅增加缓冲区溢出漏洞利用难度。kptr_restrict和dmesg_restrict限制普通用户查看内核指针和日志,防止信息泄露辅助提权。对于Web服务器或数据库服务器,还需要调整net.core.somaxconn和net.ipv4.tcp_max_syn_backlog,根据业务并发量适度增大,避免正常流量被误伤。

防火墙策略精细化与最小权限原则

CentOS默认使用firewalld或iptables,但策略往往过于宽松。安全修复方案中必须包含端口白名单机制。首先清空现有规则,只放行必要服务端口。以firewalld为例,移除所有不必要的服务,仅开放SSH、HTTP、HTTPS以及特定监控端口,并将SSH默认端口修改为高位端口以减少暴力破解噪音。

systemctl start firewalld
systemctl enable firewalld
firewall-cmd --permanent --remove-service=dhcpv6-client
firewall-cmd --permanent --remove-service=cockpit
firewall-cmd --permanent --add-port=22222/tcp  # 假设SSH改为22222
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="22222" protocol="tcp" accept'
firewall-cmd --reload

上述规则不仅限制了开放端口,还通过rich-rule将SSH访问限制在特定的内网管理网段。如果管理IP不固定,必须结合fail2ban等工具动态封禁。对于公网暴露的服务器,务必关闭ICMP Timestamp请求响应,防止时间戳信息泄露用于时间同步攻击。在firewalld中可通过添加direct规则实现:firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p icmp --icmp-type timestamp-request -j DROP。

SSH服务深度加固与认证安全

SSH是服务器管理的命脉,也是暴力破解的首选目标。编辑/etc/ssh/sshd_config文件,禁止root直接登录,禁用密码认证,强制使用密钥对,并限制可登录用户。

Protocol 2
Port 22222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers devopsuser
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

修改后执行systemctl restart sshd。密钥对生成推荐使用ed25519算法,安全性高于RSA且性能更好:ssh-keygen -t ed25519 -C "server-hardening"。将公钥部署到服务器后,私钥文件必须离线备份并设置强密码保护。对于必须保留密码登录的遗留系统,务必安装fail2ban,在/etc/fail2ban/jail.local中配置SSH监狱,设置bantime为3600秒,maxretry为3次。同时启用SELinux,将其设置为enforcing模式,不要因为部署麻烦而关闭。如果应用兼容性确实存在问题,至少使用audit2allow生成定制化策略模块,而不是直接setenforce 0。

关键服务漏洞修补与权限隔离

Web中间件、数据库和缓存服务是漏洞重灾区。Apache或Nginx必须隐藏版本号。Nginx在http块中添加server_tokens off;,Apache在httpd.conf中设置ServerTokens Prod和ServerSignature Off。PHP务必禁用高危函数,在php.ini中设置disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source。对于MySQL或MariaDB,执行mysql_secure_installation脚本设置root密码、删除匿名用户和测试数据库。数据库账户遵循最小权限原则,应用连接账户只授予特定库的SELECT、INSERT、UPDATE、DELETE权限,严禁授予FILE、SUPER、PROCESS权限。

服务运行账户隔离同样关键。每个服务必须使用独立的非特权用户运行,禁止使用root。以Nginx为例,检查nginx.conf中user指令是否为nginx或www-data。所有Web目录权限设置为755,文件为644,上传目录禁止执行脚本。在Nginx配置中针对上传目录单独设置location,添加location ~* /uploads/.*\.(php|pl|py|jsp|sh|cgi)$ { deny all; }。Redis务必设置requirepass强密码,并重命名危险命令:rename-command FLUSHALL ""、rename-command CONFIG ""、rename-command EVAL ""。如果Redis仅本地调用,绑定127.0.0.1并设置protected-mode yes。

文件完整性监控与入侵检测

漏洞修复后需要持续验证系统完整性。安装AIDE(Advanced Intrusion Detection Environment)建立文件指纹库。初始化数据库:aide --init && mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz。配置/etc/aide.conf监控关键目录,包括/bin、/sbin、/usr/bin、/usr/sbin、/etc、/var/spool/cron等。设置crontab每天凌晨执行aide --check,并将报告发送到集中日志服务器。对于内核模块变更监控,使用auditd审计系统调用。添加规则监控关键文件:auditctl -w /etc/passwd -p wa -k passwd_changes、auditctl -w /etc/shadow -p wa -k shadow_changes。

Rootkit检测方面,定期使用chkrootkit和rkhunter扫描。虽然这两个工具不能防御新型rootkit,但对常见LKM和用户态rootkit仍有效。扫描脚本可写入crontab:0 3 * * * /usr/sbin/chkrootkit -q | mail -s "Rootkit Scan Report" admin@example.com。更深入的做法是部署osquery进行系统状态查询,将结果接入SIEM平台做异常行为关联分析。osquery可实时监控监听端口变化、进程创建、用户登录等事件,一旦发现非预期的端口开放或进程启动立即告警。

日志审计与集中化管理

单机日志极易被攻击者清除,必须实现远程转发。配置rsyslog将所有authpriv、kern、cron日志发送到日志服务器。在/etc/rsyslog.conf中添加*.* @logserver.example.com:514,并使用TCP协议配合TLS加密传输。同时配置logrotate防止日志撑满磁盘,设置compress、dateext、rotate 30等参数。对于systemd-journald,设置Storage=persistent和ForwardToSyslog=yes,确保所有日志持久化并转发。

审计系统调用层面,配置auditd规则记录所有用户执行的命令。在/etc/audit/rules.d/audit.rules中添加:-a always,exit -F arch=b64 -S execve -k command_exec、-a always,exit -F arch=b32 -S execve -k command_exec。这样任何命令执行都会被记录,包括攻击者通过漏洞注入的恶意命令。使用ausearch -k command_exec --start today可查询当日所有命令历史。这些审计日志同样需要远程备份,防止本地被篡改。

自动化漏洞扫描与持续修复流程

建立周期性的漏洞扫描机制,推荐使用OpenSCAP结合SCAP Security Guide进行合规扫描。安装openscap-scanner和scap-security-guide包,执行oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_pci-dss --report report.html /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml。该命令会基于PCI-DSS标准生成详细评估报告,列出所有未修复漏洞和配置缺陷。将扫描任务加入Jenkins或GitLab CI流水线,实现每次代码发布前自动验证服务器安全基线。

对于内核漏洞,除了常规yum update外,还需要关注ELRepo等第三方内核仓库提供的长期支持内核。安装kernel-lt或kernel-ml版本,配合kexec快速重启减少业务中断。使用uname -r检查当前内核版本,对照CVE数据库确认是否存在已知提权漏洞。如果业务无法重启,采用Ksplice或KernelCare等热补丁方案,在不重启的情况下修复内核漏洞。这些商业方案对CentOS 7仍提供支持,是生产环境的关键保障。

容器化环境下的特殊加固措施

如果CentOS上运行Docker,宿主机加固不能替代容器内部安全。Docker daemon配置中启用userland-proxy=false减少攻击面,设置icc=false禁止容器间通信,配置live-restore=true保证daemon重启时容器不中断。所有镜像必须从私有仓库拉取并经过漏洞扫描,Dockerfile中使用非root用户运行应用。启动容器时添加--read-only --tmpfs /tmp --cap-drop=ALL --cap-add=NET_BIND_SERVICE参数,移除所有不必要的内核能力。定期执行docker scan或trivy扫描镜像漏洞,将扫描结果阻断CI/CD流水线。

对于Kubernetes节点,还需配置PodSecurityPolicy或Pod Security Admission,禁止特权容器和hostPath挂载。kubelet配置中启用protectKernelDefaults=true,防止容器修改内核参数。etcd数据库使用TLS证书认证,API Server关闭匿名访问并启用NodeRestriction准入控制器。这些措施与宿主机加固形成纵深防御,即使容器被突破也无法轻易逃逸到宿主机。

备份与灾难恢复的最后防线

所有安全措施都可能被绕过,可验证的备份是最终保障。使用rsync或borgbackup对/etc、/var/log、/home、数据库文件以及应用代码进行每日增量备份。备份数据必须异地存储并加密,borgbackup自带压缩和加密功能:borg init --encryption=repokey-blake2 /backup/repo。备份脚本执行后通过healthchecks.io等工具监控执行状态,失败立即告警。定期进行恢复演练,从备份中完整重建服务,验证备份有效性和恢复流程文档的准确性。

针对勒索软件场景,确保备份存储系统与生产网络隔离,使用不同认证凭据,并启用对象锁定或WORM特性防止备份数据被删除。快照功能虽然便捷但不能替代备份,快照与生产数据在同一存储系统,存在被同时加密的风险。3-2-1备份法则必须严格遵守:3份副本、2种不同介质、1份异地存放。