mirror of
https://github.com/opnsense/docs
synced 2024-11-18 21:28:29 +00:00
165 lines
7.1 KiB
ReStructuredText
165 lines
7.1 KiB
ReStructuredText
======================================
|
|
Deciso: Proxy access management
|
|
======================================
|
|
|
|
As part of the OPNsense Business Edition, Deciso offers a plugin to add fine grained access control to your existing
|
|
web proxy setup.
|
|
|
|
One of the features often requested is to easily (dis)allow (groups of) users access to certain domain or url parts,
|
|
the :code:`OPNProxy` plugin addition offers this functionality at ease.
|
|
|
|
Prerequisites
|
|
---------------------------
|
|
|
|
Before installing and using this plugin, make sure your web proxy is configured and enabled including some sort of authentication.
|
|
|
|
.. Note::
|
|
To enable authentication, goto :menuselection:`Services->Web Proxy->Administration` then collapse "Forward Proxy" and
|
|
choose "Authentication Settings". Choose a method and apply settings.
|
|
|
|
.. Note::
|
|
In order for authentication scheme's to work, users do need to exist in the firewall. You can either import them (when using ldap)
|
|
or make sure the same username exists locally to map groups too.
|
|
|
|
|
|
Installation
|
|
---------------------------
|
|
|
|
Installation of this plugin is rather easy, go to :menuselection:`System --> Firmware --> Plugins` and search for **os-OPNProxy**,
|
|
use the [+] button to install it.
|
|
|
|
Next go to :menuselection:`Services --> Web Proxy --> Access control` to start configuring polcies.
|
|
|
|
.. Note::
|
|
|
|
Redis is required for this plugin to operate, when accessing the access control settings page for the first time you will be pointed to the correct
|
|
setting to enable it directly. (just enable and apply should be enough)
|
|
|
|
General
|
|
---------------------------
|
|
|
|
In order to utilise user/group based policies, the proxy needs to be able to inspect the traffic and know the identity of the
|
|
user.
|
|
|
|
Since most of the internet is being encrypted nowadays, you would need to enable some sort of ssl inspection in between.
|
|
When setting "Enable SSL inspection" in :menuselection:`Services -> Webproxy -> Administration -> Forward Proxy`
|
|
you are able to use a "man-in-the-middle" approach (where the proxy intercepts traffic and is able to filter it).
|
|
A disadvantage of this option is that your clients would need to trust the firewalls certificate (CA selected in "CA to use").
|
|
When enabled full paths can be filtered.
|
|
|
|
A bit lighter option would be to use SSL inspection with "Log SNI information only" enabled,
|
|
in which case the firewall would know which domain you are trying to visit, but can not inspect the content of the request (or response for that matter).
|
|
|
|
.. Note::
|
|
|
|
When enabling "Log SNI information only", only domain based policies will be usable for SSL/TLS based requests.
|
|
|
|
The standard authentication options available in OPNsense apply, which can be configured in
|
|
:menuselection:`Services -> Webproxy -> Administration -> Forward Proxy -> Authentication settings`. Please make sure
|
|
to import/add the users in OPNsense in order to user their authorisation settings (existence and group membership).
|
|
|
|
|
|
.. Note::
|
|
|
|
Standard (global) policies take precedence over the ones defined in the access control plugin, this includes
|
|
"SSL no bump sites" when full TLS/SSL inspection is used.
|
|
(it's not possible to block no bump sites in full inspection mode)
|
|
|
|
|
|
Policy types
|
|
---------------------------
|
|
|
|
Part of OPNproxy is a standard list of categorized locations, which can be easily added to a policy, these type of policies
|
|
are the default ones. You will find categories here like :code:`adult`, :code:`advertisements`, :code:`malware` and many others.
|
|
|
|
In some cases however our defaults are not enough, for this reason we also offer the posibility to push your own list of
|
|
domains and locations into a custom policy.
|
|
|
|
Every policy contains what to match (either a standard category or a list of domains and paths), what to do (allow or deny)
|
|
and an audience (the users and/or groups the policy applies to).
|
|
|
|
Since both users and groups can be selected within the same policy, we choose to prefix users with a :code:`*`.
|
|
|
|
.. Tip:
|
|
|
|
For easy administration it's generally a good idea to use groups in policies instead of users.
|
|
|
|
Prioritisation within our access control is quite easy and should cover all possible scenarios, below the order in which
|
|
decisions are made:
|
|
|
|
1. No policy, default allow. When authentication is properly setup, this means that access depends on supplying valid credentials.
|
|
2. Explicit allow, the closest matching policy (see text below) returns accept, access will be granted (also when another policy returns deny)
|
|
3. Explicit deny, the closest matching policy returns deny, access will be denied
|
|
|
|
|
|
Closest matching explained
|
|
.............................
|
|
|
|
One of the key features of our access control system is a method to find the best suitable policy for the requested domain
|
|
or url.
|
|
|
|
This means that if someone defines two ACL's one denying access to all google.nl subdomains (:code:`.google.nl`) and
|
|
one allowing access to the favicon on the page :code:`www.google.nl/favicon.ico`, only access to favicon.ico is allowed on
|
|
the google.nl website.
|
|
|
|
If one of our default policies contains a website you still want to allow, you can easily add the domain (with or without path)
|
|
to another policy to still grant access. This is one of the main reasons we prioritise :code:`allow` over :code:`deny` in these
|
|
policies.
|
|
|
|
|
|
Custom policies
|
|
---------------------------
|
|
|
|
Custom policies are defined as lists of domains with optional paths using one line per item.
|
|
When domain policies should include subdomains, they should be prefixed with a point (.), e.g. :code:`.nl` matches
|
|
all dutch top level domains.
|
|
|
|
Some companies use very strict policies, in which case one should only be allowed to access specific domains. For this case
|
|
we added a special wildcard (:code:`*`). When set in a policy it will mark the absolute top level domain.
|
|
|
|
.. Tip::
|
|
|
|
If one should only be allowed to access pkg.opnsense.org you would create two policies, one containing a deny policy
|
|
on :code:`*` and one containing an allow policy on :code:`pkg.opnsense.org`.
|
|
|
|
|
|
Using the policy tester
|
|
---------------------------
|
|
|
|
When doubting if a specific location would be accessible by a user, one can always use the included ACL tester.
|
|
Although mainly used for debugging purposes, it will easily inform you about the decision the webproxy will take
|
|
when using our acl's.
|
|
|
|
The policy tester contains two fields and a test button, just enter a username followed by a url (e.g. https://www.google.nl/)
|
|
and hit the test button. Depending on settings it will return a response like:
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"message": "ERR message=\"reason:c1380754-e14b-4dc7-bcf9-96307450c025 policy_type:custom\" user=\"root\"\n",
|
|
"user": {
|
|
"uid": "root",
|
|
"id": "0",
|
|
"applies_on": [
|
|
"u:root",
|
|
"g:admins"
|
|
]
|
|
},
|
|
"policy": {
|
|
"action": "deny",
|
|
"id": "c1380754-e14b-4dc7-bcf9-96307450c025",
|
|
"applies_on": [
|
|
"g:admins"
|
|
],
|
|
"policy_type": "custom",
|
|
"description": "test_custom2",
|
|
"path": "/",
|
|
"wildcard": true,
|
|
"domain": "google.nl"
|
|
}
|
|
}
|
|
|
|
|
|
Which informs you about all settings relevant for the lookup, the message returned (to squid), the user found and the policy matched
|
|
using the rules described earlier.
|