Download presentation
Presentation is loading. Please wait.
Published byArnold Patterson Modified over 9 years ago
1
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
2
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
3
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
4
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
6
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".
7
Syslog message Consists of 3 parts :PRI /HEADER/MSG Total length 1024 bytes or less
8
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
9
Example of Facility code codefacility 0 kernel messages 1user-level messages 2mail system 3system daemons
10
Example of Severity Codeseverity 0Emergency: system is unusable 1 Alert: action must be taken immediately 2Critical: critical conditions 3Error: error conditions
11
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"
12
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
13
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 00 - 59
14
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
15
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
16
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.
17
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.
18
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
19
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.
20
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.
21
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
22
A hierarchical datastore in Netconf Fig 8-11
23
Netconf Architecture Fig 8-12
24
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
25
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
26
Netconf Message Structure Fig 8-14
27
A netconf request Ex 8-4
28
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
29
A netconf reply Ex 8-5
30
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
31
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?
32
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
33
Fig 8-15
34
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
35
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
36
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
37
Netflow packet structure Fig 8-16
38
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
39
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
40
Management protocol positioning Fig 8-17
41
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
42
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
43
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
44
Fig 8.1
45
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
46
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
47
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
48
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
49
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
50
Fig 8.3
51
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.
52
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
53
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
55
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
56
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
57
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
58
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
59
Statistics Group Fig 8-6
60
Table 8.2
62
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
63
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
64
Fig 8.7
66
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
67
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
68
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
69
Fig8.8
70
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
71
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
72
Fig 8.9
74
A simple RMON configuration Fig8.10
75
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
76
Counter in hostTable Table 8.3
77
Fig 8.11
78
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
79
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
80
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
81
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
82
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
83
Fig 8.12
84
Fig 8.13
85
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
86
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
87
Fig 8.14
88
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.
89
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
90
Logical view of the matrixSDtable rows associated with row I of the matrixControlTable Fig 8.15
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.