APAC 系统的 Linux 基础设施加固
目录
大多数生产 Linux 系统与其默认配置的接近程度，超出了任何人愿意承认的范围。加固文档是存在的，往往还是多年前为某次审计而写的，但服务器与文档并不一致。“文档化的基线"与"实际配置"之间的差距，正是攻击者稳定栖身的地方。
Linux 加固就是弥合这一差距的学科，而且要以能挺过下一次部署的方式来完成。
默认配置是起点，不是安全姿态 #
默认安装的 Linux 优先考虑兼容性而非安全性。它自带你用不到的服务、你不需要的内核特性，以及只够桌面使用、远不足以应对被攻陷的生产主机的日志配置。加固就是把这台通用机器改造成专用机器的过程。
主要工作分几类：
- 内核与 sysctl 调优：网络防护（如忽略 ICMP 重定向、启用源路由过滤）、文件系统限制，以及地址空间布局随机化等内存保护。
- 服务最小化：禁用并移除主机上不运行的东西，让不存在被利用价值的闲置组件留在系统里。
- 强制访问控制：SELinux 或 AppArmor，约束进程可以做什么，即使它已被攻陷。
- Systemd 与容器加固：丢弃 capabilities、封禁原始套接字访问，并用 seccomp 配置文件限制系统调用。
- 审计与日志：捕获真正重要的事件，并传输出主机之外，让攻击者无法抹掉自己的痕迹。
CIS Benchmarks 仍然是这些控制措施最实用、认可度最高的成文标准， OpenSCAP 则将应用与审计自动化。
配置即代码，否则等于不存在 #
躺在 wiki 里的加固指南只是一份愿望清单。活在代码里的加固（一个 Ansible role、一个 Packer 镜像、一条 Kubernetes 准入策略）才是事实。当基线成为代码，三件事随之改变：
- **它是可复现的。**每一台新主机都继承基线，而不只是那些恰好有人记得配置的主机。
- **它是可测试的。**CI 中的合规扫描会在配置漂移时让构建失败。
- **它是可评审的。**基线的变更就是一次 pull request，遵循与应用代码相同的评审纪律。
这就是"一年一次的加固活动"与"平台固有属性"之间的区别。
不可变基础设施是终点 #
合乎逻辑的终局是不可变基础设施：主机和容器从不原地打补丁，只会被替换。新镜像被构建、扫描、部署；旧镜像被销毁。配置漂移成为不可能，因为没有可以漂移的东西：运行中的系统就是一个构建产物。
不可变基础设施与代码化加固天然搭配。你维护的不再是基线，而是在把安全性编译进镜像。当漏洞出现时，修复方式是一次重建，而不是深夜的一场 SSH 会话。
主机之外 #
加固不会止步于操作系统。同样的纪律会向多个方向延伸，每个方向都有自己的失效模式。
容器继承一切，还会叠加自己的风险。 从未加固的基础镜像层构建出来的容器镜像，会把主机层面的所有弱点带进运行它的每一个 Pod。解决方案在上游：最小化基础镜像、在 CI 中扫描、以非 root 身份运行并挂载只读文件系统、裁剪 capabilities，以及用 seccomp 配置文件把 syscall 限制在工作负载真正需要的范围内。默认 seccomp 配置已经拦截了不少；再根据实际观察到的 syscall 行为定制一份配置，就能覆盖剩余部分。Kubernetes 准入策略在整个集群层面强制执行这一切，让不符合标准的部署根本无法被调度。
OT 环境的赌注更高。 在工业和运营技术场景中，加固与可用性的冲突是办公 IT 从未见过的。一条错误套用的 CIS 控制项落在楼宇管理系统、产线 PLC 网络或医院设备分区上，产生的不是一条 finding，而是停机：有时还牵涉人身安全。因此 OT 加固的顺序正好相反：先做被动监测和资产盘点，变更安排在维护窗口内并附带回滚方案，控制措施先在与生产一致的镜像环境中试点。IT 问的是"这个系统安全吗？"，OT 必须问的是"我们能不能在不让它停下来的前提下保护它？”
漂移检测闭环。 基线会在日常变更中退化：工程师为了调试打开一个端口，某个安装程序重新启用了一项服务，一个热修复没有回写进代码。没有检测机制，今天加固到位的主机就是明年的软肋。有效的模式是：每日定时扫描，将在线主机和镜像与代码化基线比对，发现的结果作为告警直接路由给责任人，而不是归档进没人读的季度报告。一天内发现的漂移是一张工单；一年后才发现的漂移是一场事件调查。
加固到位的主机，如果背后挂着一个过度宽松的云 IAM 角色，或者身处未经扫描的容器流水线，依然处于暴露之中。最持久的姿态是把主机基线、容器构建链、云配置和身份边界当作同一个连续的表面来对待，并以这种方式监控它。
我们的 Linux 与基础设施加固以代码形式交付基线和自动化的漂移检测； 配置与架构评估则审查主机周边的云与身份层。想要全貌， 请预约一次工程与范围界定会谈。