With reverse proxy ACLs, it’s possible to implement additional access controls to ensure that requests only come from authorized sources, requests are of certain types only, or that additional parameters are required to make certain requests. Below are commonly configured ACLs.
IP based restrictions #
If the desired deployment model includes technicians connecting to Automate or Control via the proxy, it’s possible to restrict certain requests (such as the desktop client, or the web UI) to specific IP addresses. This works well for the use cases where an MSP wants to restrict Automate access to office IP addresses or designated secure remote access technology (VPNs, RDS, VDI, etc.).
In the same way, it’s possible to use GeoIP rules to allow agent check-in from multiple countries but restrict web UI access to specific countries (or IP lists).
Request based restrictions #
Like the agent-only deployment model, it’s possible to selectively restrict the types of requests made to Automate. With this, we can block the default WCC2 splash page (that displays the Automate version number) or block certain pages/features (such as login pages or API access).
Parameter based restrictions #
It’s also possible to require an additional parameter (a password of sorts) for specific requests (like accessing a login page, ex.: https://…./login?authtoken=randompasswordhere). This is typically done with a URL parameter, and it can be paired with the request-based restrictions above to block access by default but allow users who know the parameter to access the page (and it can be easily distributed via a URL shortener tool).
Header based restrictions #
If HTTP headers can be configured (or already exist) to send a known value, requests can be selectively restricted by the proxy (similar to a parameter based restriction). This can be used to allow inbound requests from 3rd parties (like SaaS applications) without the administrative overhead of maintaining IP lists.
