亚马逊AWS官方博客

通过 AWS Network Firewall 实现混合云环境下资源和服务的有效防护

摘要

 

AWS在2020年底的Re:Invent大会上发布了新的安全产品的管理服务Network Firewall(网络防火墙),客户可以通过使用它来对外网进行隔离(也叫南北向),也可以用于内网之间进行隔离(也叫东西向,如同一个区域的不同VPC之间,不同区域的不同VPC之间,云和IDC之间等),实现基于规则的检测和防护。

它支持有状态的规则,也支持无状态的规则,可以灵活的配置。为了让客户更加快速的理解和使用Network Firewall,我们撰写了本系列文章。

在第一篇中,主要介绍Network Firewall的基本概念以及南北向防护的配置例子,并提供对应的CloudFormation模板让用户实现动手操作,更好的理解Network Firewall的架构设计和场景设计。

在第二篇中,将介绍基于云上的多区域互联的东西向防护,帮助客户基于Network Firewall的构建全方位的云上网络防护。

在第三篇中,将介绍在混合云环境下,本地IDC和云上资源如何协作并在防火墙的监管下的实现检测和保护下的互通。

本文为本系列的第三篇。

 

关键字

Network,Firewall,TGW,防火墙,网络防火墙,规则,规则组,中转网关,南北向,东西向,混合云,混合网络

 

架构设计

 

这是我们设计的客户常见的混合云网络架构图,云上环境的内网和外网(南北向)有网络防火墙隔离;云上环境区域/VPC之间,云上环境和私有IDC环境之间(东西向)有网络防火墙隔离;私有IDC环境的防火墙由客户的基础架构确定,不在此架构设计中。

图例:全球一张网架构

 

在内网环境(东西向)防护的架构设计中,我们以AWS新加坡区域的两个EC2(Windows)机器作为客户IDC的模拟环境(Site-to-Site VPN Client也部署在这两个Windows上),来模拟混合云网络架构,以完成内网防火墙规则验证,其架构图如下所示。

图例:混合云架构下的互联架构

 

环境部署

在本系列第一篇的环境部署环节,在IAD和PDX分别部署了CloudFormation堆栈后,会在各自区域部署一个VPN Server(Customer Gateways和VPN Connections),进入到VPN对应的控制台(点击这里),选择“Download Configuration”,把配置文件下载下来(此处我们不用手工一步一步的配置,我们只是需要配置文件里面的相关信息)。

图裂:下载VPN Server配置信息

 

打开下载的配置文件,找到对应的IP地址和PSK信息。其中弗吉尼亚北部区域(us-east-1)的如下:

名称 外网IP PSK 对接(新加坡)
Tunnel  1 34.197.129.65 Hkx_1tNuHrL9eDERg0fyQ_P3VmlnBbam 18.140.129.222
Tunnel 2 54.146.154.39 udYnxJ0mQT6JzSYBZ3EhyqixTNYWZ4Yc

表格:IAD VPN Server连接信息

 

俄勒冈区域(us-west-2)的如下:

名称 外网IP PSK 对接(新加坡)
Tunnel 1 35.162.53.215 cGpoW_bZaOKRTq9hKAqSpa76IijSr0PT 54.169.206.150
Tunnel 2 52.33.21.98 .xVhn8Xs1Ywd2V07WJYIA96wKiAuiGXK

表格:PDX VPN Server连接信息

 

打开AWS新加坡区域(ap-southeast-1)控制台并进入CloudFormation的主页,选择“创建堆栈(Create Stack)”,此处选择上传模板文件“sin-nfw-01.yml”,也可以直接点击如下图标按钮部署模板:

配置堆栈名字“sin-cfm”,选择密钥文件“kp-nfw-sin”,分别填入上表对应的Tunnel 1/2的对应地址和下载的配置文件里面的PSK密钥信息,然后创建堆栈即可。

图例:IAD VPN Server相关配置信息

 

图例:PDX VPN Server相关配置信息

 

部署完CloudFormation堆栈后,系统会生成一个VPC公有网段并部署两个可公网访问的EC2(Windows),可以使用RDP方式连接上这个EC2,具体方法请参考官方文档“连接到Windows实例的参考文档”。

 

配置混合云下的东西向防护

我们以弗吉尼亚北部区域为例说明配置过程。

配置新加坡区域的路由表

这部分内容我们在CloudFormation的模板部署堆栈的时候已经为大家配置好(前提是大家部署堆栈时参数配置正确),如果对这一块有兴趣的客户可以参考前面步骤下载的配置文件查看对应的配置步骤和内容,此处不再赘述。

配置TGW的路由表

因为我们的VPN是直接连接到TGW的,所以此处需要配置TGW的路由。打开VPC中TGW的路由表页面(点击这里),选中“rtb-spoke”,在下面的Tab页面中选择“Associations”,然后点击“Create association”,把VPN的attachment关联上。

然后选中“rtb-nfw”,在“Routes”页面添加1条静态路由,指向VPN的attachment(172.16.0.0/16)。

图例:配置TGW的NFW VPC的路由表

 

配置VPC子网的路由表

打开VPC的路由表的控制台首页(点击这里),按如下表格内容分别配置路由即可。

路由表 Destination Target 备注
vpc2-rtb-pri 172.16.0.0/16 tgw-id 因为我们的TGW和对应VPC1的NFW的都是0.0.0.0/0的路由,所以此处不用修改
vpc2-rtb-pub 172.16.0.0/16 tgw-id
vpc3-rtb-pri 172.16.0.0/16 tgw-id
vpc3-rtb-pub 172.16.0.0/16 tgw-id

表格:配置us-east-1的VPC内部路由表

用同样的方法配置俄勒冈区域即可(内容和上述基本类似)。

测试

打开新加坡区域的EC2控制台(点击这里),找到标记为IAD的那台Windows机器,登录进去后,打开命令行窗口,直接ping,系统会首先创建通道,然后往里就通了,如下图所示。

图例:VPN到弗吉尼亚北部区域配置成功

登录另外一个带PDX的Windows机器,ping对应区域的内网IP地址,可以发现和我们预期的一致(此处我们不再演示不能ssh登录Linux机器的场景了,留给客户自己测试验证)。

图例:VPN到俄勒冈区域配置成功

 

销毁环境

测试全部通过后,可以选择在各个区域的CloudFormation控制台删除对应堆栈以释放资源节省成本。

 

架构设计最佳实践

多AZ的高可用外网防火墙架构

在实际的生产环境中,我们部署服务时需要跨AZ设计架构,在部署外网防火墙时可以参考如下部署架构。

A.需要面向公网的服务(如ELB)可以部署在中间的pub_subnet层;

B.必须部署在内网的服务(如EC2)可以部署在下面的pri_subnet层,然后通过部署在公有子网的NAT网关实现主动外网连接;

C.防火墙部署在最外部接近IGW的位置;

D.每个AZ单独部署一个NAT网关;

E.每个AZ单独部署一个防火墙终端节点;

F.此架构可免去NAT网关的相关费用;

图例:多AZ的防火墙部署架构

 

同Region多VPC的内网防火墙架构

很多客户之前在云上部署环境的时候,VPC的定义和使用相对比较简单和随意,公司业务越做越大以后会发现网络互通非常的困难,不是因为有网段重叠,就是需要做某些特别的隔离,这时候内网防火墙就变得非常重要(否则只能通过ACL结合安全组实现,配置和运维难度很大)。

在Region内多VPC的互联方式可选两种,一种是VPC Peering,一种是使用中转网关TGW互联,要使用内网防火墙过滤包,则必须使用TGW互联,如下图架构所示。

图例:同区域多VPC的防火墙部署架构

在实际的使用过程中,也许不需要校验所有的内网流量,在TGW的Spoke路由表中,就不需要设置0.0.0.0/0的路由到防火墙的终端节点上,只配置对应的子网和路由即可。

 

混合云环境防火墙架构

大部分大客户的混合云网络架构会如下图所示,不仅需要全球互联,而且要根据当地的政策法规实现网络监管(如下图所示的CDG为AWS巴黎区域,IAD为AWS弗吉尼亚北部区域,SIN为AWS新加坡区域)的合规性要求,配置对应的外网防火墙和内网防火墙(本系列文章的动手实验就是基于这种架构设计,不过比下图少了一个区域,网段设计和配置都相对简单一些)。

图例:混合网络下的防火墙部署架构

 

在实际的环境下,客户构建全球一张网的时候,并不是完全对等的全互联网络架构,大概率会构建星型架构,然后再构建全互联架构,例如欧盟区域先在巴黎或者法兰克福汇聚成星型,东南亚现在新加坡汇聚成星型,北美现在美东汇聚成星型,然后这三个星型中心再构建全球一张网,这样可以避免过度的牵引流量和路由广播配置等。

 

防火墙的路由怎么配最合适

AWS的Network Firewall是一种托管的管理服务,部署防火墙的时候其实是往对应的子网部署了一个终端节点(本质为一张ENI网卡)。

我们都知道,每个ENI网卡的流量是有上限的,同时还要考虑高可用的原因(这也是我们建议每个AZ都部署防火墙的终端节点的原因之一),结合考虑之后,很多客户会发现如本系列文章的路由全部配置0.0.0.0/0其实不是最合适的方式(这样只是管理简单,且比较适合流量不太大的情况),而是应该针对不同的子网实现单独的路由管控,当然这会带来路由的管理和运维的复杂度,可以考虑结合基础架构及代码的程序化方式实现。

在本篇文章的架构设计图上我们会发现,如果不做路由的控制(设置为0.0.0.0/0)的情况下,流量进出会经过防火墙两次(如果是跨区域,跨VPC的流量经过双方防火墙,则是来回四次),虽然及时是流量在同一个AZ里面没有额外费用,但是对于服务的延时增加,对于规则的管理等工作量和异常检测,故障处理和修复都会增加复杂度,在设计网络架构的时候可以适度的参考这一点(例如只针对某一种流量进行检查和筛选,例如只针对某一个数据流向进行处理等)。

 

防火墙的规则怎么配最合适

防火墙规则除了有顺序外,还有一个容量的指标(有状态最大容量3万条,无状态最大容量1万条),而且创建了规则组以后,容量值不可更改,此时我们需要知道系统计算容量的方式。

特殊情况下,不限协议(All),不限来源(0.0.0.0/0),不限目的(0.0.0.0/0)的方式算1条;

正常情况下,例如本系列文章使用的允许curl百度的规则其实是设置了协议(HTTP/HTTPS),设置了域名(.baidu.com),这条规则其实是算2条的,而且每添加一个域名,会额外增加两条(因为有两个协议),他们是个乘积。

同类型的反向动作(如允许curl百度,不允许curl知乎这种)是不能配置在同一个规则组的,这点尤其要注意。

每一个防火墙只能关联一个策略(也只能关联一个VPC),在这个策略中可以关联多个无状态规则组,多个有状态规则组,并设置无状态规则组的默认动作。如下图所示为规则执行顺序,供参考。

图例:防火墙规则加载顺序

 

 

如何做威胁检测和可视化展示

AWS Network Firewall自带监控组件,可以在控制台页面直接查看,也可以在CloudWatch里面查看详细数据,包括多个维度数据(如收到的包,通过的包,丢弃的包等),支持按不同的终端节点过滤,如下图所示是控制台的显示。

图例:防火墙监控数据

可以通过API的方式从CloudWatch提取这些数据做额外的风险分析和防护需求定义(如告警,大屏等),也可以把数据导出到对象存储(如S3)做统计分析,趋势分析以及异常分析定位等,也可以结合如Athena/Quicksight工具实现自定义的可视化展示。

扩展阅读

请参考本系列的第一篇《(一)通过AWS Network Firewall实现南北向资源和服务的有效防护》

请参考本系列的第二篇《(二)通过AWS Network Firewall实现东西向资源和服务的有效防护》

 

参考文档

1.Network Firewall官方文档:

https://docs.thinkwithwp.com/zh_cn/network-firewall/latest/developerguide/what-is-aws-network-firewall.html

2.Network Firewall部署架构设计:

https://thinkwithwp.com/cn/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

3.Transit Gateway官方文档:

https://docs.thinkwithwp.com/zh_cn/vpc/latest/tgw/what-is-transit-gateway.html

4.VPC官方文档:

https://docs.thinkwithwp.com/zh_cn/vpc/latest/userguide/what-is-amazon-vpc.html

 

 

本篇作者

陈卫琼

亚马逊云科技资深解决方案架构师,负责协助客户业务系统上云的解决方案架构设计和咨询,现致力于大数据和IoT相关领域的研究。

龙斌

亚马逊云科技解决方案架构师,负责协助客户业务系统上云的解决方案架构设计和咨询,现致力于DevOps和容器相关领域的研究。