Linux老手也常踩的5个Unix环境搭建坑

　　去年五月帮甲方搭Unix环境，那叫一个血泪史——Linux老手都栽跟头，安全这事儿真不是靠经验堆出来的。我原以为把SELinux调成permissive就万事大吉，结果三天后审计日志里全是avc: denied，查了半天发现是某个服务硬编码了/tmp路径，SELinux默认标签根本不匹配。最离谱的是，这服务还是甲方自己写的，代码里直接写死了/tmp/xxx.sock，连环境变量都不给改的机会。

　　第一个坑是umask。我习惯性设002，结果甲方要求007——这倒不是安全问题，关键是后续权限继承全乱套。有个脚本用tar解压时没指定p参数，所有文件权限直接继承umask，导致Web服务读不到配置文件，502报错刷了一下午日志。更恶心的是，这脚本是第三方提供的，文档里压根没提权限要求，最后只能硬改umask再重启服务。群里@全员问谁改了umask，结果运维说“我以为默认就是007”，开发说“我从来不用umask”——得，全组就我一个知道这玩意儿会继承。

　　第二个坑是PATH变量。甲方要求所有服务必须用绝对路径调用命令，我嫌麻烦，在.bashrc里加了/usr/local/bin:/usr/bin:/bin，结果有个服务启动时用了相对路径的python，直接调到了用户目录下的恶意脚本——那脚本是前一天渗透测试留的马，权限还设成了777。我查日志时看到那串眼熟的IP，心想“这不就是昨天测WAF的源IP吗”，结果溯源到一半，发现脚本已经被删，只留下个空文件，时间戳还是测试当天。后来才知道，甲方为了“安全”，把用户目录的write权限全开了，说是“方便部署”——这操作我到现在都没想明白。

文章配图，仅供参考

　　第四个坑是文件描述符限制。我按惯例设了65535，结果甲方说“不够，得设成unlimited”。我查了下系统文档，发现ulimit -n unlimited在Linux下根本无效，最多只能设到4294967295——但甲方坚持要“unlimited”，最后只能写个脚本，在服务启动前动态设成最大值。结果有个服务启动时卡住了，查半天发现是文件描述符泄漏，把系统资源耗尽，连ssh都连不上。我原以为只是配置问题，结果用lsof一看，那服务开了二十万个连接，全是TIME_WAIT状态——原来是keepalive参数没调好，TCP栈直接爆了。

　　第五个坑是环境变量污染。我习惯在/etc/profile里设全局变量，结果甲方要求每个服务用自己的.env文件。我照做了，结果有个服务启动时没加载.env，直接用了系统默认变量——那变量里有个LD_PRELOAD，指向了/tmp/libxxx.so。我查了下，这so是渗透测试留的后门，会hook open()函数，把所有文件操作都记录到日志里。更离谱的是，这服务是root运行的，日志里全是明文密码——甲方看到后差点没把我开除。后来发现是服务启动脚本里漏了source .env，而运维为了“方便”，直接把脚本改成了chmod +x /path/to/service，连解释器都没指定——这操作我到现在都没敢在群里提。

　　安全这事儿，真不是靠经验堆出来的。我干了五年服务网格，自以为对Unix环境门儿清，结果去年五月这五个坑，每个都让我怀疑人生。最讽刺的是，甲方最后说“还是Windows安全，至少不用操心这些”——我差点没把键盘砸了。现在我再搭环境，第一件事就是查SELinux策略、第二件事是锁死umask、第三件事是禁用所有相对路径、第四件事是设好文件描述符限制、第五件事是隔离环境变量——安全是成本不是收入，但踩一次坑，成本比收入高多了。

　　对了，昨天群里又有人问“为什么我的服务启动不了”，我扫了眼日志，发现是PATH里多了个空格——这坑，我五年前就踩过。

（编辑：站长网）

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