Restricting Public Access to Pimcore Admin
Earlier this year, we had a client setting up a Pimcore instance behind an ELB (Elastic Load Balancer). One of their security concerns was avoiding users from accessing the Pimcore admin URL.
The following is an overview of some available options for restricting public access to private URLs that we provided them.
Implementation Options
In this particular setup, we had three options for implementing some restrictions on users.
- ELB level - Listener Rules
- Symfony level restrictions
- Server (Apache) level restrictions
Elastic Load Balancing - Listener Rules
It is possible to add listener rules to the elastic load balancer in order to redirect outside users from a list of specific paths. To do so:
- From the Amazon EC2 console, choose Load Balancing -> Load Balancers.
- Under your load balancer, choose the Listeners tab.
- After selecting your listener, click view/edit rules.
- You can now add a rule using the plus sign icon.
- You can now insert a rule.
There are several options for conditions and actions which can be used to customize your rules. If there are a collection of IPs which you are comfortable with people accessing the /admin page from, you can set up the rules such that those users get past the ELB, but others do not. The Forward to or Redirect to actions are recommended for guiding the user to an appropriate page of your choice.
If you need additional information on the ELB rules, you can see the Amazon documentation.
Symfony Level Restrictions
Restricting access at the Symfony level also has a good deal of customizability and several configuration options. This would be set up in the config file, and you would likely set up different restrictions based on which of the environments you were using. The environment this would likely be most applicable to though would be production, so we’ll discuss what that might look like.
In the configuration yaml, a security section with an access_control list will be required:
Symfony will check each rule in order to see if it matches the request at hand. As soon as a request
matches one of the rules, it stops evaluating the rest. Please see an example from Symfony documentation below.
In the following example, several possible situations are evaluated against the list of rules from the security config shown above. In each case, an access_control is determined for that request.
In the above examples, Symfony would enforce access based on the role determined by the access_control entries.
Another option which should likely be used for the /admin access and other system level routes for the prod environment would involve matching access_control by IP. This approach uses an “ips” option as seen in the following example. For that rule, and only for that rule, only IPs matching those in the list will be accepted. If other IPs matched a rule listed further down, they would be granted the access provided at that level.
Here is some helpful documentation on Symfony access control.
While there are a couple of other options listed here, such as Securing by Expression, Restricting to a port, and Forcing a Channel, in the event a Symfony level restriction is implemented, it will likely be with one of the approaches listed above.
Server level restrictions
In this particular instance, we were using Apache, so the following documentation only applies for Apache configuration.
You can update the Apache configuration file to only allow specific IP address to access certain URLs.
As an example, say we have http://pimcorewebsite.com/admin and only want users from 192.168.0.1 to access it. Under the <VitualHost> section you could add:
<Location /admin>
Order deny, allow
Deny from all
Allow from 192.168.0.1
</Location>
You would then need to save the Apache configuration and restart Apache.
Apache config Example:
Restart Apache:
You could set this up for whichever paths you required.
A good reference for this can be found here.
