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 – IP Address – 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 codefacility 0 kernel messages 1user-level messages 2mail system 3system daemons

Example of Severity Codeseverity 0Emergency: system is unusable 1 Alert: action must be taken immediately 2Critical: critical conditions 3Error: 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) entries are between

MSG part It contains some additional information of the process that generated the message, and then the 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 message. This has traditionally been a freeform message that gives some detailed information of the event

Example of syslog message Oct 11 22:14:15 mymachine su: ’su root’ failed for lonvick on /dev/pts/8 - priority Oct 11 22:14:15 – timestamp mymachine – hostname su – TAG : ’su root’ failed for lonvick on /dev/pts/8- Content

Security consideration Authentication The syslog delivery mechanism does not strongly associate the message with the message sender a misconfigured machine may send syslog messages to a collector representing itself as another machine An attacker may transmit syslog messages to a collector.

Sequenced delivery the syslog process and protocol do not ensure ordered delivery. Reliable delivery no mechanism within either the syslog process 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

Misconfiguration The syslog message may go to untended receiver Load Considerations An attacker may perform a Denial of Service attack by filling the disk of the collector 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.network managementIETF The NETCONF protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. It also can perform some monitoring functions. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages.Extensible Markup Language The NETCONF protocol operations are realized on top 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 and - frame the overall message Netconf operation is get-config ( … … specifies the config being requested (running config) … 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.UDPSCTP Juniper Networks provides a similar feature for its routers called Jflow. Juniper Networks Huawei Technology routers also support the same technology, but call it NetStream Huawei Technology

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 that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long.

Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets 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 10 7 ] 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