Smart Defense Technical White Paper - kippdata.de

Smart Defense Technical White Paper

2004 Check Point Software Technologies Ltd. 1

In This Document

1.0. Understanding SmartDefense ………………………………………………… 32.0. The Components of SmartDefense ………………………………………… 3 2.1. Enforcement Integrated with Check Point Products ……………………………………… 4 2.2. Management Integrated with SmartCenter ……………………………………………… 2.2. Management Integrated with SmartCenter ……………………………………………… 2.2. Management Integrated with SmartCenter 4 2.3. Monitor Only Mode ………………………………………………………………………… 4 2.4. SmartDefense Service: Subscription-based Updates to New Attack Protection ……… 53.0. The SmartDefense Structure ………………………………………………… 6 3.1. Anti-Spoofi ng Confi guration Status ………………………………………………………… 6 3.2. Network Security …………………………………………………………………………… 3.2. Network Security …………………………………………………………………………… 3.2. Network Security 7 3.2.1.Denial-of-Service Protections …………………………………………………………… 7 3.2.1.1. Teardrop …………………………………………………………………………… 7 3.2.1.2. Ping of Death ……………………………………………………………………… 7 3.2.1.3. LAND ………………………………………………………………………………… 7 3.2.1.4. Non-TCP Flooding ………………………………………………………………… 8 3.2.2. IP and ICMP Protections ……………………………………………………………… 8 3.2.2.1. Packet Sanity ……………………………………………………………………… 3.2.2.1. Packet Sanity ……………………………………………………………………… 3.2.2.1. Packet Sanity 8 3.2.2.2. Max PING Size ……………………………………………………………………… 8 3.2.2.3. IP Fragments ……………………………………………………………………… 8 3.2.2.4. Network Quota ………………………………………………………………………… 3.2.2.4. Network Quota ………………………………………………………………………… 3.2.2.4. Network Quota 9 3.2.3. TCP Protections ………………………………………………………………………… 9 3.2.3.1. SYN Attack Confi guration ………………………………………………………… 9 3.2.3.2. Small PMTU ………………………………………………………………………… 10 3.2.3.3. Sequence Verifi er …………………………………………………………………… 3.2.3.3. Sequence Verifi er …………………………………………………………………… 3.2.3.3. Sequence Verifi er 10 3.2.4. Fingerprint Scrambling Protections …………………………………………………… 10 3.2.4.1. ISN Spoofi ng ……………………………………………………………………… 11 3.2.4.2. TTL …………………………………………………………………………………… 3.2.4.2. TTL …………………………………………………………………………………… 3.2.4.2. TTL 11 3.2.4.3. IP ID ………………………………………………………………………………… 11 3.2.5. Successive Events Protections ………………………………………………………… 12 3.2.6. DShield Storm Center Protections …………………………………………………… 12 3.2.6.1. Retrieve and Block Malicious IPs ………………………………………………… 12 3.2.6.2. Report to DShield …………………………………………………………………… 13 3.2.7. Port Scan Protections …………………………………………………………………… 13 3.2.7.1. Host Port Scan ……………………………………………………………………… 13 3.2.7.2. Sweep Scan ………………………………………………………………………… 13 3.2.8. Dynamic Ports Protections …………………………………………………………… 14

Smart Defense Technical White Paper


3.3. Application Intelligence ……………………………………………………………………… 14 3.3.1. Automatic DCE RPC Protection ……………………………………………………… 14 3.3.2. Mail Security Protections ……………………………………………………………… 14 3.3.2.1.SMTP Content ……………………………………………………………………… 15 3.3.2.2. Mail and Recipient Content ………………………………………………………… 16 3.3.2.3.POP3/ IMAP Security ……………………………………………………………… 3.3.2.3.POP3/ IMAP Security ……………………………………………………………… 3.3.2.3.POP3/ IMAP Security 16 3.3.3.FTP Protections ………………………………………………………………………… 17 3.3.3.1.FTP Bounce ………………………………………………………………………… 17 3.3.3.2.FTP Security Server ………………………………………………………………… 3.3.3.2.FTP Security Server ………………………………………………………………… 3.3.3.2.FTP Security Server 17 3.3.3.2.1.Allowed FTP Commands ……………………………………………………… 17 3.3.3.2.3.Prevent Port Overfl ow Checking ……………………………………………… 17 3.3.4.Microsoft Protocols Protections ………………………………………………………… 18 3.3.4.1.File and Print Sharing ……………………………………………………………… 18 3.3.5.Peer-to-Peer Protections ………………………………………………………………… 18 3.3.5.1. Kaza ………………………………………………………………………………… 3.3.5.1. Kaza ………………………………………………………………………………… 3.3.5.1. Kaza 18 3.3.5.2. Gnutella ……………………………………………………………………………… 3.3.5.2. Gnutella ……………………………………………………………………………… 3.3.5.2. Gnutella 18 3.3.5.3. eMule ………………………………………………………………………………… 18 3.3.5.4. Skype ……………………………………………………………………………… 18 3.3.5.5. BitTorrent …………………………………………………………………………… 18 3.3.5.6. Yahoo ……………………………………………………………………………… 18 3.3.5.7. ICQ ………………………………………………………………………………… 19 3.3.6. Instant Messengers …………………………………………………………………… 19 3.3.6.1. MSN over SIP ……………………………………………………………………… 19 3.3.7. DNS Protections ………………………………………………………………………… 19 3.3.7.1. Protocol Enforcement ……………………………………………………………… 19 3.3.7.2. Domains Black List ………………………………………………………………… 20 3.3.7.3. Cache Poisoning …………………………………………………………………… 20 3.3.8. VoIP Protections ………………………………………………………………………… 21 3.3.8.1. H.323 Voice Protocol ……………………………………………………………… 21 3.3.8.2. SIP Voice Protocol ………………………………………………………………… 21 3.3.8.3. MGCP Voice Protocol ……………………………………………………………… 22 3.3.8.4. SCCP Voice Protocol ……………………………………………………………… 22 3.3.9. SNMP Protections ……………………………………………………………………… 224.0. SmartDefense Logging and Auditing ………………………………………… 235.0. Updating SmartDefense ……………………………………………………… 25

SmartDefense Technical White Paper


This technical white paper is designed to help customers, partners, and security administrators understand the unique capabilities of Check Point’s SmartDefense™. This paper can be read as a whole or used as reference for customers using SmartDefense. It is organized similar to the SmartDefense Tab within the Smart Dashboard management console, where protections and protection are organized much like this document.

1.0 Understanding SmartDefenseCheck Point SmartDefense enables customers to confi gure, enforce, and update network and application attack protections. In addition, SmartDefense provides information on attack defenses and access to those new attack defenses, as well as related information via SmartDefense Updates and Advisories published online by Check Point.

SmartDefense not only protects against a range of known attacks, varying from different types of Microsoft Networking worms to Distributed Denial-of-Service attacks, but it also incorporates intelligent security technologies that protect against entire categories of emerging, or unknown attacks.

SmartDefense is based on Check Point’s Stateful Inspection and Application Intelligence™ technologies, so it’s possible to block not only specifi c attacks, but also entire categories of attacks while allowing legitimate traffi c to pass.

Application Intelligence is a set of technologies that detect and prevent application-level attacks by integrating a deeper understanding of application behavior into network security defenses. The core functions of Application Intelligence are:

• Validating compliance to standards

• Validating expected usage of protocols

• Blocking malicious data

• Controlling hazardous application operations

Stateful Inspection, invented and patented by Check Point, (U.S. Patent # 5,606,668) analyzes information fl ow into and out of a network so that real-time security decisions can be based on communication session information as well as on application information. It accomplishes this by tracking the state and context of all communications traversing the fi rewall gateway even when the connection involves complex protocols.

SmartDefense is active by default on several Check Point enforcement points: VPN-1®/ FireWall-1®/ FireWall-1® ® gateways of version NG Feature Pack 3 and higher, and InterSpect. SmartDefense is available as a hotfi x for NG Feature Pack 2 installations. Each new SmartDefense release includes additional security capabilities. Customers are encouraged to use the latest version of SmartDefense. Future additions to SmartDefense will only be applied to Check Point gateways of NG with Application Intelligence R54 or higher.



2.0 The Components of SmartDefense

2.1. Enforcement Integrated with Check Point Products

SmartDefense blocks attacks at a Check Point enforcement point (either a gateway on an instance of SecureServer™) using Check Point’s Stateful Inspection and Application Intelligence technologies. Some of the SmartDefense capabilities are enforced as an integrated part of the fi rewall security policy and are distributed as part of the enforcement points’ security policy. In addition to the specifi c attack protections of SmartDefense, customers also benefi t from the strict access control to network resources offered by Check Point enforcement points.

SmartDefense controls can be active on the following enforcement points: FireWall-1, VPN-1 Pro™, VPN-1 Net, VPN-1/FireWall-1 VSX™, VPN-1/FireWall-1 SmallOffi ce (does not support SMTP security server), and VPN-1/FireWall-1 SecureServer™ (Does not support security server), InterSpect™, and Connectra™.

2.2. Management Integrated with SmartCenter

SmartDefense attack protections are confi gured within SmartDashboard to provide a single, centralized console for real-time information on attacks as well as attack detection, blocking, logging, auditing, and alerting. The console can be used to:

• Choose the attacks to defend against and read detailed information about the attack

• Easily confi gure parameters for each attack defense, including logging options

• Receive real-time information on attacks and update SmartDefense with new capabilities

SmartDefense can be managed using SmartCenter™, SmartCenter Pro™, SiteManager-1, or Provider-1™.

The SmartDefense user interface includes background details on attacks and hyperlinks to the Check Point SmartDefense Web site for more information on the nature and characteristics of attacks. In addition, valuable attack forensics are provided through Check Point’s rich log data and distributed logging infrastructure. This data provides security managers with knowledge about the nature of the attacks and potential responses, enhancing their understanding and control over network attacks. In addition, some SmartDefense attack detection capabilities are resident on the SmartCenter Server. These capabilities analyze logs from Check Point enforcement points, matching log entries to attack profi les, alerting administrators to repeated occurrences of attacks or other suspect behavior.

2.3. Monitor Only Mode

Several protections in SmartDefense can be confi gured in Monitor Only mode. This makes it possible to track unauthorized traffi c without blocking it. Traffi c that matches a protection will be logged in SmartView Tracker™. Monitor Mode can be used as a precursor to implementing a new protection on a live network.



2.4. SmartDefense Service: Subscription-based Updates to New Attack Protection

SmartDefense enforcement functionality is included with several Check Point products with no additional license. However, for the highest level of protection against changing threats, the SmartDefense Service enables administrators to apply ongoing updates to SmartDefense’s attack protection capabilities.

The latest information and advisories are published on the Check Point SmartDefense site at:

http://www.checkpoint.com/techsupport/documentation/smartdefense/index.html

Subscribing customers get one-click, automatic SmartDefense updates from within SmartDashboard. Check Point also publishes in-depth SmartDefense advisories about different mitigation factors for attacks that can be blocked without a SmartDefense update. Customers without a valid subscription license can access summaries of SmartDefense advisories, but can only update SmartDefense protections through the subscription service.

The SmartDefense Service includes updates for Web Intelligence, an optional Check Point product with specifi c protections for Web applications and servers. An additional license is required to use Web Intelligence™.

Monitor Only Mode Option and ‘M’ Icon Showing Protection in Monitor Mode



3.0 The SmartDefense StructureSmartDefense provides a unifi ed security framework for various components that identify and prevent attacks. The SmartDefense tab in the SmartDashboard is divided into a tree structure that classifi es the defenses provided by SmartDefense.

Each item in the tree refers to a category of functionality that includes defenses for families of attacks as well as more general attack protections and safeguards (e.g. scrambling system fi ngerprints). For example, SmartDefense blocks not just Blaster, but all similar variants because these attacks violate the proper connection fl ow as defi ned by the MS RPC protocol. As such, SmartDefense block attacks in a class-based manner that is not limited to a specifi c set of attack “signatures.” For each category and subcategory in the tree, the SmartDefense console allows administrators to confi gure attack protections and safeguards, as well as provides information on the attacks and vulnerabilities.

3.1. Anti-Spoofi ng Confi guration Status

IP address spoofi ng is a technique by which an intruder attempts to gain unauthorized access by altering a packet’s source IP address to make it appear as though the packet originated in a part of the network with higher access privileges. For example, a packet originating on an external network may be disguised as a local packet. If undetected, this packet will be processed by the rule base as having originated inside the fi rewall (i.e., possibly circumventing access controls). As such, it is important to verify where the packets originated.

Anti-spoofi ng verifi es that packets are coming from, and going to, the correct interfaces on the gateway. It confi rms that packets claiming to be from an internal network are actually coming from the internal network interface. It also verifi es that, once a packet is routed, it is going through the proper interface.

The SmartDefense Console



A Check Point enforcement point will block an illegal address. For example, an IP address from an external interface should not have a source address of an internal network. Legal addresses that are allowed to enter a Check Point enforcement point interface are determined by the topology of the network. When confi guring anti-spoofi ng protection, the administrator must tell FireWall-1 exactly which IP addresses behind the interface are legal.

This section indicates how anti-spoofi ng is confi gured. For gateways where anti-spoofi ng is not enabled, the “IP address behind this interface” attribute for the interface is shown as “Not Defi ned.” Administrators can change the settings by reconfi guring individual gateways.

3.2. Network Security

3.2.1. Denial-of-Service Protections

In contrast to an attack intended to penetrate or control target systems, the purpose of a Denial of Service (DoS) attack is to disrupt the normal operation of a system or service. This disruption is typically accomplished either by overwhelming the target with spurious data so that it is no longer able to respond to legitimate service requests, or to exploit vulnerabilities in applications or operating systems to remotely crash the machines.

This section describes SmartDefense protections for several common classes of DoS attacks.

3.2.1.1. Teardrop

Some implementations of the TCP/IP protocol stack do not properly handle the reassembly of overlapping IP fragments. Sending two IP fragments, with one fragment entirely contained inside the other, causes these faulty implementations to allocate too much memory and crash the server on which they run. TearDrop is a widely available attack tool that exploits this vulnerability.

Because proper reassembly is required for normal network operation, SmartDefense blocks attacks based on overlapping IP fragments even if the checkbox is deselected. By default, blocked attacks will be logged as “Virtual defragmentation error: Overlapping fragments.” Administrators can also choose to confi gure alerts, mail notifi cation, SNMP traps, or other user-defi ned actions when these attacks occur.

3.2.1.2. Ping of Death

The “Ping of Death” is a malformed PING request that some operating systems are unable to correctly process. The attacker sends a fragmented PING request that exceeds the maximum IP packet size (64KB), causing vulnerable systems to crash.

SmartDefense blocks this attack even if the checkbox is not selected. By default, blocked attacks will be logged as “Virtual defragmentation error: Packet too big.” Administrators can also choose to confi gure alerts, mail notifi cation, SNMP traps, or other user-defi ned actions when these attacks occur.

3.2.1.3. LAND

Some implementations of TCP/IP are vulnerable to packets that are crafted in a particular way —a SYN packet in which the source address and port are the same as

the destination address and port (i.e., spoofed). LAND is a widely available attack tool that exploits this vulnerability.

SmartDefense blocks this attack even if the checkbox is not selected. Administrators can also choose to confi gure alerts, mail notifi cation, SNMP traps, or other user-defi ned actions when these attacks occur.



3.2.1.4. Non-TCP Flooding

Hackers sometimes directly target security devices like fi rewalls. In advanced fi rewalls, state information about connections is maintained in a state table. The state table includes connection-oriented TCP and connectionless non-TCP protocols. Hackers can send high volumes of non-TCP traffi c in an effort to fi ll up a fi rewall’s state table. This results in a Denial of Service by preventing the fi rewall from accepting new connections. Unlike TCP, non-TCP traffi c does not provide mechanisms to “reset” or clear a connection.

SmartDefense can restrict non-TCP traffi c from occupying more than a pre-defi ned percentage of a Check Point enforcement point’s state table. This eliminates the possibility of this type of attack.

3.2.2. IP and ICMP Protections

These pages enable a comprehensive sequence of tests to ensure the integrity of communications at the network layer. A Check Point enforcement point performs full Stateful Inspection on IP and ICMP connections so that different protocol types are identifi ed, inspected, monitored and managed according to the packet fl ow security defi nitions. For each IP or ICMP packet a Check Point enforcement point identifi es its protocol type, performs protocol header analysis and performs protocol fl ags analysis and verifi cation.

3.2.2.1. Packet Sanity

This option performs several Layer 3 and Layer 4 “sanity” checks. These include verifying packet size, checking UDP and TCP header lengths, dropping IP options and verifying the TCP fl ags to ensure that packets have not been manually crafted by a malicious user, and that all packet parameters are correct.

This validation is always enforced. However, administrators can confi gure whether logs and/or alerts will be issued for offending packets.

3.2.2.2. Max PING Size

PING (ICMP echo request) is a protocol used to check whether a remote machine is running. A request is sent by the client and the server responds with a reply echoing the client’s data.

An attacker might PING (issue an ICMP echo request to) the target with a large echo data fi eld, trying to compromise the security of the client’s machine (for example causing a buffer overfl ow). This should not be confused with “Ping of Death,” in which the PING request is malformed.

This option can limit the maximum requested data echo size. The default maximum is 548 bytes, the maximum specifi ed in the protocol defi nition. Administrators can also confi gure whether logs and/or alerts will be issued for offending packets.

3.2.2.3. IP Fragments

When an IP packet is too big to be transported on a given network, it is split into several smaller IP packets and transmitted in fragments. In an attempt to conceal an attack or exploit, an attacker might break the data section of a single packet into several fragmented packets. Without reassembling the fragments, it is not always possible to detect such an attack. As a result, malicious content that is split across fragments can traverse some fi rewalls. In contrast, a Check Point enforcement point collects and reassembles all the fragments of a given IP packet, verifying that the options for the fragments are consistent (e.g. TTL is the same for all fragments), so that security checks can be run against the complete packet contents.



This page allows an administrator to confi gure whether fragmented IP packets can traverse Check Point gateways at all. It is also possible to allow fragments, setting a limit on the number of fragments allowed, and to set a timeout period for holding unassembled fragments before discarding them. These measures help to protect against Denial of Service attacks that seek to overwhelm the resources of perimeter security devices by fl ooding them with spurious packet fragments.

3.2.2.4. Network Quota

Network Quota enforces a limit upon the number of connections that are allowed to the same source IP address. When a certain source exceeds the number of allowed connections, Network Quota can either block all new connection attempts from that source or track the event. This capability is useful in protecting against Denial of Service attacks, and can help to limit worm propagation by recognizing an inappropriate increase in traffi c from an infected source.

The Network Quota protection enforces a limit on the number of connections that are allowed from the same source IP address. When the number of connection requests from a certain source exceeds the confi gured limit, Client Quota generates an alert and/or blocks all new connections from that source. This feature is particularly useful for preventing distributed denial of service attacks from overwhelming a server.

3.2.3. TCP Protections

TCP is the most common IP transport protocol used and includes Web applications as one of the many appl ications that rely on it for the reliable transmission of data. SmartDefense is able to inspect TCP segments and analyze a packet in order to verify that it contains allowed options only. In order to verify that TCP packets are legitimate, the following tests are conducted:

• protocol type verifi cation

• protocol header analysis

• protocol fl ags analysis and verifi cation

3.2.3.1. SYN Attack Confi guration

TCP is a connection oriented protocol with a defi ned “handshake” process. To begin a connection, a client sends a SYN (SYNchronize) connection request to a target host. The host then replies with an ACK (ACKnowledge) response. Finally, the client responds back with a SYN-ACK reply. This process is essential to TCP communications and is used to synchronize the two hosts before communications can begin.

SYN Flood Attacks consist of initiating a TCP handshake (SYN) and not sending the fi nal reply (SYN-ACK) to the server’s response (ACK) in the handshaking sequence. This causes the server to keep an open record in its pending connection queue. Because a server’s pending connection queue is fi nite in size, it is relatively trivial to completely fi ll the queue with a fl ood of fake SYNs. This results in the server being unable to accept valid TCP connections and results in a Denial of Service.

SmartDefense protects against SYN fl ood attacks on both protected servers and the Check Point enforcement point itself. This protection keeps hackers from overwhelming servers with false SYN requests.

SmartDefense provides two kinds of defense modes against SYN attacks and automatically switches between them as needed:

• Passive defense, which is the default behavior

• SYN Relay defense (logged as Active Defense), which automatically activates as soon as a SYN attack is detected



Passive SYN Gateway: This is the default action for SYN protection. In this mode, the Check Point enforcement point monitors the TCP handshake process. All SYN requests are passed to the target server, but a timer is started for each request. If the requesting client has not replied to the target host’s ACK response within the confi gured time frame, a TCP reset is sent to the server to drop the connection from the server’s pending connection queue. Because the timeout period is much shorter than the pending connection table, this minimizes the amount of pending TCP sessions. This mode provides increased SYN protection at an optimized performance.

SYN Relay: When SmartDefense detects a predefi ned number of unanswered SYN requests per given time period, it switches to SYN Relay Defense. SYN Relay counters the attack by making sure that the three way handshake is completed (that is, that the connection is a valid one) before sending a SYN packet to the target host. SYN Relay ensures that the protected server does not receive any invalid connection attempts, which is advantageous if the server has limited memory or often reaches an overloaded state. SYN Relay is a high-performance kernel-level process, which acts as a relay mechanism at the connection level.

3.2.3.2. Small PMTU

The MTU, or Maximum Transmission Unit of a given network link specifi es the largest allowable size of an IP packet on that link. PMTU, or “path” MTU refers to the smallest MTU in the path (i.e all of the links) from one device to another.

In a Small PMTU attack, the attacker fools a server into sending large amounts of data using very small packets by setting the PMTU to a very small value. Since each packet has a relatively large associated overhead, the target server can be overloaded.

The confi guration option “Minimal MTU size” sets a minimum allowable size for packets in a data stream, allowing FireWall-1 to deny connections that attempt to set this size unreasonably low. Some care should be taken in confi guring this option since an exceedingly small value will not prevent an attack, while an unnecessarily large value might result in legitimate requests being dropped.

3.2.3.3. Sequence Verifi er

The Sequence Verifi er matches the current TCP packet’s sequence numbers against a state kept for that TCP connection. Packets that match the connection in terms of TCP session, but have sequence numbers that do not make sense, are either dropped or stripped of data.

3.2.4. Fingerprint Scrambling Protections

“Fingerprinting” is a technique by which a remote host gleans information about a host or network by looking at the unintentional side effects of benign communications.

Techniques involve either active fi ngerprinting, by which the attacker sends slightly off-protocol packets and tries to glean information from the responses (or lack thereof), and passive fi ngerprinting, by which the attacker either generates no traffi c at all (and relies on passively received traffi c), or generates only 100% standard traffi c. These pages deal mainly with scrambling the passive fi ngerprints of hosts behind the fi rewall.

SmartDefense can scramble some of the fi elds commonly used for fi ngerprinting, masking the original identity of hosts behind the fi rewall. Please note, however, that totally preventing fi ngerprinting is next to impossible. Also note that while this feature makes fi ngerprinting the hosts protected by the fi rewall harder, it does little to hide the fact that there is a fi rewall here (i.e. - fi ngerprinting the fi rewall’s existence is still possible).



3.2.4.1. ISN Spoofi ng

The fi rst thing done when a TCP connection is established is to synchronize numbers called “sequences” between the client and the server. This is performed in a process called “three way handshake”. In this process, the client notifi es the server about the sequences for the client side of the connection, and the server notifi es the client about the sequences for the server side of the connection. The sequence chosen during the three-way handshake stage is called “Initial Sequence Number”, or ISN.

In addition to the attack described above, the mere fact that there’s a difference between the various algorithms for the different operating systems, creates a unique fi ngerprint for each system. By sending successive SYN requests and checking the difference between the ISNs, a potential attacker can fi gure out what operating system the server is running.

SmartDefense prevents this kind of reconnaissance by creating a difference between the sequence numbers used by the server and the sequence numbers perceived by the client.

3.2.4.2. TTL

Each IP packet has a fi eld called “Time to Live”, or TTL. Each router along the way decreases this value by one. When a router decrements this value to zero it drops the packet and sends an ICMP notifi cation (destination not reachable) to the source.

Typically, when a host sends a packet, it sets the TTL to a value high enough so that the packet can reach its destination under normal circumstances. Different operating systems use different default initial values for TTL. Because of this, an attacker can guess the number of routers between it and the sending machine by making an informed assumption about the original TTL. In addition, knowing which initial

TTLs were used gives some information about what operating system the host is running.

SmartDefense can change the TTL fi eld of all packets (or all outgoing packets) to a given number. This achieves two goals. First, using this approach it is not possible to know how many internal routers (hops) are between the target and the listener, and second, the listener cannot use knowledge of the default TTL value to make guesses about the operating system of the source.

3.2.4.3. IP ID

IP packets have a 16 bit fi eld called “ID”, used when an IP packet is fragmented. The ID allows the receiving machine to know which virtual packet the fragmented packets belong to. While there is a requirement that two IP packets have two distinct IP IDs, there is no formal specifi cation as to how to assign the IP ID to each packet.

Different operating systems use different algorithms for assigning IP IDs to packets. As a result, an attacker can use this information to understand what operating system generated the packet.

SmartDefense can override the original IP ID with one generated by the Check Point enforcement point, thus masking the algorithm used by the original operating system and consequently masking the operating system’s identity from potential attackers.



3.2.5. Successive Events Protections

Successive Events Detection (formerly known as Malicious Activity Detection) provides a mechanism for detecting malicious or suspicious events and notifying the security administrator.

Successive Events Detection runs on the SmartCenter Server™ and analyzes logs from Check Point enforcement points by matching log entries to attack profi les. The security administrator can modify attack detection parameters, turn detection on or off for specifi c attacks, or disable the Successive Events feature entirely. Logs that do not reach the SmartCenter Server are not analyzed. For example, this includes local logs and logs sent to a customer log module (CLM).

The types of malicious activity that can trigger successive events alerts include:

• Address Spoofi ng

• Local Interface Spoofi ng

• Port Scanning*

• Successive Alerts (an excessive number or alerts generated by policies in the Rule Base)

• Successive Multiple Connections (an excessive number of connections opened to a specifi c destination IP address and port number from the same source IP address)

• Successive Events can look for Port Scanning, however newer versions of SmartDefense include a new Port Scanning protection and should be used over Successive Events. It is included here for backwards compatibility.

For each, the administrator can confi gure the number of events required in a given time period needed to trigger an action, as well as the action itself.

3.2.6. DShield Storm Center Protections

The SmartDefense Storm Center Module enables a two way information fl ow between the network Storm Centers and the organizations requiring network security information. Storm Centers gather logging information about attacks. This information is voluntarily provided by organizations across the world for the benefi t of all. Storm Centers collate and present reports on real-time network security threats in a way that is immediately useful.

One of the leading Storm Centers is SANS Dshield.org. Check Point SmartDefense integrates with the SANS DShield.org Storm Center in two ways:

3.2.6.1. Retrieve and Block Malicious IPs

The DShield.org Storm Center produces a Block List report, which list address ranges that are worth blocking and is frequently updated. The SmartDefense Storm Center Module retrieves and adds this list to the Security Policy in a way that makes every update immediately effective.

SmartDefense enables the system administrator to decide whether to block all the malicious IP addresses received from DSchield.org or whether to block them for specifi c gateways. In addition, SmartDefense offers the system administrator the option of being informed (for example, log, alert, mail message, etc.,) when IP addresses from within the IP address ranges in the Block List attempt to access the network.



3.2.6.2. Report to DShield

Logs can be sent to the Storm Center in order to help other organizations combat the threats that were detected by SmartDefense and Web Intelligence. Administrators can decide which Check Point log type to send to the Storm Center.

The logs that submitted to the Storm Center contain the following information:

• Connection parameters: Source IP Address, Destination IP Address, Source Port, Destination Port (that is, the Service), IP protocol (such as UDP, TCP or ICMP)

• Rule Base Parameters: Time, action

• Detailed description of the log

• Name of the attack and the detected URL pattern are also sent for HTTP Worm patterns detected by Web Intelligence

To protect privacy, SmartDefense can delete identifying information from the destination IP address in the submitted log. Administrators can confi gure a mask size that defi nes how much of an internal address to delete. This ensures privacy for the organization while allowing the Storm Centers to correlate the attack information.

3.2.7. Port Scan Protections

Port Scans are reconnaissance attacks used by hackers to learn information about a network in preparation for an attack. This attack helps the hacker fi nd potential target hosts and the services running on that host. Attackers can then direct their efforts to exploits that take advantage of those services.

3.2.7.1. Host Port Scan

A host port scan is a reconnaissance attack directed at a specifi c host or network. A scan can determine which services a host offers. For example, a host port scan could discover that a certain host has TCP ports 23, 25, and 110 open, meaning it offers the Telnet, SMTP, and POP3 services, respectively.

3.2.7.2. Sweep Scan

An IP Sweep Scan looks for a specifi c open port and determines which hosts are listening in on that port. For example, IP Sweep Scans are used by network worms trying to fi nd machines that they can propagate themselves. For example, the Blaster worm looks for the RPC service —searching the entire network looking for that single open service.

ManagementServer

CorporateLocation A

CorporateLocation B

Network Storm Center

FireWall-1Gateway

FireWall-1Gateway

Block List

LoggingInformation

Block List

Internet



3.2.8. Dynamic Ports Protections

A number of application protocols (such as FTP and SIP protocols) set up connections by opening IP ports dynamically. These ports can sometimes be the same as those used by a pre-defi ned service using a well-known port (i.e. lower than 1024). Some attacks take advantage of this fact and attempt to bypass security enforcement by appearing to be generated by an allowed application that’s opening a port dynamically.

SmartDefense allows you to confi gure which ports are “privileged ports” that will be protected when opening a connection dynamically (for example FTP data connections). These ports are a subset of the ports of the TCP and UDP services defi ned. When trying to open a dynamic connection to such a protected port, the connection is dropped. In addition, it is possible to explicitly protect low ports (lower than 1024).

3.3. Application Intelligence

3.3.1. Automatic DCE RPC Protection

DCE-RPC is a protocol used by many applications in a networked environment. It allows client machines to access (call) a server for certain functions (procedures) as if the server were located on the client machine. Similar to the FTP protocol, clients and servers negotiate ports within the DCE-RPC session. For fi rewalls that must open or close ports to provide access control, DCE RPC can pose unique challenges because of the dynamic nature of the protocol. To traverse a fi rewall, either a wide range of ports must be left open to allow DCE-RPC or the fi rewall must understand DCE-RPC communications. Because of its popularity (i.e., used in nearly all Microsoft applications) DCE-RPC is often used by hackers in attacks (e.g., Blaster Worm, Spike). These attacks are based on malformed or objectionable DCE-RPC traffi c.

SmartDefense understands the DCE-RPC protocol and automatically applies several security features whenever DCE-RPC is allowed as part of the fi rewall security policy. No confi guration is required. These protections are based on the understanding of DCE-RPC formats, sessions, and defi ned fl ow.

Important Capabilities:Strict Protocol Enforcement: SmartDefense checks and verifi es protocol fi elds. This prevents worms and other attacks from using malformed DCE-RCP packets for attacks.

Protocol Flow Enforcement: SmartDefense monitors communication sessions to ensure that the state and fl ow adhere to the protocol. For example, SmartDefense ensures that new DCE-RPC sessions begin with a call to the server EndPointMapper (a.k.a. portmapper or rpcbind), defi ned as part of the DCE RPC protocol, to fi rst establish the ports to be used for the application session.

Dynamic Port Allocation: SmartDefense only opens ports as they are negotiated during the DCE-RPC session. This minimizes the number and length of time ports are open on the fi rewall.

Specifi c Application Identifi cation: For each application in a DCE-RPC environment, a globally unique Interface ID (GUID) is defi ned. For example, Microsoft Outlook would have an assigned GUID. SmartDefense recognizes GUIDs and will restrict DCE-RPC calls to only those applications allowed in the fi rewall policy.

3.3.2. Mail Security Protections

In a Mail and Recipient content attack, email worms, and viruses introduce malicious code that can reach your system and infect other users through harmful attachments. In addition, some viruses are transmitted through harmless-looking email messages and can run automatically without the need for user intervention.



Initially defi ned as a text-based message exchange, email today can be used to exchange non-text fi le types like audio and video across the Internet. MIME (Multipurpose Internet Mail Extension), RFC 2045 and 2046, was created as an extension to the basic email protocols to accommodate these other fi le types. SmartDefense can recognize MIME attachments and limit their potential to introduce malicious content. By default SmartDefense does not allow multiple content-type headers. Although the security administrator has the option of allowing multiple content-type headers, the SmartDefense default suggests that such a decision can open the network to malicious behavior and as such recommends a limitation of content-type headers.

SmartDefense strips MIME attachments of the specifi ed type from the message. For example, the message/partial MIME type is stripped to prevent fragmented and reassembled messages. The message/partial MIME type can be used to bypass most of the security restrictions imposed on email messages (because the messages are cut into smaller segments), so that the malicious message cannot be detected by virus scanners or other content testing mechanisms.

3.3.2.1. SMTP Content

The SMTP security server allows for the strict enforcement of the SMTP protocol. It protects against malicious mail messages, provides SMTP protocol centered security, prevents attempts to bypass the Rule Base using mail relays, and prevents Denial of Service and spam mail attacks.

Usually, the SMTP security server is activated by specifying resources in the rule base. However, selecting “Confi guration applies to all connections” will forward all SMTP connections to the SMTP security server and enforce the defi ned settings on all connections; selecting “Confi gurations apply only to connections related to rule base defi ned objects” means that these confi gurations will apply only to SMTP connections for which a resource is defi ned in the rule base.

Note: the settings in the Mail and Recipient Content window apply only if an SMTP Resource is defi ned, even if Confi gurations apply to all connections is checked.

The SMTP Security Server provides Content Security that enables an administrator to:

• provide mail address translation by hiding outgoing mail’s From address behind a standard generic address that conceals internal network structure and real internal users

• perform mail fi ltering based on SMTP addresses and IP addresses

• strip MIME attachments of specifi ed types from mail

• strip the Received information from outgoing mail, in order to conceal internal network structure

• drop mail messages above a given size

• send many mail messages per single connection

• resolve the DNS address for mail recipients and their domain on outgoing connections (MX Resolving)

• control the load generated by the mail dequeuer in two different ways:

- control the number of connections per site

- control the overall connections generated by the mail dequeuer

• provide a Rule Base match on the Security Server mail dequeuer which enables:

- a mail-user based policy

- better performance of different mail contents action per recipient of a given mail

- generation of different mail contents on a per-user basis

- application of content security features at the user level

- perform CVP (Content Vectoring Protocol) checking (for example, for viruses) with a third-party solution



3.3.2.2. Mail and Recipient Content

Note - The settings in this section apply only if an SMTP Resource is defi ned, even if all connections in the SMTP Security Server window are checked.

The SMTP Security Server does not provide authentication because there is no human user at a keyboard who can be challenged for authentication data. However, the SMTP Security Server provides Content Security that enables the security administrator to provide mail address translation by hiding “From” addresses behind a standard generic address that conceals internal network structures and real internal users, performs mail fi ltering based on SMTP addresses and IP addresses, and strips MIME attachments of specifi ed types from mail.

The settings on this page are summarized below:Allow multiple content-type headers - Unchecked by default; if checked, the SMTP Server will allow multiple content-type headers.

Allow multiple “encoding” headers - Unchecked by default; if checked, the SMTP Server will allow multiple “encoding” headers.

Allow non-plain “encoding” headers - Unchecked by default; if checked, the SMTP Server will allow nonplain “encoding” headers.

Allow unknown encoding - Checked by default; if checked, the SMTP Server will allow unknown encoding methods.

Force recipient to have a domain name - Checked by default; if checked, the SMTP Server will force the recipient to have a domain name.

Perform aggressive MIME strip - Checked by default:

• if checked, the entire mail body will be scanned for headers such as “Content- Type: text/html; charset=utf-8” and the MIME strip will be performed accordingly

• if unchecked, only the mail headers section and the headers of each MIME part will be scanned (If a relevant header is located, the MIME strip will be performed accordingly)

3.3.2.3. POP3/ IMAP Security

SmartDefense offers options that enable limitations on email messages delivered to the network using POP3/IMAP protocols. These options make it possible to recognize and stop malicious behavior. For example, SmartDefense can limit the length of a username and password. An attacker can send a long string of characters when it is not expected and may cause a Buffer Overfl ow attack that might crash the machine. In addition, SmartDefense can check and block binary data contained within POP3/IMAP messages.

SmartDefense can check POP3/IMAP usernames and password against the user database defi ned in VPN-1/FireWall-1. Based on this information, Administrators can confi gure SmartDefense to block connections when the username and password are identical.

SmartDefense ensures that POP3 and IMAP traffi c adhere to the established protocols and security best practices. SmartDefense monitors the communication state of connections and can, for example, block a LIST command because the user was not fi rst authenticated as required by the protocol. In addition, SmartDefense can limit the number of NOOP commands issued. The NOOP command (No Operation) is rarely used by email clients but is used in certain Denial of Service attacks.



3.3.3. FTP Protections

These pages allow administrators to confi gure various protections related to the FTP protocol.

3.3.3.1. FTP Bounce

As specifi ed by the FTP protocol when issuing the PORT command as part of the FTP control session, the originating machine specifi es an arbitrary destination address and port for the data connection. However, this behavior also means that an attacker can open a connection to a port of his or her own choosing on a machine that may not be the originating client. Making this connection to an arbitrary machine for unauthorized purposes is the FTP Bounce attack.

SmartDefense protects against FTP Bounce attacks by allowing only FTP sessions where the control and data session IP addresses match. Administrators can also confi gure preferred tracking options.

3.3.3.2. FTP Security Server

The FTP Security Server provides Authentication services and Content Security based on FTP commands (PUT/GET); fi le name restrictions, and CVP checking (viruses for example). In addition, the FTP Security Server logs FTP get and put commands, as well as the associated fi le names.

The FTP Security Server is typically enabled by specifying rules in the fi rewall security policy. However, by setting the option for “Confi guration applies to all connections” the fi rewall will forward all FTP connections to the FTP security server.

3.3.3.2.1. Allowed FTP Commands

For security reasons, you can limit the FTP commands allowed to pass through FireWall-1

3.3.3.2.2. Prevent Known Ports Checking

You can select whether to allow the FTP security server to connect to well-known ports. Thus you will provide a second layer of protection against certain bounce attacks. Even if the attacker manages to bounce the connection, that security server will not let the bounce connect to any port running a known service.

SmartDefense blocks attempts to issue FTP PORT commands to connect to well-known TCP or UDP port numbers (e.g. port 23 for Telnet).

Note: By default, SmartDefense is confi gured to perform known ports checking for FTP connections. By toggling the checkbox to ‘on’ administrators may disable this enforcement point. In general, disabling this check is only recommended when needed to preserve connectivity for a specifi c application that cannot comply with the safeguard.

3.3.3.2.3. Prevent Port Overfl ow Checking

To conform the FTP protocol, the PORT command has the originating machine specify an arbitrary destination and port for the data connection. By using different representations of the same number, attackers can attempt to bypass restrictions and PORT connections.

SmartDefense blocks connections that use multiple representations of the same number in an FTP PORT command.

Note: By default, SmartDefense is confi gured to perform PORT overfl ow checks for FTP connections — toggling the checkbox to “on” disables this enforcement. In general, disabling this check is only recommended when the administrator needs to preserve connectivity for a specifi c application that cannot comply with the safeguard.



3.3.4. Microsoft Protocols Protections

These pages specify the types of enforcement to be applied to Microsoft networking protocols. Clicking “Confi guration applies to all connections” will enforce these settings on all connections.

3.3.4.1. File and Print Sharing

CIFS, The Common Internet File System (sometimes called SMB for “Server Message Block”) is a protocol for sharing fi les and printers in a Microsoft environment. The protocol is implemented and widely used by Microsoft operating systems. CIFS has many known vulnerabilities, including Null Session exploits and Host Announcement Flooding. In addition, many worms that have infected a host use CIFS as a means of propagation. In fact, SANS has identifi ed Unprotected Windows Networking Shares as one of the top twenty critical threats to Internet security (www.sans.org/top20) in part because of the frequency of exploits that target this vulnerability.

This page allows administrators to confi gure worm signatures that will be detected and blocked by the Check Point enforcement point. This detection takes place in the kernel and does not require a security server.

3.3.5. Peer-to-Peer Protections

Peer-to-peer applications pose security concerns for organizations as they become increasingly popular and more intelligent in how they interconnect peer nodes. In the past, peer applications were easy to block because they used central servers to coordinate their communication. Today peer-to-peer applications are often diffi cult to detect for many reasons, including their ability to use proprietary protocols across any available port. They masquerade as HTTP traffi c across the typically allowed port 80, and innovative mechanisms for using reachable peers as a proxy to reach other peers blocked by a fi rewall. Peer-to-peer applications have emerged as a potential covert channel for transferring confi dential information across the traditional security perimeter.

This protection detects and blocks the most widely used peer-to-peer applications. Once confi gured, it can detect peer-to-peer applications running across all 64,000 possible ports. In addition, it inspects HTTP traffi c to detect peer-to-peer applications masquerading as HTTP traffi c across port 80. This protection includes HTTP header value defi nitions for most common peer-to-peer applications and allows Administrators to add additional headers if needed. In addition, the SmartDefense Service allows updates to these headers as they become available.

The Exclusion Settings options allow specifi c ports or hosts to be excluded from peer-to-peer checking. SmartDefense can monitor the following peer-to-peer applications and their variants:

3.3.5.1. Kaza

iMesh and Grokster are identifi ed in the SmartView Tracker as KaZaA.

3.3.5.2. Gnutella

Gnutella, Bearshare, Shareaza and Morpeheus are identifi ed in the SmartView Tracker as Gnutella

3.3.5.3. eMule

3.3.5.4. Skype

3.3.5.5. BitTorrent

3.3.5.6. Yahoo



SmartDefense recognizes Yahoo! Messenger used for messaging, voice, video, or fi le transfer

3.3.5.7. ICQ

SmartDefense recognizes ICQ used for messaging, voice, video, or fi le transfer

Important Capability:Defeats Peer-toPeer Firewall Traversal: Most peer-to-peer applications include Firewall Traversal features, which look for open ports in the fi rewall. SmartDefense can detect peer-to-peer applications attempting to traverse any open port.

Prevents HTTP Masquerading: Many peer-to-peer applications can hide by encapsulating their communications in HTTP. SmartDefense can detect and block these connections.

Defeats Peer-to-Peer Proxies: In some peer-to-peer applications, peer nodes communicate location information in a similar way as dynamic routing protocols. This information allows an internal peer to initiate a connection from inside the network, traversing fi rewalls that consider any connection initiated from inside the network as safe. SmartDefense blocks these types of connections.

3.3.6. Instant Messengers

3.3.6.1. MSN over SIP

MS Messenger uses the SIP protocol for real time voice, video, and collaboration communication. Just like other network applications, MS Messenger can be exploited bya hacker in an attack.

This protection provides several security protections for MS Messenger. SmartDefense can block all MS Messenger traffi c or restrict specifi c allowable actions: fi le transfer, application sharing, white board, remote assistant. In addition, SmartDefense will apply the general SIP protections as confi gured in Smart Dashboard.

3.3.7. DNS Protections

DNS protocol is the standard Internet protocol that maps human readable addresses(example, www.checkpoint.com) to device readable IP addresses. To infect a network with malicious content, attackers attempt to change the content of a DNS packet with the hope that it will enter the network undetected. Thus, when a client asks for a name to an IP address resolution from an infected DNS server, they may receive an IP address pointing them to a hacker or to a non-existent host.

SmartDefense is able to recognize a DNS packet that has been altered. This ability enables SmartDefense to catch potentially harmful packets before they enter the network.

DNS queries are generally transmitted over UDP, but in some cases are exchanged over TCP, such as during Zone Transfers between DNS servers. SmartDefense enables a system administrator to enforce DNS over TCP and UDP protocols. Protections will be applied to all DNS port connections over UDP and TCP to prevent hackers from using DNS for an attack.

3.3.7.1. Protocol Enforcement

By selecting the “UDP protocol enforcement option”, administrators can confi gure VPN-1/FireWall-1 to monitor DNS traffi c in order to ensure compliance with DNS RFCs, meaning that the DNS packets are correctly formatted and contain only DNS-related information. DNS enforced RFCs include 1034, 1035, 1996, 2136, 2317, 2535, and 2671. SmartDefense will check several RFC defi ned parameters, for example lengths, counters, header fl ags, domain format, Resource Record format, etc.



3.3.7.2. Domains Black List

A Black List is a group of URL addresses that have been prohibited. SmartDefense contains a Black List for the purpose of fi ltering out undesirable traffi c. SmartDefense will not allow a user to access a domain address specifi ed in the Black List. The domain Black List can be updated manually or automatically as part of the SmartDefense Service.

3.3.7.3. Cache Poisoning

To reduce DNS traffi c, name severs maintain cache. Each DNS record includes a TTL value, which tells the DNS Server how long the record can be stored in the cache before the record should expire. Cache Poisoning occurs when DNS caches mapping information that was deliberately altered from a remote name server. The DNS server caches the incorrect information and sends it out as the requested information. As a result, email messages and URL addresses can be redirected and the information sent by a user can be captured and corrupted.

3.3.7.3.1. Scrambling

DNS performs limited authentication for DNS transactions, checking only source and destination IP addresses, port numbers, and query ID. Query IDs are assigned by the host that initiates the DNS query. Hackers use several techniques to obtain a valid query ID, exploiting weaknesses in random number generators in DNS servers and employing advanced statistical analysis (e.g., Birthday attack). Given the ID number and source port, an attacker can send a spoofed reply that contains false information on behalf of the name server to which the request was initially sent. This enables the redirection of the hosts to fake Web sites that can be used to collect private user information.

To protect the corporate DNS server from Cache poisoning, SmartDefense has the ability to scramble the source port and query ID number of each DNS request. The protection can be applied either to all traffi c or to specifi c servers.

3.3.7.3.2. Drop Inbound Requests

DNS is a distributed protocol where information is distributed throughout the Internet rather than hosted in a single place. The DNS protocol defi nes a process that lets clients fi nd the correct DNS server with the information required. For each domain there are one or more authoritative domain severs, servers responsible for keeping and distributing DNS information for the domain. Because these are considered the defi nitive repository of domain information they are also an attractive target for a hacker. A hacked authoritative DNS server would pose a problem for not just a few users, but potentially all users on the network trying to connect to an organization’s domain.

SmartDefense allows an organization to minimize the risk to an authoritative domain server. Since the server is authoritative for a pre-defi ned set of domains, inbound DNS queries for other domains would not be expected. SmartDefense can restrict inbound requests to a DNS server to only those related to the defi ned domains. Any inbound requests for domains not defi ned in SmartDefense are blocked.

3.3.7.3.3. Mismatched Replies

A mismatched reply occurs when a DNS query results in an answer that does not match the requested information. Mismatched replies indicate an attempt to perform DNS Cache Poisoning. When a large number of mismatched replies occur over a specifi c period of time, it can be assumed that the network has been corrupted.

To protect the network from Cache Poisoning, SmartDefense employs a threshold. The threshold detects mismatched replies when more than a specifi c amount occurs over a specifi c amount of time. When the threshold limit is reached, the incidents of mismatched replies are logged and an alert is issued.



3.3.8. VoIP Protections

Voice and video traffi c, like any other information on the corporate IP network, has to be protected as it enters and leaves the organization. Possible threats to this traffi c are:

• Call redirections, where calls intended for the receiver are redirected to someone else

• Stealing calls, where the caller pretends to be someone else

• Unauthorized free toll calls

• Denial of Service attacks caused by hacking a VoIP device or spoofi ng a call termination message

• Systems hacking using ports opened for VoIP connections

For more information, VoIP White Papers are available at www.checkpoint.com.

Important Capabilities:In addition to the protections and capabilities offered through fi rewall policies (i.e., VoIP Domains, NAT traversal, etc.), SmartDefense provides enhanced security capabilities for VoIP protocols:

Dynamic Ports: Opens fi rewall ports only when needed. Opens only ports negotiated during VoIP call setup, even those communicated within the protocol itself.

Flow Enforcement: Monitors the state of communication between VoIP endpoints and ensures that they follow the fl ow defi ned by the individual RFCs. This helps prevent hijackers from interjecting malicious traffi c outside the regular call session process (example, sending a fake call termination notices in an attempt to fool a billing system).

3.3.8.1. H.323 Voice Protocol

H.323 is an ITU (International Telecommunication Union) standard that specifi es the components, protocols and procedures that provide multimedia communication services, real-time audio, video, and data communications over packet networks, including Internet protocol (IP) based networks.

SmartDefense supports H.323 version 2, which includes H.225 version 2 and H.245 version 3. It performs the following application layer checks:

- Strict enforcement of the protocol, including the order and direction of H.323 packets

- If the phone number sent is longer than 24 characters the packet is dropped, preventing buffer overruns in the server

- Dynamic ports will only be opened if the port is not used by another service (For example: if the Connect message sends port 80 for the H.245 it will not be opened—preventing well-known ports from being used illegally)

3.3.8.2. SIP Voice Protocol

SIP (Session Initiation Protocol) is a Voice over IP protocol, transported over UDP. SIP is one of the most popular VoIP protocols with integration in many applications, including Microsoft Windows XP and MS Messenger. SIP is an application-layer control protocol used for creating, modifying, and terminating sessions with one or more participants.

SmartDefense Application Intelligence ensures packets conform to RFC 3261 for SIP over UDP/IP (SIP over TCP is not supported), and inspects SIP-based Instant Messaging protocols. It protects against Denial of Service (DoS) attacks, and against penetration attempts such as connection hijacking and connection manipulation.



SmartDefense validates the expected usage of the SIP protocol. For example, if an end of call message is sent immediately after the start of the call, the call will be denied because this behavior is characteristic of a DoS attack.

Application Level checks include

- Checks for binaries and illegal characters in the packets

- Strict RFC enforcement for header fi elds

- Header fi elds length restrictions

- Removal of unknown media types

3.3.8.3. MGCP Voice Protocol

MGCP is a protocol for controlling telephony gateways from external call control devices called Call Agents (also known as Media Gateway Controllers).

MGCP is a client/server protocol, which means it assumes limited intelligence at the edge (endpoints) and intelligence at the core (Call Agent). In this it differs from SIP and H.323, which are peer-to-peer protocols.

SmartDefense provides full network level security for MGCP. SmartDefense enforces strict compliance with RFC-2705, RFC-3435 (version 1.0) and ITU TGCP specifi cation J.171. In addition, SmartDefense provides inspection of fragmented packets, anti spoofi ng, and protection against Denial of Service attacks. SmartDefense restricts handover locations and controls signaling and data connections. NAT on MGCP is not supported.

SmartDefense can perform additional content security checks for MGCP connections, thereby providing a greater level of protection. MGCP specifi c Application Intelligence security is confi gured via SmartDefense. Three options are available:

- Defi ne individual MGCP commands to accept or block

- Verify MGCP header content

- Allow multicast RTP connections

3.3.8.4. SCCP Voice Protocol

SCCP (Skinny Client Control Protocol) controls telephony gateways from external call control devices called Call Agents (also known as Media Gateway Controllers). SCCP is a VoIP protocol used in many Cisco voice implementations.

SmartDefense provides full connectivity and network level security for SCCP based VoIP communication. All SCCP traffi c is inspected, and legitimate traffi c is allowed to pass while attacks are blocked. All SmartDefense capabilities are supported, such as anti-spoofi ng and protection against Denial of Service attacks. SmartDefense restricts handover locations, and controls signaling and data connections. Fragmented packets are examined and secured using kernel based streaming. NAT on SCCP devices is not supported.

SmartDefense tracks state and verifi es that the state is valid for all SCCP message. For a number of key messages, it also verifi es the existence and correctness of the message parameters.

3.3.9. SNMP Protections

SNMP is part of the Internet protocol suite that provides a coherent framework for the management of various network devices. It is frequently used for managing network devices. The



current implementation of SNMP is version 3. In terms of security, SNMP versions 2 and 3 provide enhanced security over version 1. SNMPv3 contains security features such as authentication, authorization, access control, data integrity, key management, and encryption options not available in previous SNMP versions.

Hackers exploit several issues related to SNMP. SNMP packets can be used to gain information about network devices, a particular concern in older versions of SNMP that didn’t include authentication or other security features. In addition, default community strings (similar to a password for SNMP) are widely known for many vendors. Hackers can use this information to monitor or confi gure devices using these default strings.

SmartDefense provides several security features for SNMP. SmartDefense can be confi gured to permit only the more secure SNMPv3, rejecting SNMP versions 1 and 2. If SNMP versions 1 and 2 are required, SmartDefense can block SNMP packets using particular community strings. Several well known default community strings are preconfi gured, but Administrators can defi ne their own set of strings to block. This allows continued use of the less secure SNMP versions 1 and 2 while increasing security by eliminating attacks using well-known default community strings.

4.0 SmartDefense Logging and AuditingSmartDefense integrates with the Check Point log infrastructure by adding attack log entries and relevant views in SmartView Tracker, SmartView Monitor™, and SmartView Reporter™.

Attacks are identifi ed when violations of specifi c settings occur. A dedicated log view-mode is used to list SmartDefense attacks, including those identifi ed by protections in Monitor Mode. This view can be accessed by clicking on the link to “View SmartDefense Logs in SmartView Tracker” in the General section of the SmartDefense console window. For each logged attack, SmartDefense records the attack category, source, destination, service, action taken, date and time.

Example: SmartDefense view in SmartView Tracker



Example: Detailed Log Entry in SmartView Tracker

Example: SmartDefense View in SmartView Monitor



In addition to logs of individual events, SmartDefense-specifi c log information can be accessed in real-time via SmartView Monitor or as a set of historical trends for analysis in SmartView Reporter. Administrators can look at trends such as the top attacks blocked, the top sources of blocked attacks and the top targets of blocked attacks.

5.0 Updating SmartDefenseIn a dynamic security environment, where new threats and vulnerabilities are discovered on a daily basis, it is important to provide update capabilities. The types of functionality that can be updated by the SmartDefense Service are as follows:

Update feature Functionality

New SmartDefense Components New SmartDefense capabilities that can block categories of attacks (i.e. an item in the SmartDefense tree)

INSPECT scripts Update new INSPECT scripts in order to mitigate different security vulnerabilities

CIFS worm defi nition New CIFS worm patterns

New Services Creation of new services and relevant code

Check Point SmartDefense Service provides customers with frequent attack mitigation updates, including updates for Web Intelligence (requires Web Intelligence license). The customer’s management server retrieves new signature patterns, protocol defi nitions and attack mitigation solutions from Check Point and distributes them to enforcement points.

Administrators can update SmartDefense simply by clicking on the “Update Now” button on this page. In addition, by selecting the “Check for new updates” option, administrators can confi gure SmartDashboard to check for new defenses on startup.

Example: SmartDefense View in SmartView Reporter (Top Attacks)



This shows a confi rmation of receipt of a new SmartDefense Update.

This shows the results of an update in the SmartDefense Console. Two new attack patterns (CIFS null sessions and Windows Messenger Service are noted in bold.)



CHECK POINT OFFICES:

International Headquarters:3A Jabotinsky Street, 24th FloorRamat Gan 52520, IsraelTel: 972-3-753 4555Fax: 972-3-575 9256e-mail: [email protected]

U.S. Headquarters:800 Bridge ParkwayRedwood City, CA 94065Tel: 800-429-4391 ; 650-628-2000Fax: 650-654-4233URL: http://www.checkpoint.com

© 2004 Check Point Software Technologies Ltd. All rights reserved. Check Point, Application Intelligence, Check Point Express, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FireWall-1 XL, FloodGate-1, INSPECT, INSPECT XL, InterSpect, IQ Engine, Open Security Extension, OPSEC, Provider-1, Safe@Offi ce, SecureKnowledge, SecurePlatform, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, , and VPN-1 VSX are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affi liates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726 and 6,496,935and may be protected by other U.S. Patents, foreign patents, or pending applications.

About Check Point Software Technologies

Check Point Software Technologies is the worldwide leader in securing the Internet. It is the confi rmed market leader of both the worldwide VPN and fi rewall markets. Check Point provides Intelligent Security Solutions for Perimeter, Internal and Web Security. Based on INSPECT, the mostadaptive and intelligent inspection technology and SMART Management, which provides the lowest TCO for managing a security infrastructure, Check Point’s solutions are the most reliable and widely deployed worldwide. Check Point solutions are sold, integrated and serviced by a network of 1,900 certifi ed partners in 86 countries. For more information, please call us at (800) 429-4391 or (650) 628-2000 or visit us on the Web at http://www.checkpoint.com or at http://www.opsec.com.

Documents

Smart Defense Technical White Paper - kippdata.de