DirectConnect with Transit Gateway and best practices to inspect traffic
I am going to discuss pros/cons and best practices to use DirectConnect with Transit Gateway , DirectConnect Gateway and Network Firewall.
We will options to connect from on-premises to cloud and vice-versa:
- IPSEC tunnel over Internet i.e. ec2 instance in AWS VPC -> on-premises firewall.
→ Creating High available ec2 instances and route traffic when one of the ec2 instance terminates is bit challenging. Need to use lambdas/scripts to alter route table and redirect traffic to another ec2 instance ENI.
→ IPSEC bandwidth relies on IPSEC ec2 instance type. e.g. openswan/PAN/SRX etc.
→ Patch/maintain/manage IPSEC ec2 instances.
→ It uses internet; so connection reliability is not great. There can be packet losses/connection deterioration etc.
2. Create IPSEC tunnels over Directconnect:
→ Directconnect link provides reliability and IPSEC provides all traffic encryption.
→ IPSEC limitation of 1.25Gbps i.e. bandwidth per VPN tunnel.
→ Create rules/ACL’s in on-premises firewall to allow traffic; default is deny all.
→ Create at least 2 tunnels from AWS to on-premises — HA purposes
→ Whenever we create a new AWS account you need to create these IPSEC tunnels from each VPC and then it needs to be configured at on-premises firewall as well.
This solutions works OK for small scale setup and when bandwidth limitation is not an issue.
3. Use DirectConnect with Transit Gateway and DirectConnect Gateway:
→ This is better approach as it unlocked bandwidth limitation.
→ Transit Gateway can be created and shared with multiple accounts using Resource Access manager. You can use AWS Org-ID and share with all accounts at once.
→ Accounts need to change route table and use transit gateway attachment for particular routes/prefixes.
→ How can we block traffic from Cloud to on-premises and vice-versa with 100 G Directconnect ? If we add firewalls on-premises than inspecting that much of traffic will increase costs significantly.
You might need to rely on security groups and NACL’s (Network access control list) i.e. to allow traffic from on-premises to AWS and vice versa.
→ If you have 100 VPC’s then managing NACL’s per VPC is challenging and is also not scalable solution.
→ NACL can restrict/allow traffic based on IP address and not domain names.For one account you can probably create a lambda that perform IP resolution and then add results to NACL but there are limitations with this approach.
This approach is GOOD if you can put controls/ACL’s in place at traffic layer i.e. iptables or Firewall level i.e. destination side.
4. Use DirectConnect with Transit Gateway, DirectConnect Gateway and Network firewall:
If you want to inspect all traffic from VPC to on-premises and vice versa then it’s the best approach but the only major downside is pricing.
→ Similar to above scenario but we are adding Network Firewall i.e. centralised Firewall for all VPC’s. We can allow/deny traffic based on domain names.
→ Create and manage rules in Network firewall. It acts as layer 3–7 with Intrusion prevention, packet flow inspection.
→ It can also be used to filter/apply firewall policies to egress traffic as well i.e. to internet.
→ Major downside is pricing as AWS will charge for fixed prices and GB’s processed as well.
→ There are throughput limitations/prefix allowed at Transit Gateway/DirectConnect Gateway and Network firewall as well. In those cases, we need to replicate this setup for another set of VPC’s.
**With Transit Gateway and Network firewall setup you can restrict/inspect traffic for below use cases:-
→ VPC peering.
→ DirectConnect Traffic to on-premises.
→ NAT Gateway Traffic to external websites.
This Network Firewall can also be replaced with any other Firewall vendors such as Juniper/PAN’s etc. but these needs to be automatically scale up and down in case of traffic surge with Gateway Load Balancer.
Centralising egress traffic filtering for both Internet and internal make sense and you can also apply some automated preventive XSOAR functions. E.g.:- Write guardduty actions to block any TOR or vulnerable address for all VPC’s at once.
The only disadvantage is high costs associated with this additional inspection VPC setup.
(If we don’t want to invest on Firewalls for inspecting all traffic) — Use Security Groups at Scale with Network Firewall Manager + Route53 DNS Firewall — Detect and rollback changes.
→ We can rely on strict ingress/egress security groups and manage them at scale using Firewall Manager. It has all the abilities to detect changes/alert and rollback security groups.
→ Use Route53 DNS Firewall to block DNS resolution for on-premises hosts.
→ Apply host based firewall (such as iptables) or so at on-premises to block requests from Cloud or any other source.
Best Security Practices:
→ Dedicated DirectConnect AWS account. All changes via config management tools.
→ Monitor Cloudwatch rules for NACL level changes and alert to security team for any changes via SIEM tool.
→ Use latency analysis/bandwidth degradation tools from AWS to on-premises and vice-versa. It will help us checking for any connection deterioration from VPC level.
→ Check all ingress/egress traffic using VPC flow logs for insecure ports. Block insecure ports at NACL level.
→ Route53 Resolver DNS Firewall : This can be done to block DNS resolution at VPC level. We can set DNS response i.e. NXDomain/Nodata/Override (with different IP). Be noted that it’s for protection against general DNS security/bots. If anyone gains access to ec2 then it can reach destination via IP address OR simply by editing hosts entry.
→ Enable Firewall Protection for public S3 access from on-premises.
→ Enable MACSec at Directconnect level. DirectConnect doesn’t provide traffic encryption (by default) and only secure ports should be allowed. You can enable Macsec encryption for 10G and100G DX connections.
If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇