AWS · Advanced Networking Specialty

网络课程笔记

Lecture 233 · 10 张幻灯片

幻灯片、双语总结及 Transcript · 图片已内嵌,可离线阅读。

原文默认收起
lecture-233.md

Lecture 233: Hands On: AWS Network Firewall

  • 课程:[NEW] AWS Certified Advanced Networking Specialty 2026
  • 视频时长:22:19
  • 来源:Udemy Lecture 28606044
  • Slide 数量:10
  • 画面切换:01:25、05:34、08:37、09:49、12:41、14:01、16:50、19:27、20:35

扫描说明

逐条读取了 Transcript 面板中的全部 432 条英文 cue,并按播放器可见时钟扫描全长约 22:19 的实操视频。页面属性选择器只暴露 284 条 cue,初次采集在 13:48 出现断点,已全部丢弃并改用 Transcript 面板的 432 个可访问 cue 重建,最终覆盖 00:00–22:17。依据目标、Rule Logic、基础环境、Route Design、Baseline、Firewall、Rule Group、Route Update、Inbound/ICMP Test、Outbound Test/Cleanup 划分为 10 个小节。10 张截图从实际视频区精确裁取,统一为 1364×770。

Transcript 来自 Udemy 页面自带的英文自动字幕,没有使用 ASR。下面保留页面原文,包括其中的语法或识别错误。

1. 实验目标:Block ICMP,仅允许到 aws.amazon.com 的 TLS Outbound

时间范围:00:00–01:25

AWS Network Firewall lab objectives for ICMP blocking and restricted TLS egress

总结 / Summary

中文

实验在 EC2 上运行 Public Web Server,然后用 Network Firewall 实现两类 Policy:Stateless Rule 阻止所有 ICMP/Ping;Stateful Rule 让 Web Server 只能通过 TLS/HTTPS 访问指定 aws.amazon.com Domain,并阻止 Plain HTTP 与其他 Outbound Destination。该目标同时验证 Inbound Web、Management Access、Protocol/Domain Egress 与 Default-deny 行为。

English

The lab runs a public web server on EC2 and implements two policies with Network Firewall: a stateless rule blocks all ICMP and ping traffic, while stateful rules let the server reach only the specified aws.amazon.com domain over TLS and block plain HTTP plus other outbound destinations. This validates inbound web access, management access, protocol- and domain-aware egress, and default-deny behavior.

Transcript

00:00 Hello, and welcome to this lecture.

00:01 Now that you understood how AWS network firewall works,

00:05 let's try to implement this on our own.

00:08 And you know that network firewall works differently

00:11 and you have to modify route tables for your subnet

00:16 as well as for internet gateway

00:18 and all these we'll see in this lab.

00:20 So what is the objective of this lab?

00:23 We want to host a web server on EC2 instance,

00:28 that's the basic requirement.

00:29 And then using the network firewall,

00:31 we want to implement few rules.

00:33 For example, we want to add stateless rule block

00:36 to block the ICMP

00:38 that is a ping requests to our web server, right.

00:41 And then we also want to add the stateful rules

00:45 so that from my web server

00:47 I can only go to a certain domain name

00:49 for example, aws.amazon.com, that's my outbound request,

00:54 and that's to only using the TLS connection.

00:58 So I shouldn't be able to use

01:00 a plain HTTP outbound connection to this domain name

01:04 and then all other traffic should be blocked, of course.

01:08 Now this scenario is based on the AWS block, which is here.

01:13 I just slightly modified this requirement here

01:17 and accordingly I also modified my rules.

01:20 So I'll talk about that as we proceed with the labs.

01:23 So this is high-level requirement.

2. 双 Subnet 架构与 Stateless/Suricata Rule 设计

时间范围:01:25–05:34

Firewall rule slide showing ICMP stateless rules and four Suricata stateful rules

总结 / Summary

中文

VPC 包含 Public Web Subnet、Dedicated Firewall Subnet、Network Firewall Endpoint 与 IGW。Stateless Priority 10 Drop ICMP,Priority 20 把其余 Protocol 全部 Forward to Stateful。四条 Suricata Rule 分别 Pass SSH/TCP 22、Pass HTTP Host 以 .amazonaws.com 结尾的入站访问、Pass TLS SNI aws.amazon.com 的出站访问,最后 Drop 其他 Established-to-server TCP。Default Action Order 让 Pass Rule 先于 Drop,flow:established,to_server 避免在 TLS 握手阶段误杀随后获准的 Flow。

English

The VPC contains a public web subnet, dedicated firewall subnet, Network Firewall endpoint, and IGW. Stateless priority 10 drops ICMP and priority 20 forwards all remaining protocols to stateful inspection. Four Suricata rules pass SSH on TCP 22, pass inbound HTTP whose Host ends in .amazonaws.com, pass outbound TLS whose SNI is aws.amazon.com, and drop other established-to-server TCP traffic. Default action order evaluates pass before drop, while flow:established,to_server avoids killing a flow before its allowed TLS context is known.

Transcript

01:25 And now if you look at the architecture

01:27 that we want to build to achieve this,

01:29 it should look something like this, right.

01:31 You should have a VPC, in that VPC you would have to subnets

01:36 in one subnet, which is here, it's a public subnet

01:40 in which you would have public web server.

01:43 And then there will be a firewall subnet

01:45 in which you will provision

01:46 the AWS network firewall endpoint.

01:49 And there will also be internet gateway, of course.

01:52 Now,

01:53 if you look at the route tables for this three components,

01:55 of course, for the public subnet,

01:58 all the outbound internet traffic

02:00 will go through the firewall endpoint.

02:02 Now, in case of firewall endpoint,

02:05 all the traffic will go through the internet gateway

02:08 and for the internet gateway ingress traffic

02:11 for the web server, the traffic should also be routed

02:14 through the firewall endpoint.

02:15 And this is an ingress traffic

02:17 because your internet gateway will do the knotting.

02:20 It will map the public IP of FIPs over to the private IP

02:24 and this private IP is from this subnet

02:26 and that's where you see this entry.

02:28 So at high level,

02:29 these are the route tables that you need to configure

02:31 for your network firewall

02:34 to be able to intercept that traffic.

02:37 So I hope that it's clear

02:39 and now let's understand which rules you want to add here

02:42 in case of stateless and stateful rules.

02:45 So for stateless,

02:47 I will add one rule which will drop the ICMP traffic,

02:50 and then rest of the traffic,

02:53 I want to route through the stateful rule groups, right.

02:56 Because then I want to take decision

02:58 in the stateful rule groups

02:59 where I want to allow the TCP traffic or not.

03:02 And here in case of stateless rules,

03:05 I will attach the priority as 10 and 20

03:08 so that the first rule that is a drop traffic

03:11 will be evaluated first.

03:13 Now, in case of stateful rules, I have added four rules.

03:17 The very first rule is for allowing the SSH,

03:21 that is because from this web server,

03:22 we want to test the outbound connectivity

03:25 so I also want to SSH to this machine.

03:29 Second, I'm only allowing the HTTP traffic,

03:32 that means I have a web server

03:33 so I should be able to reach to web server over port 80,

03:37 that is an HTTP traffic,

03:38 and I should only be able to access my web server

03:42 using the AWS provided DNS name.

03:45 And that's where you see that,

03:47 you know, the DNS name ends in dot amazonaws.com.

03:51 That means I cannot access my web server

03:55 using the public IP of the web server

03:57 but only through the DNS name.

04:00 Third, I will add this entry

04:03 which allows the outbound request from this web server

04:07 to only the domain name that is aws.amazon.com.

04:11 And additionally, the traffic will only be the TLS traffic.

04:15 That means I cannot use plain HTTP traffic or a TCP traffic

04:19 to reach to this aws.amazon.com domain name.

04:23 And finally,

04:24 I have the rule which is drop all other TCP traffic

04:29 so that there is no other traffic

04:32 that can flow in and out of my web server.

04:34 Now you'll be wondering if that is the case

04:37 then how you are allowing the, you know,

04:40 this HTTPS traffic to the aws.amazon.com.

04:45 Because when the PCP handshake happens at that moment,

04:49 the traffic is not DLS, right, it starts with TCP.

04:53 Now, in that case, this drop rule should be applied

04:56 and your traffic will be stopped.

04:58 But for handling this use case,

05:02 we have added this flow.established as a parameter,

05:06 which allows the traffic to be dropped

05:09 only when it is not an established traffic,

05:13 that means for this TLS

05:15 the TCP handshake has already happened

05:18 and that's where it won't use this route

05:21 to drop that traffic.

05:22 But any other traffic, which does not meet this requirement

05:26 will be dropped by this fourth rule.

05:29 So overall, these are our requirements for firewall rules.

3. 先建立无 Firewall 的 VPC/EC2/HTTPD Baseline

时间范围:05:34–08:37

AWS Network Firewall lab next steps for EC2 HTTPD SSH HTTP and ICMP baseline

总结 / Summary

中文

起始环境先不插入 Firewall:创建 VPC、Public Web Subnet、Firewall Subnet 与 IGW;VPC 开启 DNS Resolution 和 DNS Hostname,确保 EC2 获得 Public DNS;在 Web Subnet 启动带 Public IP 的 EC2,通过 SSH 安装并启动 HTTPD,建立测试页面。实验暂时让 SG 放宽 SSH/HTTP/ICMP 且不修改 NACL,以隔离变量并确认 Firewall 才是后续 Block 来源;这种 Allow-all SG 仅适合受控 Lab。

English

The starting environment contains no firewall path: create the VPC, public web subnet, firewall subnet, and IGW; enable VPC DNS resolution and hostnames so EC2 receives public DNS; launch an EC2 instance with a public IP in the web subnet; and install and start HTTPD over SSH with a test page. The lab temporarily opens the security group for SSH, HTTP, and ICMP and leaves NACLs unchanged so later blocking is attributable to the firewall. Such broad SG access is suitable only for a controlled lab.

Transcript

05:34 Now, if I want to set this up,

05:36 I need a basic setup to start with, right.

05:39 That means I will need a VPC,

05:41 I will need EC2 machines and all.

05:43 Now, if you follow AWS blogs,

05:45 everything can be set up using a cloud formation template,

05:48 but here I have done that manually.

05:50 So if you want to start, this is very simple.

05:53 There is no AWS firewall, right,

05:56 I'm just creating two subnets and one subnet would be public

05:59 in which I launch a web server

06:01 and then there will be a route table

06:04 where the traffic goes to the internet gateway.

06:06 So there is nothing fancy here, right,

06:08 it's all, you know how to create this setup.

06:11 Just remember one more thing that enabled the DNS hostname

06:15 and DNS resolution on your VPC,

06:17 because otherwise AWS won't locate the public DNS name

06:22 for your EC2 instance.

06:23 So in order to handle that,

06:25 please enable these two settings

06:27 because in our firewall rules, as you have seen,

06:30 we are allowing HTTP traffic only for the web server

06:34 where the DNS name ends in amazonaws.com.

06:39 Okay, so for simplicity,

06:40 what I've done is I already created this VPC

06:45 and this subnets and internet gateway

06:48 and I'll start from there.

06:49 Now, once I have that set up,

06:51 I will just SSH into this web server

06:53 because there is no web server, as of now,

06:55 it's just an EC2 instance,

06:57 and I will install the HTTPD web server there

07:00 and we'll start the HTTPD service.

07:03 Now by launching EC2 machine,

07:04 I also need to provide the security group,

07:06 but I will just allow everything in the security group

07:09 so that I know that traffic is not really getting blocked

07:11 at the security group level

07:13 and I'm not touching the network ACL as well.

07:16 Now then verify that you are able to access the web server

07:20 or a browser using the EC2 instance IP

07:23 and our public DNS.

07:25 Then also verify that you are able to ping to EC2 instance

07:28 using the public IP or the public DNS.

07:31 Now, this is a simple setup

07:33 where there is no network firewall.

07:36 Then we will create the network firewall

07:38 in its designated subnet.

07:40 And then we will also add

07:42 corresponding stateful rule groups

07:44 as well as stateless rule groups.

07:47 Finally, once the firewall has been added,

07:50 we need to modify the route tables, right.

07:52 As I said to you, a route table has to, you know,

07:56 take all this traffic through the firewall

07:58 whether, you know, going to the internet

08:01 or coming from the internet.

08:04 And finally, once that is done,

08:06 we will test the ping to the web server from local machine,

08:10 it shouldn't work.

08:12 And then we'll SSH to the web server,

08:14 which should be successful

08:15 because we have added that in our stateful rule.

08:19 And from there, we will try to get some data

08:21 from say, aws.amazon.com or HTTPS, which we should succeed,

08:27 but any other domain names shouldn't work, right.

08:32 That would be our final test.

08:34 So if this works, that means our firewalls are working well.

4. 三张 Route Table 强制 Web Subnet 与 IGW 双向经过 Endpoint

时间范围:08:37–09:49

Network Firewall route table design for IGW firewall subnet and protected subnet

总结 / Summary

中文

Web/Protected Subnet 的 0.0.0.0/0 要从原 IGW Target 改为 Firewall Endpoint;Firewall Subnet 的 Default Route 指向 IGW;新建 IGW Ingress Route Table,把 Web Subnet CIDR 指向 Endpoint,并通过 Edge Association 关联 IGW。IGW 本身没有直接的 Route Table 编辑入口,必须在 VPC Route Table 的 Edge Association 中选择该 IGW。三表配合才能保证 Inbound、Return 与 Outbound 对称检查。

English

The web or protected subnet's 0.0.0.0/0 route changes from the IGW to the firewall endpoint. The firewall subnet's default route points to the IGW. A new IGW ingress route table sends the web-subnet CIDR to the endpoint and is attached to the IGW through edge association. The IGW does not expose a standalone route-table editor; the association is made from the VPC route table. These three tables together enforce symmetric inspection for inbound, return, and outbound paths.

Transcript

08:37 Now, as I said, for route tables

08:40 you need to have the route table,

08:42 something like this for your public subnet

08:45 where your web server site,

08:46 you will have the route table entry.

08:48 You'll say is all the internet traffic

08:51 will go through the firewall endpoint,

08:53 for firewall subnet, all the traffic will be routed

08:57 through the internet gateway

08:59 and for internet gateway,

09:01 any traffic that is going to your protected subnet here,

09:06 it will go through the firewall endpoint.

09:09 Now,

09:10 as of now we haven't seen the route table for the internet.

09:13 Now this is an ingress route table for the internet.

09:16 And how you do that

09:17 is you have to first go to the route table,

09:20 you have to create the route table,

09:22 and then when you associate the route table,

09:24 there is an additional entry there which is age association,

09:28 and at that moment, you can sell it internet gateway there

09:32 and then that route table

09:33 is associated with the internet gateway.

09:35 Otherwise, if you go to the AWS console

09:38 and go to internet gateway,

09:39 you don't see an option to add a route table

09:42 to the internet gateway, right, so just remember that.

09:46 So with that, let's get started

5. 在 Console 建好 Subnet/Route/EC2,并验证 IP 与 DNS Baseline

时间范围:09:49–12:41

Browser baseline showing the public web server reachable before Network Firewall insertion

总结 / Summary

中文

Console 中使用 10.0.0.0/16 VPC,建立 Firewall Subnet(示例 10.0.100.0/...)与 Web Subnet(10.0.0.0/...),分别关联 Route Table。Web Route 最初直连 IGW,Firewall Route 先只完成 Subnet Association。EC2 获得 Public IP/Public DNS,安装 HTTPD 并写入 Dummy Page 后,通过 Public IP 与 Public DNS 都能访问。这个 Working Baseline 为后续 Rule Test 提供对照。

English

In the console, the lab uses a 10.0.0.0/16 VPC with a firewall subnet such as 10.0.100.0/... and a web subnet such as 10.0.0.0/..., each associated with its route table. The web route initially reaches the IGW directly, while the firewall route first receives only its subnet association. EC2 receives a public IP and public DNS, installs HTTPD, and serves a dummy page through both address forms. This working baseline provides a control for later rule tests.

Transcript

09:49 and now I'll just jump to my console.

09:52 Okay then,

09:53 you can see that I already created this demo VPC

09:56 with DCIDR 10.0.0/16.

09:58 And in this, I created two subnets,

10:00 one subnet for the firewall and one subnet for the web.

10:04 And this CIDRs are 10.0.100.0 and 10.0.0.0.

10:09 Now, for the subnet for the web server

10:13 I just modified the route table

10:14 to add entry for internet gateway and this is very simple,

10:18 I'm not adding the firewall as of now, as I told you, right.

10:22 So it's a public subnet,

10:23 and I haven't touched this firewall sub-net as of now.

10:27 And then if you see the route tables,

10:29 I have two route tables, one for the web server

10:32 and I have the route to internet gateway

10:35 and then I also attached to the corresponding subnet.

10:38 Now for the firewall, also I created a route table

10:43 and I just also need to attach it

10:45 to the firewall subnet here.

10:48 So I'm just doing that.

10:50 Now, I'm not really launching anything

10:52 in the firewall subnet as of now,

10:53 so it doesn't really matter,

10:55 but the setup is really very simple.

10:58 Then what I additionally did is I launched a web server

11:02 inside my VPC in the web server subnet

11:05 and I associated the public IP as well.

11:08 And on the VPC level, I also have the enable DNS resolution

11:14 and the hostname setting steps

11:16 where it also got this public DNS.

11:18 Now, what I did is I just connected to this instance

11:22 or an SSH and now I'll just install the web server.

11:26 So let's do that

11:32 and then also let's start the web server.

11:36 (keyboard clacking)

11:39 And finally, let's just create one dummy file

11:47 so that we can access this web server

11:49 and some web pages displayed.

11:52 This is my web server,

11:59 that's it.

12:00 And now if I access this web server or an IP address,

12:04 it should work.

12:10 Right, it works.

12:11 And similarly, if I get it public DNS name,

12:17 it should also work.

12:19 So using this DNS name I can also access my web server.

12:24 Okay, so that's the test that we did.

12:27 Now, our setup is ready with the starting point

12:31 and now let's get into the, you know,

12:34 mood where we want to set up everything else, right.

12:37 So we want to create now firewalls

12:39 and corresponding group tables and everything.

6. 创建 Regional Firewall、Endpoint 与空 Firewall Policy

时间范围:12:41–14:01

AWS Network Firewall console showing the demo firewall and attached policy

总结 / Summary

中文

在 VPC Console 的 AWS Network Firewall 中创建 demo-firewall,选择实验 VPC、单一 AZ 与 Firewall Subnet,并同时创建空的 demo-firewall-policy。Provision 需要几分钟,Status Ready 后可在 Firewall Detail 取得 AZ-specific Endpoint ID,之后 Route Table 会引用该 vpce-...。演示只用一个 AZ;生产架构应为所有使用 AZ 创建 Endpoint 并保持 AZ Affinity。

English

From AWS Network Firewall in the VPC console, the lab creates demo-firewall, chooses the lab VPC, one Availability Zone, and the firewall subnet, and creates an empty demo-firewall-policy. Provisioning takes several minutes. Once ready, the firewall details expose the AZ-specific vpce-... endpoint ID used by route tables. The demo uses one AZ, whereas production should create endpoints in every active AZ and preserve AZ affinity.

Transcript

12:41 So let's do that now.

12:43 So I'm going back to my console and AWS network firewall

12:48 is part of the VPC console, so let's go there.

12:52 There's already one firewall, I'm not going to use that,

12:55 so let's create a new firewall

12:58 and let's give it a demo as the name

13:01 and VPC, we want to choose the one that we created,

13:06 which is demo one, the easy, I want to just have one easy

13:10 and the subnet we have 10.0.100.0, this one.

13:15 Okay, and we want to create a firewall policy

13:20 which is empty.

13:21 To start with, let's give it a name demo firewall policy

13:27 and also just let's change the name to demo firewall here,

13:34 that's it and let's create the firewall.

13:37 So it will take a couple of minutes

13:39 for this firewall to be ready,

13:42 by the time I'm just pausing this video.

13:45 Okay, you can see that the firewall status is ready

13:48 and now let's go to the network firewall rule groups.

13:52 And there're older rule groups, I'm not going to use those.

7. 创建 Stateless 与 Suricata Stateful Rule Group 并加入 Policy

时间范围:14:01–16:50

Network Firewall console configuring Suricata-compatible IPS rules

总结 / Summary

中文

创建 Capacity 100 的 demo-stateless Rule Group:Priority 10 对任意 Source/Destination Drop ICMP,Priority 20 对其余全部 Protocol 执行 Forward to Stateful。再创建 Capacity 100 的 demo-stateful,选择 Suricata-compatible IPS Format,粘贴四条 SSH、HTTP Host、TLS SNI 与 Catch-all TCP Drop Rule。Rule Group 创建后不会自动生效,必须分别加入 demo-firewall-policy 的 Stateless 与 Stateful Section。

English

The lab creates a capacity-100 demo-stateless group: priority 10 drops ICMP for any source and destination, and priority 20 forwards every other protocol to the stateful engine. It then creates a capacity-100 demo-stateful group in Suricata-compatible IPS format containing the SSH, HTTP Host, TLS SNI, and catch-all TCP drop rules. Creating rule groups does not activate them automatically; both must be added to the corresponding stateless and stateful sections of demo-firewall-policy.

Transcript

14:01 Let's create the stateless rule group,

14:04 and let's call it demo stateless.

14:08 And you have to mention some capacity,

14:10 how many rules you want, so let's keep it 100.

14:15 So you can add a priority, as you know,

14:17 the lowest the priority

14:18 the rule will be evaluated in that order.

14:20 So, first we want to have the rule with ICMP

14:25 and here let's give the priority as 10

14:30 so that we can insert a rules later as well.

14:33 And the source is anything and the destination is anything.

14:37 And I want to drop all this traffic, right.

14:40 So I'm just adding this rule

14:42 and then I'll add another rule, which say priority 20

14:46 and all protocols for any IP address,

14:51 I want to just forward this traffic

14:54 to my stateful rule groups, and let me just add that.

15:00 So just this two rules for the stateless rule group

15:03 and we are just creating that now.

15:06 And now also let's create the stateful rule groups,

15:10 and in that case, let's select the stateful,

15:14 let's call it demo stateful, define the capacity as 100.

15:20 Now, in this case, we are not using the 5-tuple format,

15:24 we are not using the domain list,

15:26 but we are using the Suricata compatible IPS rules.

15:31 And you can grab this from the downloadable content

15:35 or you can also just type it here.

15:39 So let me get this rules from my presentation.

15:43 So I have this four rules here

15:47 I'm just copying those and I'll just put it here.

15:52 Okay, you can see that first rule is about allowing the SSH.

15:57 Second is for allowing the HTTP traffic

15:59 so that I can access my web server or the browser.

16:03 And third rule is for connecting to aws.amazon.com

16:07 from my web server.

16:09 And fourth is to drop anything else,

16:12 which is our TCP traffic.

16:14 So let's create this and now I have this two rule groups,

16:18 but understand that as of now,

16:20 we haven't added these rule groups to our firewall policy.

16:24 So let's go to the firewall policy

16:26 and let's add this two rule groups.

16:29 So the first one is the stateless, so let's select that.

16:36 And similarly, let's also add this stateful rule group here.

16:42 So I'm just adding the demo stateful rule group here.

16:47 Okay, so on the firewall side, we are good,

8. 用 Endpoint ID 更新 Web、Firewall 与 IGW Ingress Route

时间范围:16:50–19:27

VPC route table console updating the protected subnet route to the firewall endpoint

总结 / Summary

中文

从 Firewall Detail 复制 Endpoint ID。Web Route Table 将 0.0.0.0/0 Target 从 IGW 改为 Endpoint;Firewall Subnet Route Table 将 0.0.0.0/0 指向 IGW;创建 demo-igw-route-table,将 Web Subnet CIDR(示例 10.0.0.0/24)指向同一 Endpoint。最后在 Edge Association 将该表关联 IGW。完成后逐表核对 CIDR、Target 与 Association,避免任何 Direct IGW Bypass。

English

The endpoint ID is copied from firewall details. In the web route table, 0.0.0.0/0 changes from the IGW to the endpoint. In the firewall-subnet route table, 0.0.0.0/0 points to the IGW. A demo-igw-route-table sends the web-subnet CIDR, such as 10.0.0.0/24, to the same endpoint and is attached to the IGW through edge association. Every CIDR, target, and association should then be checked to eliminate a direct IGW bypass.

Transcript

16:50 everything is set up and now what's remaining, if you know,

16:54 is our route tables, right,

16:56 we need to modify all these three root table

16:59 so that traffic can flow through this firewall endpoint.

17:03 So first let's modify the route table for a public subnet.

17:08 Now, in this case, all the traffic to internet

17:14 should go through the firewall endpoint.

17:16 Now, for that, we need to first get the firewall endpoint.

17:20 So if you go to the firewall and go to it's details,

17:24 you will find the firewall endpoint there,

17:27 and we will need this firewall endpoint for our route table

17:31 so I'm just copying this firewall endpoint.

17:34 Right, now let's go to the route tables

17:38 and the web route table, routes

17:42 and I'm just now modifying this.

17:44 Now this is a public subnet when we created earlier,

17:48 but here instead of internet gateway,

17:50 I want to use my firewall endpoint

17:53 and just save the changes, so that is done.

17:57 Now for the firewall route table,

18:01 I want to have all the traffic

18:06 going through the internet gateway, right.

18:09 So let's do that and save the changes.

18:15 If you're confused, just look at this architecture

18:18 and you should be able to understand what I'm doing.

18:21 Now, the third thing which is new to you

18:24 is having the route table for the internet gateway.

18:28 Now, in order to do that,

18:29 let's create a new route table first.

18:32 So let's go to the route table and create a route table,

18:35 say demo igw route table in the VPC,

18:42 and just create that route table

18:46 and then as in routes, we will again add,

18:50 if the traffic is going to the web server subnet,

18:52 which is $10.0.0.0/24,

18:56 again it has to take the route through the firewall endpoint

19:01 and save the changes.

19:02 But as of now, this route table

19:04 is not associated with the internet gateway.

19:07 In order to do that, as I said,

19:09 you need to go to the age association

19:13 and then you need to attach this to the internet gateway.

19:18 So remember, this is important step, right,

19:20 and save the changes.

19:22 Okay, so I think we are done with the architecture

19:25 that we want to try.

9. 验证 Inbound Host Rule 与 Stateless ICMP Drop

时间范围:19:27–20:35

Command prompt showing ping attempts blocked by the Network Firewall stateless rule

总结 / Summary

中文

通过 EC2 Public IP 访问 HTTP 失败,因为 Stateful Rule 只 Pass Hostname 以 .amazonaws.com 结尾的 HTTP Request;改用 AWS Public DNS 则页面成功。随后对 Public IP 和 Public DNS 执行 Ping 都超时,证明 Stateless Priority 10 的 ICMP Drop 生效。由于 DNS 最终解析到同一 IP,这个差异来自 HTTP Host Rule,而 Ping 与 Hostname 无关,仍被 ICMP Rule 阻断。

English

HTTP access through the EC2 public IP fails because the stateful rule passes only requests whose hostname ends in .amazonaws.com; the AWS public DNS name succeeds. Ping to either the public IP or public DNS times out, proving that stateless priority 10 drops ICMP. DNS resolves to the same address, so the HTTP difference comes from Host matching, while ping remains independent of the hostname and is blocked by the ICMP rule.

Transcript

19:27 Now, let's verify what's happening here, right.

19:31 First of all,

19:32 let's verify if we are able to access the web server

19:34 using the IP address.

19:36 If you just refresh, this is not working.

19:40 Now, this is because in the stateful rules,

19:43 we said that only HTTP traffic for the domain name

19:47 which ends in amazonaws.com should be allowed.

19:51 Now, if I refresh this page, ideally it should work,

19:54 I can also test this like this and this is working, right,

19:59 that means our stateful rule groups are working.

20:02 Also let's verify if ping is working or not.

20:05 We had blocked all the ping requests

20:07 so let's go to the command prompt

20:09 and let's say ping to the IP address and it is not working.

20:19 Also, let's ping to this public DNS

20:27 and you can see this is also not working

20:30 because in a stateless rule group

20:32 we have defined that block the ping request.

10. SSH 与 Egress Test:HTTPS Allow、HTTP/Other Domain Deny,并清理计费资源

时间范围:20:35–22:19

SSH terminal testing allowed aws.amazon.com HTTPS and blocked other outbound destinations

总结 / Summary

中文

SSH 登录成功,因为 Stateful Rule 明确 Pass TCP/22。Instance 内执行 curl http://aws.amazon.com 失败:Domain 虽匹配但 Protocol 不是 TLS;curl https://aws.amazon.com 成功:TLS SNI 与 Domain 均匹配;curl https://google.com 失败:SNI 不在 Allowlist,随后命中 TCP Drop。测试完成后必须删除 EC2、Network Firewall、Rule/Policy 与相关实验资源,因为 Firewall Endpoint/Processing 和 EC2 都会持续计费。

English

SSH succeeds because a stateful rule explicitly passes TCP 22. From the instance, curl http://aws.amazon.com fails because the domain matches but the protocol is not TLS. curl https://aws.amazon.com succeeds because both TLS SNI and domain match. curl https://google.com fails because its SNI is outside the allowlist and the TCP drop rule catches it. After testing, delete EC2, Network Firewall, rule and policy resources, and the rest of the lab because firewall endpoints or processing and EC2 continue to incur charges.

Transcript

20:35 Now, one more thing we want to try

20:37 is we want to log into this website or our SSH

20:40 and then we want to see if we can reach to, you know,

20:44 aws.amazon.com or our TLS connection.

20:47 So let's go to this session,

20:51 I'm just going to duplicate this

20:55 and you can see I'm able to log into the web server or SSH

20:59 that's because I have allowed that

21:02 in our stateful rule groups.

21:04 Okay, so I'm here, now let's try to do something like this

21:08 curl, first let's try, http://aws.amazon.com.

21:16 Now, even though it's an aws.amazon.com DNS

21:19 that we have white listed in those stateful rule groups

21:22 this one work,

21:23 because we said the condition has to be the TLS.

21:26 That means it should be an HTTPS connection.

21:29 And if I do that, I get the page of aws.amazon.com.

21:34 And at the same time, if I do something different,

21:37 maybe let's try to do https://google.com.

21:41 So it won't work

21:43 because we are white listing only the domain name

21:46 that we are interested in.

21:47 So this is what we wanted to achieve

21:49 and I think this is working perfectly as we expected.

21:53 And that's it about the Network Firewalls.

21:56 So I hope you enjoyed this lecture

21:58 and you understood how these things work.

22:01 Now, make sure that when you do this exercise,

22:03 you delete all your resources

22:05 because everything is charged, right.

22:07 There is an EC2 instance, there's a network firewall

22:09 everything has a price.

22:10 So make sure you delete all those resources.

22:13 So thanks for watching

22:14 and stay tuned for more exciting stuff.

22:17 Thank you.

整讲总结 / Overall Summary

中文

本讲把 Network Firewall 从目标、Rule、Endpoint 到 Route 与验证完整串起来:Stateless 先 Drop ICMP、Forward 其余;Suricata Stateful Pass SSH、指定 HTTP Host/TLS SNI,并 Drop 其他 TCP;三张 Route Table 保证 Inbound/Outbound 对称经过 Endpoint。最终 Public DNS HTTP、SSH 与 https://aws.amazon.com 成功,Public-IP HTTP、Ping、Plain HTTP Egress 与其他 Domain HTTPS 失败。Rule Group 必须加入 Policy,Policy 必须绑定 Firewall,Route 必须指向 Endpoint,四层缺一不可。

English

The lab connects every Network Firewall layer from objectives and rules to endpoints, routes, and validation. Stateless rules drop ICMP and forward everything else; Suricata stateful rules pass SSH and selected HTTP Host or TLS SNI traffic and drop other TCP; three route tables enforce symmetric endpoint traversal. Public-DNS HTTP, SSH, and https://aws.amazon.com succeed, while public-IP HTTP, ping, plain-HTTP egress, and HTTPS to other domains fail. Rule groups must join the policy, the policy must attach to the firewall, and routes must target the endpoint—every layer is required.

返回顶部 ↑