VMware Cloud Director: WAF 101

During my work with Service Providers, when it comes to Web Application Firewalls (WAF) to protect VMware Cloud Director (VCD) portal against web attacks, there is no definitive guide on the required configuration.

This post is based on field experience, in which I will attempt to set some baselines and will update the content based on my different experiences with the different WAF platforms.

What should the WAF you place in front of a VCD deployment do:

• The usual WAF known web attacks with a continuously up-to-date database of attack signatures (OWASP Top 10 for reference).
• SSL Termination (Users <-> Firewall <-> WAF <_SSL-Termination_1> LB <_SSL-Termiantion-2_> VCD Cells).
• Most importantly API security/protection.

For those who work with WAF knows that the golden rule is “WAF without optimization breaks things“. So, do not expect to get a WAF, setup external access via your firewall and point it to the load balancer and all things will be jolly, IT WILL NOT.

The optimization is around URL filtering, what to allow, and what not to allow, and what to deny by default. Access to the VCD portal _from_my_point_of_view_ should be via WAF for:

• Internal access:
  • Users (i.e support): No better way to keeping WAF in check and make sure all things are good is when you maintain day-2-day usage of the portal via WAF, so this is like a continuous non-stop functional testing.
  • Administrators: The higher the privilege the higher the risk, adding an internal layer of protection is always welcomed especially when handling customer-facing services.
• External access – > Customers.

The hereunder information is not 100% conclusive, and will most likely be updated based on new input I get from the field or from other community members.

Allowed API Methods

GET

POST

PUT

DELETE

OPTION

Table 1: Fortinet WAF (only URLs hereunder should be whitelisted, anything else should be denied) [LAST UPDATED 11/01/2023]:

External Access	Notes/Additional Whitelisting
/tenant/*
/api/sessions/*
/transfer/*	Allow only ISO, OVF, and OVA extensions (the WAF should be able to filter file headers and not just extensions) the idea is not to make the storage backend an HTTP like file transfer ;-).
/api/task/*
/api/media/*
/api/catalog/*
/network/*
/tenant-networking/*
/cloudapi/*
/cloud/org/*
/cloud/vmrcconsole.html
/cloud/customtheme*
/cloud/webmksconsole.html
/cloud/support/
/cloud/amf/*
/api/vApp/*
/api/versions/*
/login/*
/api/query/*
/api/admin/*
/api/org/*
/api/vdc/*
/oauth/tenant/*	Required for CSE 4 EPHEMERAL VM
/oauth/provider/token	I’ve noticed that when impersonating a tenant as a System Administrator and creating a Kubernetes cluster through CSE 4, this was getting denied.
Internal Access	Notes/Additional Whitelisting
/tenant/*
/api/sessions/*
/transfer/*	Allow only ISO, OVF, and OVA extensions (the WAF should be able to filter file headers and not just extensions) the idea is not to make the storage backend an HTTP like file transfer ;-).
/api/task/*
/api/media/*
/api/catalog/*
/network/*
/tenant-networking/*
/cloudapi/*
/cloud/org/*
/cloud/vmrcconsole.html
/cloud/customtheme*
/cloud/webmksconsole.html
/cloud/amf/*
/provider/*
/api/vApp/*
/api-explorer/*
/api/admin/extension/*	# Requires whitelisting of for RabbitMQ extension URL against Generic Attacks (Client-Side URL Redirect).
/api/versions/*
/login/*
/api/query/*
/api/admin/*
/api/org/*
/api/vdc/*
/oauth/*
/messaging/mqtt	You also need to allow WebSocket connections on the WAF as well.

Sometimes URL filtering is not enough, and the WAF might suspect a legitimate request as an attack; these false positives need to be whitelisted on a case-by-case basis (similar to the /api/admin/extension/* listing).

I’m looking forward to updating this blog post continuously, and I hope this helps =).

(Abdullah)^2