Typically traffic matching a security policy with permit action is allowed to pass. The SRX however provides option to perform additional tasks before the data is finally let through. Few examples of these additional tasks are:
- making the decision based on the layer 7 application (AppFW)
- searching for attacks located in the packet payload (IDP)
- unified threat examination (antivirus, antispam, content and web filtering)
- restricting who is allowed to use the policy (firewall authentication)
- etc.
Here we will focus only on the firewall authentication.
SRX permits traffic that matches a policy with authentication enabled only from authenticated sources. The authentication takes place in form of providing the user name and password. The user credentials can be stored either locally on the SRX or the authentication can be done against an external authentication server (for example RADIUS).
Two types of firewall authentication exist:
- pass-trough - The user has just to initiate a connection to the desired destination. The firewall intercepts the communication and prompts the users for credentials. But the SRX is able to intercept only HTTP, FTP and telnet protocols and no other. For FTP and telnet the user is prompted within the connection and for HTTP a browser authentication window pops up (see images below for Mozilla Firefox and Internet Explorer).
- web-authentication – Fro this authentication type the user has to explicitly access an URL (IP address configured on the firewall) and perform the authentication there (shown on the image below).
Regardless of the authentication type once the user provides correct credentials the SRX remembers the his details (an example will be shown later). And while it is remembered the user's subsequent connections are granted without the need to authenticate again. The record however is not kept forever. It is removed after either the defined “client-idle-timeout” time is reached or “client-session-timeout” elapses. The idle timer is counted when the user is “idle”, i.e. has no active sessions on the device. If the user starts a new connection while being idle (i.e. changes state from idle to active) the idle timer is reset to the configured initial value. The timer starts running (from the initial value) once the user becomes idle again. The session timeout on the other hand is counted regardless whether the user is active or idle and is reset only after another successful authentication.
The configuration of firewall authentication involves 3 steps
1. Create an access profile
- authentication sources (locally stored user credentials or reference to an external authentication server)
- session options (client-group, client-idle-timeout, client-session-timeout)
2. Configure the firewall authentication details
- either pass-through and/or web-authentication (they can coexist)
- reference the access profile from step 1.
- specify banners for login, success and failure
3. Enable firewall authentication in the security policy (policies)
- reference the authentication type – pass-through or web-authentication (only one can be defined per policy)
- define the client-match
Traffic that matches a policy with authentication but comes from unauthenticated sources is denied. This applies even if the next policy in line would allow the traffic without authentication. In other words the first and (only the first) policy the traffic matches makes the decision – traffic allowed or denied.
An example firewall authentication configuration with both pass-through and web-authentication defined is shown below.
Two access profiles, one for each authentication type.
Firewall authentication configuration. SRX allows to reference different access profiles for each authentication type. This means each authentication type can have its own set of users.
Security policies
Additionally the web-authentication requires to have its own IP address configured on the interface. It must be a different IP address than the interface has but must be from the same subnet and have the same mask. Otherwise the page for entering credentials will not be displayed.
To verify the authentication following operational mode commands are useful. They show the authentication history and current user authentication status.
The example above illustrates the “show security firewall-authentication history” lists only the past (historical) login attempts without currently active users.
An user identifier can be supplied to the “show security firewall-authentication users” command to retrieve more details about him. Following identifiers are available:
Similarly as with other SRX features the traceoptions can be enabled if even more information is needed (for example for troubleshooting).
Firewall-authentication has its own traceoptions. They provide information about the configuration and authentication process. But the decision whether the authentication should take place or not is done within the traffic handling process. Therefore the information appears in the security flow traceoptions.
Next few example situations for firewall authentication follow. For each situation both - firewall authentication and security flow - traceoptions messages (but only relevant ones) are shown.
A connection where authentication was done
Firewall-authentication traceoptions
Security flow traceoptions
A connection from already authenticated user
No firewall-authentication traceoptions messages were created in this case.
Security flow traceoptions
A connection with failed authentication
Firewall-authentication traceoptions
Security flow traceoptions
SRX treats the users authenticated through pass-through separately from the web-authentication users.
For example: A user is already authenticated through web-authentication.
Now if he initiates a connection that is matching a policy with pass-through authentication he will be prompted for credentials.
The “show security firewall-authentication users” confirms it because it reveals there are 2 users remembered from the same IP address (one for each authentication type).
The fact a user successfully authenticated does not automatically mean he can use every security policy with authentication. The parameter responsible for this restriction is the “client-match”. This parameter can be defined in each policy when enabling the authentication. Another parameter related to this restriction is “client-group”. This one is defined either for each user individually or for the whole access profile in the session-options. Users that do not have this parameter defined take it from the profile session options. If this parameter is configured on both places (in the session-options and also for the user) the SRX uses only the value from the user's client-match parameter. Simply put the SRX does not combine them.
For example:
In the configuration above the user test1 belongs to the group AAA (inherited from the profile session-options) and user test2 belongs only to the group BBB (listed in his client-group parameter).
When comparing the SRX looks for an exact match between the client-match parameter and either user login name or user's client-group.
An example:
With the configuration above both users BBB and test2 are allowed to use the policy. User BBB matches policy client-match parameter with his login name and user test2 matches it with his client-group.
Wildcards are not supported for matching.
For example the user “test2” does not match the policy action configuration shown below. Even if successfully authenticates he cannot use the policy and his traffic will be dropped.
The firewall-authentication traceoptions messages show the user failed the client-match.
Luckily both parameters (client-group and client-match) can contain multiple values.
Conclusion
The firewall authentication feature increases the security and flexibility of security policies usage. It is achieved by allowing the traffic matching such security policy only from authenticated and authorized users, i.e. from users with correct credentials whose login name or client-group matches the client-match statement in the policy. The two available authentication types – pass-through and web-authentication – are described. Options for verification and troubleshooting of firewall-authentication are included as well together with few examples.
