Packet Filtering Toolset

The 7750 SR series provide an extensive security toolset in order to address the security requirements. This section defines the application and operation of these tools.

6.9.4.1 Filter Policies

Filter policies, also referred to as Access Control Lists (ACLs) are templates applied to services or network ports to control traffic into (ingress) or out of (egress) a Service Access Port (SAP) or Network port based on IP and/or MAC matching criteria. Filters are applied to services to look at packets entering or

leaving a SAP or network interface. Filters can be used on several interfaces. The same filter can be applied to ingress traffic, egress traffic, or both. Ingress filters affect only inbound traffic destined for the routing complex, whilst egress filters affect only outbound traffic sent from the routing complex.

6.9.4.2 Filter Policy Entities

A filter policy compares the match criteria specified within a filter entry to packets transiting the system in the order that the entries are numbered in the policy. When a packet matches all of the parameters specified in the entry, the system

takes the specified action to either drop or forward the packet. If a packet does not match the entry parameters, the packet continues through the filter process and is

compared to the next filter entry (and so on). If the packet does not match any of the entries, then the packet is subject to the default action specified in the filter policy. Each filter policy is made up of the following

1. Scope (Exclusive policies can be applied to a single SAP/Network port whereas a template policy can be applied to multiple SAPs/Network ports).

2. Default Action (Action to be taken when packets do not match the specified criteria in any of the IP filter entries of the filter).

3. Description

4. At least one filter entry And each filter entry contains

1. Match Criteria 2. An action

Filter policies can be associated with the entities defined in Table 14

IP Filter MAC Filter

Epipe SAP, spoke SDP Epipe SAP, spoke SDP

Fpipe SAP, spoke SDP N/A

IES interface SAP N/A

Ipipe SAP, spoke SDP N/A

VPLS mesh SDP, spoke SDP, SAP VPLS mesh SDP, spoke SDP, SAP

VPRN interface SAP, spoke SDP N/A

Table 14: Applying Filter Policies 6.9.4.3 Packet Matching Criteria

IP and MAC filter policies specify either a forward or a drop action for packets based on information specified in the match criteria. The 7750 SR supports up to

2000 IP and 2000 MAC filter policies per node, and up to 65535 entries within each filter.

Filter entry matching criteria can be as general or specific as required, but all conditions in the entry must be met in order for the packet to be considered a

match and the specified entry action performed. The process stops when the first complete match is found and executes the corresponding action specified in the entry;

either to drop or forward packets that matches the criteria.

IP filter matching criteria includes the following ƒ IPv4/IPv6 source IP address/mask.

ƒ Ipv4/Ipv6 destination IP address/mask ƒ Protocol

ƒ Source port/range ƒ Destination port/range ƒ DiffServ Codepoint ƒ ICMP code

ƒ ICMP type

ƒ Fragmentation (match occurs if packets have „More Fragment‟ (MF) bit set or have a non-zero field in the Fragmentation Offset field.

ƒ IP options ƒ TCP SYN ƒ TCP ACK

MAC filter matching criteria includes the following ƒ Source MAC address and mask ƒ Destination MAC address and mask ƒ 802.1p value and mask

ƒ Ethertype

ƒ IEEE 802.2 LLC source SAP ƒ IEEE 802.2 LLC destination SAP ƒ IEEE 802.3 LLC SNAP Protocol ID

ƒ IEEE 802.3 LLC SNAP Ethernet Frame OUI 6.9.4.4 Event Logging

Event logging controls the generation dissemination and recording of system events for monitoring status and troubleshooting faults. Event Logs are the means of recording locally generated system events for real-time of subsequent analysis. The 7750 SR groups events into one of four main categories (or event sources)

1. Security. Events that pertain to attempts to breach system security such as failed login attempts, attempts to access MIB tables to which the user is not granted access, or attempts to enter a branch of the CLI to which access has not been granted.

2. Change. Events that pertain to the configuration or operation of the node

3. Main. Events that pertain to OS applications that are not assigned to other event categories/sources.

Examples of applications within the 7750 SR series include IP, MPLS, ISIS, System, and Security. The command „show log applications‟ displays all applications within the context of logging and the following output provides an output of this command.

A:router# show log applications

A number of events are associated with each application. For example, the following output illustrates the events that are associated with the Security application.

A:PPESBAR01# show log event-control security

=====================================================================

L 2004 cli_user_login_max_attempts MI gen 0 0

L 2005 ftp_user_login MI gen 0 0

L 2006 ftp_user_logout MI gen 0 0

L 2007 ftp_user_login_failed MI gen 0 0

L 2008 ftp_user_login_max_attempts MI gen 0 0

L 2009 ssh_user_login MI gen 5 0

L 2010 ssh_user_logout MI gen 4 0

L 2011 ssh_user_login_failed MI gen 0 0

L 2012 ssh_user_login_max_attempts MI gen 0 0

2013 radiusServerOperStatusChange MI gen 0 0

2014 radiusOperStatusChange MI gen 0 0

L 2015 user_disconnect MA gen 0 0

L 2016 radiusSystemIpAddrNotSet MA gen 0 0

2017 tacplusServerOperStatusChange MI gen 1 0

2018 tacplusOperStatusChange MI gen 2 0

L 2019 mafEntryMatch MA gen 0 0

L 2020 ftp_transfer_successful MI gen 0 0

L 2021 ftp_transfer_failed MI gen 0 0

L 2022 enable_admin WA gen 0 0

L 2023 host_snmp_attempts WA gen 0 0

2024 SSH_server_preserve_key_fail MI gen 0 0

=======================================================================

6.9.4.5 Event Control

Event control assigns the severity for each application event and whether the event should be suppressed or generated. The severity numbers supported in the 7750

SR confirm to the ITU standards M.3100 X.733 and X.21 and are detailed in Table 15.

Severity

Number Severity Name

1 Cleared

Table 15: Event Severity Levels

The following figure illustrates a function block diagram of Event Logging and is followed by some description of each element within the event logging process.

Figure 21: Event logging block diagram

Once an event has been generated, it is passed through Event Control that may pre-process events before passing them to the main event stream. Event Control processes events before they are passed into the main event stream and provides the capability to forward or suppress events from particular applications. Suppressed events will not generate log entries (as the event never reaches the log manager), however, they are recorded within Event Control.

Events that are forwarded by Event Control are sent to the Log Manager. The Log Manager is responsible for managing the event logs within the system. Each event log consists of a unique log ID (a numeric identifier), one or more log sources (main, security, change, debug), and a single destination. The destination can be console, session, SNMP Trap Group, memory, or a local file. Finally, each log ID can be assigned an optional event filter policy which again determines whether to forward or drop an event based on defined match criteria. Each generated event has the following characteristics

a. A time stamp (in UTC) b. The generating application

c. A unique event ID within the application d.

A subject identifying the affected object e. A short text description

6.9.4.6 Log Destinations

Only a single log destination can be associated with an event log. An event log can be associated with multiple event sources, but it can only have a single log destination. Table 16 details the log destinations supported by the 7750 SR.

Log Destination Description

Console Messages sent to all active console sessions. If there are no active console sessions, the event log entries are dropped.

Session A temporary log destination that directs entries to the active console session for the duration of the console session. When the session is terminated, the event log is removed.

Memory Log

A memory log is a circular buffer. When the log is full, the oldest entry in the log is replaced with the new entry. When a memory log is created, the specific number of entries it can hold can be specified

Log file

Log files are stored on the compact flash devices in the file system. A log file is identified with a single log file ID (value 1-99). A log file is configured with a roll-over parameter expressed in minutes that represents the length of time an individual log file should be written to before a new file is created for the relevant log file ID. The rollover time is checked only when an update to the log is being performed. A log file is also configured with a retention time that specifies the amount of time the file should be retained on the file system based on the creation date and time of the file. The retention time is used as a factor to determine which files should be deleted first if the file system nears 100% utlisation.

SNMP Trap Group

An event log can be configured to send events to SNMP trap receivers by specifying an SNMP trap group destination. An SNMP trap group can have multiple trap-receivers with different trap destinations. Each trap receiver can have different operational parameters such as SNMP version (v1, v2c, or v3), community, or port used to send the trap.

Syslog An event log can be configured to send events to one Syslog destination.

Table 16: Event Log Destinations 6.9.4.7 CPM Filters

The 7750 SR series have embedded traffic management and queuing hardware on the Control Processor Module (CPM) dedicated to protecting the control plane. CPM filters can be created on this hardware. These filters can be used to drop or accept packets, as well as allocate dedicated hardware shaping queues for traffic directed to the control processors.

This feature essentially provides dedicated hardware protection for their control planes.

It is possible to allocate dedicated CPM hardware queues for certain traffic designated to the CPUs and also set corresponding rate-limits for those queues. The following CPM traffic management features are supported and are recommended for use

• Traffic classification using CPM filters

• Packets going to the CPM are first classified by the IOM into forwarding classes (FCs) before the CPM hardware sees them. CPM filters can be used to further classify the packets using conventional IP filtering criteria.

• Queue allocation

• Up to 2000 queues are available for allocation to CPM filters. Queue parameters such as PIR, CIR, CBS, and MBS are provisioned on a per- queue basis.