User Authentication

This section includes the following topics:

 

User Authentication allows an administrator to grant or reject access to specific users from specific IP addresses, based on their user credentials.

Before any traffic is allowed to pass through any user authentication-enabled rules, the user must first authenticate him/her-self. The firewall passes along the user information to an external authentication server, which verifies the user and the given password, and transmits the result back to the firewall. If the authentication is successful, the Amaranten firewall will remember the source IP address of this user, and any matching rules with user authentication enabled will be allowed. Specific rules that deal with user authentication can be defined, thus leaving rules that not require user authentication unaffected.

The Amaranten Firewall supports the RADIUS (Remote Authentication Dial In User Service) authentication protocol. This protocol is heavily used in many scenarios where user authentication is required, either by itself or as a front-end to other authentication services.

There are currently two Authentication Agents supported, HTTP and XAUTH. These are explained in detail later.

User Authentication Servers configuration

Servers used with User Authentication are defined in the User Authentication Servers configuration section located in the Miscellaneous folder.

General parameters

Name ?Symbolic name of the authentication server.

Type ?The type of authentication server to use. Currently only RADIUS is supported.

IP Address ?IP address, or symbolic name if the server has previously been defined in the Host and Networks section, of the authentication server.

Port ?The port of the authentication server.

Shared Secret - The shared secret enables basic encryption of the user password when the RADIUS-packet is transmitted from the firewall to the RADIUS server. The shared secret is case sensitive, can contain up to 100 characters, and must be typed exactly the same on both the firewall and the RADIUS server.

Confirm Secret ?Confirm that the shared secret is entered correctly by entering it again.

 

User Authentication Rules configuration

A user authentication rule specifies from where users are allowed to authenticate to the firewall. It also allows the firewall administrator to define different timeout-restrictions and authentication servers based on the source of the authenticated user. Furthermore, user authentication rules enable the possibility to customize the look of the return messages from the firewall to the authenticating user (login success, login failed, and so on), depending on the source of the user.

General parameters

Name ?Symbolic name for the rule.

Interface - The interface, which the connection was received on.

Network - The network object that the incoming IP address must be a part of.

Agent - HTTP or XAUTH

  • HTTP The user authenticates by first surfing to the firewall on port 80 with an internet-browser and then entering the user-credentials.

  • XAUTH The user will be prompted for a username and password when establishing a VPN-tunnel (if the VPN-tunnel has been configured to require XAUTH authentication).

When using XAUTH, there is no need to specify the receiving interface, or source network, as this information is not available at the XAUTH phase. For the same reason, only one XAUTH User Authentication rule can be defined. Neither will the firewall save any timeout value for XAUTH users, as XAUTH is only used to set up the VPN-tunnel.

Authentication Source ?RADIUS or DISALLOW. Choose DISALLOW to specifically reject any authentication attempts for this user.

Radius Options

The authentication method being used for encrypting the user password in the RADIUS packet being sent from the firewall to the RADIUS server. This can be set to PAP or CHAP.

General parameters

PAP - Password Authentication Protocol. Might be defined as the less secure of the two. If a RADIUS packet is intercepted while being transmitted between the firewall and the RADIUS server, the user password can be extracted, given time. The upside to this is that the password does not have to be stored in plaintext in the RADIUS server.

CHAP - Challenge Handshake Authentication Protocol. Does not allow a remote attacker to extract the user password from an intercepted RADIUS packet. However, the password must be stored in plaintext on the RADIUS server.

Authentication Servers - A list of authentication servers that will be used to authenticate users matching this rule.

These servers must previously have been defined in the User Authentication Servers section. If a response is not received from the first server in the list, the firewall continues with the next, and so on, until either a response has been received, or the end of the list is reached. The firewall will use the first server that returned a response (access granted or access denied) the next time this rule triggers. After a reconfigure, the first server in the list will be used again. A maximum of three authentication servers can be configured per user authentication rule.

Agent Options

General Parameters

Login Type - FORM or BASICAUTH.

  • FORM - The authenticating user will be presented a HTML page containing a HTML-FORM when surfing to the firewall. This form contains two fields, one for username and one for password. These values will then be sent to the firewall with the POST method.

  • BASICAUTH - The authenticating user will not be presented with a HTML page, but instead with a 401 ?Authentication Required dialog.

The problem with BASICAUTH is that web-browsers cache the username and password entered in the 401- Authentication Required dialog. This is normally no problem if the browser is closed down, as it then clears the cache, but for systems with the browser imbedded in the operating system, the cache is harder to clear

Realm string - The string that is presented as a part of the 401 - Authentication Required message which is presented to the user when surfing to the firewall. The default is Protected Resources. This setting is only valid for BASICAUTH Login Type.

HTML Directory - This is used in order to customize the look of the pages that is presented to the user at authentication time. Leave this blank in order to use the default pages. Please see the last chapter for details on how to set up customized pages.

Restrictions

Timeouts

Idle Timeout - If a user has successfully been authenticated, and no traffic has been seen from his IP address for this number of seconds, he/she will automatically be logged out.

Session Timeout - If a user has successfully been authenticated, he/she will automatically be logged out after this many seconds, regardless of if the firewall has seen activity from the user or not.

Use timeouts received from the authentication server - Some authentication servers (like RADIUS servers) can be configured to return session- and idle-timeout values. If this checkbox is checked, the firewall will try to use these timeouts, prior to the timeout values specified above. If no timeouts are received from the authentication server, or this checkbox is unchecked, the timeout values specified above will be used.

Multiple Username Logins

Allow multiple logins per username ?If this is checked, the firewall will allow users from different source IP addresses, but with the same username, to be simultaneous logged on.

Allow one login per username, disallow the rest ?If this is checked, the firewall will only allow one simultaneous username to be logged on. That is, if a user from another IP address tries to authenticate with the same username as that of an already authenticated user, the firewall will disallow this login.

Allow one login per username, replace existing user if idle for more than X seconds ?If this is checked, the firewall will only allow one simultaneous username to be logged on. If a user from another IP address tries to authenticate with the same username as that of an already authenticated user, the firewall will check if the authenticated user has been idle for more than X (where X is the number of seconds entered in the edit-field) seconds. If so, the old user will be removed, and this new user will be logged in. If not, the new login-request will be rejected.

 

Enabling XAUTH on VPN tunnels

In the VPN tunnel section; check the checkbox that says Require IKE XAuth user authentication for inbound VPN tunnels.

In order to use XAUTH in a VPN-tunnel, a user authentication rule specifying XAUTH as the Agent-type must be created. Note that for XAUTH, the firewall does not currently store any user-authentication information, such as source IP address or timeouts. It is only used to establish the VPN tunnel.

Enabling User Authentication on network objects

In order to create user authentication specific rules, user authentication information is entered in the network objects.

Groups and user names that belong to this network object are specified here. These network objects can then be used in the rule-section, just like normal rules. The same group information must be returned from the RADIUS server, using the Amaranten-User-Group attribute, as explained earlier, as the ones entered here.

Checking No defined credentials specifies that this network object requires user authentication, but has no user names or groups is specified. This means that the network object only requires that a user is authenticated, but ignores any kind of group that the user might belong to.

Enabling User Authentication on rules

Rules requiring user authentication are created just like any other rules, with the exception that ?ource network?is a network object containing user authentication information, created like described above.

(Note that access to port 80 on firewall must be allowed for authenticating users, who are using HTTP as the agent type).

When the firewall encounters a rule that requires user authentication in the source network object, the following happens:

  1. The firewall checks what group and/or usernames the source network object for this rule contains.

  2. The firewall then makes sure that a user from the IP address, from which the traffic that caused this rule to be interpreted originated from, is currently authenticated. If no authenticated user is found, the rule will not trigger.

  3. If an authenticated user if found, the firewall compares the information gathered in step 1, with the group/username information of the authenticated user.

  4. If the authenticated user has the credentials required by the source network object in this rule, the rule triggers. If not, the rule will not trigger.

When the firewall encounters a rule that requires user authentication in the destination network object, the following happens:

  1. The firewall checks what group and/or usernames the destination network object for this rule contains.

  2. The firewall then makes sure that a user from the IP address, from which the traffic that caused this rule to be interpreted should be sent to, is currently authenticated. If no authenticated user is found, the rule will not trigger.

  3. If an authenticated user if found, the firewall compares the information gathered in step 1, with the group/username information of the authenticated user.

  4. If the authenticated user has the credentials required by the destination network object in this rule, the rule triggers. If not, the rule will not trigger.