Введение в R71

©2010 Check Point Software Technologies Ltd. | [Unrestricted] For everyone

Введение в R71

Антон Разумов[email protected]Консультант по безопасностиCheck Point Software Technologies

22©2010 Check Point Software Technologies Ltd. | [Unrestricted] For everyone |

R71

New feature release Released in Q2 2010

What’s new with IPS ? IPSec VPN Enhancements Improved Anti-Virus Performance SecureXL by default in UTM-1 appliances Security Management Enhancements

Firewall Rule Expiration Automatic Deletion of Old Database Versions Object Management Improvements Other Enhancements

Data Loss Prevention (DLP) Blade SSL VPN Blade


Agenda IPS

2

1 Introduced in R70.20 (and now integral part of R71)

3

R71 IPS contract enforcement

R71 IPS other news


IPS Event Analysis (IPSA)

Old front page

Timeline

StatisticsCritical events


Prevention – Block Specific Region

Geo-Protection allows Complying with certain regulation by

blocking and logging of traffic from certain states

Analyzing where attacks come from Increase/Decrease confidence a

certain event is an attack based on where it came from

Identify malware trying to “call home”


Geo Protection View


Other

Web Intelligence Log improvements Web server type and Browser type is included in IPS

logs of Web related protections

Logs now show the original IP addresses of proxied connections

Packet capture on first trigger of any protection


IPS R71 Management – Overview

Located in IPS tab of the SmartDashboard

Information on unified updates available.

RSS feed of recently updated protectionsQuick view of alerts in the network


IPS-1 Sensor – Management

Choose to also manage IPS-1.

Each sensor/GW is listed.

Profiles contain both IPS-1 and IPS Software Blade protections, and can be applied to both

IPS-1 appliances and GWs.

Select which type of sensor to add.

List of IPS-1 and IPS Software Blade GWs.


Agenda IPS

2


3


R71 IPS other news



Software blade Architecture was released in March of 2009 as R70

The IPS Software Blade is a Service Blade, which requires an annual subscription in order to use it and download protection updates

Starting R71, each Security Gateway must have a valid subscription, also known as an “IPS contract”


Contract types

There are 4 types of IPS Software Blade contracts: CPSB-IPS – This contract covers most Open server gateways, all

Power-1 gateways and some of the UTM-1 models CPSB-IPS-S1- This contract covers UTM-1 130, UTM-1 270,

UTM-1 570 and SG101 CPSB-IPS-HA - This contract is for secondary cluster members in

a gateway cluster, and covers most Open server gateways, all Power-1 gateways and some of the UTM-1 models

CPSB-IPS-S1-HA- This contract is for secondary cluster members in a gateway cluster and covers UTM-1 130, UTM-1 270, UTM-1 570 and SG101

Each contract must be attached to a Blade Container


Contracts information

To check if a gateway has a valid contract just locate the gateway container in the UserCenter

Choosing a container, you will be able to see associated contracts

Contracts information must be imported into SmartUpdate in order to use IPS Blade

See sk44245


Contract notifications

SmartUpdate can show notifications about expired contracts

Messages window in IPS tab will also show this information


Contract notifications

Policy install will also notify about IPS contract issues


Insufficient IPS contract coverage

If an IPS contract is not available the IPS Blade functionality will be restricted as follows:

Protections will be limited to only those protections which were available as of March 2009 (the same protection set which existed when R70 was released). All protections introduced after March 2009 will be disabled.


IPS Blade Grace periods

Grace periods are periods after the IPS blade license expires, in which the protections will still be active and no restrictions are made, but warnings are issued regarding the missing contracts.

The grace period is set for 60 days starting from the latest contract expiration date on that gateway.

The grace periods are calculated per gateway individually.


Agenda IPS

2


3


R71 IPS other news


IPS updates

With R71 it is now possible to schedule IPS updates

Policy can also be installed after updates

Offline updates are available after special EULA terms (next slide)


Offline update

Customer must send Check Point a mail to get access to offline updates at this page: http://www.checkpoint.com/defense/updates/index.html


Service based link selection


Agenda Service Based Link Selection

2

1 Introduction

3

Overview and technology

Scenarios


Introduction and terminology

Source based routing Not to be confused with “source routing” where the source

determines the network route This means to decide a route down the network based on the

source IP of the packet and is typyically considered a part of: Policy based routing

Policy-based routing may also be based on the size of the packet, the protocol of the payload, or other information available in a packet header or payload such as the service. This permits routing of packets originating from different sources to different networks even when the destinations are the same and can be useful when interconnecting several private networks.


What does R71 introduce ?

Expansion on existing technologies IPSEC VPN Link selection on VPN gateway

► Outgoing packet (ergo outbound)► Remote peer selection (ergo inbound)► Uses probing mechanism (UDP 259)

Only method available up to R71 was hot standby HA, one link active at any given time.

R71 introduces VPN link loadsharing Service based link selection



2

1 Introduction

3


Scenarios


Link Selection …Why ?


When all else fails, use dial-

up (or DSL or FR)

Link Selection – how should the gateway behave ?

ISP 2

ISP 1

ISDN

Use primary ISP to establish VPN with

peer GW

Use another ISP as backup

Test peer GW availability through

each link “ping”

Peer’s available on this link

“pong”

“ping”

Peer’s available on this link, too

“pong”


Link Selection

The challenge is connectivity How should remote peers select the IP of the

Gateway? How should the Gateway route its own outgoing VPN

traffic? The mechanisms used for this feature have been

enhanced since ‘NGX R60’


Link Selection The first mechanism determines how remote peers resolve the IP address

of the local Gateway Remote peers can connect to:

The main IP Address of the Gateway A single IP address reserved for VPN (which does not have to be an interface

IP ( the address could be the statically NATed IP address of the VPN Gateway) One of Multiple IP addresses available for VPN traffic

If a Gateway has multiple IP addresses available for VPN traffic, then the correct address for VPN is discovered through one of the following:

Topology information contained in the network object DNS lookup One-time RDP probing (via RDP packets) On-going probing (via RDP packets)

For both the probing options (one-time and on-going) a Primary Interface can be assigned. If not all of Gateway’s interfaces are used for VPN, a smaller set of interfaces can be selected


Link Selection

The second mechanism, Route Based Probing (for link selection), also uses RDP probing to determine how the local Gateway selects an interface for outgoing VPN traffic. Using Route Based Probing, the Gateway consults the routing tables, and selects an active link with the lowest metric (highest priority).

These 2 mechanisms cover a lot of connectivity scenarios: As examples the manual covers the following

► Gateways with a single IP for VPN► Gateways with several IP addresses used by different parties for VPN

Gateways hidden behind a static NAT device Gateways located on an internal private network

► Gateways with a dynamic IP address for VPN► Gateways with multiple IPs providing High Availability (HA)


Link Selection

High Availability, incoming tunnel

Remote peer polls Local Gateway to discover the IP associated with the interface available for VPN

If one link goes down, an alternative link is used for VPN traffic.

Remote peer

eth0eth0

eth1

Local gateway


Link Selection - Example

The IP used for outgoing traffic on the Local Gateway is determined via the Route Based Probing mechanism

Each entry in the routing table contains the following information: Destination IP Address Prefix Source Interface IP address of the next-hop router

After probing all routing possibilities, the Gateway selects the best match (highest prefix length) active route with the lowest metric, and hence the highest priority

High Availability, outgoing tunnel

eth0eth0

eth1

Local gateway

Remote peer



2

1 Introduction

3


Scenarios


Link Selection

eth0

eth1

eth0

eth1

primary primary

High Availability


Link Selection

eth0

eth1

eth0

eth1

Load Sharing


Link Selection

eth0

eth1

eth0

eth1

Service Based

VoIP VoIP

All other trafficAll other traffic


VoIP VoIPISP-1

VoIP VoIPISP-2

All other trafficISP-3

All other traffic


All other traffic

Link Selection

Service Based


VoIP VoIPISP-1

VoIP VoIPISP-2


All other traffic


All other traffic

Link Selection

Service Based

VoIP

VoIP

VoIP

VoIP

VoIP Failover


VoIP VoIPISP-1

VoIP VoIPISP-2


All other traffic


All other traffic

Link Selection

Service BasedVoIP Failover


VoIPAll other traffic

VoIPAll other traffic

VoIP

VoIP

All other traffic

All other traffic

ISP-1

ISP-2


All other traffic


All other traffic

Link Selection

Service BasedAll other traffic failover

It is not possible to disallow failover for ‘All other traffic’


Link Selection

Service Based Configuration Link Selection Load Sharing Route Based Probing Configuration file on the management:

Gateway Interface Service [dont_failover]

A eth0 VoIP

B eth0 VoIP

eth0

eth1

eth0

eth1

VoIP VoIP

All other trafficAll other traffic

A B


vpn_service_based_routing.conf

The configuration file includes the following fields:

Gateway: the gateway that sends the traffic according to the service. Valid values: single VPN gateway\cluster object.

Interface: Outgoing interface for the following services. Valid values: single interface name (as shown in the Topology page of the gateway

in the SmartDashboard). Note that specific interface can appear only once in the configuration file.

Service: Specific service configuration for the given interface. Valid values: group or single service object.

dont_failover flag (optional): if this string is present the service stays sticky on the configured interface. Even if the link associated with the interface reported as “down” by the probing session, the connections of the configured service will still be routed through the configured interface

Gateway Interface Service [dont_failover]

A eth0 ABC

B eth0 XYZ, group


R71 UTM

AV and URLF acceleration


Agenda

1 What’s new?

2 Anti Virus in detail

3 URL Filtering in detail

4 Performance


What’s New?

Anti Virus Move to industry-leading AV engine by Kaspersky, provide

better coverage than current AV solution Use two detection modes:

New stream mode (default) - new kernel stream architecture, based on Virus signatures

► Focusing on viruses in the wild (“WildList”) Proactive mode – Similar architecture to R70 AV solution, but

based on improved engine Performance is significantly better, higher than IPS

recommended feature set: UTM-1 3070: 1.3 Gbps throughput, Power-1 9070: 3.6 Gbps

throughput. Improve stability and memory consumption


What’s New?

URL Filtering

Move to SecureComputing URL Filtering engine improving coverage and accuracy

Move to a new kernel architecture This new architecture eliminates the limitation of concurrent

connections which was dictated by the Security Servers architecture and improves the performance numbers of URL Filtering: UTM-1 3070: ~ 500K concurrent connections, Power-1 9070: ~ 750K concurrent connections.

Improve stability and memory consumption. Support wild characters (‘*’) in Allow/Block lists


Agenda


1 What’s new?


4 Performance


Antivirus in detail

Stream mode Default operation mode Kernel streaming architecture based on signatures provided by

Kaspersky – currently more than 13,000 signatures Focusing on viruses in the wild - Excellent detection rate of (“WildList”) Performance is significantly higher, similar and even better than IPS

recommended feature set: UTM-1 3070: 1.3 Gbps throughput, Power-1 9070: 3.6 Gbps throughput. Latency is minimal.

Limitations:► Zoo viruses► Polymorphic viruses or ones that their signatures require multiple passes or

other heuristics Proactive mode

Same as R70 architecture using security servers Based on Kaspersky KAV engine which performs advanced heuristics,

including sandbox simulation► Enable decompressing files, multiple passes and other heuristics► Number of signatures is irrelevant – using both proactive heuristics and

signatures Excellent detection rate and Proactive capabilities of all viruses Wild and

Zoo Performance is similar to current AV solution


Antivirus in detail II

Common Update of AV database is done via current Update

mechanism – no change in GUI compared to R70► Automatic update – recommended► Manual Update

Same behavior of FileType feature ► Note that file type policy is available in stream mode as well,

implemented in kernel Upgrade

if a customer that is currently using the existing AV solution, upgrades to R71, his GWs will continue to work in Proactive mode (!), until he decides to move to stream mode

One little check box that makes a world of change


Antivirus in detail III

Traffic Flow

HTTP requestHTTP response



Parser

Kernel

Streaming Layer

Connection Layer

File Type Pattern Matcher

AV Kernel Module Sigs. DB

Generic Filters

Block connection if necessary



Traffic Flow

HTTP response


Antivirus in detail IV

Environment UTM peripheral capabilities did not change:

► File Type and general settings► Fallbacks options – block or accept► Logs, SmartViewTracker, SmartViewMonitor

Backward compatibility is supported Reports have been added to SmartEvent


Antivirus in detail V

Even though a R71 system will prevent a live virus in its default mode, EICAR is handled per the following command.

fw ctl set int g_ci_av_eicar_handling_mode <mode> mode can be:

0 – monitor only 1 – ignore 2 - block

The default is 0


Agenda


1 What’s new?


4 Performance


URL Filtering in details I

Our new kernel architecture Connections are all handled in kernel mode and not

folded to Security Servers Eliminates the limitation of concurrent connections

which was dictated by the Security Servers architecture and improves the performance numbers: UTM-1 3070: ~ 500K concurrent connections, Power-1 9070: ~ 750K concurrent connections

Results are cached in kernel, thus actual categorization is often skipped, and leads to even better performance

In cases that the URL is not in cache, categorization is done in user mode, but connection handling is all done in kernel

► The flow is not blocking and does not interrupt other connections


URL Filtering in details II

Clean installation and upgrade Must perform a URLF DB update, this process may take several minutes the first time

Upgrade GWs that are upgraded to R71 will automatically start

using the new URLF engine in the kernel if URLF was enabled before upgrade

Backward compatibility is supported


URL Filtering in details III

Traffic Flow

HTTP request



Parser

Kernel

Streaming Layer

Connection Layer

Caching Matcher

UF Kernel Module

Generic Filters

User ModeUF queries QueueUF DB

Hold ResponseResume Response or Block connections



Parser

Kernel

Streaming Layer

Connection Layer

Caching Matcher

UF Kernel Module

Generic Filters

User ModeUF queries QueueUF DB

URL in Cache Filter – no need to hold ResponseBlock connection if necessary



Traffic Flow

HTTP request


Agenda


1 What’s new?


4 Performance


R71 UTM-1 Boost - AV / URLF

UTM-1 276 UTM-1 1076 UTM-1 3076Maximum

Performance and Capacity

R70 R71 Boost R70 R71 Boost R70 R71

FW (1518 bytes), Mbps 600 1,500 X2.5 2,000 3,000 x1.5 4,500

IPS Throughput - Default

Protections, Mbps

380 1,000 X2.6 900 2,200 X2.7 4,000

Anti-Virus, Mbps 30 120 X4 75 300 X4 175 1,200

Connection rate (cps) 3,400 10,000 X2.9 8,800 25,000 X2.8 35,00

0 54,000

Max concurrent HTTP

AV & URLF2,500 50,000 X20 4,000 110,000 X27 6,500 280,000

All UTM-1 platforms include SecureXL (R71)


Q&A

Q: does AV use CoreXL? A: Yes.

Q: Does changing stream mode to proactive mode , require restart of FW service?

A: No, only policy installation. Q: what's the upgrade process?

A: If AV was activated in the old version it will continue to work in proactive mode after the upgrade, and if it was initially disabled, it’s default mode will be stream mode.

Q: Do we support Antivirus offline updates? A: Yes, the process is being defined. Planned to be available

during Q2/Q3 2010 Q: Is FTP accelerated as well?

A: No, FTP is handled as before in proactive mode


Summary

Anti Virus Moved to industry-leading AV engine by Kaspersky New stream mode utilizing > 13,000 signatures, updated daily to

protect against Viruses in the wild Performance is significantly higher Eliminated the limitation of connection concurrency Significant improvement in memory consumption as well

URL Filtering Move to SecureComputing URL Filtering engine Move to a new kernel architecture Performance is significantly higher Eliminated the limitation of connection concurrency Significant improvement in memory consumption as well Support wild characters (‘*’) in Allow/Block lists


Security Management Enhancements

Firewall Rule expiration: In SmartDashboard, Temporary Rules and Expired rules are marked by new

clocked-shaped icons. Rule expiration can be added to existing rules, or created as an independent object

and applied to multiple rules. New filtering options enable you to quickly find in SmartDashboard's Security

RuleBase all temporary rules, or only those rules which have expired. Automatic Deletion of Old Database Versions Object Management Improvements Define default acces mode for SmartDashboard

Multi select and group

©2010 Check Point Software Technologies Ltd. | [Unrestricted] For everyone

Антон Разумов[email protected]Консультант по безопасностиCheck Point Software Technologies

Спасибо!

Documents

Введение в R71