syslog

advertisement
SYSLOG, NetConf, NetFlow
W.lilakiatsakun
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
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
General 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
Example of Severity
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 hh:mm:ss"
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
HEADER part (3)
• 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
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
Example of syslog message
• <34> Oct 11 22:14:15 mymachine su: su root
failed on /dev/pts/8
• <34> - priority
• Oct 11 22:14:15 – timestamp
• mymachine – hostname
• su – TAG
• “su root’ failed for on /dev/pts/8 “- Content
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.
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.
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
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.
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
syslog deployment (2)
Circular log file
syslog deployment (3)
• syslog receiver (con’t)
– 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.
syslog deployment (4)
Logging host
syslog relay
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.
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.
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
Netconf Datastore (2)
A hierarchical datastore in Netconf
Netconf Datastore (3)
• Management operations can be applied to
individual subtrees
• This capability feature is called as subtree
filtering
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 readonly status information and collected statistics
State Data and Configuration Data
(2)
• NETCONF protocol recognizes the difference
between configuration data and state data
and provides operations for each.
• The <get-config> operation retrieves
configuration data only.
• The <get> operation retrieves configuration
and state data.
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
<email>alex@cisco.com(/email)
Netconf Architecture (1)
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
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
Netconf Message Structure
• Fig 8-14
A netconf request (1)
• Ex 8-4
A netconf request (2)
• RPC tag
<rpc message-id =“101 … > …. </rpc>
– The <rpc> 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 <rpcreply> message.
A netconf request (3)
• Namespace
– All NETCONF protocol elements are defined in the following
namespace:
urn:ietf:params:xml:ns:netconf:base:1.0
• Netconf operation
– <get-config> … </get-config>
• Netconf Data addressing
– <source>… </source> specifies the address of data
– <filter> … </filter> specifies the subtree
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
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.
Security Consideration (2)
• The protocol, therefore, must minimally
support options for both confidentiality and
authentication. (SSH, BEEP, etc)
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?
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 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
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.
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.
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
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.
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
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
Netflow packet structure
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 (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.
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.
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.
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.
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.
Example of Export Packet (1)
Example of Export Packet (2)
Example of Export Packet (3)
Management protocol positioning
Download