2020 网络安全重保日记

2020 年双节前夕，国内疫情稳定，长假将启，各项安保措施比以往有所升级，而此时更是网络安全重点保障时期，信息安全工作尤其不能懈怠。各用户单位也陆续启动响应，对网络安全负责人、联络人通知到位，深度排查网络安全风险，及时调整网络安全策略，部署实施态势感知、应急响应、持续安全评估、安全监测巡检等安全措施，并确保安全人员现场保障。安保工作如火如荼，天存信息的技术工程人员也相继奔赴各个信息重保工作现场。

一、安全措施与前期建设

1.1 个人心理建设

在三个重点客户的工作现场轮流值守期间，我需要时刻紧盯日志审计平台，跟踪满屏的访问日志，捕捉攻击行为的蛛丝马迹，深感责任重大。相信技术工程人员都会有类似感受：每每遇到这种境况，或多或少会事先祈祷一切顺利，平安渡劫。

1.2 安全措施建设

重保安全的准备工作一点也含糊不得。“工欲善其事，必先利其器”，一个典型的机房安全建设设计是这个样子的——

▲看到密密麻麻的安全设备有没有乱了心境？

有这张严防死守的安全图纸在手，再加上各安全厂商的 IT 精英们悉数到场镇守，安全感油然而生。设想，在我方强大布防下，任他什么扫描、洪水攻击、DDoS 攻击、注入或是跨站，应该都挤不进这密不透风的防控体系。蜗居于安全中心的 WEB 应用服务器，应该能高枕无忧了。即便攻击者挖到了应用或中间件的“0-Day”漏洞，或者事先植入了 WebShell，在主机安全加固环节，或攻击者利用 WebShell 时，我方的 WAF 和入侵行为检测也能排查出问题所在，并做出预警和拦截。

然而，最担心的事情，还是自然地发生了。

二、安全事件始末

重保期间某日，我们接到了一则上级通知，还附带有一份漏洞描述文件。

图2

附带的漏洞利用过程描述文件，如下。

图3

我们立即着手排查原因，力求快速修补这个漏洞。

NO.1 首先排查日志。基于漏洞利用过程文件的描述，我们逐一检查了 WAF 的攻击日志，显示无异常。

NO.2 查询入侵行为检测。它确实只是一条访问日志，不是攻击行为。

NO.3 登入服务器，跟踪这个文件所有的访问日志和访问IP，寥寥数条，没有所谓的上下文关联，无法还原出一个完整的攻击过程。

NO.4 最后，进入 WEB 应用的目录，找到这个文件，粗略浏览代码，发现这是一个任何人都有权限访问的文件，没有任何用户和会话的检查机制。这是一个典型的越权+任意文件上传漏洞。

用户单位要求紧急处置这一加急任务，对于 IT 安全运维部门，有以下几种解决方式：

• 设置应用的访问控制策略，只允许特定 IP 访问这个上传组件功能。而由于应用系统的业务面向 Internet 用户，每天都会有业务数据通过 HTTP 协议上传系统，限制特定 IP 并不可行。
• 临时关闭上传功能。基于上述实际情况，同样无法实现。
• 限制上传目录的执行权限，可以禁止上传文件的执行。然而这并非用户可以接受的解决方案。

其实，最根本的解决办法是协调开发部门，对这个上传功能增加用户限制和会话绑定。现实问题再一次横亘在大家面前，一个5年前开发并交付的系统，找到当初的开发参与人员进行修复，当下更不具备可操作性。而 WAF 不能配置理解业务执行过程的的访问规则，焦点便对准了我们负责 WEB 应用安全的几家厂商。客户要求第二天上午 8:00 前必须完美解决，时间紧迫。

在重保期间，红头文件和加急电话，成了压在我们几个相关人员头顶上的大山。

幸好在运维期间，我把公司的 WEB 业务补丁平台，放置在了关键业务的前端。现在，余下要做的就是整理客户需求，编写用户补丁了。

客户的 WEB 应用环境和需求如下：

1. WEB 服务器上有两个应用目录 /app_a/ 和 /app_b/，分别对外负责不同业务。
2. 其中 /app_a/ 不需要对外有上传功能，上传功能可以关闭，面向公网用户开放。
3. /app_b/ 只允许内网访问，公网用户不能访问，上传功能不可关闭，内网用户的 IP 是以 10 开头的 IP。
4. 上传功能需要验证用户和 session 绑定，登录后才能执行上传操作。

三、安全事件处置

接下来是着手编写虚拟补丁并上线补丁。虚拟补丁如下：

{
    "rules": [
        {
			"meta": {
				"phase": 1,
				"function": "如果请求文件名以/szyx开头，而且请求文件名中包含upload_json.jsp,则进行拦截，并记录日志。"
			},
			"if": [
				"begin(REQUEST_FILENAME, '/szyx')",
				"contain(REQUEST_FILENAME, 'upload_json.jsp')"
			],
			"then": {
				"action": "deny",
				"log": "不允许在访问/szyx相关应用的时候，访问upload功能模块."
			}
		},
		{
			"meta": {
				"phase": 1,
				"function": "如果客户端为公网IP(不是10.开头)，却访问非/szyx开头的页面，则进行拦截，并记录日志."
			},
			"if": [
				"!begin(REQUEST_FILENAME, '/szyx')",
				"!begin(REMOTE_ADDR, '10.')"
			],
			"then": {
				"action": "deny",
				"log": "不允许公网IP的客户端(此处为非10开头的客户端ip)访问非/szyx相关的应用."
			}
		},
		{
			"meta": {
				"phase": 4,
				"comment": "如果登录成功(登录成功的标志是Set-Cookie中有jcxx_cookie_session_xtbz和flushcookie成员存在)，则记录代表登录成功的变量到SESSION中。"
			},
            "if": [
				"REQUEST_FILENAME == '/sys/system/login/logincheck'",
				"REQUEST_METHOD == 'POST'",
				"notNull(RESPONSE_SET_COOKIES.jcxx_cookie_session_xtbz)",
				"notNull(RESPONSE_SET_COOKIES.flushcookie)"
			],
            "then": "SESSION.login_success@300 = 1"
        },
		{
			"meta": {
				"phase": 1,
				"function": "如果进来的请求URL中包含upload_json.jsp，则进行会话检查."
			},
			"if": "contain(REQUEST_FILENAME, 'upload_json.jsp')",
			"then": {
				"if": "SESSION.login_success != 1",
                "then": {
					"action": "deny",
					"log": "No Auth! You don't have access to the upload page!"
				}
			}
		}		
    ]
}

编写好虚拟补丁，意味着 80% 的工作量已完成，心情可以舒缓一些了。

下一步，要验证补丁的有效性。对此，我们分别模拟内网用户和外网用户对虚拟补丁做访问和攻击测试，日志截图如下：

内网越权访问（基于IP的访问控制策略验证）：直接访问，直接拦截。(如图)

图4

内网越权访问拦截日志：拦截日志报出，因为没有用户登录和会话的绑定，这次越权请求被拒绝。

图5

外网IP访问限制：

图6

处置结果：用户单位的安全问题“越权+任意文件文件上传漏洞”被上线的虚拟补丁完美解决，客户表达了感谢，我们也又一次通过了安全考验。（钱文芳 | 天存信息）