It i possible to allow/deny access to individual resources based on the country their inbound IP is coming from.
Note:As with all IP-based lookup schemes, a user coming via VPN can appear in an alternate location.
Geo-location is done at the granularity of country. Countries are identified by their ISO-code (a 2-letter code unique per country).
Rules have priorities. Lower numbers evaluate first. Rules with the same priority evaluate in parallel, taking the most restrictive answer.
Actions include:
Allow
Deny
Log
An example configuration allowing (priority-0 evaluates first) traffic from Canada, US, and denies (priority-1, NOT Canada, US) the remainder is shown below.
A Content-Security-Policy is a header which instructs a browser how to interpret & allow or deny various types of active content (images, fonts, frames, …). It helps mitigate certain types of attacks including Cross-Site-Scripting (XSS) or data injection.
A Content-Security-Policy is a header which instructs a browser how to interpret & allow or deny various types of active content (images, fonts, frames, …). It helps mitigate certain types of attacks including Cross-Site-Scripting (XSS) or data injection.
The Agilicus Web Application Firewall allows setting and editing this header. You can see it on the ‘Define’ tab of the application. 3 macro-settings may be applied:
clear — remove (unset) the Content-Security-Policy
strict angular defaults — this is a set of defaults suitable for an Angular application compiled with AOT and subresource-integrity
lax angularjs defaults — this is a set of defaults suitable for an older AngularJS application (including unsafe-inline)
Once you set one of these buttons you may then edit the individual types.
In addition to the check-box settings, a set of ‘hosts’ may be configured. This can include ‘data:’ , ‘*’, ‘https:’, ‘https://example.com’, etc. For more information see Content Security Policy (CSP) in the Mozilla Web Docs.
Authentication is how a user “proves” their Identity
Authorisation is “what” a user is allowed to do. In the AnyX platform this is implemented via a set of firewall rules. For web applications, these have many options (method, path, body, who, etc).
The firewall rules are access via “Resources/Applications/Overview”, and then selecting the individual application, and navigating to the “Security” tab.
HTTP Rules
For web applications, HTTP rules allow matching on a set of conditions, and then performing a set of actions.
The conditions include:
Priority. Rules are evaluated in order until a match occurs
HTTP Path (the part after the host name in e.g. https://hostname/path).
Method (e.g. GET, PUT, POST, DELETE, HEAD, …)
Scope. One of “Assigned to User”, “Anyone”, “Any Known User”, “Any App User” (see Scopes below)
Methods are as defined in the HTTP standard (GET, PUT, POST, …). For most applications GET/HEAD will mean ‘read’, PUT will mean ‘create’, POST will mean ‘update’, and DELETE will mean remove a record.
Actions are Allow, Deny (and None, which can be used to disable a rule temporarily, or for debugging with logging).
Application Roles are defined per application, but often include ‘Self’ (my own records), ‘Owner’ (all, admin), ‘Editor’ (can change but not create/delete), ‘Viewer’ (can read).
Negated (the rule is inverted in sense, so whatever does *NOT* match).
Scopes
The scopes control what ‘type’ of user is matched by this rule. The scopes are:
Assigned to User. The user must have a valid role within this application, and, that role is assigned (see Access/Application Permissions in admin)
Anyone. Literally anyone on the Internet, regardless of who they are (e.g. Anonymous)
Any Known User. Any user who exists in your org as a valid user.
Any App User. Any user who was authenticated by this application (see Authentication/Application Identity. Note this is a rare case).
GeoIP Firewall
In some cases you may want to include only, or exclude only, specific countries from using a resource. You may do this by selecting the ISO 3166 country code for each locale, and then selecting IN/NOT_IN and action. The most common action (ALLOW, DENY) would fall-through to the other authorisation rules (ALLOW), or block entirely (DENY) regardless of user.
During the new organisation Signup flow you may find an error as below. This is caused by a corporate network filter (e.g. Palo Alto) which blocks certain encrypted flows.
During the new organisation Signup flow you may find an error as below. This is caused by a corporate network filter (e.g. Palo Alto) which blocks certain encrypted flows.
You may have firewalls in two locations: between your browser and the Internet (e.g. if you run endpoint protection software, or are using a device not currently on your corporate network), and, between the Agilicus Connector and the Internet.
Firewall Configuration: End-User Browser to Internet
In order to use your browser with the Agilicus AnyX platform, whether for signup purposes, or for ongoing usage, you need to be able to navigate to these host names:
*.__MYDOMAIN__ (each of yoru resources will appear hre)
(where __MYDOMAIN__ is the domain name you will choose during the signup process).. You will know you need these rules if you see errors like below image.
In addition, your name server (DNS) must be able to resolve:
ca-1.agilicus.ca
api.agilicus.com
www.agilicus.com
The most common problem observed is that if you navigate to https://auth.agilicus.cloud you get an error implying the connection was RESET. This is typically done by a content-filtering firewall such as Palo Alto blocking “auth.*” as a domain name.
To resolve, work with your outbound firewall filtering vendor to allow:
*.agilicus.com
*.agilicus.ca
*.agilicus.cloud
Firewall configuraton: Agilicus Connector to Internet
The Agilicus Connector makes outbound connections only, on port 443 HTTPS only. It will have 2 outbound TCP connections (for resilience) as well as periodic ones to its API and update server.
Configure your outbound firewall to allow:
www.agilicus.com (upgrades)
api.agilicus.com (configuration)
agent-server.ca-1.agilicus.ca
*.__MYDOMAIN__ (authentication via auth.__MYDOMAIN__)
If you prefer to use IP (and port) – based rules, you may use as below. Note: it is possible this list will change in the future.
