VMware Cloud provides numerous ways in which workloads can be made resilient to security and other types of incidents.
Consider the following ideas:
- Ensure all rules allowing inbound access are restricted to the most specific set of source IP addresses and services required and avoid using “ANY” as the source or destination IP or services.
- Provide more general outbound rules at the perimeter but enforce specific outbound rules at the DFW.
- Use groups with dynamic membership and/or tag-based membership to simplify management.
- Include top-line rules to drop any traffic that should NEVER be allowed (for example traffic from a public IP source).
- Logging should be enabled on rules necessary to track access, or attempted access. By default, logging is not enabled.
- Always limit the Applied To field to the specific uplink the traffic is expected on, and avoid using “All Uplinks”
- Block traffic closest to the source (e.g. outbound traffic with the DFW, on-premises outbound traffic at the on-premises FW)
- When using NAT, ensure that only the ports required for the NAT are included in the NAT rule, and ensure the NAT matching criteria is set correctly for the use case. If the NAT matching criteria is set to private IP, then it will not be possible to differentiate between traffic that has been NATted and traffic that originated internally.
- If a NAT rule is configured for ANY services, then that NAT rule will be also be used for outbound (SNAT) traffic for Internet traffic from the private IP specified.
- NAT will not match unless the traffic is routed out the SDDC’s native internet (e.g. NAT cannot be used when a default route is advertised from one of the uplinks to the SDDC).
- Traffic between Management VMs and customer VMs in the same SDDC do not require Compute Gateway rules, but still must be allowed by the Management GW firewall.