The IPv4 Access rules in a firewall policy can be configured to match only when the user is authenticated. With client-to-gateway VPNs, some form of authentication is always mandatory, but authentication can be required for non-VPN access as well. The authentication parameters are defined in the Users and Authentication cells.
Illustration 13.3 Authentication Field in the IPv4 Access Rules
An authentication method is activated when at least one rule that contains the corresponding Authentication Service element is installed on the firewall. The authentication is usually granted for a specific duration based on source IP address (single connection authentication is an alternative with Telnet-based authentication).
The actual authentication connection is separate from the rules that grant access to resources based on an authentication requirement. Any valid user account for the active authentication methods is allowed to authenticate even if the end-user gains no additional access by authenticating (does not match the Access rules that require authentication to match).
The end-users usually authenticate through a VPN client, which requests the user to
authenticate as needed. When the VPN client is used, successful authentication opens a VPN tunnel. A second option is for the end-user to launch a separate Telnet authentication
connection to the firewall. The rules for allowing both types of authentication connections are included in the Default Template Policy.
Once the user successfully authenticates, the firewall adds the user on a list of authenticated users. The next connection that the user opens can now match an Access rule that contains an authentication requirement if the user and authentication method match the parameters of the rule.
Note that the User, User Group, and Authentication Service are simply used as matching criteria, so any of the other rules above or below may also match the authenticated user’s connections. This is especially important to consider when VPN client connections are
Caution – The Telnet method transfers the username and password in cleartext and does not provide any security in addition to the initial authentication of an IP address or a connection. Use a VPN client when a higher security level is required.
concerned, since the VPN client can be configured to receive an IP address from the
organization’s internal IP address space. Authentication rules may not seem intuitive at first, so we use the example rule set below to better illustrate them.
The first rule references a specific VPN and a specific authentication method. This activates both the VPN and the authentication method on the firewall. Any users who reside in any user storage location that is defined in your system can log in with the VPN client if their allowed authentication methods include a method included in the policy. This activation of features is independent of the rule (which only allows user Lisa to have access) and does not consider the rule’s conditions.
Any user whose account is stored in the same user storage as Lisa can use the VPN client to establish a VPN tunnel to the office. In this case, Lisa is stored in Active Directory and the defined user storage is a specific locations in the Active Directory such as a specific
Organizational Unit (so not the entire contents of the whole user database). Other users are not allowed access to “Secure Networks” because only Lisa is allowed access in the first access rule. However, they are allowed access to “Internal Networks”, because the second rule specifically allows access from their DHCP-assigned IP address with no other conditions.
In the example rule set, users in StoneGate’s internal LDAP user storage do not gain any type of authenticated access. This is because those users cannot use the only authentication method that is included in the policy (IAS Authentication). However, further changes in the configuration may accidentally activate such access, so in this example case, access should be made more specific by adding a specific User and Authentication method in the second rule. This way, other users can gain permissions to log in (=establish a VPN tunnel), but still cannot access any additional resources (connections they try to open through the VPN tunnel do not match any rule that allows traffic and are all dropped).
If necessary, you can define rules that discard connections from some combinations of Users and Authentication methods. The Source VPN cell in Access rules can be used to match VPN traffic/non-VPN traffic as desired.
Table 14 Example Rules
Source Destination Service Action Users Authentication
DHCP
Examples of User Authentication 143
Examples of User Authentication
The examples in this section illustrate some common uses for User Authentication in StoneGate and general steps on how each scenario is configured.
Using the Internal Database for Authenticating Users
Company A has a general office network and a separate network for servers that contain HR information, such as employee records and payroll information. The servers restrict the users who have access, but for auditing reasons, the administrators want to make anyone accessing the network to authenticate. The administrators:
1. Create a User Group “HR users” in the InternalDomain and assign the User Password authentication service as the authentication method.
2. Create User elements for each person with access rights with the User Password authentication method selected.
3. Add an IPv4 Access rule with authentication defined as shown below.
Using StoneGate with a Microsoft Active Directory Server
This example provides an overview to the configuration. For more information on configuring IAS, consult Microsoft’s documentation at http://technet.microsoft.com/.
Company B has an existing Microsoft Active Directory server that stores user information. They decide to use this existing information for user authentication in StoneGate.
The administrators:
1. Define an Active Directory Server element.
2. Add the StoneGate-specific classes and attributes into the Active Directory server’s configuration to be able to fully manage the user accounts through the Management Client.
3. Define StoneGate as an LDAP client for the Active Directory server.
4. Define StoneGate as an authentication client for the IAS.
5. Add a new LDAP Domain element for the Active Directory server in StoneGate.
Table 13.1 Example Access Rule for Internal LDAP Authentication
Source Destination Users Authentication
Network element for general office network.
Network element for HR network.
“HR Users” user group.
Require authentication with “User Password”
Authentication Service.
6. Add an IPv4 Access rule with authentication defined as shown below.
Using SecurID Authentication with StoneGate VPN Clients
This example provides an overview to the configuration. For more information on using SecurID authentication with StoneGate, consult RSA’s documentation at http://www.rsa.com/
rsasecured/product.aspx?id=1850.
Company C is about to introduce remote StoneGate IPsec VPN Client access to their network.
The administrators want to enhance the security of their authentication solution, as authentication is currently done using an external LDAP server and Telnet clients within the internal network. They decide to add the use of one-time passwords with SecurID cards with their existing RSA Authentication Manager server that already shares the user information with the company’s LDAP server.
Illustration 13.4 Company C’s Authentication Scheme Table 13.2 Example Access Rule for IAS Authentication
Source Destination Users Authentication
IP addresses of authenticated hosts.
IP addresses of network services that require authentication.
Some User or User Group elements from the AD’s LDAP Domain.
Require authentication with “IAS
Authentication”
Authentication Service.
RSA Authentication Manager server Authentication
(New Configuration) User Information
(Existing Configuration)
User Information (Existing Configuration) StoneGate
Firewall
User’s Host Internal
Services
LDAP Server
Examples of User Authentication 145 The administrators:
1. Create an Agent Host record for StoneGate in the RSA Authentication Manager server.
2. Create a VPN configuration in StoneGate with the default Hybrid Authentication selected as the authentication method for connecting clients.
•Hybrid authentication, available for StoneGate IPsec VPN Clients, requires that the VPN Gateway (the firewall) authenticates using a certificate and that the users provide the correct Username/Password combination (validated by the RSA Authentication Manager server in this case).
3. Create an Authentication Server element with RADIUS selected as the authentication method.
4. Create a custom Authentication Service element for the server and name it “SecurID”.
5. Add the “SecurID” Authentication Service in the correct User and User Group elements (stored on the existing external LDAP server).
6. Add IPv4 Access rules with both an authentication and a VPN requirement defined as shown below.
Table 13.3 Example Access Rule for SecurID Authentication
Source Destination Users Authentication Action
The virtual IP address range used on VPN Clients’ virtual adapters.
IP addresses of network services that require authentication.
Some User or User Group elements.
Require
authentication with
“SecurID”
Authentication Service.
“Use IPsec VPN”
with the “Enforce VPN” option.
147
C HAPTER 14
HTTPS I NSPECTION
The HTTPS Inspection feature decrypts HTTPS connections so that they can be inspected for malicious traffic, and then re-encrypts the traffic before sending it to its destination.
The following sections are included:
Overview to HTTPS Inspection (page 148)
Configuration of HTTPS Inspection (page 149)
Using HTTPS Inspection (page 151)
Examples of HTTPS Inspection (page 151)
Overview to HTTPS Inspection
HTTPS is used to secure HTTP connections. When a web browser connects to a server that uses HTTPS, the server sends a certificate that contains its public key and a digital signature from a certificate authority that verifies its identity to the web browser. The browser and the server negotiate an encryption algorithm, which is used to create the encrypted connection.
However, the encrypted HTTPS connection can also be used to obscure web-based attacks.
HTTPS Inspection allows you to decrypt HTTPS traffic so that it can be inspected.
The HTTPS Inspection feature consists of server protection, which inspects incoming
connections to servers in the protected network, and client protection, which inspects HTTPS outgoing connections initiated by clients in the protected network. HTTPS Inspection requires two separate secure connections: one from the client to the firewall, and one from the firewall to the server.
When an HTTPS server in the internal network is the destination of an incoming connection, the firewall uses the server's credentials to decrypt and re-encrypt the traffic.
When a client in the internal network initiates a connection to an external HTTPS server, the firewall checks whether the server’s certificate was signed by a certificate authority that is considered trusted. If the certificate was signed by a trusted certificate authority, the engine makes a new certificate that matches the server's certificate. From the point of view of a user in the internal network, the process is invisible: the connection is established in the same way as a connection made directly to an HTTPS server.
When a server’s certificate is self-signed or has not been signed by a trusted certificate authority, the engine cannot trust the server certificate. In this case the engine makes a new self-signed certificate. This certificate is presented to the user in the internal network, and the user’s browser shows the same warning it would show if it received a self-signed certificate directly from an HTTPS server. In this case, the user must decide whether or not to accept the certificate.
In both cases, the engine adds a Netscape Certificate Comment to the Extensions in the certificate to indicate that the certificate is a dynamically created certificate for StoneGate SSL/
TLS deep inspection. Substituting the original server certificate allows the firewall to decrypt and re-encrypt the traffic.
After decrypting the traffic, normal HTTP inspection and optionally virus scanning (requires the StoneGate UTM solution) are applied, and if the traffic is allowed to continue, it is re-encrypted before forwarding it. HTTPS inspection can only be applied to IPv4 traffic.
Configuration of HTTPS Inspection 149
Configuration of HTTPS Inspection
Illustration 14.1 Elements in HTTPS Inspection
The Server Protection Credentials and the Client Protection Certificate Authority are specified in the properties of the firewall that provides HTTPS Inspection. The firewall uses the private key and certificate stored in the Server Protection Credentials to decrypt traffic to and from HTTPS servers in the protected network for inspection. The Client Protection Certificate Authority contains a private key and a certificate. The firewall uses the private key stored in the Client Protection Certificate Authority to sign the certificates presented to the user’s Web browser, and the certificate to negotiate encrypted connections with HTTPS servers.
The HTTPS Inspection Exceptions element is a list of domains that are excluded from decryption and inspection. The HTTPS Inspection Exceptions can be specified in the Protocol Parameters of a custom HTTPS Service, which is used in the Access rules to select HTTPS traffic for
inspection.
Default Elements
There are predefined Trusted Certificate Authority elements that represent the signing certificates of major certificate authorities. Default Trusted Certificate Authority elements are automatically added to the system from dynamic update packages and cannot be edited or deleted. When client protection is used, the engine checks whether the certificate of an external server was signed by one of the Trusted Certificate Authorities. You can also create your own Trusted Certificate Authority elements to represent other certificate authorities that the engine should consider trusted.
Configuration Workflow
The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.