Here is my thinking on considerations when using AWS Network Firewall to aggregate and inspect inbound traffic from the internet
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 non-Pi (@non____97).
Have you ever wondered what configurations are available and what considerations exist when aggregating 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 to be a fairly common configuration.
But what about inbound traffic? I feel there are fewer examples compared to outbound traffic.
Let me think about why there are fewer examples and what configurations are possible.
Summary upfront
- 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
- Much of the externally exposed traffic is encrypted, limiting the inspection scope without TLS inspection
- Enabling the Advanced Inspection Endpoint for TLS inspection increases the fixed monthly cost 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 rules / 22,888 rules)
- HTTP/HTTPS threats can be addressed by AWS WAF and AWS Shield Advanced as alternatives
- ALB absorbs SYN floods and UDP reflection attacks by acting as a TCP termination point
- Aggregation requires separating VPCs and AWS accounts, increasing management overhead
- There are hurdles with cross-account dynamic IP address tracking
- Communication logs can be partially substituted with VPC Flow Logs / ALB access logs / WAF logs
- HOME_NET definitions become complex and prone to detection gaps
- CloudFront VPC Origins and Global Accelerator can become bypass routes
- Mainly due to the following reasons
- Cases where inspecting inbound traffic with Network Firewall is still motivated
- Externally exposing TLS protocols other than HTTP/HTTPS (SMTPS / IMAPS / LDAPS, etc.)
- Externally exposing TCP/UDP services via NLB
- Finding value in inbound rules within threat signature managed rule groups
- Compliance or audit requirements explicitly mandating a network-based IDS/IPS
- Evaluate what threats you want to address, what gaps your existing controls leave, and whether the cost is justified before deciding to adopt it
Overview of configurations
The possible configurations fall broadly into 2 patterns.
- Place Network Firewall upstream of internet-facing resources
- Place Network Firewall downstream of internet-facing resources
Each is explained below.
1. Place Network Firewall upstream of internet-facing resources
This is an approach like IGW → Network Firewall → ALB, where Network Firewall is placed upstream of internet-facing resources.
Illustrated as follows:
In the case of Cloud WAN, Transit Gateway is simply replaced and nothing else changes.
This is also introduced in AWS Blogs as shown below.
Excerpt: AWS Network Firewall deployment models | Amazon Web Services Blog
Excerpt: AWS Network Firewall deployment models | Amazon Web Services Blog
Excerpt: Design your firewall deployment for internet ingress traffic flows | Amazon Web Services Blog
Normally it is not possible to inspect the content of TLS-encrypted communications, but by enabling TLS inspection it is also possible to inspect encrypted portions.
2. Place Network Firewall downstream of internet-facing resources
This is an approach like IGW → ALB → Network Firewall → Target, where Network Firewall is placed downstream of internet-facing resources.
Illustrated as follows:
In the case of Cloud WAN as well, Transit Gateway is simply replaced and nothing else changes.
This is also introduced in AWS Blogs as shown below.
Excerpt: AWS Network Firewall deployment models | Amazon Web Services Blog
Excerpt: Design your firewall deployment for internet ingress traffic flows | Amazon Web Services Blog
In this pattern, if an internet-facing resource such as an ALB terminates TLS, then TLS inspection is not required.
On the other hand, the source IP address visible to Network Firewall becomes the IP address of internet-facing resources such as the ALB.
Summary of Pros/Cons for each configuration
Let me organize the Pros/Cons for each configuration.
To state my conclusion upfront, I prefer 2. Place Network Firewall downstream of internet-facing resources.
The Pros/Cons are organized 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 the contents of HTTPS | ○ Since ALB terminates TLS, plain HTTP can be inspected directly without TLS inspection |
| Client IP visibility | ○ The client's IP address can be confirmed as-is | The client IP address visible to Network Firewall becomes the ALB's private IP address, and the true client IP address can only be confirmed via the X-Forwarded-For header |
| Network Firewall processing volume | All inbound traffic passes through and is evaluated by Network Firewall, including DDoS and scan attempts, increasing charges for Network Firewall processing volume | ○ Only traffic that passes through ALB and AWS WAF without being dropped reaches Network Firewall |
| Reuse of Network Firewall for East-West / Egress | Separate procurement is required (not a concern if you explicitly want to separate from other Network Firewalls) | ○ The same Network Firewall can be easily reused. Since both the ALB → Target path and East-West / Egress paths go through TGW to the same Inspection VPC, firewall endpoint hourly charges can be reduced |
Analysis of why inbound traffic from the internet is rarely inspected with Network Firewall
First, let me consider why inbound traffic from the internet is rarely inspected with Network Firewall.
I believe the reasons are as follows:
- 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 countermeasures
- ALB handles the L3/L4 proxy layer
- When aggregating and inspecting inbound traffic from the internet, VPCs and AWS accounts for internet-facing resources and target resources must be separated, increasing management overhead
- When AWS accounts for internet-facing resources and target resources are separated for aggregated inspection of inbound traffic, there are hurdles with cross-account dynamic IP address tracking
- Communication log aggregation can be partially substituted with VPC Flow Logs, ALB access logs, and WAF logs
- When inspecting downstream of ALB, if CIDRs are not properly organized, source IP addresses may be included in HOME_NET, resulting in insufficient detection
- There are bypass routes when using CloudFront VPC Origins or Global Accelerator
1. Inbound traffic from the internet is often encrypted, making it difficult to obtain meaningful results from inspection
Perhaps the biggest reason is that inbound traffic from the internet is often encrypted, making it difficult to obtain meaningful results from inspection.
The primary inbound traffic broadly exposed to the internet is likely HTTPS. SSH and RDP connections should have their source IP addresses properly restricted via security groups.
In that case, the role of Network Firewall becomes detecting and defending based on elements other than source IP address, destination port, security groups, and NACLs.
However, if inbound traffic from the internet consists of encrypted communications such as HTTPS, inspection can only be performed on unencrypted elements.
This means that even if Network Firewall is introduced, it cannot do much more than a security group.
2. The cost of TLS inspection is high
So you might ask why not just enable TLS inspection — but the cost of TLS inspection is a concern.
The pricing for Network Firewall 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, the Network Firewall Advanced Inspection Endpoint charge applies in addition to the regular Network Firewall Endpoint charge.
Comparing the fixed monthly costs excluding traffic processing charges, with and without the Network Firewall Advanced Inspection Endpoint:
| 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 additional cost of approximately 2.7x 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, making it possible to inspect traffic that was encrypted with TLS, such as HTTPS, SMTPS, and POP3S. Suppose we also want to explore whether suspicious communications can be detected from unencrypted parts of traffic such as HTTPS.
As mentioned earlier, the role of Network Firewall involves detecting and defending based on elements other than source IP address, destination port, security groups, and NACLs.
Specifically, it controls traffic handling by examining various headers such as IP, TCP, HTTP, and payload content.
Defining rules from scratch to detect or defend against communications deemed threats would be extremely challenging for operators. In practice, the managed rule groups provided by AWS would typically be adopted.
However, as of May 31, 2026, the managed rule groups provided by AWS have few that are effective for inbound traffic from the internet.
The managed rule groups provided by Network Firewall fall into 3 categories:
- 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 basically on Egress = outbound traffic to the internet.
The second category, domains and IP addresses, also consists of rule groups for blocking 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 all rule groups as of May 31, 2026.
Breaking down by traffic direction, the rule counts are as follows:
| 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) |
3,045 |
| I | $EXTERNAL_NET → any + flow:to_server (external origin, wildcard destination, request) |
69 |
| J | $EXTERNAL_NET → any + flow:to_client (external origin, 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 their messages since no traffic direction is specified gives the following breakdown:
| 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 |
Organizing all of this, the rules that inspect inbound traffic from the internet total 900 rules.
As a proportion of all rules, that is about 4%. The absolute number is unavoidably small.
The rule information at the time of writing is also stored in the following GitHub repository.
I also believe that among managed rule groups subscribable from AWS Marketplace, there are not that many that cover inbound traffic from the internet.
At a glance, it looks like perhaps Network Scanners Protection for Network Firewall by ThreatSTOP might be one.
A small number of managed rule groups does not necessarily mean Network Firewall cannot provide sufficient detection, but introducing Network Firewall solely for inbound traffic from the internet seems to have poor overall cost-performance.
4. Other services such as AWS WAF and AWS Shield Advanced are often considered sufficient countermeasures
What about cases where externally exposed traffic to the internet is HTTP or HTTPS?
For these, AWS WAF and AWS Shield Advanced provide L7 controls. In other words, inspection based on HTTP headers and request bodies is possible.
Furthermore, for HTTPS, if you associate it with ALB or CloudFront — which terminate TLS rather than passing it through like NLB — no additional charges like TLS inspection are required.
As introduced earlier, the absolute number of rules in AWS-provided managed rule groups that operate against inbound traffic from the internet is small. Given that costs are also high, it is hard to imagine a scenario where Network Firewall alone is introduced without AWS WAF.
For this reason, in the case of HTTP or HTTPS, other services such as AWS WAF and AWS Shield Advanced are often considered sufficient countermeasures.
Also, when deploying products such as Trend Micro's TrendAI Vision One Endpoint Security as an anti-malware requirement for individual targets, these products may already include host-based IPS/IDS functionality.
A network-based IPS/IDS may be a good option from the perspective of preventing access to arbitrary resources such as lateral movement. However, for inbound traffic from the internet where the target is identifiable, the host-based IPS/IDS deployed on that target may be sufficient.
5. ALB handles the 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 communications. Thanks to this, ALB handles L3 and L4 issues such as SYN floods and UDP reflection attacks.
For web applications, you can use an Application Load Balancer to route traffic based on content and to 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 application from attack. Application Load Balancer automatically scales to absorb additional traffic when these types of attacks are detected. Scaling activity due to infrastructure layer attacks is transparent to AWS customers and does not affect billing.
Elastic Load Balancing (BP6) - AWS Best Practices for DDoS Resiliency
Therefore, if Network Firewall is inspecting traffic downstream of ALB, ALB can be said to already be filtering out some suspicious packets.
6. When aggregating and inspecting inbound traffic from the internet, VPCs and AWS accounts for internet-facing resources and target resources must be separated, increasing management overhead
When there are many systems receiving inbound traffic from the internet, Network Firewall would need to be deployed for each system.
This incurs not only the cost of Network Firewall itself, but also very high operational and maintenance costs for rule management and so on.
As a countermeasure, an approach is taken where inbound traffic from the internet is aggregated and inspected as shown below.
It is not possible to accept access to a public IP address associated with a VPC resource from a different VPC.
Therefore, due to the aggregation requirement, the VPCs and AWS accounts for 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, and separating AWS accounts for internet-facing resources and target resources, there are hurdles with dynamic IP address tracking across accounts
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 those instances by instance ID. You can register those 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 those instances by instance ID. You can register those instances by IP address.
Register targets with your Network Load Balancer - 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 using Auto Scaling for targets or adopting ECS Fargate.
It's not completely impossible, but it requires additionally preparing an NLB or using subnet sharing. The configuration becomes more complex, and the former also incurs additional costs.
Excerpt: Expose Amazon EKS pods through cross-account load balancer | Containers
8. Since aggregation of communication logs can be partially substituted by VPC Flow Logs, ALB access logs, and WAF logs
There may be cases where the purpose of aggregating inbound traffic from the internet also includes aggregating communication logs.
However, VPC Flow Logs, ALB access logs, and AWS WAF logs may serve as partial substitutes. These logs can be sent to S3 buckets across accounts.
In that case, the value lies in what can only be confirmed through logs output by Network Firewall, but there is little difference.
9. When inspecting traffic downstream of ALB, if CIDR allocation is not properly managed, 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, when placing Network Firewall downstream of ALB, care must be taken with IP address-based controls.
Rules within managed rule groups almost always use a variable called HOME_NET, which defines the network of the protected target. As a result, if the IP address range to which the ALB belongs is included in HOME_NET, even if managed rules are defined, most of them will fall outside the scope of rule evaluation.
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 definition of HOME_NET 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
If inbound traffic from the internet is being aggregated and inspected using a configuration where Network Firewall is placed in front of internet-facing resources as in Pattern 1, bypass routes are 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 has 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.
- 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 CloudFront after you define the CloudFront resource for the private origin. To successfully complete the ENI creation process, the private subnet must have at least one available IPv4 address. The IPv4 address can be private. There is no additional charge. 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 it in a private subnet and send internet traffic directly to and from your endpoint in a virtual private cloud (VPC). The VPC that contains your load balancer or EC2 instance must have an internet gateway attached to indicate that the VPC accepts internet traffic. However, a public IP address isn't required for the load balancer or EC2 instance, and an internet gateway route associated with the subnet isn't required.
This differs 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's elastic network interface exists in a public subnet (a subnet with an internet gateway route), when using Global Accelerator for internet traffic, Global Accelerator overrides the typical internet route, and all logical connections arriving via Global Accelerator are also returned via Global Accelerator rather than 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 route table. Therefore, if traffic does not pass through the IGW, it will not be routed to Network Firewall. Despite the effort to aggregate traffic, care for exceptions becomes necessary.
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 so far, the following can be considered:
- When exposing TLS protocols other than HTTP/HTTPS externally
- When exposing TCP/UDP services externally via NLB
- When finding value in inbound rules of threat signature managed rule groups
- When compliance or audit requirements explicitly call for a "network-based IDS/IPS"
If none of these apply, you may not need to proactively introduce Network Firewall for the purpose of inspecting inbound traffic from the internet.
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 |
Furthermore, the rules within each managed rule group that apply to inbound traffic from the internet are as follows:
| Rule Group | A | B (inbound traffic detection) | C (inbound traffic detection) | F (inbound traffic detection) | I | K | Contribution Total | Cumulative Rate | Group Total Rules |
|---|---|---|---|---|---|---|---|---|---|
| Exploits | 331 | 8 | 21 | 4 | 3 | 4 | 371 | 43.4% | 635 |
| WebAttacks | 334 | 0 | 1 | 1 | 0 | 8 | 344 | 83.6% | 909 |
| Scanners | 1 | 0 | 2 | 0 | 59 | 0 | 62 | 90.8% | 67 |
| BotnetWindows (=MalwareWeb identical) | 39 | 0 | 0 | 0 | 3 | 3 | 45 | 96.1% | 3,289 |
| DoS | 9 | 0 | 5 | 1 | 0 | 0 | 15 | 97.9% | 24 |
| Malware | 7 | 0 | 0 | 1 | 0 | 2 | 10 | 99.1% | 877 |
| Botnet | 3 | 0 | 0 | 0 | 1 | 1 | 5 | 99.6% | 3,484 |
| BotnetWeb | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 99.8% | 2,420 |
| IOC | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 99.9% | 299 |
| Phishing | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 100.0% | 4,152 |
When inspecting inbound traffic from the internet with Network Firewall, it is advisable to select managed rule groups based on the above.
Evaluate what threats you want to address, what gaps exist in your current measures, and whether the implementation and running costs are justified before introducing it
We have considered the points to take into account 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 measures, and whether the implementation and running costs are justified, then make the decision to introduce it.
I hope this article is helpful to someone.
This has beennonPi (@non____97) from the Cloud Business Division, Consulting Department!
