Guidence on protecting privatelink endpoint service
We have a need to create a PrivateLink endpoint service in our London VPC to provide access to our platform for customers who also reside in AWS. The endpoint will be configured to require acceptance, ensuring only known parties are able to connect. We will put an NLB into each AZ within the region to handle the traffic flowing from the PrivateLink endpoint. In this case, we’d expect to protect the NLB with a security group that only permits the private IPs of the endpoint in the incoming rule set. Our Cyber team has asked us to look at AWS Firewall to add a layer of protection to this set-up and I am trying to understand how this would work and what additional protection it could provide.
- Language
- English
- Newest
- Most votes
- Most comments
Is this traffic TLS? If yes, whats the value addition by adding firewalls in this traffic flow? It sounds like you are already implementing some security controls such as NLB security groups, permissions and acceptance settings which help you control which service consumers (AWS principals) can access your endpoint service. Additionally you could consider using endpoint policies.
Hello,
just to better understand the requirement, what is the concern of your Cyber team with your current constellation?
Nevertheless, in your PrivateLink setup, AWS Network Firewall would typically be deployed between the VPC service endpoint’s Network Load Balancer (NLB) and your application.
Customer VPC -> PrivateLink VPC Endpoint -> Your VPC -> NLB -> Network Firewall -> Your Application
The Firewall would inspect traffic after it exits the NLB. The benefits of having either AWS Network Firewall or some 3rd party NGFW vendor solution in the communication chain, would give you possibility of:
- Deep Packet Inspection (DPI)
- To inspect application-layer protocols (TLS, HTTP/HTTPS, etc...)
- Detect and block malicious payloads
- Intrusion Prevention
- Signature-based threat detection using Suricata-compatible (for AWS Network Firewall) rules. Or any other 3rd party vendor threat detection engine (eg. heuristic) with their own compatible rules/rule-sets.
- Protection against known vulnerabilities and exploits
- Custom rule creation for your specific use cases and expected traffic patterns
- Stateful Group Rules
- Domain-based filtering (block requests to specific domains)
- Protocol-specific rules (e.g., HTTP header inspection)
- 5-tuple rules, which gives you more granular control than security groups
- Better Logging and Visibiity
- With the DPI you get a better traffic flow visibility
- Better forensic capabilities in case of security incidents
As a final thought here, for a PrivateLink endpoint handling customer traffic, AWS Network Firewall is particularly valuable in cases where:
- You're dealing with external parties (even if approved)
- You need audit trails for compliance purposes
- You want to detect and prevent application-layer attacks
- You need visibility into traffic patterns
Depending on the requirements and use-case, having just traffic encrypted (with TLS for example) is not always enough, because of the attacks happening through "covert channels" where TLS is actually hiding the malicious traffic within seemingly legitimate TLS traffic, potentially bypassing security measures. This is where services as AWS Network Firewall shine.
But as already mentioned, maybe it would be better to understand your Cyber team concerns and requirements, to avoid implementing something which won't bring a lot of value and will be over-engineered.
Best regards, Neven
Relevant content
- asked 2 years ago
- asked 9 months ago
