| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
In situations where individual users connect to protected resources through the Clavister 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 cOS Core but first the general issues involved in authentication will be 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 as an X.509 Digital Certificate.
C. Something the user knows such as a password.
Method A may require a special piece of equipment such as a biometric reader. Another problem with A is that the special attribute often cannot be replaced if it is lost.
Methods B and C are therefore the most common means of identification 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 therefore sometimes combined, for example in a passcard that requires a password or pin code for use.
Making Use of Username/Password Combinations
This chapter deals specifically with user authentication performed with username/password combinations that are manually entered by a user attempting to gain access to resources. Access to the external Internet through a Clavister firewall by internal clients using the HTTP protocol is an example of this.In using this approach, username/password pairs are often the subject of attacks using guesswork or systematic automated attempts. To counter this, any password should be carefully chosen. Ideally it should:
To remain secure, passwords should also:
Authentication Processing in cOS Core
The following steps describe the processing flow through cOS Core for username/password authentication:cOS Core sees the new user connection on an interface and checks the Authentication rule set to see if there is a matching Authentication Rule for traffic on this interface, coming from this network and is one of the following types of connection:
If no authentication rule matches, the connection may be allowed, provided that the IP rule set permits it and nothing further happens in the authentication process.
Based on the settings of the first matching authentication rule, cOS Core may prompt the user with an authentication request which requires username/password credentials to be entered.
cOS Core validates the given credentials against the Authentication Source specified in the authentication rule. This will be either a local cOS Core database or an external database server such as RADIUS, LDAP etc.
The pros and cons of using RADIUS or LDAP with cOS Core is discussed in a Clavister Knowledge Base article which can be found at the following link:
cOS Core then allows further traffic through this connection as long as authentication was successful and the service requested is allowed by an IP rule set entry. 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.
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.
The sections that follow explain in detail the components and setup for authentication.
