ALB与NAT协同:后端服务的“隐身术”

一、背景

目前对于很多企业很多项目,云原生开发是趋势,但是很多团队开发得项目都是“裸装”,也即是服务器、数据库等资源直接开放公网直连,那么这种情况下抛开服务层面的漏洞攻击不说,每天都会收到大面积的ssh暴力破解、数据库的root账户的暴力破解,虽然说可能设置了比较复杂的密码策略,但是想到万一被破解了,也会是不是得虎躯一震。

简单来说这些暴力攻击都是网络攻击,那么对于网络攻击无非是出栈和入栈,有没有什么方式可以做到出栈和入栈受限？

• 出栈: 服务器可以出栈,但是在互联网世界里,无法通过服务器的出栈身份反向追踪和入栈。
• 入栈: 只能受限的通过应用服务正常合法请求入栈,服务器的入栈需要通过云平台。

做到这两点,对于服务资源的防护就算是相对比较安全了。本篇文章我们将介绍一下在云平台上,基于NAT网关和ALB负载均衡把我们的服务资源从互联网世界里隐藏起来,从而提供更高级的防护。

二、什么是NAT网关？

1.概念和功能

NAT(Network Address Translation)网关是一种在网络中执行网络地址转换（NAT）功能的网络设备或服务，它能将私有IP地址转换为公共IP地址（SNAT），使内部网络设备能够安全地访问互联网，并隐藏内部网络的真实结构。同时，它也能将公共IP地址转换回私有IP地址，允许外部用户访问内部资源（DNAT）。主要作用包括实现内网安全访问互联网、提供公网服务、隐藏内网信息以及提升网络安全。简单来说,NAT 网关是一种网络地址转换 (NATI) 服务。您可以使用 NAT 网关，以便私有子网中的实例可以连接到 VPC 外部的服务，但外部服务无法启动与这些实例的连接,也就是说服务器可以通过NAT访问外部资源,但是外部资源不能反向访问服务器资源,只能出栈不能入栈。

2.工作原理

默认情况下,我们购买的服务器使用公有子网进行网络资源管理,公有子网与路由表协作将出栈流量路由到互联网网关,反过来路由表将互联网网关的入栈流量路由到公有子网,当然这中间也少不了网络接口(虚拟网卡)的作用。

协作关系如下:

IGW是VPC内必不可少的,任何需要与互联网通信的VPC都必须附加一个IGW。它是VPC通往互联网世界的总出口。而NAT网关并不是必须的,只有在提高VPC内资源的安全性或者隐藏服务器ip时才需要。当然NAT工作也离不开IGW,以共有NAT网关为例,它的出栈还是需要IGW配合。

协作关系如下:

以一栋写字楼来形象的比如NAT与IGW之间的关系来帮助更好的理解:

三、基于NAT隐藏服务器

1.创建NAT网关

创建NAT网关时,如果需要公网访问能力,一定要选择公有类型,另外子网一定选择公有子网(私有子网不会连接IGW),否则没有出网能力,另外也需要为NAT分配一个公网ip,特别是对接支付的场景需要对方加白,那么就可以把这个ip给到对方加白。

2.配置路由表

路由表需要添加一条规则,将公网流量路由到NAT网关,这样私有子网的出网流量都统一由NAT网关转发。

3.创建服务器绑定私有子网

创建服务器的时候选择私有子网,禁用分配公网ip:

需要注意的是,选择私有子网的时候要确保私有子网绑定的路由表是有公网流量转发到NAT网关规则的。

4.创建终端节点

创建没有公网ip的服务器,默认控制台是无法连接的,那就需要创建中断节点来连接登录服务器。

创建终端节点,选择ec2服务,选择子网以及选择合适的安全组(实例ssh端口需要对终端节点开放)。

然后控制台连接服务器的时候选择私有ip连接并选择前边创建的终端节点,就可以连接登录服务器了。

四、使用ALB透出API

ALB全称为应用型负载均衡器 (Application Load Balancer)，是一种在应用层（第七层）对网络流量进行分配的云服务。它通过检查请求内容，如 HTTP 报头或 URL，将流量智能地分发到后端服务器，以提高应用程序的可用性、弹性和性能。ALB 支持复杂的路由规则，能够根据不同的业务需求将流量精确导向相应的后端服务，是云原生应用和服务的重要组件。

之所以使用ALB,是因为使用ALB的公网能力以及与服务器在同一VPC下可以内网交互,也就是说通过ALB的公网能力对外暴露API,同时又通过ALB与后端服务通过内网交互从而隐藏后端服务器的真实ip。换个角度来说,从接口公网域名跟踪调用链路,通过traceroute等ip路径追踪探测工具追踪到alb这一层就会终止,后续都是内网交互无法嗅探,从而更好的防护了内网资源。

相比于直接用服务器的公网ip提供服务,ALB能够更好的阻断一些低端的网络攻击,比如如果通过接口域名追踪ip、分析公网暴露的端口,然后通过Kali里边的ssh、mysql等暴力破解工具暴力攻击服务器,但是如果用了ALB反向代理服务后,后端服务器ip是隐藏的,这些简单的攻击问题也就不存在了,就算攻击也是攻击云平台的ALB服务集群,跟我们基本没什么关系。

当然不止ALB可以实现隐藏和防护后端服务的能力,各大云平台的API gateway也能更好的提供类似或者更像大的能力,此处不做赘述,感兴趣可自行研究。

另外ALB能够更好的与云平台的防护能力做集成,比如WAF、shield等,可以提供应用层面的的防护,比如XSS、XFF、CORS以及DOS攻击。

所以,通过ALB等类似云平台能力能够从入栈维度提高服务器和应用服务的安全性,让服务器不必拥有公网ip就能提供公网服务能力,从而杜绝或者规避一些比较低级的网络攻击。

五、总结

通过NAT和ALB对VPC内服务器资源进行安全改造后,能够规避和防护绝大多数的网络攻击和暴力破解等问题,改造后VPC内的资源大致理想状态如下:

虽然上述的改造确实从入栈和出站角度防护了服务器和应用服务,但是上述的网络和资源状态就无懈可击了吗？答案肯定是否。

对于专业的黑客和专业的黑灰产团队,暴力破解已经是小儿科了,或者是小朋友玩的技术了,现在流行的是“内存马”和“shell反弹”,这两个东西不在本篇文章的介绍范围,换个角度来说,现在的后端服务会使用各种各样的框架和脚手架,各种各样的开源工具,不要站在上帝视角或者圣人的角度问我为什么会用这些东西,对于中小型公司,框架和开源工具能极大的提高生产力,就这么简单。

那么问题就来了,生产力是提高了,但是开源框架会出现层出不穷的漏洞,比较致命的就是RCE类型的漏洞。

以Nacos、xxl-job、Rocketmq为例看一下漏洞报告:

Nacos

xxl-job

Rocketmq

借用我之前一篇分析xxl-job漏洞的图:

你的服务使用ALB,我无法嗅探你的服务ip进行攻击,但是你的框架存在漏洞,我把攻击代码伪装成撑场的请求,你的服务器做了NAT网关防护,我无法反向追踪你的服务器ip,无法连接你的服务或者服务器,但是我的攻击代码通过请求运行于你的内存,让你通过shell反弹的方式主动连接我的服务器,这样完全绕开了你的ALB和NAT等防护能力。

最后寄语:“道高一尺,魔高一丈”。没有极致的安全,只有极致的追求安全,多关注行业动态,多关注开源框架的漏洞公开披露。否则说不定哪天自己就中招了。