The USP Secure Entry Server ^® appliance provides support for using both free and commercial GeoIP databases by MaxMind. The free "GeoLite" databases are provided under the so-called "Creative Commons License":

The details of the MaxMind licensing can be reviewed on their own website:

The hardware appliance has a standard rack size form factor. Besides the common ports, the appliance offers four network interfaces. See Interface Roles section for details how these interfaces are used. To prevent service failures, the appliance supports redundant power-supplies and mirrored hard disks (RAID 1).

The USP Secure Entry Server^® can run as a virtual appliance. The functionality does not differ to the hardware appliance, except that the hardware settings can be individually adjusted to the expected needs.

The following settings are recommended for a moderate system usage:

If the virtualization software allows to define a guest operation platform, a 64bit architecture with Linux Kernel 4.X should be used.

The supported virtualization solutions are:

Figure 2.1. Network Interface Roles

During operation the external interface and the internal interface are mandatory and must be connected to your network.

It is possible to run the appliance in Authentication Service or Identity Manager Standalone mode. If enabled, the WAF and other service features are disabled and only the respective service is running. This setups requires at least two interface, else the Cloud Appliance mode will be enabled(Cloud Appliance). Only the internal interface needs to be connected to the network during operation.

See Setup Authentication Service Standalone Mode section for further information how to enable e.g the Authentication Service Standalone mode. Identity Manager Standalone can be setup in the same way.

United Security Providers provides the necessary machine images to instantiate a virtual cloud appliance.

The main difference to the other setups is that only one network interface is available. The IP Address is automatically assigned by the cloud service and the administration Web GUI can only be accessed on port 8443.

This High Availability setup allows a failover between two appliances.

Figure 2.2. HA Active/Passive Setup

This High Availability setup allows load distribution and failover between two or more appliances.

Figure 2.3. HA Active/Active Setup

Whenever one or more configuration parameters in the "System Settings", "Web Application Firewall", "Authentication Service" or "Identity Manager" section are changed, it is necessary to commit these changes. A "Commit" button will be displayed in the navigation sidebar, taking the user to the commit screen where a review of the changes to the configuration files is possible. Every commit requires a commit message, describing what has been changed, which is then added to the change history.

The current configuration can be tested for issues (e.g. invalid security certificates, misconfigured custom commands) by clicking on the Test button in the Configuration Deployment screen (Configuration→Manage and deploy). This will deploy the configuration to a temporary directory structure, and start the services in test mode.

The Configuration Deployment screen will also show warnings about obvious configuration issues. Clicking on an entry will open the related screen where the issue can be fixed.

Configuration activation is only possible if there are no uncommitted changes. To activate the current configuration, go to Configuration→Manage and deploy→Configuration Deployment screen and click on the Activate button. The activation process takes a while, as some serviced might require a restart or a reload. Services, whose configuration has not been changed, will not be restarted.

Sometimes, the activation will perform a restart of the web GUI, for example if the internal or administrative IP address has been changed. In that case, it may be necessary to reconnect to the web GUI manually after a while.

If the USP Secure Entry Server^® is set up as a High Availability cluster, the configuration needs to be synchronized to the other node(s) after activation. A Synchronize button will be displayed in the Configuration Deployment screen which starts the synchronization process. <<<

The appliance host name helps to identify the appliance. The configuration field is located in the tab System.

In the Interface tab, the network interface assignment as well as the IP addresses for all operational interfaces can be set.

Network Interface Roles

The roles are usually preset correctly, but can be changed if necessary. The external and internal interface roles must have an assignment (except in Standalone Appliance mode, where the external interface is not used).

Internal IP Address

An IP address for the internal interface is required. An additional gateway is optional and only needed when the target servers are not in the same subnet. It is possible to specify either an IPv4 address, an IPv6 address, or both.

Administrator Interface

This interface is not in use per default. It can be enabled by checking the Enable interface checkbox and entering the IP address information. It is possible to specify either an IPv4 address, an IPv6 address, or both.

Routing

Depending on the network setup, special routing settings are required. For each target server, an automatic route will be created using the internal interface. Manually added routes can overwrite the automatically created routes. These will be marked accordingly.

Warning

Be cautious when adding manual routes. If misconfigured, it can lead to improper functioning of the USP Secure Entry Server^® and even preventing operators from accessing the Web GUI. <<< === Web Application Firewall Setup

The Web Application Firewall configuration has a hierarchic structure and is divided in the three sections:

General Settings

Also called base server settings. These are globally applied settings like server sizing or default SSL protocols. The settings are inherited by any virtual host.

Virtual Host

A virtual host is represented by a host name and an IP address (IPv4 and/or IPv6) and other virtual host wide configuration (e.g. authentication service or SSL settings). The virtual host matching the host of the URL is selected to serve the request.

Location

Locations provide fine a grained configuration structure using the URL path. For instance, in location configurations it is defined to which target server the request should be forwarded to. A location configuration inherits the settings from its virtual host and from all its parents (in case of a sub-location).

Figure 6.1. URL components

To serve any request via USP Secure Entry Server^® a virtual host must be created.

This screen also shows warnings related to expired certificates, weak keys etc. The certificates and keys can be generated offline and imported as PEM encoded files. The files must be selected and uploaded by clicking the Import file button.

Alternatively, the private key can be generated by the USP Secure Entry Server^® appliance. Creating a new private key and certificate consists of the following steps:

Alternatively, you may also create and use self-signed certificates, which is usually very useful in testing environments. To generate such certificates, click the Create self-signed certificate button at the top.

For each virtual host at least one location must be created as otherwise no target server can be served.

Every virtual host has a Security Profile which defines the active rules to detect potential attacks. You can change the Security Profile by either applying a template or by customizing the settings manually.

Mode: The mode defines the actions to be taken when the profile is applied to traffic:

Profile Settings: The profile settings can be edited by clicking on "Settings" in the "Profile" menu. Depending on whether your profile is based on "Lean" or on "Typical/Fully Fledged", the following settings are at your disposal:

Figure 6.2. Security Profile

Settings for "Lean"-based Security Profiles

This type of profile is based on the rules which were shipped prior to USP Secure Entry Server^® 5.2.

Figure 6.3. Settings for a "Lean"-based Security Profile

Request Rules: Every rule in this profile checks requests for a certain type of attack. You can enable or disable any of the rules. If the current mode is "Prevent" and an enabled rule detects an anomaly, the affected request is blocked. If a rule is disabled, it won’t log nor block any suspicious requests.

Access Request Body: Allows to choose whether to apply rules to request bodies or not. Please be aware that if this setting is disabled, POST parameters and other content submitted in the request body will not be inspected.

Inspect Size Limit: This puts a limit on inspecting request bodies. It is used to keep the processing load on an acceptable level. A higher limit will consume more processing time. Request bodies which are larger than this value will still be inspected, but only up to this limit. The limit can be specified in bytes (B), kilobytes (kB), megabytes (MB) or gigabytes (GB).

Parse JSON: Enabling JSON parsing will apply the rules to JSON payloads.

Validate JSON Syntax: This is a special rule which checks the syntax of JSON requests. If the syntax is invalid and the current mode is "Prevent", then such requests are blocked.

Settings for "Typical/Fully Fledged"-based Security Profiles

This type of profile comes with an enhanced, accurate rule set which was designed to detect and prevent today’s sophisticated web attacks.

Figure 6.4. Settings for a "Typical/Fully Fledged"-based Security Profile

Enforcement: Enforcement defines how strictly suspicious requests will be blocked. This has only an effect if the mode is set to "Prevent". The enforcement levels behave as follows:

Level	Description
Tight: 5	Requests with one or more critical anomalies will be blocked
4	Requests with 2 or more critical anomalies will be blocked
3	Requests with 3 or more critical anomalies will be blocked
2	Requests with 5 or more critical anomalies will be blocked
Loose: 1	Requests with 10 or more critical anomalies will be blocked

Request Rules: Request rules are organized in categories. Enabling or disabling a category will enable or disable all rules contained within.

Access Request Body: Allows to choose whether to apply rules to request bodies or not. Please be aware that if this setting is disabled, POST parameters and other content submitted in the request body will not be inspected.

Inspect Size Limit: This puts a limit on inspecting request bodies. It is used to keep the processing load on an acceptable level. A higher limit will consume more processing time. Request bodies which are larger than this value will still be inspected, but only up to this limit. The limit can be specified in bytes (B), kilobytes (kB), megabytes (MB) or gigabytes (GB).

Parse XML: Enabling XML parsing will apply the rules to XML payloads.

Parse JSON: Enabling JSON parsing will apply the rules to JSON payloads.

Request Rule Exceptions: This table lists all request rule exceptions. A request rule exception disables a rule based on certain conditions. Conditions may include a request part (for example a HTTP header) with a specific name (for example the "User-Agent") as well as a specific location (including children thereof). Exceptions can be created either by clicking onto "Add Exception" or by using the "Advanced Learning" functionality.

By clicking onto an icon next to an exception you can invoke the following actions:

• Edit: Opens an editor where you can change the rule and conditions of an exception.
• Delete: Will delete the exception after confirmation.

Add Exception: Clicking on this button opens an editor which allows you to add a new request rule exception. The following parameters are available:

• Rule Choose the rule which should be disabled.
• Request Part Depending on the selected rule, you can specify a condition based on a request part.
• Request Part Name Depending on the selected request part, you can specify a name as an additional condition.
• Location Optionally specify a location. You can choose a defined location or enter an arbitrary one.

Response Rules: Response rules are organized in categories. Enabling or disabling a category will enable or disable all rules contained within.

Note

Enabled response rules will be applied to the response body and have a significant impact on processing load and request delay. You should enable them only selectively!

Response Rule Exceptions: This table lists all response rule exceptions. A response rule exception can disable a rule completely or just for a certain locations. Exceptions can be created either by clicking onto "Add Exception" or by using the "Advanced Learning" functionality.

By clicking onto an icon next to an exception you can invoke the following actions:

• Edit: Opens an editor where you can change the rule and location of an exception.
• Delete: Will delete the exception after confirmation.

Add Exception: Clicking on this button opens an editor which allows you to add a new response rule exception. The following parameters are available:

• Rule Choose the rule which should be disabled.
• Location Optionally specify a location. You can choose a defined location or enter an arbitrary one.

Advanced Learning: With "Advanced Learning" you can optimize the Security Profile using recorded requests. The goal is to reach the highest enforcement level without risking false positives.

Note

It is crucial that "Advanced Learning" uses only safe requests for determining false positives. Use it only in a controlled test-phase/environment or restrict it to safe requests by known client IP address or range.

Note

"Advanced Learning" is not available if "Advanced Log Management" is disabled or the Security Profile is based on "Lean".

Figure 6.5. Advanced Learning

In the "Advanced Learning" dialog, you have the following options:

• Consider requests from/to (UTC) You can enter a time period for requests to be considered. If you choose a date before the first recorded request or a date after the last recorded request, it will be corrected automatically.
• All requests are valid Choose this option if you know that all recorded requests are safe and contain no attacks.
• Only requests from the following IP addresses are valid Choose this option to consider only requests which came from specific IP addresses or ranges.
• Learn This button triggers the Advanced Learning based on the considered requests. You can repeat the learning when you choose to use different options.
• Update After successful learning, you can click this button to update the current Security Profile.
• Cancel Closes the "Advanced Learning" dialog without changing the Security Profile.

Save as Template: Saves the current Security Profile as a template. Templates can be applied to other Virtual Hosts or exported for use in other USP Secure Entry Server^® instances. If you use the name of a previously saved template, it will be overwritten. Overwriting a template does not modify the Security Profiles of existing Virtual Hosts. Names of built-in templates cannot be used.

Replace by Template: Replaces the current Security Profile settings with the settings from a chosen Template. Any built-in or previously saved Template can be selected.

The target server manager is located in the Web Application Firewall view. Any target server to which the requests should be forwarded to must be defined as a tuple of hostname and/or IP address, and port number.

The view contains a list of all backend targets:

Figure 6.6. Target Manager

The table contains one line per target, or target group. "group" because one target can contain two or more actual backends, to provide load-balancing. The table has 3 columns:

To edit a target, just click on the link in the "Name" column. To add a new one, click the Add target server button at the top, and this screen appears:

Figure 6.7. Edit target server

This view is split into five sections:

Always click the Save button at the top when changing anything in this screen.

On this screen you can manage the available Security Profile Templates.

Figure 6.8. Security Profile Templates

Import Security Profile Template: By clicking on the "Import" button you can import a Security Profile Template which was exported on any USP Secure Entry Server^® instance. If a Template with the same name already exists, an editor is opened which lets you enter a different name. If you keep the same name, the existing Template will be replaced. Replacing a Template does not modify the Security Profiles of existing Virtual Hosts. Names of built-in Templates cannot be used.

Security Profile Template Actions: By clicking on an icon of a template you can invoke the following actions:

IMPORTANT NOTE

If you use custom session cookie names, by means of custom commands, those custom session cookies might get blocked by the ModSecurity rules. In such a case, you will have to add custom exceptions to make sure your cookies will not be blocked. <<< === Authentication Service Setup

The "Authentication Service"(SLS) is a separate component on the USP Secure Entry Server^® appliance.

Authentication can be enabled and enforced for any application location in a virtual host. In order to do this, the Access Area Level must be configured for the location.

Access Area Levels

Any location in any virtual host always has one of three "Access Area" levels:

"Member" and "Customer" levels have a hierarchical relationship - when a user has been authenticated for a location with "Member" access level, she will still need to authenticate again for locations with "Customer" level. But a user who was already granted access to a "Customer" level location will not have to authenticate again when accessing a "Member" level location.

However, the actual strength of the authentication is defined by the settings of the authentication service. But as soon as a location has an "Access Area" level other than "Public", the WAF will enforce authentication before allowing access to the location. And choosing either "Member" or "Customer" allows to distinguish between locations with lower and higher security requirements, and implement step-up authentication procedures.

The "Access Area" level can be set in the location configuration screen of the Web Application Firewall part by selecting either "Member" or "Customer" in the drop-down selection box:

Figure 6.9. Enable Authentication for Virtual Host

On the virtual host screen, it is possible to define which instance of an SLS to use - either the local (by default) or a remote one. The latter allows to separate the actual WAF functionality from the authentication, by using a Standalone Authentication Service Appliance on a remote appliance:

Figure 6.10. Configure Authentication for Virtual Host

In case of some login procedures like PKI (certificate) based login, it may be necessary to disable the query filter for the SLS, or customize the regular expression.

There are two important concepts in the SLS related to setting up a certain authentication flow:

model.login.uri=/auth
model.login.failedState=get.cred
model.login.state.1000.name=get.cred
model.login.state.2000.name=do.auth
model.login.state.3000.name=do.success

model.<model-name>.

A typical example of this process when trying to access a web application through a browser looks like this:

Figure 6.11. Simple Login Flow

The credential verification happens where the user’s identity is actually confirmed by use of credentials like username, password and maybe an additional challenge-/response check with a hardware token.

LDAP Authentication Example

The following example shows which configuration screens are involved when setting up a simple LDAP-based authentication for a location:

After committing and activating the configuration the WAF will enforce LDAP authentication when accessing the application location.

The appliance GUI does not yet support all features of the SLS authentication service. So in some cases, when a certain functionality needs to be configured as described in the "SLS Administration Guide" and no corresponding page can be found in the GUI, it may be necessary to instead configure the feature with a set of custom properties. This basically corresponds to using "Custom Commands" in the WAF part of the appliance.

So, whenever certain SLS functionality needs to be configured by hand with a few custom properties, set them by selecting the Custom Settings entry in the left navigation tree under Configuration→Authentication Service:

Figure 6.12. Setting custom properties

For creating an Authentication Service Standalone appliance, a fresh installed appliance is recommended. After the software installation is finished, the standalone mode must be activated first.

This is controlled in the Web GUI under Configuration→Manage and Deploy→Enabled Services. Only Authentication Service should be set to on.

Figure 6.13. Enable services running on appliance

After this the Authentication Service can be configured in the usual way.

To use a remote standalone authentication appliance instead of the local SLS, select "remote" in the "Authentication service" row of the Authentication tab in the virtual host settings:

Figure 6.14. Configuring a Remote Authentication Service

If a Remote Authentication Service is used and the local service is not needed, the local Authentication Service on the Web Application Firewall appliance can be disabled. To achieve this, the Authentication Service must be set to off in the Enabled Services view.

Active/Passive requires two USP Secure Entry Server^® appliances.

Configuration

To enable Active/Passive the following steps must be executed on both appliances:

Configuration Synchronization

Before activating the failover cluster, it is advised to synchronize the component configuration:

Start Failover

In this last step the failover service must be activated.

Be aware, that stopping the HA service, as well as a shutdown or reboot of the appliance, are considered to be controlled maintenance actions, which lead to a regular exit of a node from the HA cluster. Consequently the other node is becoming active, although auto mode is turned OFF. If the auto mode is turned OFF, it will only prevent the passive node from takeover upon an uncontrolled or irregular exit, such as a power or network outage.

Active/Active requires at least two USP Secure Entry Server^® appliances.

Configuration

To enable Active/Active the following steps must be executed on all appliances:

Configuration Synchronization

Before the High Availability cluster is fully functional, the configuration should be synchronized between all nodes:

Session Transfer allows to request session data from another USP Secure Server^® appliance in the same High Availability cluster. This happens when an user request is served by another appliance which did not initiate the users session.

The sessions are only transferred by request and not automatically distrusted. Therefore when an appliance is taken offline due to maintenance reasons, it should not be restarted/updated until the client session inactivity timeout has passed. Otherwise user session data might be lost.

Session Transfer is by default disabled in an Active/Active setup. It can be enabled in the Deploy view, pressing the Enable Session Transfer button in the High Availability control panel. The load balancer in front of the HA cluster should enforce session-stickiness, otherwise the sessions are transferred unnecessarily often.

On the dashboard, the status of each HA appliance node is shown. The status are:

For high availability setups Active/Passive and Active/Active:

When you migrate your self-managed certificate setup to ACME, we recommend you to do a step by step vhost migration and validation. This is due the rate limiting which are enforced by the CAs. Check the rate limiting documentation of the CA in use.

For "Let’s Encrypt^™" the rate limiting documentation you can found under https://letsencrypt.org/docs/rate-limits/

The main configuration tab is located under Configuration→Web-Application Firewall→Certificates and keys→Automatic Certificate Management (ACME). * In this tab you have the possibility to enter the "Certificate Authority URL" endpoint and your contact email address. The API endpoint for "Let’s Encrypt^™" is documented under https://letsencrypt.org/docs/acme-protocol-updates/

The CA Certificate is used to validate the certificate of the CA URL endpoint. For "Let’s Encrypt^™" the validation certificate is available by default. If you are using another CA, then please upload the corresponding CA certificate for validation under "Certificate and keys" and select it in the dropdown list.

There are two supported types of ACME challenge used to prove domain ownership. If "http-01" is selected, the SES must be reachable from the Internet on port 80.

Renewed certificates are not automatically active and the WAF must do a graceful restart first. The "Graceful cron time" defines a time schedule when the WAF HTS is automatically gracefully restarted. It is recommended to choose a regular frequency (e.g. once a day or once a week).

The other option is to disable the automatically restart, but then the graceful restart must be triggered manually as soon as new certificates are available.

In a HA Active/Active setup it’s important that only one cluster node triggers the renewal process. The "Master ACME Node" flag indicates which node carries the responsibility for this. As the renewal process happens early enough before the certificate expiry, it’s also not a problem it the selected master node is not available during a short period in time due to maintenance or failure and the flag must not necessarily be changed. Should the master node be offline for a long period of time, the fallback process on the second node will try to renew the certificates at a later stage.

To enable ACME on a vhost you must select the checkbox "Automatic certificate management (ACME)" Vhost→SSL→SSL Certificate *

It’s possible to define specific certificates from the drop-down list in combination with ACME. The certificates are used till the ACME process for the vhost is finished and graceful restart is completed.

If no certificate is selected, the ACME module will use automatically generated fallback certificates. Until the ACME process is finished, and a graceful restart was triggered, the access to this vhost is blocked with a 503 HTTP response code.

ACME certificates and keys are not part of the configuration export or backup. In case a backup is restored, new certificates are requested from the CA.

There are four different roles:

A configuration export will provide a tar archive for downloading. The default file name contains prefix "sesconfig" with the hostname and the date. The archive can be downloaded in the Administration GUI Configuration→Manage and Deploy→Import/Export by pressing the Export button.

The import can be initiated in the same view as the export. After importing the archive the configuration is marked as "uncommitted" and must be committed and activated to apply the changes.

A system backup will provide a tar archive for downloading. The default file name contains prefix "sesbackup" with the hostname and the date. The archive can be downloaded in the Administration GUI Configuration→Manage and Deploy→Import/Export pressing the Backup button. This action is only available for users with administration privileges.

A system recovery process includes the following steps:

Backup archives can be automatically pushed to a remote server, either on a daily or weekly basis, or based on a custom schedule. If the "custom" scheduling option is selected, the backup interval must be configured with the common CRON job syntax in the text input field. The backup files are copied using the SCP protocol.

Automatic backup can be enabled by configuring the remote backup server in the Remote Backup tab under Configuration→System Settings→Network Settings:

After activating the modified configuration, a SSH public key will be presented in Configuration→Manage and Deploy→Import/Export→Remote Backup. This key must be registered on the remote backup server so that logins using public/private keys are possible. If using OpenSSH, the key must be added to the file ~/.ssh/authorized_keys. Set the permissions of the ~/.ssh directory and its containing files so that they may be only accessed by the current user.

Click on the button Execute to manually start the backup process, and verify that the backup is copied to the remote backup server.

The log files are crucial for analyzing any problems or incidents. Depending on the load which is processed by the USP Secure Entry Server^® the log file can grow very big. As the disk space is limited the log files must be properly managed.

The log management is located under Configuration→System Settings→Log Management.

Figure 7.1. General log management settings

Log File Management

The Web Application Firewall log are kept several days. The number of days how long the log files should be kept can be defined here. The log files are rotated daily.

Advanced Log Management

The advanced log management allows to aggregate log data from different sources with the Log Viewer and can make it easier to locate problems in the overall processing chain.

When disabling this feature completely, the possibility to aggregate the log data is lost. The components will only write the normal log files.

Log messages from the WAF and Authentication Service can be forwarded to an external SIEM infrastructure or syslog server over UDP or TCP.

To configure a remote syslog server, go to Configuration→System Settings→Network Settings→Monitoring/Alerting→Syslog Server and enter the IP address, gateway, port and select the protocol to be used. It’s possible to select between four different formats, how the message are forwarded:

Native logfile forwarding

For Syslog servers having Native Logfiles output format selected, it’s must be configured which logs will be forwarded for each component:

Figure 7.2. WAF native log file forwarding

Figure 7.3. Authentication service native log format forwarding

Secure log message forwarding with SSL/TLS

Log messages can be transported securely using SSL/TLS. In the Syslog Server settings panel, select TLS in the list of protocols. Click on the Manage certificates icon to go to the Certificates and keys screen, where you can upload your SSL/TLS CA certificate for the selected syslog server. For proper validation of the server certificate, ensure that the subject alternative name field includes the IP address of the syslog server.

A client certificate & private key pair can be uploaded and specified Syslog Server settings panel if the server requires client authentication.

Analytics→Log Viewer is only accessible when Advanced Log Management is enabled. This log viewer will allow to aggregate the different log sources and provides an extended search and filter mechanism.

Figure 7.4. Log viewer

Consult the context help in the Web GUI for details how the different filter and search mechanism are working.

Alternative Log Viewer

When the Advanced Log Management is disabled, an alternative view exists to analyze the log files. In Analytics→Log Download each log file can be viewed separately by clicking . Basic filtering is possible, but only the log entries of the current log rotation generation can be viewed.

The traffic analyzer is used for debugging purposes when integrating new applications. It records detailed request and response data during different processing steps.

Configuration

This feature can be enabled on virtual host level in the tab Logging. By specifying a certain URL path, an client IP address or a specific user-agent regular expression pattern, only matching requests will be captured. This will limit the amount of recorded data and will simplify the analysis.

Analysis

The captured request data can be analyzed with the build in Traffic Analyzer found under Analytics→Traffic Analyzer.

The Dashboard provides an overview of the usage of system resources like CPU usage, memory, swap and disk space. Clicking on the System menu item in the navigation opens a screen containing time-based charts of the system resource usage, as well as network and disk performance.

The USP Secure Entry Server^® features a local SNMP service which can be accessed by external monitoring solutions to obtain system status, configuration and health information.

The local SNMP service can be configured by navigating to Configuration→System Settings→Network Settings→Monitoring/Alerting→Local SNMPD Server. Entering a community string and activating the configuration will enable the SNMP service, which can be accessed on port 161 using SNMP protocol version 2c.

In addition to the standard MIB-2 information, it is possible to query USP Secure Entry Server^® specific information like virtual host usage, component service status, appliance release or system health information. You can download the related MIB files by clicking the Get MIB button in the Network Settings screen.

If the monitoring system detects an event (for example, an unexpected stop of a service, memory or hard disk filling up, errors reported by the WAF or Authentication Service), it can inform the operator by sending an SNMP trap message to a monitoring system which supports receiving SNMP traps.

SNMP trap receivers can be configured by navigating to Configuration→System Settings→Network Settings→Monitoring/Alerting→SNMP Server. Adding multiple SNMP servers, with individual community strings, is possible.

The structure of the SNMP trap message is defined in the USP-SES-TRAP-MIB file, which can be downloaded by clicking the Get MIB button in the Network Settings screen.

The various components of the USP Secure Entry Server^® generate events. These events provide consistent, uniformly structured information related to monitoring the status of various components and services in all USP products. With this structured information, a user is able to perform meaningful analysis of issues of any kind (using drill-down or statistical methods).