670 likes | 809 Vues
Введение в R71. Антон Разумов arazumov@checkpoint.com Консультант по безопасности Check Point Software Technologies. 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
E N D
Введение в R71 Антон Разумов arazumov@checkpoint.com Консультант по безопасности CheckPointSoftwareTechnologies
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 1 3 Introduced in R70.20 (and now integral part of R71) R71 IPS contract enforcement 2 R71 IPS other news
IPS EventAnalysis (IPSA) Old front page Timeline Statistics Critical 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”
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. Quick view of alerts in the network RSS feed of recently updated protections
IPS-1 Sensor – Management Choose to also manage IPS-1. List of IPS-1 and IPS Software Blade GWs. Profiles contain both IPS-1 and IPS Software Blade protections, and can be applied to both IPS-1 appliances and GWs. Each sensor/GW is listed. Select which type of sensor to add.
Agenda IPS 1 3 Introduced in R70.20 (and now integral part of R71) R71 IPS contract enforcement 2 R71 IPS other news
R71 IPS contract enforcement • 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 See sk44245 • 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
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 1 3 Introduced in R70.20 (and now integral part of R71) R71 IPS contract enforcement 2 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
Agenda Service Based Link Selection 1 3 Introduction Overview and technology 2 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
Agenda Service Based Link Selection 1 3 Introduction Overview and technology 2 Scenarios
Link Selection – how should the gateway behave ? “ping” “pong” Peer’s available on this link, too “ping” “pong” Peer’s available on this link Use another ISP as backup Use primary ISP to establish VPN with peer GW Test peer GW availability through each link ISP 2 ISP 1 ISDN When all else fails, use dial-up (or DSL or FR)
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 eth0 Local gateway eth0 Remote peer eth1 • 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.
Link Selection - Example High Availability, outgoing tunnel • 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 eth0 eth0 Local gateway Remote peer eth1
Agenda Service Based Link Selection 1 3 Introduction Overview and technology 2 Scenarios
Link Selection High Availability primary primary eth0 eth0 eth1 eth1
Link Selection Load Sharing eth0 eth0 eth1 eth1
Link Selection Service Based VoIP VoIP eth0 eth0 eth1 eth1 All other traffic All other traffic
Link Selection ISP-1 ISP-2 ISP-3 ISP-4 Service Based VoIP VoIP VoIP VoIP All other traffic All other traffic All other traffic All other traffic
Link Selection ISP-1 ISP-4 ISP-2 ISP-3 Service Based VoIP Failover VoIP VoIP VoIP VoIP All other traffic All other traffic VoIP VoIP All other traffic All other traffic VoIP VoIP
Link Selection ISP-1 ISP-2 ISP-3 ISP-4 Service Based VoIP Failover VoIP VoIP VoIP VoIP All other traffic All other traffic All other traffic All other traffic
Link Selection ISP-2 ISP-4 ISP-3 ISP-1 Service Based All other traffic failover All other traffic VoIP VoIP All other traffic All other traffic VoIP VoIP All other traffic All other traffic All other traffic All other traffic All other traffic It is not possible to disallow failover for ‘All other traffic’
Link Selection VoIP VoIP eth0 eth0 A B eth1 eth1 All other traffic All other traffic Service Based Configuration • Link Selection Load Sharing • Route Based Probing • Configuration file on the management:
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
Agenda 1 2 3 4 What’s new? Anti Virus in detail URL Filtering in detail 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 2 3 4 What’s new? Anti Virus in detail URL Filtering in detail 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 HTTP response HTTP request Traffic Flow