Dec 27, 2008

Check Point宣佈收購Nokia資訊安全設備業務

2008.12.26 下午 12:55:12

Check Point軟體技術有限公司宣佈,與Nokia簽署協議收購其資訊安全設備(security appliance)部門。Check Point與Nokia已合作長達十年之久,並共同致力研發領導產業的企業安全解決方案。透過此次收購,Check Point將可增強其在資安硬體設備的支援和發展,擴大其在全球資安市場的版圖。

Check Point軟體技術有限公司首席執行長Gil Shwed表示,Nokia的資訊安全設備部門一直是Check Point重要的策略合作夥伴,更曾協助Check Point早一步成為安全設備的領導者。把Nokia深受市場肯定的資訊安全設備,整合到Check Point的強大安全解決方案中,是雙方長期合作下來必然的結果。

Check Point與Nokia長期提供客戶在關鍵環境中,擁有最高效能的資安解決方案。Nokia的資訊安全設備,為Check Point的防火牆、虛擬私人網路(VPN)和統一威脅管理系統(UTM),提供最有效的安全平台。目前財星雜誌500大企業中已有85%購買Nokia安全設備,超過220,000個Nokia安全設備,被全球逾23,000個客戶安裝使用。

而Check Point擁有多樣的安全閘道解決方案,如Check Point UTM-1 appliances和Check Point Power-1 appliances等,能夠帶給小型公司及大型企業完整的資料保護。目前,已有超過700,000個Check Point安全閘道授權給全球逾100,000個企業使用,Check Point客戶群包含100%的財星雜誌前100大企業,及98%的財星雜誌500大企業。

Check Point與Nokia的收購案,預計2009年第一季完成所有交易程序;詳細交易資料將不對外公開。

Check Point台灣區總經理簡淑真表示,Check Point期盼透過此次收購案,除拓展全球的資安市場外,Check Point也將繼續在台提供企業客戶與合作夥伴們優質的服務,及安全設備產品。

Dec 25, 2008

QoS Bandwidth/Priority Remaining Percent 保留頻寬計算

很多人在學習QoS LLQ & CBWFQ的時候,遇到了頻寬保留分配問題都會有一些不太確定的感覺,因為Cisco在課程中並沒有非常詳細的說明不同的指令參數之間的搭配,會得到什麼樣的後果,所以我把這個問題在這邊提出來(這要感謝課堂上的同學問我這個問題,也順便釐清了這個不確定因素)。

假設我們現在在P1R1上有一路Serial頻寬為512k,現在我們要進行頻寬分配,分配的條件如下:

  • Class TEST1使用LLQ(10%)
  • Class TEST2使用CBWFQ剩下可用頻寬的(30%)
  • Class TEST3使用CBWFQ剩下可用頻寬的(20%)

這個問題看似簡單,但是如果從來沒有認真去注意到的話就可以會有不同的解讀,到底TEST3可以使用多少的保留頻寬?

正確答案是:

  • Class TEST1 LLQ使用頻寬上限=512k * 10%=51.2k
  • Class TEST2 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 30%
  • Class TEST3 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 20%

也就是說最後所有使用bandwidth percent remaining指令的總和不得超過100%

還有一點很重要的是,在這邊所謂的remaining並非指interface上現在實際流量的剩餘頻寬,Cisco QoS的指令在MQC中沒有這麼厲害可以隨時去監控現行使用流量來進行等比例的動態保留(maybe in the future)

為了證明真的是這個樣子,我進行了以下的實驗:

P1R1(config)#policy-map TEST
P1R1(config-pmap)#class TEST1
P1R1(config-pmap-c)#priority percent 10
P1R1(config-pmap-c)#class TEST2
P1R1(config-pmap-c)#bandwidth remaining percent 30
P1R1(config-pmap-c)#class TEST3
P1R1(config-pmap-c)#bandwidth remaining percent 80
Sum total of class bandwidths exceeds 100 percent

結果Cisco Router回應了以上的訊息,這表示bandwidth remaining percent指令是一視同仁,大家共同使用扣除之前並非使用remaining參數進行保留頻寬動作之後的可用頻寬再來均分;而不是每一行的bandwidth remaining percent都要把之前所有已保留頻寬動作都扣除之後再來計算比例。

附上一張Cisco Slide希望各位可以看得更清楚!


Dec 24, 2008

Management Plane Protection(MPP)

The Management Plane Protection (MPP) feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device.

Restricting management packets to designated interfaces provides greater control over management of a device, providing more security for that device. Other benefits include improved performance for data packets on nonmanagement interfaces, support for network scalability, need for fewer access control lists (ACLs) to restrict access to a device, and management packet floods on switching and routing interfaces are prevented from reaching the CPU.

In-Band Management Interface

An in-band management interface is a Cisco IOS physical or logical interface that processes management as well as data-forwarding packets. Loopback interfaces commonly are used as the primary port for network management packets. External applications communicating with a networking device direct network management requests to the loopback port. An in-band management interface is also called a shared management interface.

Control Plane Protection Overview

A control plane is a collection of processes that run at the process level on a route processor and collectively provide high-level control for most Cisco IOS software functions. All traffic directly or indirectly destined to a router is handled by the control plane.

Control Plane Policing (CoPP) is a Cisco IOS control-plane feature that offers rate limiting of all control-plane traffic. CoPP allows you to configure a quality of service (QoS) filter that manages the traffic flow of control plane packets. This QoS filter helps to protect the control plane of Cisco IOS routers and switches against denial-of-service (DoS) attacks and helps to maintain packet forwarding and protocol states during an attack or during heavy traffic loads.

Control Plane Protection is a framework that encompasses all policing and protection features in the control plane. The Control Plane Protection feature extends the policing functionality of the CoPP feature by allowing finer policing granularity. Control Plane Protection also includes a traffic classifier, which intercepts control-plane traffic and classifies it in control-plane categories. Management Plane Protection operates within the Control Plane Protection infrastructure.

Management Plane

The management plane is the logical path of all traffic related to the management of a routing platform. One of three planes in a communication architecture that is structured in layers and planes, the management plane performs management functions for a network and coordinates functions among all the planes (management, control, data). The management plane also is used to manage a device through its connection to the network.

Examples of protocols processed in the management plane are Simple Network Management Protocol (SNMP), Telnet, HTTP, Secure HTTP (HTTPS), and SSH. These management protocols are used for monitoring and for CLI access. Restricting access to devices to internal sources (trusted networks) is critical.

Management Plane Protection Feature

The MPP feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device. Restricting management packets to designated interfaces provides greater control over management of a device.

The MPP feature is disabled by default. When you enable the feature, you must designate one or more interfaces as management interfaces and configure the management protocols that will be allowed on those interfaces. The feature does not provide a default management interface. Using a single CLI command, you can configure, modify, or delete a management interface.When you configure a management interface, no interfaces except that management interface will accept network management packets destined to the device. When the last configured interface is deleted, the feature turns itself off.

Following are the management protocols that the MPP feature supports. These management protocols are also the only protocols affected when MPP is enabled.

  • Blocks Extensible Exchange Protocol (BEEP)
  • FTP
  • HTTP
  • HTTPS
  • SSH, v1 and v2
  • SNMP, all versions
  • Telnet
  • TFTP

Cisco IOS features enabled on management interfaces remain available when the MPP feature is enabled. Nonmanagement packets such as routing and Address Resolution Protocol (ARP) messages for in-band management interfaces are not affected.

This feature generates a syslog for the following events:

  • When the feature is enabled or disabled
  • When a management interface fails.

For example, a failure will occur when the management interface cannot successfully receive or process packets destined for the control plane for reasons other than resource exhaustion.

Benefits of the Management Plane Protection Feature

Implementing the MPP feature provides the following benefits:

  • Greater access control for managing a device than allowing management protocols on all interfaces
  • Improved performance for data packets on nonmanagement interfaces
  • Support for network scalability
  • Simplifies the task of using per-interface ACLs to restrict management access to the device
  • Fewer ACLs needed to restrict access to the device
  • Management packet floods on switching and routing interfaces are prevented from reaching the CPU

Configuring a Device for Management Plane Protection

Perform this task to configure a device that you have just added to your network or a device already operating in your network. This task shows how to configure MPP where SSH and SNMP are allowed to access the router only through the FastEthernet 0/0 interface.

Prerequisites

  • IP Cisco Express Forwarding must be enabled before a management interface can be configured.

SUMMARY STEPS

1. enable

2. configure terminal

3. control-plane host

4. management-interface interface allow protocols

5. Ctrl-z

6. show management-interface [interface | protocol protocol-name

Examples

The configuration in this example shows MPP configured to allow SSH and SNMP to access the router only through the FastEthernet 0/0 interface. This configuration results in all protocols in the remaining subset of supported management protocols to be dropped on all interfaces unless explicitly permitted. BEEP, FTP, HTTP, HTTPS, Telnet, and TFTP will not be permitted to access the router through any interfaces, including FastEthernet 0/0. Additionally, SNMP and SSH will be dropped on all interfaces except FastEthernet 0/0, where it is explicitly allowed.

To allow other supported management protocols to access the router, you must explicitly allow these protocols by adding them to the protocol list for the FastEthernet 0/0 interface or enabling additional management interfaces and protocols.

Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router(config)# control-plane host 
Router(config-cp-host)# management-interface FastEthernet 0/0 allow ssh snmp 
Router(config-cp-host)# 
.Aug  2 15:25:32.846: %CP-5-FEATURE: Management-Interface feature enabled on Control plane  host path 
Router(config-cp-host)# 

The following is output from the show management-interface command issued after configuring MPP in the previous example. The show management-interface command is useful for verifying your configuration.

Router# show management-interface 

Management interface FastEthernet0/0 
        Protocol        Packets processed 
             ssh                0 
            snmp                0 

Router# 

Configuration Examples for Management Plane Protection

This section provides the following configuration example:

Configuring Management Plane Protection on Gigabit Ethernet Interfaces: Example

The following example shows how to configure MPP where only SSH, SNMP, and HTTP are allowed to access the router through the Gigabit Ethernet 0/3 interface and only HTTP is allowed to access the router through the Gigabit Ethernet 0/2 interface.

Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router(config)# control-plane host 
Router(config-cp-host)# management-interface GigabitEthernet 0/3 allow http ssh snmp        
Router(config-cp-host)# 
.Aug  2 17:00:24.511: %CP-5-FEATURE: Management-Interface feature enabled on Control plane  host path 
Router(config-cp-host)# management-interface GigabitEthernet 0/2 allow http 
Router(config-cp-host)# 

The following is output from the show management-interface command issued after configuring MPP in the previous example. The show management-interface command is useful for verifying your configuration.

Router# show management-interface  
Management interface GigabitEthernet0/2 
        Protocol        Packets processed 
            http                0 

Management interface GigabitEthernet0/3 
        Protocol        Packets processed 
            http                0 
             ssh                0 
            snmp                0 

The Steps of QoS Preclassification Configuration with IPSec and GRE

The qos pre-classify mechanism allows Cisco routers to make a copy of the inner IP header and to run a QoS classification before encryption based on fields in the inner IP header. Without this feature, the classification engine sees only a single encrypted and tunneled flow since all packets that traverse across the same tunnel have the same tunnel header and receive the same treatment in the event of congestion.

If your classification policy matches with the ToS byte, you do not need to use the qos pre-classify command since the ToS value is copied to the outer header by default. You can create a simple QoS policy which sorts traffic into classes based on IP precedence. However, to differentiate traffic within a class and to separate it into multiple flow-based queues, the qos pre-classify command is required.

Note: ToS byte copying is done by the tunneling mechanism and not by the qos pre-classify command.

The qos pre-classify command can be applied at various points in your configuration, as illustrated here.

  • GRE only - Configure the qos pre-classify command on the tunnel interface.

    interface Tunnel0   ip address 1.1.1.1 255.255.255.252   qos pre-classify   tunnel source 12.2.2.8   tunnel destination 12.2.2.6 ! interface serial 0/0   ip address 12.2.2.8 255.255.255.0   fair-queue
  • IPSec only - Configure the qos pre-classify command under the crypto map.

    crypto map TEST 10 ipsec-isakmp   set peer 5.5.5.5   set transform-set SET   match address Test   qos pre-classify ! interface serial 0/0   ip address 5.5.5.4 255.255.255.0   crypto map TEST   random-detect   random-detect flow
  • IPSec and GRE - Configure the qos pre-classify command on the tunnel interface and under the crypto map.

    crypto map TEST 10 ipsec-isakmp   set peer 12.2.2.6   set transform-set SET   match address Test   qos pre-classify ! interface Tunnel0   ip address 1.1.1.1 255.255.255.252   qos pre-classify   tunnel source 12.2.2.8   tunnel destination 12.2.2.6   crypto map TEST ! interface serial 0/0   ip address 12.2.2.8 255.255.255.0   service-policy out matchPORTnumbers   crypto map TEST

Complete these steps to configure QoS preclassification with IPSec and GRE.

  1. Configure a crypto map and specify the qos pre-classify command in map configuration mode.

    crypto map cryptomap_gre1 10 ipsec-isakmp  set peer 172.32.241.9  set transform-set transf_GRE1_transport  match address 130  qos pre-classify
  2. Use the show crypto map command to confirm your configuration.

    2621vpn1#show crypto map Crypto Map: "cryptomap_gre1" idb: Loopback0 local address: 172.31.247.1 Crypto Map "cryptomap_gre1" 10 ipsec-isakmp         Description: Crypto map on GRE1 tunnel mode transport - 10.240.252.0->3/30         Peer = 172.32.241.9         Extended IP access list 130             access-list 130 permit gre host 172.31.247.1 host 172.32.241.9         Current peer: 172.32.241.9         Security association lifetime: 4608000 kilobytes/3600 seconds         PFS (Y/N): N         Transform sets={ transf_GRE1_transport, }         QOS pre-classification
  3. Define a GRE tunnel interface and apply the crypto map and qos pre-classify commands.

    interface Tunnel0 ip address 10.240.252.1 255.255.255.252 qos pre-classify tunnel source Loopback0 tunnel destination 172.32.241.9 crypto map cryptomap_gre1
  4. Use the show interface tunnel 0 command to confirm that QoS preclassification is enabled.

    2621vpn1#show interface tunnel 0 Tunnel0 is up, line protocol is up   Hardware is Tunnel   Description: VPN resilience test - 1st GRE tunnel Interface mode transport - 10.240.252.0->3/3   Internet address is 10.240.252.1/30   Tunnel source 172.31.247.1 (Loopback0), destination 172.32.241.9   Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled   Checksumming of packets disabled,  fast tunneling enabled   Last input 00:00:04, output 00:00:04, output hang never   Last clearing of "show interface" counters 00:00:51   Queueing strategy: fifo (QOS pre-classification)   Output queue 0/0, 0 drops; input queue 0/75, 0 drops

The above output illustrates that the tunnel interface continues to use first in, first out (FIFO) as the queuing strategy even with QoS preclassification and fancy queuing enabled. This is illustrated in the show command output with the line Queueing strategy: fifo (QOS pre-classification). Both GRE and IPSec tunnels require FIFO queuing since a destination device drops IPSec packets that arrive out of order.

In a VPN environment, you can apply a QoS service policy to the tunnel interface or to the underlying physical interface. The decision of whether you need to configure the qos pre-classify command depends on which header and which header values you want to use for classification.

  • If you want to classify packets based on the inner header, apply the policy to the tunnel interface without the qos pre-classify command.

  • If you want to classify packets based on the outer header, apply the policy to the physical interface without the qos pre-classify command.

  • If you want to classify packets based on the inner header and apply the policy to the physical interface since the physical interface may be a congestion point, apply the policy to a physical interface and enable the qos pre-classify command.