Date post: | 04-Jan-2016 |
Category: |
Documents |
Upload: | arnold-patterson |
View: | 238 times |
Download: | 2 times |
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