Here is what I considered regarding the points to keep in mind when aggregating and inspecting inbound traffic from the internet using AWS Network Firewall
This page has been translated by machine translation. View original
When aggregating inspection of inbound traffic from the internet, what configurations are available and what are the key considerations?
Hello, I'm Nonpi (@non____97).
Have you ever wondered what configurations are available and what key considerations exist when aggregating the inspection of inbound traffic from the internet? I have.
Using Network Firewall with Transit Gateway or Cloud WAN to aggregate and inspect outbound traffic to the internet seems like a fairly common configuration.
But what about inbound traffic? Compared to outbound traffic, I feel it comes up less often.
Let me think about why it comes up less often and what configurations are possible.
Summary Up Front
- There are 2 patterns for inspecting inbound traffic from the internet with Network Firewall
- Pattern 1: IGW → Network Firewall → ALB
- Pattern 2: IGW → ALB → Network Firewall
- Cases where Network Firewall is adopted for aggregated inspection of inbound traffic are rare
- Mainly due to the following reasons
- Most externally published traffic is encrypted, limiting the scope of inspection without TLS inspection
- Enabling the Advanced Inspection Endpoint for TLS inspection increases the monthly fixed cost by approximately 2.7x (576.70 USD → 2,175.40 USD)
- Only about 4% of AWS managed rule group rules operate in the inbound direction (900 / 22,888 rules)
- HTTP/HTTPS threats can be addressed by AWS WAF and AWS Shield Advanced instead
- ALB's TCP termination absorbs SYN floods and UDP reflection attacks
- Separating VPCs and AWS accounts for aggregation increases management overhead
- There are hurdles in dynamically tracking IP addresses cross-account
- Traffic logs can be partially substituted with VPC Flow Logs / ALB access logs / WAF logs
- Complex HOME_NET definitions can easily lead to missed detections
- CloudFront VPC Origins and Global Accelerator can become bypass paths
- Mainly due to the following reasons
- Cases where inspecting inbound traffic with Network Firewall is still motivating
- Externally publishing TLS protocols other than HTTP/HTTPS (SMTPS / IMAPS / LDAPS, etc.)
- Externally publishing TCP/UDP services with NLB
- Finding value in the rules within threat signature managed rule groups that address inbound internet traffic
- Compliance or audit requirements explicitly mandate network-based IDS/IPS
- Evaluate what threats you want to address, what gaps existing controls leave, and whether the cost is justified before deciding to adopt it
Overview of Configurations
There are broadly two possible configurations:
- Place Network Firewall in front of internet-facing resources
- Place Network Firewall behind internet-facing resources
Each is described below.
1. Place Network Firewall in Front of Internet-Facing Resources
This is the pattern where Network Firewall is placed in front of internet-facing resources, like IGW → Network Firewall → ALB.
The diagram looks like this:
For Cloud WAN, you simply replace Transit Gateway and nothing else changes.
This is also introduced in the AWS Blog as follows:
Excerpt: AWS Network Firewall Deployment Models | Amazon Web Services Blog
Excerpt: AWS Network Firewall Deployment Models | Amazon Web Services Blog
Excerpt: Designing Your Firewall Deployment for Internet Ingress Traffic Flows | Amazon Web Services Blog
Normally, you cannot inspect the contents of TLS-encrypted traffic, but by enabling TLS inspection, you can also inspect encrypted portions of the communication.
2. Place Network Firewall Behind Internet-Facing Resources
This is the pattern where Network Firewall is placed behind internet-facing resources, like IGW → ALB → Network Firewall → Target.
The diagram looks like this:
Here too, for Cloud WAN, you simply replace Transit Gateway and nothing else changes.
This is also introduced in the AWS Blog as follows:
Excerpt: AWS Network Firewall Deployment Models | Amazon Web Services Blog
Excerpt: Designing Your Firewall Deployment for Internet Ingress Traffic Flows | Amazon Web Services Blog
If an internet-facing resource such as an ALB terminates TLS, then TLS inspection is not required here.
On the other hand, the source IP address visible to Network Firewall will be the IP address of the internet-facing resource such as ALB.
Summary of Pros/Cons for Each Configuration
Let me summarize the pros and cons of each configuration.
To state my conclusion up front, I prefer 2. Place Network Firewall behind internet-facing resources.
The pros/cons are as follows:
| Aspect | Pattern 1 (IGW → Network Firewall → ALB) | Pattern 2 (IGW → ALB → Network Firewall) |
|---|---|---|
| TLS/HTTPS Traffic Inspection | Without TLS inspection, only plaintext portions such as SNI are visible. TLS inspection is required to inspect HTTPS content | ○ Since ALB terminates TLS, plaintext HTTP can be inspected directly without TLS inspection |
| Client IP Visibility | ○ Client IP addresses can be seen as-is | The client IP address visible to Network Firewall is the private IP address of the ALB; the true client IP is only available via the X-Forwarded-For header |
| Network Firewall Processing Volume | All inbound traffic, including DDoS attempts and scanning attempts, passes through and is evaluated by Network Firewall, increasing charges based on traffic volume | ○ Only traffic not dropped by ALB and AWS WAF passes through Network Firewall |
| Reuse of East-West/Egress Network Firewall | Separate procurement is required (not a concern if you want explicit separation from other Network Firewalls) | ○ Easier to reuse the same Network Firewall. Both the ALB → Target path and the East-West/Egress path go through the same Inspection VPC via TGW, enabling savings on Firewall endpoint hour charges |
Thoughts on Why Network Firewall Is Rarely Used to Inspect Inbound Traffic from the Internet
First, let me explore why Network Firewall is rarely used to inspect inbound traffic from the internet.
I think the reasons include the following:
- Inbound traffic from the internet is often encrypted, making it difficult to obtain meaningful results from inspection
- The cost of TLS inspection is high
- There are few effective AWS managed rule groups for inbound traffic from the internet
- Other services such as AWS WAF and AWS Shield Advanced are often considered sufficient
- ALB serves as an L3/L4 proxy layer
- Aggregating inbound traffic inspection requires separating the VPCs and AWS accounts for internet-facing resources and target resources, increasing management overhead
- When AWS accounts are separated for aggregated inspection, there are hurdles in dynamically tracking IP addresses cross-account
- Aggregating traffic logs can be partially substituted with VPC Flow Logs, ALB access logs, and WAF logs
- When inspecting behind ALB, if CIDR ranges are not properly managed, source IP addresses may be included in HOME_NET, leading to insufficient detection
- Bypass paths exist when using CloudFront VPC Origins, Global Accelerator, or similar services
1. Inbound Traffic from the Internet Is Often Encrypted, Making It Difficult to Obtain Meaningful Inspection Results
The number one reason is probably that inbound traffic from the internet is often encrypted, making it difficult to obtain meaningful results from inspection.
Most inbound traffic that is broadly exposed to the internet is primarily HTTPS. For SSH and RDP connections, you would tightly restrict the source IP address using security groups.
In that case, the role of Network Firewall becomes to detect and defend based on factors other than source IP address, destination port, security groups, and NACLs.
However, if the externally published inbound traffic from the internet is encrypted—such as HTTPS—then inspection can only be performed on the unencrypted portions.
This means that even if Network Firewall is introduced, it cannot do much more than security groups.
2. The Cost of TLS Inspection Is High
So the natural question is: why not just enable TLS inspection? But the cost of TLS inspection is a concern.
The Network Firewall pricing is as follows:
| Resource Type | Price |
|---|---|
| Network Firewall Endpoint | USD 0.395/hour |
| Network Firewall Secondary Endpoint | USD 0.158/hour |
| Network Firewall Traffic Processing | USD 0.065/GB |
| Network Firewall Advanced Inspection Endpoint | USD 1.095/hour |
| Network Firewall Advanced Inspection Traffic Processing | USD 0.00/GB |
| Network Firewall Advanced Threat Protection Traffic Processing | USD 0.005/GB |
Excerpt: AWS Network Firewall Pricing – Network Security Service – Amazon Web Services Tokyo Region
When performing TLS inspection, charges for the Network Firewall Advanced Inspection Endpoint are incurred in addition to the standard Network Firewall Endpoint charges.
Comparing the monthly fixed cost (excluding traffic processing) with and without the Network Firewall Advanced Inspection Endpoint:
| With/Without Network Firewall Advanced Inspection Endpoint | Monthly Cost |
|---|---|
| Without | 0.395 USD/h × 2AZ × 730 h = 576.70 USD |
| With | 0.395 USD/h × 2AZ × 730 h + 1.095 USD/h × 2AZ × 730 h = 2,175.40 USD |
An approximately 2.7x increase in cost is quite a significant impact.
3. There Are Few Effective AWS Managed Rule Groups for Inbound Traffic from the Internet
Suppose TLS inspection is enabled and you can now inspect traffic that was encrypted with TLS, such as HTTPS, SMTPS, and POP3S. Suppose you also want to explore whether suspicious traffic can be detected from unencrypted portions of traffic such as HTTPS.
As mentioned earlier, the role of Network Firewall is to detect and defend based on factors other than source IP address, destination port, security groups, and NACLs.
Specifically, it controls traffic handling by examining various headers such as IP, TCP, and HTTP, as well as payload content.
It would be extremely difficult for operators to define rules from scratch to detect or block traffic considered a threat. In practice, operators will rely on the managed rule groups provided by AWS.
However, as of May 31, 2026, there are few effective AWS managed rule groups for inbound traffic from the internet.
There are three types of managed rule groups provided by Network Firewall:
- Active Threat Defense
- Domains and IP Addresses
- Threat Signatures
The threat categories detected by the first category, Active Threat Defense, are as follows:
| Indicator group and description | Traffic direction | Indicator types |
|---|---|---|
| Command and control Infrastructure that malicious actors use to remotely control compromised systems. |
Egress | IPs, domains |
| Malware staging Infrastructure that facilitates the distribution of malware and attack tooling. |
Ingress/Egress | URLs |
| Sinkholes Previously abused infrastructure used for malicious purposes. |
Egress | Domains |
| Out-of-band application security testing A technique where injected payloads make an outbound connection to external infrastructure that validates the existence of a vulnerability. |
Egress | IPs, domains |
| Crypto-mining pool Infrastructure used by crypto-miners. |
Egress | IPs, domains |
Excerpt: Understanding active threat defense managed rule group indicators - AWS Network Firewall
As you can see, the primary focus is on Egress = outbound traffic to the internet.
The second category, Domains and IP Addresses, also consists of rule groups that block requests to suspicious domains, such as block requests to a class of domains.. and block requests to domains that are known for hosting malware.
| Rule name | Description and label |
|---|---|
AbusedLegitMalwareDomainsStrictOrder,AbusedLegitMalwareDomainsActionOrder |
Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host malware. This can help reduce the risk of receiving malware or viruses originating from these sources with poor reputation. |
MalwareDomainsStrictOrder,MalwareDomainsActionOrder |
Rules that allow you to block requests to domains that are known for hosting malware. This can help reduce the risk of receiving malware or viruses originating from these known sources. |
AbusedLegitBotNetCommandAndControlDomainsStrictOrder,AbusedLegitBotNetCommandAndControlDomainsActionOrder |
Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host botnets. This can help reduce the risk of resources accessing botnets originating from these sources with poor reputation. |
BotNetCommandAndControlDomainsStrictOrder,BotNetCommandAndControlDomainsActionOrder |
Rules that allow you to block requests to domains that are known for hosting botnets. This can help reduce the risk of resources accessing botnets originating from these known sources. |
Excerpt: AWS domain and IP managed rule groups for AWS Network Firewall - AWS Network Firewall
The third category, Threat Signatures, had a total of 22,888 rules across rule groups as of May 31, 2026.
Breaking down the rules by traffic direction:
| Category | Definition | Count |
|---|---|---|
| A | $EXTERNAL_NET or any → $HOME_NET + flow:to_server (request from external to internal) |
764 |
| B | $EXTERNAL_NET or any → $HOME_NET + flow:established only |
25 |
| C | $EXTERNAL_NET or any → $HOME_NET + no flow specification |
67 |
| D | $EXTERNAL_NET or any → $HOME_NET + flow:to_client (response from external to internal) |
3,881 |
| E | <> (bidirectional) |
0 |
| F | any → any |
28 |
| G | $HOME_NET → $EXTERNAL_NET or any + flow:to_server (request from internal to external) |
14,964 |
| K | $HOME_NET → $EXTERNAL_NET or any + flow:to_client (response to inbound request) |
23 |
| L | $HOME_NET → $EXTERNAL_NET or any + no flow specification / established (other Egress-related) |
3,045 |
| I | $EXTERNAL_NET → any + flow:to_server (externally originated, wildcard destination, request) |
69 |
| J | $EXTERNAL_NET → any + flow:to_client (externally originated, wildcard destination, response) |
3 |
| H | Other ($HOME_NET → $HOME_NET 13 rules, $HOME_NET → other 4 rules, $EXTERNAL_NET → $EXTERNAL_NET 2 rules) |
19 |
| Total | 22,888 |
Of these, the categories that include rules for inspecting inbound traffic from the internet are A, B, C, F, I, and K.
Further classifying B, C, and F by message content since they have no explicit direction specification:
| Category | Total | Inbound Detection | Client Protection | Post-compromise | Lateral Movement | Scan Detection | IoT |
|---|---|---|---|---|---|---|---|
B (flow:established only) |
25 | 8 | 17 | 0 | 0 | 0 | 0 |
C (no flow specification) |
67 | 29 | 7 | 21 | 0 | 4 | 6 |
F (any → any) |
28 | 7 | 0 | 5 | 14 | 0 | 2 |
| Total | 120 | 44 | 24 | 26 | 14 | 4 | 8 |
Summing these up, there are 900 rules that inspect inbound traffic from the internet.
As a proportion of matching rules, this is only about 4% of the total. The absolute number is inevitably small.
The rule information at the time of writing is also stored in the following GitHub repository:
I also believe that among the managed rule groups available for subscription from AWS Marketplace, not many cover inbound traffic from the internet.
At a glance, it seems like perhaps only Network Scanners Protection for Network Firewall by ThreatSTOP fits.
A small number of managed rule groups does not necessarily mean Network Firewall cannot detect threats sufficiently, but introducing Network Firewall solely for inbound internet traffic seems to have poor overall cost-performance.
4. Other Services Such as AWS WAF and AWS Shield Advanced Are Often Considered Sufficient
What if the traffic externally published to the internet is HTTP or HTTPS?
For these, AWS WAF and AWS Shield Advanced provide L7 control. In other words, inspection at the HTTP header and request body level is possible.
Furthermore, for HTTPS, if you associate it with an ALB or CloudFront that terminates TLS rather than passing it through like NLB, no additional charges like TLS inspection are required.
As mentioned earlier, the absolute number of rules in AWS managed rule groups that operate against inbound traffic from the internet is small. Combined with the high cost, it seems unlikely that anyone would introduce only Network Firewall without AWS WAF.
For these reasons, in the case of HTTP or HTTPS, other services such as AWS WAF and AWS Shield Advanced are often considered sufficient.
Also, when products such as Trend Micro's TrendAI Vision One Endpoint Security are deployed on individual targets as anti-malware requirements, the host-based IPS/IDS functionality is sometimes included in those products.
A network-based IPS/IDS makes sense for preventing access to arbitrary resources such as lateral movement. However, when dealing with inbound traffic from the internet and the target is identifiable, the host-based IPS/IDS deployed on that target may be sufficient.
5. ALB Serves as an L3/L4 Proxy Layer
Network Firewall also operates at L3 and L4. This means it can cover layers that AWS WAF cannot handle.
On the other hand, ALB terminates TCP connections once. Thanks to this, ALB handles L3 and L4 threats such as SYN flood and UDP reflection attacks.
For web applications, you can use Application Load Balancer to route traffic based on content and accept only well-formed web requests. Application Load Balancer blocks many common attacks, such as SYN flood DDoS attacks and UDP reflection attacks, protecting your applications. When these types of attacks are detected, Application Load Balancer automatically scales to absorb additional traffic. Scaling activity due to infrastructure layer attacks is transparent to customers and does not affect billing.
Elastic Load Balancing (BP6) - AWS Best Practices for DDoS Resiliency
Therefore, if Network Firewall inspection is placed behind ALB, ALB can be said to have already filtered out a certain amount of suspicious packets.
6. Aggregating Inbound Traffic Inspection Requires Separating VPCs and AWS Accounts for Internet-Facing and Target Resources, Increasing Management Overhead
When there are many systems receiving inbound traffic from the internet, placing a Network Firewall in each system would be required.
This not only incurs the cost of Network Firewall itself, but also very high operational and maintenance costs for rule management and similar tasks.
As a solution, an approach is taken to aggregate and inspect inbound traffic from the internet as follows:
You cannot receive traffic destined for a public IP address associated with resources in one VPC from a different VPC.
Therefore, for aggregation purposes, the VPCs and AWS accounts of internet-facing resources and target resources must be separated.
As a result, a large number of ALBs and NLBs for each application end up being created in the Ingress VPC. This increases the difficulty of operational mistakes, cost allocation, and permission management.
7. When aggregating and inspecting inbound traffic from the internet while separating the AWS accounts of internet-facing resources and target resources, there are hurdles with cross-account dynamic IP address tracking
Currently, it is not possible to specify instance IDs or Auto Scaling Groups in a different VPC from ALB or NLB in target groups, nor to specify cross-account target groups in ALB or NLB.
If you have instances in a VPC that is peered with the load balancer VPC (same Region or different Region), you cannot register these instances by instance ID. You can register these instances by IP address.
Target groups for your Application Load Balancers - Elastic Load Balancing
If you register targets by instance ID, the instances must be in the same VPC as the Network Load Balancer. If you have instances in a VPC that is peered with the load balancer VPC (same Region or different Region), you cannot register these instances by instance ID. You can register these instances by IP address.
Register targets with your target group - Elastic Load Balancing
To associate an Application Load Balancer as a target of a Network Load Balancer, the load balancers must be in the same VPC within the same account.
Use an Application Load Balancer as a target of a Network Load Balancer - Elastic Load Balancing
Therefore, there are hurdles to adopting mechanisms where resources change dynamically, such as Auto Scaling targets or using ECS Fargate.
It is not entirely impossible, but it requires additionally preparing an NLB or using subnet sharing. The configuration becomes more complex, and in the former case, additional costs are also incurred.
Excerpt from: Expose Amazon EKS pods through cross-account load balancer | Containers
8. Because aggregation of communication logs can be partially substituted by VPC Flow Logs, ALB access logs, and WAF logs
In some cases, the purpose of aggregating inbound traffic from the internet may also include aggregating communication logs.
However, VPC Flow Logs, ALB access logs, and AWS WAF logs may partially substitute for this. These logs can be sent cross-account to an S3 bucket.
In that case, the value would lie in content that can only be confirmed through logs output by Network Firewall, but there is not much difference.
9. When inspecting traffic behind the ALB, if CIDR ranges are not properly organized, the source IP address may be included in HOME_NET, preventing sufficient detection
When ALB routes traffic to targets, the source IP address of that traffic becomes the private IP address of the ALB.
Therefore, in configurations where Network Firewall is placed behind the ALB, careful attention must be paid to IP address-based controls.
Rules within managed rule groups almost always use a variable called HOME_NET, which defines the network of the resource being protected. As a result, if the IP address range to which the ALB belongs is included in HOME_NET, most rules will be excluded from evaluation even if managed rules are defined.
If the CIDR of the Ingress VPC cannot be cleanly separated from the CIDR of the target VPC, the definition of HOME_NET becomes complex.
The HOME_NET definition is per AWS Network Firewall, not per rule group. Therefore, if CIDRs are not properly allocated, there is a possibility that sufficient detection cannot be achieved.
10. Because there are bypass routes when using CloudFront VPC Origins, Global Accelerator, and similar services
Assuming that inbound traffic from the internet is aggregated and inspected in a configuration where Network Firewall is placed in front of internet-facing resources (Pattern 1), the existence of bypass routes is also a concern.
Specifically, this applies when using CloudFront VPC Origins or Global Accelerator. In these cases, inbound traffic from the internet does not pass through the IGW.
- Internet gateway – You must add an internet gateway to the VPC that contains the VPC origin resource. The internet gateway is required to indicate that the VPC can receive traffic from the internet. You don't need to update your routing policy because the internet gateway is not used to route traffic to the origin in the subnet.
- A private subnet with at least one available IPv4 address – CloudFront routes to the subnet using a service-managed Elastic Network Interface (ENI) that CloudFront creates in the subnet after you define the private origin CloudFront resource. For the ENI creation process to succeed, the private subnet must have at least one available IPv4 address. The IPv4 address can be private. No additional charges apply. IPv6-only subnets are not supported.
When you add a Network Load Balancer, internal Application Load Balancer, or Amazon EC2 instance endpoint to AWS Global Accelerator, you can target them in private subnets and send internet traffic directly to and from the endpoint in your virtual private cloud (VPC). The VPC that contains the load balancer or EC2 instance must have an internet gateway attached to indicate that the VPC accepts internet traffic. However, the load balancer or EC2 instance does not need a public IP address. And there's no internet gateway route required associated with the subnet.
This is different from the typical internet gateway use case where both a public IP address and an internet gateway route are required to send internet traffic to an instance or load balancer in a VPC. Even if the target elastic network interface resides in a public subnet (a subnet with an internet gateway route), when you use Global Accelerator for internet traffic, Global Accelerator overrides the typical internet route, and all logical connections arriving via Global Accelerator also return via Global Accelerator, not through the internet gateway.
Secure VPC connections in AWS Global Accelerator - AWS Global Accelerator
The routing of inbound traffic from the internet to Network Firewall is handled by the IGW's route table. Therefore, if traffic does not pass through the IGW, it will not be routed to Network Firewall. Even when trying to aggregate traffic, care must be taken to handle these exceptions.
Motivations for inspecting inbound traffic from the internet with Network Firewall
So what are the motivations for inspecting inbound traffic from the internet with Network Firewall?
Summarizing the content discussed so far, the following motivations can be considered:
- When exposing TLS protocols other than HTTP/HTTPS externally
- When exposing TCP/UDP services externally via NLB
- When finding value in the rules within threat signature managed rule groups that correspond to inbound traffic from the internet
- When compliance or audit requirements explicitly mandate a "network-based IDS/IPS"
If none of these apply, you may not need to actively introduce Network Firewall specifically for inspecting inbound traffic from the internet.
Regarding "3. When finding value in the rules within threat signature managed rule groups that correspond to inbound traffic from the internet," the number of rules broken down by protocol is as follows:
| Protocol | Count |
|---|---|
| http | 570 |
| tcp | 148 |
| smtp | 36 |
| udp | 22 |
| http1 | 11 |
| tls | 10 |
| smb | 3 |
| ftp | 2 |
| dcerpc | 2 |
| icmp | 1 |
| tcp-pkt | 1 |
| icmpv6 | 1 |
| ike | 1 |
If only HTTPS is exposed externally and TLS inspection is not enabled, only about 10 rules can detect threats. The specific rules are as follows:
| SID | Group | Category | proto | dst port | msg |
|---|---|---|---|---|---|
| 2861650 | Exploits | A | tls | any | Microsoft Windows Web Threat Defense (WTD.sys) Unauthenticated Denial of Service (CVE-2025-29971) M1 |
| 2861651 | Exploits | A | tls | any | Microsoft Windows Web Threat Defense (WTD.sys) Unauthenticated Denial of Service (CVE-2025-29971) M2 |
| 2809192 | Exploits | B | tls | any | SChannel Possible Heap Overflow DSAWithSHA1 CVE-2014-6321 |
| 2809193 | Exploits | B | tls | any | SChannel Possible Heap Overflow DSAWithSHA224 CVE-2014-6321 |
| 2809194 | Exploits | B | tls | any | SChannel Possible Heap Overflow DSAWithSHA256 CVE-2014-6321 |
| 2809195 | Exploits | B | tls | any | SChannel Possible Heap Overflow ECDSAWithSHA1 CVE-2014-6321 |
| 2809196 | Exploits | B | tls | any | SChannel Possible Heap Overflow ECDSAWithSHA224 CVE-2014-6321 |
| 2809197 | Exploits | B | tls | any | SChannel Possible Heap Overflow ECDSAWithSHA256 CVE-2014-6321 |
| 2809198 | Exploits | B | tls | any | SChannel Possible Heap Overflow ECDSAWithSHA384 CVE-2014-6321 |
| 2809199 | Exploits | B | tls | any | SChannel Possible Heap Overflow ECDSAWithSHA512 CVE-2014-6321 |
All of these are rules related to vulnerabilities in Microsoft Windows products.
There are about 148 rules with TCP protocol, but most of them do not operate over HTTPS, or they reference URL paths, so very few are applicable.
The rules meeting all of the following criteria:
- Protocol is TCP
- Destination port is any or 443
- The inspected protocol is HTTPS (non-HTTPS protocols such as SMB / DCE/RPC / TDS / DNS / proprietary RAT C2 are excluded)
- Capable of detection even without TLS inspection enabled
- Rules do not include conditions that inspect URL paths or HTTP body content
- Rules that act directly on the TCP layer
- Higher-layer protocols running over TCP such as Java serialization / S/MIME / HTML ActiveX, etc. are excluded because they are encrypted when delivered over HTTPS, making the match target invisible
- Category is one of the following:
- A
- B
- C
- F
- I
- K
※ For B, C, and F, only those that detect inbound traffic from the internet are included
Only the following single rule matched:
| SID | Group | Category | proto | dst port | msg |
|---|---|---|---|---|---|
| 2823966 | DoS | A | tcp | any | CVE-2016-8610 |
In other words, in a configuration where Network Firewall is placed in front of internet-facing resources as in Pattern 1, without enabling TLS inspection, only 11 rules would be operational in this scenario.
For reference, the number of rules by category for each AWS managed rule group is as follows:
| Group | Total | A | B | C | D | E | F | G | K | L | I | J | H |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Botnet | 3,484 | 3 | 0 | 20 | 1,631 | 0 | 2 | 1,194 | 1 | 630 | 1 | 1 | 1 |
| BotnetWeb | 2,420 | 0 | 0 | 0 | 96 | 0 | 0 | 2,320 | 1 | 1 | 0 | 0 | 2 |
| BotnetWindows | 3,289 | 39 | 0 | 0 | 485 | 0 | 0 | 2,755 | 3 | 2 | 3 | 1 | 1 |
| DoS | 24 | 9 | 0 | 6 | 1 | 0 | 1 | 1 | 0 | 5 | 0 | 0 | 1 |
| EmergingEvents | 56 | 0 | 0 | 0 | 11 | 0 | 16 | 18 | 0 | 11 | 0 | 0 | 0 |
| Exploits | 635 | 331 | 8 | 28 | 142 | 0 | 7 | 91 | 4 | 9 | 3 | 0 | 12 |
| FUP | 13 | 0 | 0 | 0 | 1 | 0 | 0 | 11 | 0 | 1 | 0 | 0 | 0 |
| IOC | 299 | 0 | 0 | 0 | 238 | 0 | 0 | 40 | 1 | 20 | 0 | 0 | 0 |
| MalwareCoinmining | 24 | 0 | 0 | 0 | 6 | 0 | 0 | 16 | 0 | 2 | 0 | 0 | 0 |
| MalwareMobile | 3,172 | 0 | 0 | 0 | 6 | 0 | 0 | 2,673 | 0 | 493 | 0 | 0 | 0 |
| Malware | 877 | 7 | 0 | 0 | 141 | 0 | 1 | 433 | 2 | 293 | 0 | 0 | 0 |
| MalwareWeb | 3,289 | 39 | 0 | 0 | 485 | 0 | 0 | 2,755 | 3 | 2 | 3 | 1 | 1 |
| Phishing | 4,152 | 1 | 17 | 4 | 156 | 0 | 0 | 2,421 | 0 | 1,553 | 0 | 0 | 0 |
| Scanners | 67 | 1 | 0 | 5 | 0 | 0 | 0 | 1 | 0 | 1 | 59 | 0 | 0 |
| Suspect | 178 | 0 | 0 | 1 | 1 | 0 | 0 | 173 | 0 | 3 | 0 | 0 | 0 |
| WebAttacks | 909 | 334 | 0 | 3 | 481 | 0 | 1 | 62 | 8 | 19 | 0 | 0 | 1 |
| TOTAL | 22,888 | 764 | 25 | 67 | 3,881 | 0 | 28 | 14,964 | 23 | 3,045 | 69 | 3 | 19 |
When inspecting inbound traffic from the internet with Network Firewall, it is advisable to use these figures as a basis for selecting managed rule groups.
Evaluate what threats you want to address, what gaps exist in your current security measures, and whether the implementation and running costs are justified before introducing it
I have considered the points to keep in mind when aggregating and inspecting inbound traffic from the internet using AWS Network Firewall.
Evaluate what threats you want to address, what gaps exist in your current security measures, and whether the implementation and running costs are justified, then decide whether to introduce it.
I hope this article is helpful to someone.
This has beennonPi (@non____97) from the Cloud Business Division, Consulting Department at Classmethod!
