攻防演练中的救命稻草（设置方法篇）
最近的攻防演练尘埃落定了。演练结果既在预料之中，也在预料之外。总的来说就是：拉胯。有时间再以科技奇趣的角度写一篇。
在上一篇：没有资源的攻防演练靠什么做救命稻草？（对抗篇），这救命稻草是限制攻击者获得操作系统管理员。
具体到信息系统上，就是绝对不能用管理员权限用户运行中间件或者WEB服务器。
笔者：国际认证信息系统审计师、软考系统分析师
那么这根稻草怎样才能种出来还种得好呢？
从安全基准的角度看，这根稻草有两个来源：1、CIS Benchmark 安全基准；2、等级保护测评的加固要求。
1、CIS Benchmark 加固基准
以面向 Apache Tomcat 的CIS基准要求文档为例，在文档中，关于 Tomcat 加固基准的整个系列，也就是从 Tomcat 7 到 Tomcat 10，这一条要求都是存在的。因为这本来就是 Tomcat 预先设计的功能，只是默认不启用。
在基准要求的原文条目是 10.18 （Tomcat 7~10的CIS基准都是一样的条目号，内容基本一样），节选并翻译如下：
10.18 设置安全生命周期监听器（计分）
安全生命周期监听器在 Tomcat 启动时实施一些安全检查，如果安全检查失败，则禁止 Tomcat 启动。
注：Listener有两种中文译法，监听器/侦听器，从效用上看，监听器的含义表达更恰当。
启用安全生命周期监听器可以：
（1）强制实施不可以用于启动 Tomcat 的操作系统用户黑名单；
（2）在 Tomcat 启动前设置最低限制的 umask。
在进行信息系统安全审计时，需要检查 server.xml 配置文件，确认安全生命周期监听器的相关定义元素取消注释，并且 checkedOsUsers，minimumUmask 属性已设置为期望的值。
文档中给出的具体措施，是需要在 $CATALINA_BASE/conf/server.xml 配置文件中取消该参数的注释而启用该项。如果操作系统支持 umask，则 $CATALINA_HOME/bin/catalina.sh 内获取 umask 的相关操作行也应该取消注释。
启用该项后，需要在添加如下两个参数：
checkeOsUsers：不可用于启动 Tomcat 的操作系统用户名（不区分大小写），如果不指定，则默认为 root。设置为空字符串时禁用该参数。
minimumUmask：在 Tomcat 启动前必须配置的最低的 umask 值。如果不指定，则默认为0007。设置为空字符串时禁用该参数。
关于 umask 这种基本功就不详细介绍了。实际如果不能禁用 root 运行 Tomcat，设置什么 umask 都意义不大。另外，Windows 平台不支持 umask，即使设置了也不会检查。
注：这只是 Tomcat 的设置，在操作系统方面还要做配套设置。
示例：
<Listener className="org.apache.catalina.security.SecurityListener"
checkedOsUsers="alex,bob" minimumUmask="0007" />
Tomcat 7 文档：
https://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#Security_Lifecycle_Listener_-_org.apache.catalina.security.SecurityListener
其它版本 Tomcat 文档地址可自行查找。
在CIS基准要求中，该项目的级别被定为Level 1，即：该配置是可实施且谨慎的；可提供清晰的安全收益；不会在超出可接受的意义下妨碍使用该项技术。
说人话就是干了没坏处，好处还很多。
2、等保测评的系统加固
等保测评的整改要求中，对中间件会有这么一项问题：
操作系统（中间件）未配置可降权启动 Tomcat 的用户。
不同的测评机构会有不同的文字表述。
问题是，在不同的时间点上，这个项目的风险等级居然在变化，而且是在降低。
在我经手的数次等保测评中，2019年的时候该项设定为高风险项，但到了2021年时，该项设定为低风险，才给0.05分，估计很多人会直接忽略。
这个变化，或许是因为定为高风险后整改不一定可行，为了减少因难以整改而长期无法通过等保测评而调整的。
因为从笔者的经验看，如果不使用 root 用户运行 Tomcat，需要信息系统在开发时良好地遵循各种安全要求，并且在部署时也要明确地符合安全部署要求。
但这对于大多数开发商来说，都是纯成本。除非甲方在签订合同时明确提出验收标准是通过等保测评且整改范围包括低风险项。但甲方很难做到这点，原因并不在甲方是否足够强势，而是甲方得有人是真懂，而不只是各种要求的复读机。
经过我这次攻防演练的过程，足以明确这就是一个高风险项。
不过，等保测评只是指出存在漏洞，并不会直接告诉你如何整改。你得自己去找资料，找文档，找别人的成功实施经验。
环境因素确实复杂。虽然操作系统基本上就是 Windows 和各种 Linux，但中间件或者WEB服务器种类繁多。中间件还涉及到用操作系统原生版本还是信息系统开发商自己选择的版本的问题。
先以 Tomcat 为例，结合操作系统的设置，看看如何做。
1、Linux环境非 root 用户启动 Tomcat
Linux 要做的设置过程大致如下。由于网上有大量详细教程，所以我这就不详细给出过程，只指出关键点：
（1）创建一个普通用户A，不允许登录，所以不需要解锁也不需要给密码。
（2）把中间件相关的文件目录的所有者改为该用户A
（3）中间件所在目录以及文件的访问属性，如果不能确认是否可以对中间件所在目录禁止写入，那么分别设置为775和664。如果可以禁止写入，那就500和400。
（4）设置和修改服务的启动方式，使用该普通用户启动服务。具体可行的设置方法包括修改 systemd 服务配置文件、修改 /etc/rc.d/rc.local、直接修改 tomcat 启动脚本等，基本上都是通过：su - 用户名A -c "服务启动命令"这样的方式实现用非特权用户启动 Tomcat。
（5）启动服务，观察启动结果和测试是否运行正常。正常后再部署信息系统和开展对信息系统的测试。
（6）如果可以100%确认信息系统在运行期间不会向中间件目录写入，那还可以进一步调整，另外创建一个普通用户B将中间件目录及文件的所有权赋予该用户B，然后设置用户A和B同组，中间件目录及文件同组可读但不可写。
如上设置，可以达到中间件运行（用户A）、中间件文件访问（用户B）、中间件部署管理（root）三种模式相互分离。
如果要再进一步，还可以通过SELinux规则，进一步限制用户A的能力。
2、Windows环境非管理员启动 Tomcat
首先要纠正一个常见误区：在桌面运行中间件服务。
我见过大量的系统部署人员直接在 Windows 的 Administrator 管理员桌面部署运行 Tomcat，每次服务器重启要么登录后手工启动，要么设置自动登录后自动启动。
这种做法直接破坏了与管理员账号管理有关的所有加固基准要求，无论是CIS基准要求或是等保测评要求，是必须否定并予以纠正的。
具体设置过程：
（1）首先创建用于运行中间件的普通用户A。同样可以参考上面Linux的做法，在确认可行时创建两个普通用户A和B分别用于运行控制和文件控制。
下图是我自己的测试环境设置，为明确区分，用户A和B分别命名为tomcat_runner和tomcat_owner。
有所区别的是，运行 Tomcat 的用户A需要设置密码，否则会和本地安全策略中的“帐户: 使用空密码的本地帐户只允许进行控制台登录”（默认启用）冲突。
（2）设置中间件所在目录和文件的属性，让用户A能读取和执行。是否允许用户A写入则依然是取决于信息系统的具体设计。在能分离时，用户B可以设置为完全控制：
（3）运行SECPOL.MSC本地安全策略，修改“本地策略”-“用户权限分配”-“作为服务登录”，添加用户A，从而允许使用用户A运行服务。
还可以在充分测试的基础上，进一步限制用户A，比如在“拒绝本地登录”、“拒绝从网络访问这台计算机”添加用户A实现限制。
（4）使用 Tomcat 安装包，安装时会自动注册到 Windows 成为服务。然后通过服务管理控制台 services.msc 修改 Tomcat 服务的启动用户为用户A，注意要设置密码。
修改后如下：
（5）启动 Tomcat 服务，全面测试中间件本身的部署是否成功，尤其是各种日志输出。期间各种500错误一般都是权限问题。
如果启动 Tomcat 出现“拒绝访问”错误（事件ID7000），那就是用于运行 Tomcat 中间件的用户未授权访问（读取和执行）Tomcat的安装目录。
只有 Tomcat 本体运行正常了，接下来才是测试信息系统的部署。
其它中间件或者 Web 服务器也是一样的。
1、Web 服务器
比如 IIS 、Apache或者 Nginx，软件包在操作系统的配合下都会默认设置不使用管理员账号启动。另外，CIS 安全基准中也都很明确地给出了指引。比如对于 Apache HTTPD 服务器，CIS有专门的基准要求文档，其中的章节举例如下：
3.2 Ensure the Apache User Account Has an Invalid Shell (Scored)
确保Apache用户账号的SHELL环境无效（计分）
3.3 Ensure the Apache User Account Is Locked (Scored)
确保Apache用户账号是锁定的（计分）
需要注意在Linux环境部署 Apache 时，如果不是操作系统原生组件包的话，在设置过程中要仔细检查配置文件中的默认设置。
其它 WEB 服务器也基本无异，网上也有相应的指引介绍文章。
2、其它中间件
WebLogic，WebSphere等等其它中间件，实际在设计时都考虑了允许使用非特权用户运行，中间件文档内都会有相应的部署指南。
关键还是在于我一开始强调的，能否实施，很大程度上取决于信息系统具体开发的结果。
比如我碰到的实例。基于某比较著名的中间件开发的某系统，用非root用户可以启动运行，但有些功能就总是不正常（简单说就是错误日志输出的内容翻倍），不得已又回退回去用root。
要做好网络安全，不出事，是很难的。
就如这篇文章讨论的内容，到最终要解决的问题，很多时候并不是安全措施如何实施，而是甲乙方（乙方指信息系统开发商）之间的博弈。
所以这是网络安全必须坚持“三同步”尤其是其中的“同步验收”的关键原因。
而网络安全这个行业本身，注定是做乙方人员比做甲方人员更舒心一些。
题图来自Pixabay公共图片库
本页网址二维码：