Blacklist Example Configuration for StoneGate

Transcription

1 Blacklist Example Configuration for StoneGate (8) Blacklist Example Configuration for StoneGate StoneGate versions: SMC 4.1.2, IPS 4.1.2, FW 3.0.8

2 Blacklist Example Configuration for StoneGate (8) 1.1 Introduction Why blacklisting is needed Blacklisting risks Example Task IPS Configuration Analyzer Element Configuration Sensor Policy Rule Options/ Blacklisting Firewall Configuration Firewall Policy... 7

3 Blacklist Example Configuration for StoneGate (8) 1.1 Introduction A good security consists of prevention, detection and reaction layers. The preventive layer means threat identification and blocking before they can cause any damage. The detection monitors for any anomalies that may signify of a breach through the passive prevention layer. The reaction consists of a set of actions that are carried out when such anomalies are detected. The reactive security's goal is to minimize the harm and to restore the systems back to the normal status quickly and cost-effectively. The procedures to do that should be pre-planned and documented. Many times, however, the exact reactions are hard to define before the incident happens and therefore the reactive actions usually require human analysis and adaption. For some cases, it may be possible to define active responses, i.e. actions that a security device can automatically launch when it detects an incident. Even then, the active responses are used only to save time and to limit the damage - the human intervention is usually required as well. Blacklist is an active response. It is a command chain from the intrusion detection system (IDS) to a device, which is able to control the traffic stream through it. The purpose of the blacklist is to instruct the access control device to block harmful connections as determined by the IDS. In StoneGate architecture the IPS Sensor is able to send a blacklist request through the IPS Analyzer to a StoneGate firewall engine. Blacklist requests can also be sent manually to firewalls through the Management Client Why blacklisting is needed Blacklisting is a reactive response that combines the IDS's ability to detect attacks and the firewall's ability to block traffic. Blacklisting is needed whenever the firewall is unable to determine if the traffic is good or bad, but needs separate IDS to tell the difference. An inline-ips combines these functions and in many cases is able to block the attack attempts alone without a need to send blacklist responses to anyone. However, the blacklisting is useful in the following cases: i) The traffic latency requirements are too strict for an inline-ips. The IDS analyses the traffic off-line and therefore does not cause any delays to the good traffic. ii) The risk of the inline-ips failures (software or hardware) or the needs for inline-ips maintenance does not meet the network availability requirements. If an IDS breaks, the attacks are not detected, but the good traffic is not interrupted. iii) Sometimes the offending connection is not the (only) one that is desired to block. If the IDS detects that a businesscritical application server has been compromised, the desired reaction may be to shut down the whole network until the intruder has been cleaned out. This may require blacklist requests to several firewalls. iv) Firewall may be already in a proper place and therefore adding the IDS is a lot easier step than implementing the real inline-ips Blacklisting risks All active responses always decrease the availability. Termination of a single connection breaks that connection only, whereas the blacklist request can block all future connections also between the defined hosts for a defined set of time. If the blocked host belongs to a malicious attacker, the response serves its purpose very well. However, there is always a risk that the blocking itself causes denial or service (DoS) damage to the innocent ones.

4 Blacklist Example Configuration for StoneGate (8) The following two categories represent the risks associated with the blacklisting: a) Blacklisting innocent connections If the detection heuristic to detect the malicious activities out from the network traffic is not fully accurate, the good traffic may sometimes be blacklisted. This causes service downtime for the anomalous-looking hosts. The accuracy imperfection may be caused by bad quality with the fingerprints or by administrator errors in the configuration. b) Acting as a denial of service (DoS) automation A blacklist configuration essentially means an automation that responds to a defined set of attacks with denial of service. Sometimes this may lead to a response that causes more damage than the attack would have caused. The attackers may also deliberately trigger the IDS to blacklist business-critical communications, by spoofing the attack's source IP addresses. The attackers motivation in these cases is not to succeed with the original attacks, but to use them to tear down valid connections. The risks can be tackled with good planning. The threats should be listed and evaluated carefully and the active responses should be defined only with good reasons. Whitelisting is a technique that protects the business critical connections against blacklisting. By carefully planning the administrator can categorize the connections to three different groups: 1) Connections that are allowed and that cannot be blacklisted (i.e. they are whitelisted) 2) Connections that are allowed normally but are subject to blacklisting 3) Connections that are discarded In StoneGate firewall the whitelisting is a part of the normal firewall policy and there is not a need to maintain a separate whitelist rulebase. For more information about the Blacklisting configuration in StoneGate, please read Administrator s Guide available at: (

5 Blacklist Example Configuration for StoneGate (8) 1.2 Example Task The following example describes the configuration steps needed for StoneGate IPS and FW to respond for detected anomalies using blacklisting. Task: IPS engine SGIPSCombo1 blacklists all client-server pairs that have been matched for Attacks category situations for 3 minutes. In addition, IPS should raise an Alert every time new blacklist request is done. Blacklist requests are sent to both StoneGate Firewall engine SGFWengine1 and the SGIPSCombo1 Whitelist SSH service in SGFWengine1 from source: Control-NET to destination: WWW-NET-1 Blacklist is allowed in SGFWengine1 for SSH, FTP, HTTP and HTTPS services when the destination is WWW-NET-1. Blacklist is allowed for ANY service in SGIPSCombo1 1.3 IPS Configuration Analyzer Element Configuration Analyzer and combined Sensor-Analyzer element/ blacklisting: Define to which firewall(s)/ inline IPS(s) interface the IPS Analyzer sends the Blacklist requests Sensor Policy Open the Sensor s system policy for editing and add a new rule in Inspection Rules/ Insert Point. Drag-and-drop Attacks situation category to the Situation column (Situations/By Tag/By Situation Type/Attacks).

6 Blacklist Example Configuration for StoneGate (8) Rule Options/ Blacklisting Double-click rule options in the defined rule and select Blacklist Scope view. Configure the Blacklist Scope according to the screenshot bellow. o Terminate the single connection IPS Terminates the matching connection and blacklists the endpoints in the future accordingly. o Block traffic between endpoints IPS selects the Client_IP_address, Server_IP_address and Destination_Port_number from the matching connection and uses it in blacklist request for Firewall and IPS engine(s). o Blacklist Executors IPS analyzer sends the blacklist request to the selected blacklist executors. o Include the original observer into the list of executors If checked, the analyzer automatically sends the blacklist request for the engine that detected the anomaly or violation. In this example, the blacklist request is send for SGIPSCombo1 engine too. Save the IPS policy with different name and install IPS sensor. Analyzer policy will be generated and installed automatically during sensor policy installation.

7 Blacklist Example Configuration for StoneGate (8) 1.4 Firewall Configuration Firewall Policy Whitelisted access rules are located before the blacklist rules in firewall policy. In this example, rule 14.1 whitelists SSH service when the source is Control-NET and destination is WWW-NET-1. The rule 14.2 defines which services are allowed to blacklist in firewall engine. SSH, FTP, HTTP and HTTPS services can be blacklisted when the traffic destination is WWW-NET-1. The following access rules 14.3 and 14.4 define how the WWW-NET-1 can be accessed from other networks. To allow blacklist requests from the IPS Analyzer engine (SGIPSCombo1) you need to add the Analyzer to the list of granted blacklisters in the rule Options (see rule 14.2/ Options) Select the rule s Options/Granted Blacklisters and add the IPS element into the list.

8 Blacklist Example Configuration for StoneGate (8) The Firewall policy is now ready for installation. To summarize: o Access rules located before the blacklist rules are automatically considered as whitelisted traffic/ services. o Blacklist rule defines the services that can be blacklisted if requested. Save the changes and install the FW policy.