Linux安全环境搭建：从零到生产就绪

　　我越来越觉得“Linux安全环境搭建：从零到生产就绪”是错的。

　　去年国庆前五天，我在测试环境给一台新装的CentOS 7.9加SELinux策略——不是用semanage port -a，是手改/usr/share/selinux/targeted/nginx.if里第47行的type nginx_port_t；改完没重启restorecon，也没验证context是否继承到了/var/log/nginx/下。结果上线那天凌晨三点，运维老张电话打进来：“日志目录进不去，但curl -I能通”，我一边套着拖鞋连跳板机一边说“应该只是logrotate没跑”，他顿了两秒：“logrotate进程自己被kill了，信号是-9，进程树上找不到父进程”。

　　我原以为只要配齐SSH密钥、关掉root登录、禁用密码认证、开fail2ban、打全补丁，就能撑过灰度发布——结果第三台机器刚挂上负载均衡，kubeflow那边就弹出“Permission denied (publickey)”告警，而我们的authorized_keys文件明明是600权限，且owner是deploy用户。后来查出来是/usr/bin/ssh-keygen在生成ed25519密钥时，如果/home/deploy/.ssh目录属组是wheel（而非deploy），它会悄悄把authorized_keys的group写成wheel，而sshd_config里StrictModes on就卡死在这里。这事我查了三天，最后靠strace -f sshd -t -D 2>&1 | grep -A3 "stat.authorized"才捞出那个被忽略的gid检查。

　　“从零到生产就绪”这套话术，本质是把安全当安装包——解压、./configure、make install、systemctl start，仿佛启动成功=生效成功。可你见过谁用systemctl start firewalld以后真去抓包验证22端口是不是只允10.128.0.0/16段连进来？没有。我上周还看见同行在微信群里晒“加固完成截图”，八张图，全是rpm -qa | grep kernel和ss -tlnp输出，第七张里netstat -tuln居然还显示:22监听0.0.0.0，但他配了iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT——后面三条规则全是DROP，可规则链顺序是反的。没人测。

文章配图，仅供参考

　　真正要命的从来不是漏掉某个模块，而是“就绪”这个状态根本无法定义。比如你设了ulimit -n 65535，但PHP-FPM子进程启动时读的是/etc/security/limits.d/20-nproc.conf里的nproc限制，而那个文件是两年前老王写的，内容是“ soft nproc 2048”，硬编码，没变量没注释没版本号。又比如你用auditctl -w /etc/shadow -p wa，可auditd服务本身没开systemd启动依赖，机器重启后auditctl规则全丢——但你永远看不到日志，因为audit.log的轮转脚本里grep “audispd is not running”那一行，被前任删掉了注释符号#，变成了有效代码，反而把警告屏蔽了。

　　再说个闲事：前天帮测试同事看docker容器启动慢，他贴出docker info输出里Storage Driver: overlay2，Root Dir: /var/lib/docker，我顺手df -h /var/lib/docker，发现只剩3%空间。他说“这不归我管”，我说“那你的image pull失败是因为磁盘满”，他回：“我pull成功了啊”，我让他docker images | wc -l，返回17；我再ls -l /var/lib/docker/image/overlay2/repositories.json，size是0字节；他盯着终端三秒，敲了rm -f /var/lib/docker/image/overlay2/repositories.json，回车，然后docker images立刻变空。他抬头问：“这文件不是该由docker自己管理吗？”我没说话，因为去年十一我在另一台机器上干过一模一样的事——把repositorie.json手动touch出来，假装它存在，骗过dockerd的启动校验。当时觉得省事，后来发现所有image history都断了，docker build --cache-from全失效，而我连为什么失效都说不清，只知道它就是不认了。

　　优胜劣汰这点我倒认——去年十一那批机器，活下来的七个站全靠每次发版前手工执行一遍./check-hardening.sh，里面第十二条是curl -s http://127.0.0.1:6379/info | grep -q “redis_version”，不是检测redis-server进程是否存在，是真发HTTP请求过去；第十一条是ls -l /proc/$(cat /var/run/nginx.pid)/exe | grep -q “nginx: master process /usr/sbin/nginx”，必须看到master进程的exe链接路径，不是ps aux里有没有nginx字样。这些步骤没文档，没commit，是我边试边记在个人笔记本上的。其他人照着跑，跑通了就算“就绪”，跑不通就换方案。没人问原理，反正上线前没崩就行。

　　这事我也可能就运气好。毕竟我们还没遇到过攻击者专门针对/etc/cron.d/下某个空格结尾的job文件做解析绕过——虽然我知道这种事肯定存在，只是现在没撞上。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!