Chapter 8. User Authentication This chapter describes how NetDefendOS implements user authentication. Overview, page 220 Authentication Setup, page 221 8.1. Overview In situations where individual users connect to protected resources through a D-Link Firewall, the administrator will often require that each user goes through a process of authentication before access is allowed. This chapter deals with setting up authentication for NetDefendOS but first the general issues involved in authentication are examined. Proving Identity The aim of authentication is to have the user prove their identity so that the network administrator can allow or deny access to resources based on that identity. Possible types of proof could be: A. Something the user is. Unique attributes that are different for every person, such as a fingerprint. B. Something the user has, such a passcard, a X.507 Digital Certificate or Public and Private Keys. C. Something the user knows such as a password. Method A may require a special biometric reader. Another problem is that the feature often can't be replaced if it is lost. Methods B and C are therefore the most common in network security. However, these have drawbacks: Keys might be intercepted, passcards might be stolen, passwords might be guessable, or people may simply be bad at keeping a secret. Methods B and C are sometimes combined, for example in a passcard that requires a password or pincode for use. Using Username/Passwords This chapter deals specifically with user authentication through validation of username/password combinations manually entered by a user attempting to gain access to resources. Access to the Internet using the HTTP protocol through a D-Link Firewall is an example of this where a username/password combination is the primary authentication method. In using this approach, passwords are often subject to attacks by guesswork or systematic searches. To counter this, a password should be carefully chosen. Ideally it should: Be more than 8 characters with no repeats. Use random character sequences not commonly found in phrases. Contain both lower and upper case alphabetic characters. Contain both digits and special characters. To remain secure passwords should also: Not be recorded anywhere in written form. Never be revealed to anyone else. Changed on a regular basis such as every three months. 220
8.2. Authentication Setup Chapter 8. User Authentication 8.2. Authentication Setup 8.2.1. Setup Summary The following list summarizes the steps for User Authentication setup with NetDefendOS: Set up a database of users, each with a username/password combination. This can exist locally in a NetDefendOS User DB object, or remotely on a RADIUS server and will be designated as the Authentication Source. Membership of an Authentication Group can optionally be specified for each user. Define a User Authentication Rule which describes which traffic is to be authenticated and which Authentication Source will be used. Define an IP object for the IP addresses of the clients that will be authenticated. Associate this with an Authentication Group if required. Set up IP rules to allow the authentication to take place and also to allow access to resources by the clients belonging to the IP object set up in the previous step. The following sections describe the components of these steps in detail. Authentication Sources The database that an Authentication Rule uses to check a user's username/password combination can be one of two types: The local user database internal to NetDefendOS. A RADIUS server which is external to the D-Link Firewall. 8.2.2. The Local Database The Local User Database is a built-in registry inside NetDefendOS which contains the profiles of authorized users and user groups. Usernames and passwords can be entered into this database, and users with the same privileges can be collected together into groups to make administration easier. There are two default user groups, the administrators group and the auditors group. Users that are members of the administrators group are allowed to change the NetDefendOS configuration, while users that belong to the auditors group are only allowed to view the configuration. Press the buttons under the Groups edit box to grant these group memberships to a user. 8.2.3. External Authentication Servers The Need for Servers In a larger network topology with a larger administration workload, it is often preferable to have a central authentication database on a dedicated server. When there is more than one D-Link Firewall in the network and thousands of users, maintaining separate authentication databases on each device becomes problematic. Instead, an external authentication server can validate username/password combinations by responding to requests from NetDefendOS. To provide this, NetDefendOS supports the Remote Authentication Dial-in User Service (RADIUS) protocol. RADIUS with NetDefendOS 221
8.2.4. Authentication Rules Chapter 8. User Authentication NetDefendOS acts as a RADIUS client, sending user credentials and connection parameter information as a RADIUS message to a nominated RADIUS server. The server processes the requests and sends back a RADIUS message to accept or deny them. One or more external servers can be defined in NetDefendOS. RADIUS Security To provide security, a common shared secret is configured on both the RADIUS client and the server. This secret enables encryption of the messages sent from the RADIUS client to the server and is commonly configured as a relatively long text string. The string can contain up to 100 characters and is case sensitive. RADIUS uses PPP to transfer username/password requests between client and RADIUS server, as well as using PPP authentication schemes such as PAP and CHAP. RADIUS messages are sent as UDP messages via UDP port 1812. 8.2.4. Authentication Rules Authentication Rules are set up in a way that is similar to other NetDefendOS security policies, by specifying which traffic is to be subject to the rule. They differ from other policies in that the destination network/interface is not of interest but only the source network/interface. An Authentication Rule has the following parameters: Interface - The source interface on which the connections to be authenticated will arrive. Source IP - The source network from which these connections will arrive. Authentication Source - This specifies that authentication is to be done against a Local database defined within NetDefendOS or by using a RADIUS server (discussed in detail below). Agent - The type of traffic being authenticated. This can one of: HTTP or HTTPS - Web connections to be authenticated via a pre-defined or custom web page (see the detailed HTTP explanation below). PPP - L2TP or PPP tunnel authentication. XAUTH - IKE authentication which is part of IPsec tunnel establishment. Connection Timeouts An Authentication Rule can specify the following timeouts related to a user session: Idle Timeout - How long a connection is idle before being automatically terminated (1800 seconds by default). Session Timeout - The maximum time that a connection can exist (no value is specified by default). If an authentication server is being used then the option to Use timeouts received from the authentication server can be enabled to have these values set from the server. Multiple Logins An Authentication Rule can specify how multiple logins are handled where more than one user from different source IP addresses try to login with the same username. The possible options are: Allow multiple logins so that more than one client can use the same username/password 222
8.2.5. Authentication Processing Chapter 8. User Authentication combination. Allow only one login per username. Allow one login per username and logout an existing user with the same name if they have been idle for a specific length of time when the new login occurs. 8.2.5. Authentication Processing The list below describes the processing flow through NetDefendOS for username/password authentication: 1. A user creates a new connection to the D-Link Firewall. 2. NetDefendOS sees the new user connection on an interface and checks the Authentication rule set to see if their is a matching rule for traffic on this interface, coming from this network and data which is one of the following types: HTTP traffic HTTPS traffic IPsec tunnel traffic L2TP tunnel traffic PPTP tunnel traffic 3. If no Authentication Rule matches, the connection is allowed if the IP rule set permits it and nothing further happens in the authentication process. 4. Based on the settings of the matching authentication rule, NetDefendOS prompts the user with an authentication request. 5. The user replies by entering their identification information which is usually a username/password pair. 6. NetDefendOS validates the information against the Authentication Source specified in the authentication rule. This will be either a local NetDefendOS database or an external RADIUS database server. 7. NetDefendOS then allows further traffic through this connection as long as authentication was successful and the service requested is allowed by a rule in the IP rule set. That rule's Source Network object has either the No Defined Credentials option enabled or alternatively it is associated with a group and the user is also a member of that group. 8. If a timeout restriction is specified in the authentication rule then the authenticated user will be automatically logged out after that length of time without activity. Any packets from an IP address that fails authentication are discarded (unless they are caught be another rule). 8.2.6. HTTP Authentication Where users are communicating through a web browser using the HTTP protocol then authentication can be done by presenting the user with HTML pages to retrieve required user information. This is sometimes referred to as WebAuth and the setup requires further considerations. 223
Changing the Management WebUI Port HTTP authentication will collide with the WebUI's remote management service which also uses TCP port 80. To avoid this, the WebUI port number should be changed before configuring authentication. Do this by going to Remote Management > Advanced Settings in the WebUI and changing the setting WebUI HTTP Port. Port number 81 could instead, be used for this setting. Agent Options For HTTP and HTTPS authentication there is a set of options in Authentication Rules called Agent Options. These are: Login Type - This can be one of: FORM - The user is presented with an HTML page for authentication which is filled in and the data sent back to NetDefendOS with a POST. An HTML pre-defined in NetDefendOS will be used but this can be customized as described below. BASICAUTH - This sends a 401 - Authentication Required message back to the browser which will cause it to use its own inbuilt dialog to ask the user for a username/password combination. A Realm String can optionally be specified which will appear in the browser's dialog. FORM is recommended over BASICAUTH because the in some cases the browser might hold the login data in its cache If the Agent is set to HTTPS then the Host Certificate and Root Certificate have to be chosen from a list of certificates already loaded into NetDefendOS. Setting Up IP Rules HTTP authentication can't operate unless a rule is added to the IP rule set to explicitly allow authentication to take place. If we consider the example of a number of clients on the local network lannet who would like access to the public Internet on the wan interface then the IP rule set would contain the following rules. Action Src Interface Src Network Dest Interface Dest Network Service 1 Allow lan lannet core lan_ip http-all 2 NAT lan trusted_users wan all-nets http-all 3 NAT lan lannet wan all-nets dns-all The first rule allows the authentication process to take place and assumes the client is trying to access the lan_ip IP address, which is the IP address of the interface on the D-Link Firewall where the local network connects. The second rule allows normal surfing activity but we cannot just use lannet as the source network since the rule would trigger for any unauthenticated client from that network. Instead, the source network is an administrator defined IP object called trusted_users which is the same network as lannet but has additionally either the Authentication option No Defined Credentials enabled or has an Authentication Group assigned to it (which is the same group as that assigned to the users). The third rule allows DNS lookup of URLs. Forcing Users to a Login Page With this setup, when users that aren't authenticated try to surf to any IP except lan_ip they will fall through the rules and their packets will be dropped. To always have these users come to the authentication page we must add a SAT rule and its associated Allow rule. The rule set will now look like this: 224
Action Src Interface Src Network Dest Interface Dest Network Service 1 Allow lan lannet core lan_ip http-all 2 NAT lan trusted_users wan all-nets http-all 3 NAT lan lannet wan all-nets dns-all 4 SAT lan lannet wan all-nets all-to-one 127.0.0.1 http-all 5 Allow lan lannet wan all-nets http-all The SAT rule catches all unauthenticated requests and must be set up with an all-to-one address mapping that directs them to the address 127.0.0.1 which corresponds to core (NetDefendOS itself). 225
Example 8.1. Creating an authentication user group In the example of an authentication address object in the Address Book, a user group "users" is used to enable user authentication on "lannet". This example shows how to configure the user group in the NetDefendOS database. Web Interface Step A 1. Go to User Authentication > Local User Databases > Add > LocalUserDatabase Name: lannet_auth_users Comments: folder for "lannet" authentication user group - "users" Step B 1. Go to lannet_auth_users > Add > User Username: Enter the user's account name eg. user1 Password: Enter the user's password Confirm Password: Repeat the password Groups: One user can be specified into more than one group. Enter the group names here separated by comma eg. users for this example. 4. Repeat Step B. to add all the lannet users having the membership of users group into the lannet_auth_users folder. Example 8.2. User Authentication Setup for Web Access. The configurations below shows how to enable HTTP user authentication for the user group users on lannet. Only users that belong to the group users can get Web browsing service after authentication, as it is defined in the IP rule. We assume that lannet, users, lan_ip, local user database folder - "lannet_auth_users", and an authentication address object lannet_users have been specified. Web Interface A. Set up an IP rule to allow authentication. 1. Go to Rules > IP Rules > Add > IP rule Name: http2fw Action: Allow Service: HTTP Source Interface: lan 226
Source Network: lannet Destination Interface core Destination Network lan_ip B. Set up the Authentication Rule 1. Go to User Authentication > User Authentication Rules > Add > User Authentication Rule Name: HTTPLogin Agent: HTTP Authentication Source: Local Interface: lan Originator IP: lannet 3. For Local User DB choose lannet_auth_users 4. For Login Type choose HTMLForm 5. Click OK C. Set up an IP rule to allow authenticated users to browse the Web. 1. Go to Rules > IP Rules > Add> IP rule Name: Allow_http_auth Action: NAT Service: HTTP Source Interface: lan Source Network: lannet_users Destination Interface any Destination Network all-nets Example 8.3. Configuring a RADIUS server. Web Interface 1. User Authentication > External User Databases> Add > External User Database a. Name: Enter a name for the server b. Type: Select RADIUS c. IP Address: Enter the IP address of the server, or enter the symbolic name if the server has been defined in the Address Book 227
d. Port: 1812 (RADIUS service uses UDP port 1812 by default) e. Retry Timeout: 2 (NetDefendOS will resend the authentication request to the sever if there is no response after the timeout, for example every 2 seconds. This will be retried a maximum of 3 times) f. Shared Secret: Enter a text string here for basic encryption of the RADIUS messages. g. Confirm Secret: Retype the string to confirm the one typed above 228