Syslog The purpose of syslog is to write system messages to a log Syslog messages can include...

syslog The purpose of syslog is to write

system messages to a log Syslog messages can include

everything from critical alarm conditions to ordinary debugging statement

It provides a general trail of activities It provides the capability for the

device to emit event messages without solicitation

Syslog message has 2 parts A message header and the

message body The message body contains the

content of the message itself (english text, unstructured)

The message header contains minimal but essential information in structured manner

Syslog message

179.19.209.130 – IP Address 000024 – sequence number Apr 12 18:01:55:643 – local time ENV_MON – facility emitting the alarm 1 – severity SHUTDOWN – Event

Syslog protocol IETF is in process of passing a

particular version of syslog as a standard RFC 3164 BSD syslog protocol RFC 3195 reliable delivery for syslog

Refer to RFC3164 UDP is used as transport service Port 514

definition A machine that can generate a message

will be called a "device". A machine that can receive the message

and forward it to another machine will be called a "relay".

A machine that receives the message and does not relay it to any other machines will be called a "collector". This has been commonly known as a "syslog server".

Syslog message

Consists of 3 parts :PRI /HEADER/MSG

Total length 1024 bytes or less

PRI (Priority) part

Priority – combination of a facility and severity Facility – category of a message (kernel

message) , it is a numeric code Severity – numeric code 0 -7 , 0 is the

most severe Priority is formed by multiplying the

numeric code of the facility by 8 and adding the severity

Facility 7 and severity 3 , so priority = 59

Example of Facility code

code facility

0 kernel messages

1 user-level messages

2 mail system

3 system daemons

Example of Severity

Code severity

0 Emergency : system is unusable

1 Alert: action must be taken immediately

2 Critical : critical conditions

3 Error : error conditions

HEADER part The HEADER part contains a timestamp and

an indication of the hostname or IP address of the device

The HEADER part of the syslog packet MUST contain visible (printing) characters (7-bit Ascii)

HOSTNAME field will contain the hostname or IP address

Timestamp field will contain the local time and is in the format of “Mmm dd hh:mm:ss"

Mmm –month of the year with the first character in uppercase and the other two characters in lowercase“Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec”

dd -dd is the day of the month. If the day of the month is less than 10, then it MUST

be represented as a space and then the number. For example,

the 7th day of August would be represented as "Aug 7", with two spaces between the "g" and the "7

hh:mm:ss is the local time. The hour (hh) is represented in a

24- hour format. Valid entries are between 00 and 23

The minute (mm) and second (ss) e ntries are between 00 - 59

MSG part It contains some additional information of the p

rocess that generated the message, and then t he text of the message

It has 2 fields : TAG and CONTENT TAG field will be the name of the program or process that generated the message.(not

exceed 32 chars) The CONTENT contains the details of the messa

ge. T his has traditionally been a freeform message that

gives some detailed information of the event

Example of syslog message <34> Oct 11 22:14:15 mymachine su:

’su root’ failed for lonvick on /dev/pts/8

<34> - priority Oct 11 22:14:15 – timestamp mymachine – hostname su – TAG : ’ su r oot ’ f ai l ed f or l onvi ck on / d

ev/ pt s/ 8- Content

Security consideration Authentication

The syslog delivery mechanism does n ot strongly associate the message wit

h the message sender a misconfigured machine may send sy

slog messages to a collector represent ing itself as another machine

An attacker may transmit syslog mess ages to a collector.

Sequenced delivery the syslog process and protocol do not ensur

e ordered delivery. Reliable delivery

no mechanism within either the syslog proce ss or the protocol to ensure delivery

May be maliciously intercepted or discarded Message Integrity

syslog messages may be damaged in transit or an attacker may maliciously modify them.

Message observation No mechanisms to provide confidentiality

of the messages in transit. (clear-text messages)

Message Prioritization & Differentiation No mechanism relating to priority

message Critical message and non critical message

can be treated as equal in term of reception

Mi sconfi gur at i on The syslog message may go to

untended receiver Load Consi der at i ons

An attacker may perform a Denial of S ervice attack by filling the disk of the c

ollector with false messages.

Netconf Netconf is a network management

protocol developed in the IETF by the Netconf working group. It was published as

RFC 4741. The NETCONF protocol provides mechanisms to in

stall, manipulate, and delete the configuration of n etwork devices. It also can perform some monitori

ng functions. It uses an Extensible Markup Language

(XML) based data encoding for the configuration d ata as well as the protocol messages.

The NETCONF protocol operations are realized on t op of a simple Remote Procedure Call (RPC) layer.

Netconf Datastore The configuration information of devices

can be thought of and handle as being contained in a datastore (like a file)

The datastore resembles a MIB. Netconf provide the operations to

manage those datastores. SNMP targets the individual managed

object in side MIB Netconf targets the MIB as a whole or

portion

A hierarchical datastore in Netconf Fig 8-11

Netconf Architecture Fig 8-12

Transport layer (using Netconf over) Secure Shell (SSH) RFC4742 Block Extensible Exchange Protocol (BEEP)

RFC4744 Simple Object Access Protocol (SOAP)

RFC4743 Remote Procedure Call layer

Allow manager to invoke function on agent rpc request / rpc reply

The operation layer To manipulate configuration files Get-config / edit-config

The content layer Configuration data

The management information will be transported and exchanged as XML documents

Netconf Message Structure Fig 8-14

A netconf request Ex 8-4

Rpc tag <rpc message-id =“101 … > and </rpc> - frame the overall message

Netconf operation is get-config (<get-config> … </get-config>

<source>… </source> specifies the config being requested (running config)

<filter> … </filter> specifies the subtree within the config

A netconf reply Ex 8-5

Management operations Get-config – to retrieve config file

(default is running config) Get – to retrieve state information Edit-config – to modify or change a

configuration Copy-config – to copy new configuration Delete-config – to remove a

configuration Lock and unlock – to protect

configuration file

Netflow protocol /IPFIX Netflow was introduced by cisco to

collecting data about networking traffic from a device. Who are the top “talker” in the network How much traffic is being exchanged

between two destination How are links in the network being used Where are the traffic bottlenecks in the

network?

Netflow communicates statistical information about IP-based data traffic that flow over router

The statistics are provided on a per-flow basis

A flow consists of all traffic that belongs to the same communication context A file–transfer application ,all packets

belong to the same transfer

Fig 8-15

Flow Identified by the following information Source address/Source port Destination address/Destination port Protocol type (TCP or UDP) Type of service (TOS) Input logical interface (same index in SNMP

MIB) Flow record includes the keys that identify the

flow as well as the time when flow started /stopped /how many packets were transported

Benefit Allow network managers to account for

detailed network use by individual users Charge based on actual traffic

consumption Provide a wealth of data for traffic

analysis, bottleneck and network planning

Provide tool to spot and defend against attacks on a network

Protocol RFC 3954 (version 9) Flow information is exported from the router in User

Datagram Protocol (UDP

) or Stream Control Transmission Protocol (SCTP

) packets and collected using a netflow collector. Juniper Networks

provides a similar feature for its routers called Jflow .

Huawei Technology

routers also support the same technology, but call i t NetStream

Netflow packet structure Fig 8-16

Packet structure

Header Sequence number of the packet The number of flow records contained in the

Netflow packet The version number of the netflow protocol

itself Flow record

keys to identify flow Start/finish time Statistical data

Finishing the flow

No traffic has been detected on a flow for a certain time

A packet is detected at the app-protocol level that the data transfer supported by the flow has completed

If a flow has been going on for a long time (30 minutes) ,the router simply declare the flow ends and start a new one

Management protocol positioning Fig 8-17

Remote Network Monitoring RMON specification is primarily a

definition of a MIB RFC 1757/2819 Remote network

monitoring management information base

RFC 2021 Remote network monitoring management information base II

RFC 2074 Remote network monitoring MIB identifier

Goals Off-line operation

reduce polling from manager Proactive monitoring

Monitor can run diagnostics and log network performance (if sufficient resources)

Problem detection and reporting Active probing of the network The consumption of network resources Passively recognize certain error conditions such

as congestion on the traffic that it observes

Value-added-data Monitor can perform analyse specific to

the data collected on its subnetwork Analyse subnetwork traffic to determine

which hosts generate the most traffic or errors on the subnetwork

Multiple managers Support more than one manager

Fig 8.1

Control of remote monitors

RMON MIB contains features that support extensive control from the management station

2 categories of RMON MIB features Configuration Active invocation

Configuration & Active invocation

Configuration Each MIB group consists of one or more

control tables and data tables Control table – read/write contains

parameter that describe the data in data table

Data table – read only contains information that is defined by control table

Action invocation Use SET operation to issue a command RMON MIB defines objects to be

represented several commands

Multiple Manager - Problems Concurrent requests for resources

could exceed the capability of the monitor to supply those resources

A management station could capture and hold monitor resources for long period of time

Resources could be assigned to management station that crashes without releasing the resources

Multiple Manager – Solution

Ownership label is used for a particular row of the table

A management station may recognize resources it owns and no longer need

A network operator can identify and negotiate the management station to free the resources

If a management station experiences a reinitialization , it can recognize resources it had reserved in the past and free those it no longer needs

Ownership concept Ownership label contains one or more of

the following: IP address, management station name,

network manager’s name, location or phone number

However, the ownership label does not act as a password or access-control mechanism

Therefore, a row can be read-write by the management station who does not own the row

Fig 8.3

Good and Bad Packets

RFC 2819 - Good packets are error free packets th

at have a valid frame length. Forexample, on Et her net , good packet s ar e er r or

- free packets that are between 64 octe ts long and 1518 octets long.

Bad packets are packets that have pr oper framing and are therefore recog nized as packets, but contain errors within the packet or have an invalid l ength.

For example, on Ethernet, bad packet s have a valid preamble and SFD, but

have a bad CRC, or are either shorter

The RMON MIB

RMON (v1) MIB is incorporated into MIB-II with a subtree identifier of 16 (10 groups)

statistics: maintains low-level utilization and error statistics for each subnetwork monitored by the agent

History: record periodic statiscal samples from information available in the statistic group

RMON MIB Group alarm: allow the management console

user to set a sampling interval and alarm threshold for any counter or integer recorded by the RMON probe

host:contains counter for various types of traffic to and from hosts attached to the subnetwork

hostTopN: contains sorted host statistics that report that top a list based on some parameter in the host table

matrix: show error and utilization information in matrix form

filter:allow the monitor to observe packet that match a filter

(Packet) capture: governs how data is sent to a management console

event: gives a table of all events generated by RMON probe

tokenRing:maintains statistics and configuration information for token ring subnetworks

Important note 1

All groups in the RMON MIB are optional but there are some dependencies

The alarm group require the implementation of the event group

The hostTopN group requires the implementation of the host group

The packet capture group require the implementation of the filter group

Important note 2

Collection of traffic statistics for one opr more subnetworks statistics, history, host, hostTopN,

matrix, tokenRing Various alarm conditions and

filtering with user-defined alarm, filter, capture, event

Statistics Group Fig 8-6

Table 8.2

The statistics group provides useful information about the load and overall health of the subnetwork

Various error conditions are counted such as CRC or alignment error, collision, undersized and oversized packets

History Group

The history group is used to define sampling functions for one or more of the interfaces of the monitor

2 tables historyControltable – specify the

interface and detail of sampling function

etherHistorytable – record data

Fig 8.7

historyControlTable historyControlIndex: index of entry which is

the same number as used in etherhistoryTable historyControlDataSource: identify interface to

be sampled historyControlBucketsRequested: the

requested number of discrete sampling interval, a default value is 50

historyControlBucketsGranted: the actual number of discrete sampling interval

historyControlInterval: interval in second maximum is 3600 (1 hour) ,default value is 1800

Sampling scheme

Consider by historyControlBucketGranted and historyControlInterval

Ex. Use the default value of both the monitor would take a sample once

every 1800 seconds ( 30 min) each sample is stored in a row of etherHistoryTable

The most 50 rows are retained

Utilization

It calculates on the two counters :ehterStatsOctets and etherStatsPkts

Utilization=100% x [(Packets x (96+64)))+(Ocetsx8)/interval x 107]

64 bit – preamble 96 bit – interframe gap

Fig8.8

Host Group

To gather statistics about specific hosts on the LAN by observing the source and destination MAC addresses in good packets

Consists of 3 tables: one control table (HostControlTable) two data tables (hostTable,hostTimeTable)

same information but index differently

hostControlTable hostControlIndex: identify a row in the

hostControlTable ,refering to a unique interface of the monitor

hostControlDatasource: identify the interface (the source of the data)

hostControlTablesize: the number of rows in hostTable (hostTimeTable)

hostControlLastDeleteTime: the last time that an entry (hostTable) was deleted

Fig 8.9

A simple RMON configuration Fig8.10

hostTable

hostAddress: MAC address of this host

hostCreationOrder: an index that defines the relative ordering of the creation time of hosts (index takes on a value 1-N)

hostIndex : the same number as hostControlIndex

Counter in hostTable Table 8.3

Fig 8.11

hostTopN Group

To maintain statistics about the set of hosts on one subnetwork that top a list based on some parameters

Statistics that are generated for this group are derived from data in the host group

The set of statistics for one object collected during one sampling interval is referred as report

hostTopNCntrolTable

hostTopNControlIndex : identify row in hostTopNControlTable,defining one top-N report for one interface

hostTopNHostIndex; match the value of hostControlIndex ,specifying a particular subnetwork

hostTopNRateBase: specify one of seven variables from hostTable

hostTopNTimeRemaining: time left during report currently being collected

hostTopNDuration: sampling interval hostTopNRequestedSize: maximum

number of requested hosts for the top-N report

hostTopNGrantedSize: maximum number of hosts for the top-N report

hostTopNStartTime: the last start time

hostTopNTable

hostTopNReport: same value as hostToNControlIndex

hostTopNIndex: uniquely identify a row

hostTopNAddress:MAC address hostTopNRate:the amount of

change in selected variable during sampling interval

Report preparation

A management station creates a row of the control table to specify a new report.

This control entry instructs the monitor to measure the difference between the beginning and ending values of a particular host group variable over a specific sampling period

The monitor calculates the final results and creates a set of N data rows

Fig 8.12

Fig 8.13

Matrix group To record information about the traffic

between pairs of hosts on a subnetwork The information is stored in the form of

a matrix Consists of 3 tables

One control table - matrixControlTable Two data table – matrixSDTable (traffic from

one host to all others) , matrixDSTable (traffic from all hosts to one particular host

matrixControlTable matrixControlIndex: identify a row in

the matrixControlTable matrixControlDataSource: identify

interface matrixControlTableSize: the number

of rows in the matrixSDTable matrixControlLastDeleteTime: the

last time that an entry was deleted

Fig 8.14

matrixSDTable (matrixDSTable)

matrixSDSourceAddress: the source MAC Address matrixSDDestAddress: the destination MAC Address matrixSDIndex: same value as matrixControlIndex matrixSDPkts: number of packets transmitted from

this source add. to destination add. including bad packet

matrixSDOctets: number of octets contained in all packets

matrixSDErrors:number of bad packets transmitted from this source add. to destination add.

matrixSDTable - operation

Indexed first by matrixSDIndex then source address then by destination address ,for matrixDSTable the source address is the last

The matrixSDTable contains 2 rows for every pair of hosts One row per direction

Logical view of the matrixSDtable rows associated with row I of the matrixControlTable

Fig 8.15