Blacklist scope options in the Exceptions of the Inspection Policy trigger automatic blacklisting for the detected events. You can define Blacklisting scope options for any type of Exception, including rules that use Correlation Situations. Automatic blacklist entries are created using the detected event’s IP source and destination addresses, and optionally the TCP or UDP ports. If the event does not contain this information, a blacklist entry cannot be created. Netmasks can optionally be used to blacklist the detected event’s network.
Using Blacklisting
Manual Blacklisting
You can blacklist connections manually through the Management Client. There are three ways to create new blacklist entries manually. You can blacklist a connection found in the log data, define a new blacklist entry for a Security Engine element, or create new blacklist entries in the Blacklist view. Blacklist entries can be removed and added manually.
Monitoring Blacklisting
The currently active blacklisting entries on the Security Engine can be monitored in the Blacklist view. Blacklist monitoring does not show you which connections are actually dropped. Blacklist monitoring only shows you the IP addresses that are currently on the blacklist. The Logs view can show which connections are actually dropped, depending on the logging options you have set. The blacklist can be sorted and filtered in the same way as log entries.
Whitelisting
Whitelisting means defining a list of IP addresses that must never be blacklisted. Whitelisting is implemented by following general Access rule design principles. Blacklisting applies only at the position of the blacklisting Access rule(s) in the policy. Connections that have already been allowed or discarded before the blacklisting rules is not affected by blacklisting. If an Access rule in the policy allows a connection, an Access rule that refers to the blacklist further down in the policy cannot blacklist the connection.
U SERS AND A UTHENTICATION
In this section:
Directory Servers - 181 User Authentication on the Firewall - 187 External User Authentication - 193
C HAPTER 21
D IRECTORY S ERVERS
A directory server is a server that contains a database where information about user accounts is stored.
The following sections are included:
Overview to Directory Servers (page 182)
Configuration of Directory Servers (page 182)
Examples of Directory Servers (page 185)
Overview to Directory Servers
A directory server is a server that contains a user database that is queried during the user authentication process. You can store the user accounts in the Management Server’s internal user database, or on an external directory server. Different users can be stored in different directories. Authentication is based on the user information, but is a separate operation and is not necessarily done on the same server that stores the user information. See User
Authentication on the Firewall (page 187) and External User Authentication (page 193) for more information about authentication.
Configuration of Directory Servers
User information is stored in an internal or an external LDAP (Lightweight Directory Access Protocol) directory. The standard LDAP user management model consists of three different levels: LDAP domains, user groups, and users. All three levels are represented as elements in the Management Client.
Internal User Database
The Management Server includes an integrated LDAP directory for storing user information. The Management Server’s internal user database can be used for authenticating users with passwords. Using an internal LDAP directory is the simplest choice when there is no specific need to have an external LDAP server.
When the Management Server’s internal LDAP directory is used, the user and user group information is stored on the Management Server. Each firewall node stores a replica of the user database, and any changes to the main database are replicated immediately to the firewalls.
This way, the firewalls can access their local directories instead of constantly communicating user information over the network.
If Domain elements have been configured, the Internal LDAP directory belongs to the Shared Domain. This means that the administrators who log in to some other Domain are allowed to view the contents of the Internal LDAP directory. If all user information should not be available to administrators in all Domains, you must use an external LDAP directory in each Domain. See the Management Center Reference Guide for more information on Domains.
Authentication Server User Linking
The optional Authentication Server component includes its own user database that is not based on LDAP. User and user group information is not replicated from the Authentication Server’s user database to firewalls. See Overview to External User Authentication (page 194) for more information about the user authentication process with the Authentication Server.
Note – It is not possible to give external components (such as external authentication servers) access to the Management Server’s internal LDAP directory.
External Directory Server Integration
An external LDAP directory can be used instead of or in addition to the internal LDAP directory.
The external directory server can be a general LDAP server, or a Microsoft Active Directory server providing LDAP services. The Management Server and the firewall engines each use their own integrated LDAP client to query the external LDAP directory directly. The external LDAP directory is not replicated into the internal directory on the Management Server, or into the local directory of the firewalls. Instead, the external LDAP directory is queried separately each time by the Management Server when you view the User elements in the Management Client and by the firewalls when a user attempts to authenticate.
The external LDAP server’s schema file defines the attributes (individual pieces of data) that a user account can contain. Extending the external server’s schema with Stonesoft-specific attributes is optional, but extending the schema allows you to also add Stonesoft-specific information to User and User Group elements through the Management Client.
User Agents for Active Directory
The User Agent is an optional, separately licensed software component that associates users from an integrated Active Directory server with IP addresses. This allows User and User Group elements to be used as the source and destination of rules without user authentication. For more information, see Creating User-Specific Access Rules (page 98).
Illustration 21.1 User Agent Communications
1. The User Agent monitors the Domain Controller’s Security Event Log to keep track of when a user logs on or logs off, a user’s IP address changes, or a user acquires the same IP address that was previously associated with another user.
•Users are associated with IP addresses based on logs collected by the Active Directory Domain Controller. For this reason, it is only possible to associate one user with each IP address from a client computer. It is not recommended to use the User Agent with terminal servers or other computers that have many users logged on at the same time.
•The User Agent periodically sends ICMP echo (ping) requests to users’ workstations to monitor which users are active. If a user’s workstation does not respond, the user is removed from the list of IP addresses. In cases where ping requests to workstations are not allowed, users’ connections may be incorrectly closed. Workstation monitoring can optionally be disabled in the Windows registry to prevent this. See the User Agent Release Notes for more information.
2. When the User Agent receives information about a particular user, the User Agent sends an LDAP query to the Active Directory server to look up the user’s group membership from
Firewall User Agent
Configuration Workflow
The following sections provide an overview of 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.