SYSLOG, NetConf, NetFlow - PowerPoint PPT Presentation

1 / 64
About This Presentation
Title:

SYSLOG, NetConf, NetFlow

Description:

SYSLOG, NetConf, NetFlow W.lilakiatsakun – PowerPoint PPT presentation

Number of Views:107
Avg rating:3.0/5.0
Slides: 65
Provided by: woraphon
Category:

less

Transcript and Presenter's Notes

Title: SYSLOG, NetConf, NetFlow


1
SYSLOG, NetConf, NetFlow
  • W.lilakiatsakun

2
syslog (1)
  • 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

3
syslog (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

4
General syslog message
  • 179.19.209.130 IP Address
  • 000024 sequence number
  • Apr 12 180155643 local time
  • ENV_MON facility emitting the alarm
  • 1 severity
  • SHUTDOWN Event

5
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
(No Transcript)
7
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".

8
syslog message
  • Consists of 3 parts PRI /HEADER/MSG
  • Total length 1024 bytes or less

9
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

10
Example of Facility code
11
Example of Severity
12
HEADER part (1)
  • 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 hhmmss"

13
HEADER part (2)
  • 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

14
HEADER part (3)
  • hhmmss 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

15
MSG part (1)
  • 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)
  • CONTENT field contains the details of the
    message.
  • This has traditionally been a freeform message
    that gives some detailed information of the event

16
Example of syslog message
  • lt34gt Oct 11 221415 mymachine su su root failed
    on /dev/pts/8
  • lt34gt - priority
  • Oct 11 221415 timestamp
  • mymachine hostname
  • su TAG
  • su root failed for on /dev/pts/8 - Content

17
Security consideration (1)
  • 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.

18
Security consideration (2)
  • 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.

19
Security consideration (3)
  • 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

20
Security consideration (4)
  • 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.

21
syslog deployment (1)
  • Two roles are distinguished
  • syslog sender (management agent)
  • syslog receiver (management manager)
  • Syslog receiver (1)
  • Device itself writing the messages to a local log
    file
  • use circular log file for a limit size
  • Log files are created with a certain capacity

22
syslog deployment (2)
Circular log file
23
syslog deployment (3)
  • syslog receiver (cont)
  • Centralized logging host
  • Receiving messages from several devices and
    logging those messages
  • Applications access this logging host instead of
    individual devices
  • Syslog relay , forwarding syslog messages to
    various apps.

24
syslog deployment (4)
Logging host
syslog relay
25
Netconf (1)
  • 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
    install, manipulate, and delete the configuration
    of network devices.
  • It also can perform some monitoring functions.

26
Netconf (2)
  • It uses an Extensible Markup Language (XML) based
    data encoding for the configuration data as well
    as the protocol messages.
  • The NETCONF protocol operations are realized on
    top of a simple Remote Procedure Call (RPC)
    layer.

27
Netconf Datastore (1)
  • 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 provides the operations to manage those
    datastores.
  • SNMP targets the individual managed object in
    side MIB
  • Netconf targets the MIB as a whole or portion

28
Netconf Datastore (2)
A hierarchical datastore in Netconf
29
Netconf Datastore (3)
  • Management operations can be applied to
    individual subtrees
  • This capability feature is called as subtree
    filtering

30
State Data and Configuration Data (1)
  • The information that can be retrieved from a
    running system is separated into two classes,
    configuration data and state data.
  • Configuration data is the set of writable data
    that is required to transform a system from its
    initial default state into its current state
  • State data is the additional data on a system
    that is not configuration data such as read-only
    status information and collected statistics

31
State Data and Configuration Data (2)
  • NETCONF protocol recognizes the difference
    between configuration data and state data and
    provides operations for each.
  • The ltget-configgt operation retrieves
    configuration data only.
  • The ltgetgt operation retrieves configuration and
    state data.

32
Netconf and XML (1)
  • Netconf uses XML as encoding for its management
    operations
  • XML documents contain so-called tags to delimit
    different pieces of information
  • Tags are defined by users such as
  • ltemailgtalex_at_cisco.com(/email)

33
Netconf Architecture (1)
34
Netconf Architecture (2)
  • Transport layer - NETCONF implementation MUST
    support the SSH transport protocol mapping Secure
    (Authentication, Integrity, and Confidentiality )
  • 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

35
Netconf Architecture (3)
  • 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

36
Netconf Message Structure
  • Fig 8-14

37
A netconf request (1)
  • Ex 8-4

38
A netconf request (2)
  • RPC tag
  • ltrpc message-id 101 gt . lt/rpcgt
  • The ltrpcgt element has a mandatory attribute
    "message-id", which is an arbitrary string chosen
    by the sender of the RPC that will commonly
    encode a monotonically increasing integer.
  • The receiver of the RPC does not decode or
    interpret this string but simply saves it to be
    used as a "message-id" attribute in any resulting
    ltrpc-replygt message.

39
A netconf request (3)
  • Namespace
  • All NETCONF protocol elements are defined in the
    following namespace
  • urnietfparamsxmlnsnetconfbase1.0
  • Netconf operation
  • ltget-configgt lt/get-configgt
  • Netconf Data addressing
  • ltsourcegt lt/sourcegt specifies the address of data
  • ltfiltergt lt/filtergt specifies the subtree

40
A netconf reply
  • Ex 8-5

41
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

42
Security Consideration (1)
  • Configuration information is by its very nature
    sensitive.
  • Its transmission in the clear and without
    integrity checking leaves devices open to classic
    eavesdropping attacks.
  • Configuration information often contains
    passwords, user names, service descriptions, and
    topological information, all of which are
    sensitive.

43
Security Consideration (2)
  • The protocol, therefore, must minimally support
    options for both confidentiality and
    authentication. (SSH, BEEP, etc)

44
Netflow protocol /IPFIX (1)
  • RFC 3954 (Netflow V.9)
  • RFC 5101 (IPFIX- aka. Netflow V.10)
  • Netflow was introduced by cisco to collect 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?

45
Netflow protocol /IPFIX (2)
  • 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 filetransfer application ,all packets belong
    to the same transfer

46
  • Fig 8-15

47
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

48
Terminology (1)
  • Observation Point
  • An Observation Point is a location in the network
    where IP packets can be observed for example,
    one or a set of interfaces on a network device
    like a router.
  • Observation Domain
  • The set of Observation Points that is the largest
    aggregatable set of flow information at the
    network device with NetFlow services enabled is
    termed an Observation Domain.

49
Terminology (2)
  • IP Flow or Flow
  • Set of IP packets passing an Observation Point in
    the network during a certain time interval.
  • All packets that belong to a particular Flow have
    a set of common properties derived from the data
    contained in the packet and from the packet
    treatment at the Observation Point.
  • Flow Record
  • A Flow Record provides information about an IP
    Flow observed at an Observation Point.
  • The Flow Data Records are also referred to as
    NetFlow services data and NetFlow data.

50
Terminology (3)
  • Exporter
  • A device (for example, a router) with the NetFlow
    services enabled, the Exporter monitors packets
    entering an Observation Point and creates Flows
    from these packets.
  • The information from these Flows is exported in
    the form of Flow Records to the NetFlow Collector

51
Terminology (4)
  • NetFlow Collector
  • The NetFlow Collector receives Flow Records from
    one or more Exporters.
  • It processes the received Export Packet(s) that
    is, it parses and stores the Flow Record
    information.
  • Flow Records can be optionally aggregated before
    being stored on the hard disk.

52
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

53
Netflow Protocol
  • Netflow version5 is commonly used
  • The newest version is 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 it NetStream

54
Netflow packet structure
55
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

56
Finishing the flow (1)
  • 1. If the Exporter can detect the end of a Flow.
    For example, if the FIN or RST bit is detected in
    a TCP RFC793 connection, the Flow Record is
    exported.
  • 2. If the Flow has been inactive for a certain
    period of time. This inactivity timeout SHOULD be
    configurable at the Exporter, with a minimum
    value of 0 for an immediate expiration.

57
Finishing the flow (2)
  • 3. For long-lasting Flows, the Exporter SHOULD
    export the Flow Records on a regular basis. This
    timeout SHOULD be configurable at the Exporter.
  • 4. If the Exporter experiences internal
    constraints, a Flow MAY be forced to expire
    prematurely for example, counters wrapping or
    low memory.

58
Security Consideration (1)
  • Disclosure of Flow Information Data
  • Export Packets are not encrypted, the observation
    of Flow Records can give an attacker information
    about the active flows in the network,
    communication endpoints and traffic patterns.
  • This information can be used both to spy on user
    behavior and to plan and conceal future attacks.
    The information that an attacker could derive
    from the interception of Flow Records depends on
    the Flow definition.

59
Security Consideration (2)
  • Forgery of Flow Records or Template Records
  • If Flow Records are used in accounting and/or
    security applications, there may be a strong
    incentive to forge exported Flow Records (for
    example to defraud the service provider, or to
    prevent the detection of an attack).
  • This can be done either by altering the Flow
    Records on the path between the Observer and the
    Collector, or by injecting forged Flow Records
    that pretend to be originated by the Exporter.

60
Security Consideration (3)
  • Attacks on the NetFlow Collector
  • Denial of service attacks on the NetFlow
    Collector can consume so many resources from the
    machine that, the Collector is unable to capture
    or decode some NetFlow Export Packets. Such
    hazards are not explicitly addressed by the
    NetFlow Version 9 protocol, although the normal
    methods used to protect a server from a DoS
    attack will mitigate the problem.

61
Example of Export Packet (1)
62
Example of Export Packet (2)
63
Example of Export Packet (3)
64
Management protocol positioning
Write a Comment
User Comments (0)
About PowerShow.com