Young fighter course: we are protected by a router. Continuation: NBAR

On many routers, even in basic IOS, there is a fairly convenient and clear ciscina technology: Network-Based Application Recognition (NBAR). Using it, a router can recognize various protocols and applications and, if necessary, use this knowledge to implement quality of service (QoS).

How can a router isolate various protocols from traffic?

1. By analyzing the TCP / UDP header and sorting by known numbers. This is the simplest and most accessible in all IOSs
2. By analyzing the header of the protocol of level 7. For example, parsing the HTTP header and deciphering the type of transmitted data (for example, the HTTP protocol itself, citrix and some other Web-enabled applications), URLs, attachments.
3. Analyzing the service protocol of complex (multichannel) applications and taking into account dynamic sessions agreed on the service channel.
4. By analyzing the RTP headers.
5. Analyzing the header of protocols other than TCP / UDP

The third and fourth algorithm require the inclusion of protocol inspection (ip inspect), discussed a little earlier.

Inspection requires IOS with a firewall feature set.

There are two ways to enable NBAR technology:

1. Simply enable the study of all known protocols.

Ro (config) # int f0 / 0
Ro (config-if) # ip nbar protocol-discovery

After enabling the study on the interface, statistics on known protocols will be collected and it can be viewed with the command

Ro # show ip nbar protocol-discovery


2. Use the architecture of MQC (Modular QoS CLI)

Create a traffic class by specifying the necessary protocol

Ro (config) # class-map [CLASSNAME]
Ro (config-cmap) # match protocol [protocol]

For example:

Ro (config) # class-map PD
Ro (config-cmap) # match protocol citrix ica-tag 2


Create a policy and specify action for the class

Ro (config) # policy-map [POLICY]
Ro (config-pmap) # class [ CLASSNAME]
Ro (config-pmap-c) # {action}


For example:

Ro (config) # policy-map POL
Ro (config-pmap) # class PD
Ro (config-pmap-c) # {shape | police | priority | service-policy} It


remains to attach the policy to the interface to activate it

Ro (config) # int f0 / 0
Ro (config-if) # service-policy {input | output} [POLICY]


For example, let's hang up a policy on the interface input

Ro (config) # int f0 / 0
Ro (config-if) # service-policy input POL


Specifying match protocol in the keyword traffic class means enabling NBAR technology.
You can see the statistics of getting into the class with the

Ro # sh policy-map interface f0 / 0
command.

All that remains is to recall that any process of traffic analysis is performed by the processor and pretty annoying. By reference - an article with a performance test without trying NBAR, using basic and advanced analysis technologies.

article on tsisko.com

NBAR traffic processing results can be collected via SNMP and analyzed. From the point of view of protecting the perimeter, the closest attention should be paid to a sharp increase in the amount of traffic using some protocol. This may indicate the presence of worms on the network, as well as other problems, such as botnets, spam proxies, etc.

(To be continued)