开发团队重保自救

2023-06-01, 杭州

本文简要写给对网络安全没有什么概念的开发团队，在面对攻防演练/重保时，完全从实战操作出发，应当如何保护好自己的项目。

如果您的组织有完备且专业的安全团队，请求助于安全团队进行加固处置。 本文主要面向没有独立且强大的安全资源的开发者。

可以按照以下几个步骤进行：

  1. 资产收集
  2. 保护运行环境
  3. 保护应用程序
  4. 保护数据
  5. 缩窄攻击面
  6. 应战

资产收集

最经常见到的误区是，开发把一个资源访到了互联网上，然后想着“这是测试环境，我不告诉别人，别人就不知道有这个东西，怎么会来打我”。然而在网络空间，黑客有强大的测绘能力（IP扫描、天眼查企查查的企业信息、拆包你的app、在你的门户网站上对着字典遍历爬取……），就好比哪怕你在沙漠中间建了个房，天上的卫星也能看到，也能对你发射轨道炮。甚至有更可怕的情况，黑客比你还清楚你的资产，比如项目的禅道、GitLab，丢到角落一两年换了一批人，现在大家都不知道这个东西还在，但是黑客通过网络空间测绘测出来了，他们就会对这些资产进行攻击。

概括起来，凡是项目组扔到网上的（比如网站、数据库、云中间件、代码、项管、网盘），不管是用于测试还是其他什么用途，都需要进行资产的收集和梳理。

保护运行环境

不管是开发环境还是生产环境，凡是跑着的环境都要上保护措施。很多时候并不能怪病毒有多么凶猛，反而往往是自己把管理口开放出去了又放了弱口令之类的情况。可以按照下面的走查单进行走查：

  • 服务器是否安装了主机防护软件。
  • 防火墙入端是否已阻断外网访问22、3306、3389、5432、6179等高危端口（如果开了白名单，请检查白名单策略）。一个好方法是自己手机开热点，用流量网络试一下。
  • 防火墙是否对出端进行限制。一般来说服务器需要出端的场景不多，主要是调第三方API，而第三方API一般地址都是固定的。这方面更加推荐，如果有服务器集群互调场景，尽量做到能入的机器不准出，能出的机器不准入。
  • 排查机器的SSH、RDP、FTP和MySQL等服务的登录账号的弱口令/匿名任意登录账号情况。SSH一般建议使用公私钥登录，修改/etc/ssh/sshd_config禁止密码登录。
  • 排查机器是否将容器管理端口暴露到互联网。
  • 如果你比较有钱的话，可以部署工作在TCP/IP层的防火墙和IPS。
  • 如果你更有钱的话，可以部署实时流量审计。

保护应用程序

主要针对的是开放出来的各类Web程序和相关中间件的安全防护。可以按照下面的走查单进行走查：

  • 是否启用并配好了Web应用防火墙（WAF）。需要注意两点，一是WAF必须有效保护到了你的入口，二是HTTPS的TLS卸载必须在WAF上或WAF之前做，否则WAF起不到作用。
  • 不要忘记，如果域名配了AAAA解析，IPv6层也要防护。
  • 如果是新上的基于域名解析的云WAF，建议在上线停业窗口将被保护的IP开启对WAF地址的白名单。因为之前对应的IP可能已经被黑客提前网络测绘记录，黑客可以绕开WAF直接攻击IP。
  • 网站的管理页面（/admin之类）建议开启Nginx的HTTP Basic Auth，最好避免暴露在外网。
  • 开发项目组全局走查看是否存在未授权访问的查询接口，如路人或A用户改个参数就可以查到B用户所属的私人敏感信息/文件/……。
  • 排查是否可以通过猜解的情况猜出别的用户的文件和信息接口。
  • 排查SQL注入情况，避免一切先拼接SQL语句再prepare，甚至直接拼接查询的情况。
  • 排查Mongodb、ElasticSearch和OSS等组件是否存在未授权访问的情况。
  • 排查MQ、Mongodb、ElasticSearch、nacos、zabbix、greylog、prometheus、loki和OSS等周围中间件是否存在管理端和接口不慎开放到互联网的情况，这些不应该开到互联网。
  • 排查涉及文件系统读写（文件上传、根据文件名进行读取、删除）的情况，尤其文件上传点需要强制鉴权，并检查文件头。
  • 排查应用使用的开源组件是否存在漏洞，重点关注Apache Commons、fastjson、jackson和log4j2等组件。
  • 项目组使用的GitLab、Jira、禅道、Jenkins等系统应当针对开发IP强制开启白名单，如果实在开不了白名单，要将应用升到最新版本。一个推荐实践是使用强口令的Nginx HTTP Basic Auth进行保护，git的推拉都走SSH。
  • 排查应用的源代码和AK/AS是否被泄露。
  • 排查Swagger等接口文档是否暴露在互联网上。好些Java应用会生成swagger-ui页面，黑客简单一扫就能看到你的接口文档。
  • 排查是否不慎将网站备份文件放在了静态资源目录，可能导致黑客直接下载到你的源代码。
  • 在WAF或Nginx上设置server_name，避免被人直接扫IP扫到。server_name会校验和匹配HTTP请求头中的Host字段，如果不匹配，Nginx会帮你拦一道。
  • 业务应用不要使用root运行。你应该新建个普通权限用户，用这个用户跑应用。也不要贪图方便让这个用户直接免密sudo。
  • 门户页建议开启防篡改功能，避免发生不好的政治影响。

保护数据

主要针对的是数据库、文件系统和队列等存储数据的地方。

一个简单粗暴的判断方法是：{姓名, 手机号, 身份证, 订单/地址/健康情况}，里面任意出现两项的组合，就叫敏感信息。 可以按照下面的走查单进行走查：

  • 数据是否及时备份。这里不仅包括业务数据，也包括应用程序配置，定时的机器快照、数据库备份，都可以规划起来。
  • 数据是否加密。
  • 存储的密码是否经过SHA1及以上级别的加盐哈希。
  • 数据是否有权限控制。
  • 敏感数据打印到日志时是否脱敏。
  • 敏感数据是否按照相关行业法律法规（比如银行业的JR/T 0068-2020）放在符合网络隔离的安全区域。

缩窄攻击面

主要针对实际上我们可能暴露给黑客的内容进行判断。可以按照下面的走查单进行走查：

  • 不需要的服务直接关机！
  • 一些外包性质的网站上和数据库中适当抹去自己的logo、字样等，以显得这不是我们自己的资产。
  • 如果你相对有钱，请购买云厂商的云安全中心、态势感知等服务。态势感知服务的基线检查和漏洞扫描服务务必开启，他们能提示许多底线程度的安全问题。
  • 如果你相对有钱，可以请人来做渗透测试。
  • 如果你相当有钱，可以在服务器网段部署蜜罐。

应战

主要考虑真要打起来了的一个动态流程，可以按照下面的走查单进行走查：

  • 对接到WAF、主机安全和态势感知的监控告警是否已配置。实战中人不可能7*24小时盯着屏幕，但这些组件可以主动把异常情况推送到你手机短信甚至电话上。
  • 日常攻击态势巡检。可以每天定期登录，根据WAF看看有哪些IP一天按固定时段密集打你几百次，然后直接上手封掉。有些全球的肉鸡可能零零星星扫一下你，是正常现象，可以不理（也可以顺手封一下）。
  • 应急响应方案。需要明确写好，被打穿了第一时间谁处理，联系谁（建议联系安全专家），怎么处置。需要注意两点，一是业务连续性保障，如果服务器直接宕机了怎么起，被灌了垃圾数据怎么清理；二是由于黑客可能采用你没见过的持久化技术，一般的开发根本看不出已经中了病毒。沦陷主机最好直接全部格盘并重装系统。
  • 攻击溯源方案。一般来说还是建议临时找个安全专家来帮忙，在被打完的第一时间立刻到场取证溯源。蜜罐很多时候也有助于溯源，安全专家还有些别的社会手段去溯源。
  • 公共关系方案。考虑到读这篇文章的人大概是在中国大陆的，你应该提前考虑好可以使用什么社会关系去将现实中的影响（比如背锅）降到最低。

以上就是一些重保小知识，如果你有更好的建议和反馈，欢迎给我发邮件（左边最下方的“关于”）或是去我的GitHub个人首页仓库开issue或discussion。