2010年4月16日 星期五

Cisco FPM – Flexible Packet Matching (Super ACL)

 

What is Cisco IOS Flexible Packet Matching (FPM)?

Networks are experiencing increasing sophisticated attacks that require mitigating tools that are as flexible as possible. Cisco IOS Flexible Packet Matching (FPM) is a set of classes and policies that provides pattern matching capability for more granular and customized packet filters for Layer 2 to 7-bit/byte matching capability deep into the packet at any offset within the packet header and payload.

Put simply, it is a powerful, easy, and rapid deployment mechanism that enables users to specify criteria to match against any part of a packet (header and payload) and define the action to take. In short, FPM is able to classify a packet based on its characteristics and take appropriate action.

How does Cisco IOS Flexible Packet Matching Work?

Cisco IOS Flexible Packet Matching (FPM) uses the following characteristics to ensure users successfully mitigate attacks.

• Is a stateless solution and inspects one packet at a time.

• Matches on all static packet characteristics like protocol, port, IP address.

• Uses a Protocol Header Description File (PHDF) that allows the user to define a class match criteria based on any field in the protocol header.

• Supports an offset, size and string keywords, and regular expressions (regex) to allow the user to match on strings or bytes in the packet payload.

• Uses class-map and policy-map configuration syntax to specify the protocol stack, the match criteria and action to take.

Protocol Header Description File (PHDF)

A PHDF defines each field contained in a particular protocol’s header. Each field is described with a name, optional comment, offset, and length.
The offset is always specified from the beginning of the header. Both the offset field and the length field may be specified either in terms of bits or
bytes.

Standard PHDFs available to be loaded include: ether.phdf, ip.phdf, tcp.phdf, and udp.phdf. These PHDFs provide Layer 2–4 protocol definition.
Users may write their own custom PHDFs off-box using the XML language to provide the desired protocol definition through Layer 7.

Steps to Configure Cisco IOS Flexible Packet Matching (FPM)

Step 1.    Load the protocol header description file(s) (PHDF)

Router(config)# load protocol system:udp.phdf


Step 2.    Define the protocol stack (IP-UDP, IP-TCP, etc.)

Router(config)# class-map type stack ip-udp match-all
Router(config-cmap)# match field ip protocol eq 0x11 next udp

Step 3.    Define FPM match criteria filter (class-map)

Router(config)# class-map type access-control slammer match-all
Router(config-cmap)# description "match on slammer packets"
Router(config-cmap)# match field udp dest-port eq 1434
Router(config-cmap)# match start l3-start offset 224 size 4 eq 0x4011010

Step 4.    Define action to take on classes (service-map)

Router(config)# policy-map type access-control fpm-udp-policy
Router(config-pmap)# description "policy for UDP based attacks"
Router(config-pmap)# class slammer
Router(config-pmap)# drop
Router(config)# policy-map type access-control fpm-policy 
Router(config-pmap)# class ip_udp
Router(config-pmap-c)# service policy fpm-udp-policy

Step 5.    Apply service policy to an interface

Router(config)# interface gigabitEthernet 0/1
Router(config-if)# service-policy type access-control input fpm-policy


Reference:

http://www9.cisco.com/en/US/products/ps6723/prod_presentation_list.html

http://www9.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6723/prod_white_paper0900aecd803936f6.html

http://www9.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6723/prod_white_paper0900aecd80633b0a.html

2010年4月14日 星期三

IOS CLI Role-Based Views

 
Benefits of Using CLI Views

Views: Detailed Access Control

Although users can control CLI access via both privilege levels and enable mode passwords, these functions do not provide network administrators with the necessary level of detail needed when working with Cisco IOS routers and switches. CLI views provide a more detailed access control capability for network administrators, thereby, improving the overall security and accountability of Cisco IOS software.

As of Cisco IOS Release 12.3(11)T, network administrators can also specify an interface or a group of interfaces to a view; thereby, allowing access on the basis of specified interfaces.

Root View

When a system is in "root view," it has all of the access privileges as a user who has level 15 privileges. If the administrator wishes to configure any view to the system (such as a CLI view, a superview, or a lawful intercept view), the system must be in root view.

The difference between a user who has level 15 privileges and a root view user is that a root view user can configure a new view and add or remove commands from the view. Also, when you are in a CLI view, you have access only to the commands that have been added to that view by the root view user.

View Authentication via a New AAA Attribute

View authentication is performed by an external authentication, authorization, and accounting (AAA) server via the new attribute "cli-view-name."

AAA authentication associates only one view name to a particular user; that is, only one view name can be configured for a user in an authentication server.

How to Use Role-Based CLI Access

Configuring a CLI View

Use this task to create a CLI view and add commands or interfaces to the view, as appropriate.

Prerequisites

Before you create a view, you must perform the following tasks:

Enable AAA via the aaa new-model command.

Ensure that your system is in root view—not privilege level 15.

SUMMARY STEPS

1. enable view

2. configure terminal

3. parser view view-name

4. secret 5 encrypted-password

5. commands parser-mode {include | include-exclusive | exclude} [all] [interface interface-name | command]

6. exit

7. exit

8. enable [privilege-level] [view view-name]

9. show parser view [all]

 

Reference:

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_role_base_cli.html

2010年4月13日 星期二

Network Foundation Protection

 

  • Control Plane Protection
    1. CPPr
    2. Routing Protocol Protection
    3. CPU & Memory thresholding
    4. Auto Secure
  • Management Plane Protection
  • Data Plane Protection

Control plane is sub-divided into three subinterfaces:

- Host
- Transit
- CEF-exception 

type of controll mechanisms

- CoPP
- Port-filter
- Queue-thresholding

146086

feature-proc-order

Reference:

http://www.cisco.com/web/about/security/intelligence/understanding-cppr.html#14

2010年4月2日 星期五

Question of 802.1x Guest Vlan

 

Cisco Switch supports 802.1x guest vlan function which allow 802.1X-incapable client to be put into a guest vlan.

IOS version before 12.1(22)EA2 does not maintain EAPoL packet history. So it can not differentiate where a client is “802.1X-incapable” or “802.1X-capable but failed the authentication”.

After IOS 12.1(22)EA2, the EAPoL packet history table enable the switch to differentiate the aforementioned situations. So only “802.1x-incapable” client can trigger the interface been put into “guest-vlan”.

If you want switch with IOS 12.1(22)EA or later to act the same as previous IOS version, you can use the command “dot1x guest-vlan supplicant”.  With this command, a client will be put into guest-vlan even if it is 802.1X-capable and failed the authentication.

But if the same switchport (put into guest-vlan) receive the EAPoL packet, it will revert to an unauthorized state and 802.1X authentication restarts on this port.

So my question is, if a 802.1X-capable client failed the authentication and had the switchport been put into guest-vlan. Will it resend the EAPoL (802.1X request) later?

IF so, the port will be in a endless loop of fluctuating between “unauthorized state” and “guest-vlan state”.

I need to setup a lab to find out the answer.