When IPS is used, blacklist scope options in IPS Inspection rules trigger blacklisting for the detected events. Blacklisting scope options can be defined for any type of IPS Inspection rules, including rules that use Correlation Situations. Blacklisting is defined 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.
The source and destination addresses to be blacklisted can be determined from the IP addresses of the detected event. Netmasks can also be used to blacklist detected event’s network in addition to the IP address.
Using Blacklisting
You can blacklist traffic 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 Firewall element, or create new blacklist entries in the Blacklist view. Blacklist entries can be removed and added manually.
Automatic Blacklisting
Automatic blacklisting is needed whenever the Firewall is unable to determine whether traffic is harmful and relies on a separate IPS to tell the difference. Blacklisting with a firewall and IPS is useful in the following cases:
•The traffic latency requirements are too strict for an Inline Sensor. A non-inline Sensor analyzes the traffic off-line and therefore does not cause any delays to legitimate traffic.
•The offending connection is not the only one that the administrators want to block. If the IPS detects that a business-critical application server has been compromised, the desired reaction may be to shut down the whole network until the intruder has been cleared out. This may require blacklist requests to several Firewalls.
•A Firewall is already in a suitable place, so adding the non-inline Sensor is easier than implementing an inline Sensor.
Monitoring Blacklisting
The currently active blacklisting entries on the Firewall can be monitored in the Blacklist view.
Blacklist monitoring does not show you which connections are actually dropped. Blacklist monitoring only shows you the 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 logs.
Examples of Blacklisting
The examples in this section illustrate some common uses for blacklisting in StoneGate and the general steps on how each scenario is configured.
Blacklisting Traffic from a Specific IP Address Manually
Company A is using StoneGate Firewalls. The company starts getting a large amount of spam from IP address X. The company’s administrators decide to blacklist all traffic originating from that IP address for two hours. To do this, the administrators:
1. Create a new IPv4 Access rule in the Firewall policy. The Access rule applies blacklisting and allows the Management Server to send blacklist requests to the Firewalls.
2. Refresh the Firewall policy on all Firewalls.
3. Open the Logs view.
4. Select one of the entries that originate from IP address X.
5. Create a new blacklist entry that sets two hours as the Duration of the blacklist entry and defines the Firewalls that receive the blacklist request.
Automatic Blacklisting with IPS
Company B is using a Firewall and IPS managed by the same Management Server. The IPS has recently detected a large number of attempted attacks against several of the company’s servers. The attempted attacks have come from multiple IP addresses. It is difficult to predict which server will be the target of a particular attack. The administrators want to automatically block traffic between the IP address that is the source of the attacks and the target server for one day whenever an attempted attack is detected.
There is already a default Situation for attempted attacks that defines the source IP address of matching traffic as the Attacker and the destination IP address as the Victim.
To configure the automatic blacklisting for traffic from the attacker to the company’s servers, the administrators:
1. Create a new IPv4 Access rule in the Firewall policy. The rule applies blacklisting and allows any component to send blacklist requests to the Firewall.
2. Refresh the Firewall policy.
3. Create an Inspection rule in the IPS policy that sends a blacklist request to the Firewall when traffic matches the Situation for attempted attacks.
4. Define the following Blacklist Scope properties in the options of the inspection rule:
•Block traffic between endpoints
•Duration: 1 day
•Endpoint 1 Address: Attacker
•Endpoint 2 Address: Victim
•Blacklist Executor: Firewall 5. Refresh the IPS policy.
U SERS AND A UTHENTICATION
In this section:
Directory Servers - 181 User Authentication on the Firewall - 187 External User Authentication - 193
C HA PT E R 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 StoneGate’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 in StoneGate, 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 StoneGate-specific attributes is optional, but extending the schema allows you to also add StoneGate-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 97).
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.