Simple authentication of syslog messages for embedded network devices

[Alex Brown]

This is not yet in proper RFC form, but it should suffice to restate the case for improved practice within an existing syslog environment.    All comments are welcome.

http://www.msg.com/~abrown/draft-syslog-auth.html

-- 
Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761

 

Title: Simple authentication of syslog messages for embedded network devices

Simple authentication of syslog messages for embedded network devices

Alex Brown, [EMAIL PROTECTED]
Wed Jul 19 08:00:00 EDT 2000

Network logging is a security concern because it handles
authentication and authorization event information and is itself a
potential path for attack.  The UNIX syslog service has become a de
facto logging protocol for network systems, despite significant
security flaws; these problems are discussed and strategies for
cautious use of the service are recommended.  This document is a draft of an Internet Draft recommending a Best Common
Practice for use of syslog.  Distribution of this memo is unlimited.

1. Introduction  

1.1 Status of this Memo  

This document is a draft of an Internet Draft.
Distribution of this memo is unlimited.

1.2 Copyright Notice  

Copyright (C) The Internet Society (2000).  All Rights Reserved.
2. UNIX syslog as a de facto standard logging protocol

As a result of the close relationship between the UNIX operating
system and the Internet protocols, the UNIX syslog service has become
a de facto logging protocol for network systems, despite severe
deficiencies as a protocol, either for a persistent storage service or
for protection of critical information about device and service
status.  This is because the syslog service was provided initially
for local event logging within a UNIX host, and only later grew
into a general network log service.  
(Because of this close relationship, the following description assumes
a UNIX system environment.  Other system environments also have
implementations of syslog, notably Windows PCs servers and clients in
network devices such as routers, switches, and firewalls.)
UNIX syslog is both an API and a very simple protocol, for persistent
storage of text messages, used throughout UNIX network service
software.  The protocol and its security issues are described in [LOG00].
In early UNIX and Internet practice, syslog was primarily a local UNIX
logging mechanism, which provided a convenient debugging and
monitoring facility for software in all parts of the system -- kernel,
system applications, and user applications.  Logging was often carried
out only to the hard-copy system console, to capture transient events
leading to a system failure that would destroy the event record before
it reached a file.
Syslog is now widely used in network operations to record
authentication events, originating both in the authentication agents
of UNIX network server applications such as login(1), su(1M),
getty(1M), ftp(1) and others, and in network devices such as remote
dialup access servers.  It has therefore become a security feature of
UNIX networks.
As network installation size grows, and administrators are responsible
for more and more system activity, forwarding of syslog messages over
more than one hop is widely used to relay event records to a central
system, where scripts and other offline analysis tools can be used
either periodically scheduled, or interactively, to identify attack
sequences.  The integrity of both the syslog configuration files, as
well as the syslog output logfiles, are therefore also security
concerns.  Resource limitations for log message traffic on the
network, and especially log storage on disk, are significant security
vulnerabilities, primarily due to lack of authentication, which would
permit a log server to discard bogus messages.

3. Current practice

Syslog is still the most widespread and usable tool for network event
logging, and it is useful for embedded network devices because it is a
low-cost protocol that can be easily added to even the smallest
devices.  While improved security event logging mechanisms such as
[IAP00] can provide far better solutions in the long run, these
mechanisms require more cryptographic resources in the originating
device than an embedded device can easily afford, as well as coordinated
deployment of analyzer and reporting facilities.  The following
recommendations are for cautious interim use of an existing insecure syslog
infrastructure, and are not intended to provide an alternative to a
fully secure network logging and intrusion alert facility.
Best common practice strategies for cautious use of syslog include:


Provide syslog servers with CPU and disk capacity far
exceeding normal needs.
Check file permissions for all logfiles and syslog.conf at each log host.
Design network to limit access for udp/514 syslog, and isolate syslog
regions within a network as well as inside from outside.


4. Improved practice

Recommended improved practies include:


Add basic security and authentication information to message text in syslog client implementations.
Add filtering of messages based on basic security and authentication information in text, to syslog server implementations.


4.1 Basic security enhancements  



Add IP address or DNS FQDN of originator to message text so
it's not lost in forwarding.
Use an IP access list for syslogd to permit receiver to filter all
packets not claiming to be from a valid source address, either in
header or in message text.


4.2 Authentication filtering enhancements  

A cryptographic hash in the message text using a secret shared
between client and server can provide authentication, making it
possible to filter out falsified syslog messages.  (The shared
secret string must be initialized in the originating device in some
secure way during installation.)  By adding chaining of hash codes
in a sequence of authenticated messages, missing messages can be
detected and falsified messages can be dropped.  Use of chained
hash codes for authentication of message sequences is discussed in
detail in [CSL98], [SAL99], and [RAL99].
Crypto hash functions, e.g. HMAC-MD5 [RFC1321], are fast and small,
and are often present in even the smallest network devices and
therefore pose little additional code burden.  A hash value can be
added by the client to existing log message text, as an optional
feature, and interpreted by a syslogd filter, or by a postprocessor
filter.  
The following are examples of security enhancement extensions to
both client and server (or analysis filters) in a syslog
environment.  Syntax of the examples follows the general approach of
[ULM99].  (Long hex string values are line-wrapped for presentation
here only.)

Authentication field within message text    

If a shared secret is provided between log client and log host, a
message authentication code (MAC, e.g. HMAC-MD5) field can be
appended to the message text by the log client as an optional
extension, computed over the message text excluding the MAC field,
and the shared secret (in this case the string "notobvious"):
Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
  for user abrown by (uid=0) md5=02ebc80d6d165fb6cdd4cc2520e8192f
    

The log host syslogd can filter on this MAC in real time so that
bogus messages never reach the logfiles, or filtering can take
place offline.  A table of shared secrets for all log sources must
be available; this table is security critical information.

Nonce field within message text    

If more than one message with the same text occurs (as is common
in syslog) the authentication field can have the same value; this
makes a variety of spoofing attacks possible.  To reduce the
likelihood of messages with identical text, a nonrepeating nonce
can be placed in plaintext in the message (same secret):

Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
  for user abrown by (uid=0) nonce=941841456 \
  md5=227c40a6cde84f49bfad43c412490110
    


Chained authentication    

The nonce may be replaced with the last MAC sent from the log
client, making it possible to detect an insertion or gap in the
syslog stream from a client (same secret):
...
Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
  for user abrown by (uid=0) chain=227c40a6cde84f49bfad43c412490110 \
   md5=a6739e57964c9dec7613d663f049c0f7
Nov  5 14:14:55 zorilla PAM_pwdb[509]: (login) session closed \
  for user abrown chain=a6739e57964c9dec7613d663f049c0f7 \
  md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
...
    

Each individual record can still be authenticated independently
from all others, but also can be sequenced by verifying the
"chain" field.  The log host syslogd or filter must retain the
previous MAC value for each log source.  The first record from
each source will be unsequenceable, because no prior MAC value is
available.  A missing or corrupted record or a gap can be
identified but not recovered.
5. Security Considerations

This document is primarily concerned with security issues in network
logging.  Other related issues in UNIX system and network
administration are not within its scope.

6. References


     [LOG00]
          C. Lonvick, "Syslog Protocol."
          The Internet Society, July 2000. Available from
          ftp.ietf.org/internet-drafts/draft-ietf-syslog-syslog-0.3.txt
     [IAP00]
          D.Gupta, "Intrusion Alert Protocol - IAP"
          The Internet Society, March 2000. Available from
          ftp.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
     [ULM99]
          J. Abela and T. Debeaupis, "Universal Format for Logger Messages."
          The Internet Society, May 1999. Available from
          ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt.
     [CSL98]
          B. Schneier and J. Kelsey, "Cryptographic Support for Secure
          Logs on Untrusted Machines", The Seventh USENIX Security
          Symposium Proceedings, USENIX Press, January 1998, pp. 53-62.
          http://www.counterpane.com/secure-logs.html
     [SAL99]
          B. Schneier and J. Kelsey, "Secure Audit Logs to Support
          Computer Forensics", ACM Transactions on Information and
          System Security, v. 1, n. 3, 1999.
          http://www.counterpane.com/audit-logs.html
     [RAL99]
          B. Schneier and J. Kelsey, "Minimizing Bandwidth for Remote
          Access to Cryptographically Protected Audit Logs", Second
          International Workshop on the Recent Advances in Intrusion
          Detection (RAID '99), September 1999.
          http://www.counterpane.com/auditlog2.html
     [RFC1321]
          R. Rivest, "The MD5 Message-Digest Algorithm".
          The Internet Society, April 1992. Available from
          ftp://ftp.isi.edu/in-notes/rfc1321.txt


7. Author's Address


Alex Brown
3Com Corporation
Three 3Com Drive
Marlborough MA 01752

Phone: (508) 323-2283

EMail: [EMAIL PROTECTED]

  Simple authentication of syslog messages for embedded net-
  work devices
  Alex Brown, [EMAIL PROTECTED]
  Wed Jul 19 08:00:00 EDT 2000

  Network logging is a security concern because it handles authentica-
  tion and authorization event information and is itself a potential
  path for attack.  The UNIX syslog service has become a de facto log-
  ging protocol for network systems, despite significant security flaws;
  strategies for cautious use of the service are recommended in this
  memo.  This document is a draft of an Internet Draft recommending a
  Best Common Practice for use of syslog.  Distribution of this memo is
  unlimited.
  ______________________________________________________________________

  Table of Contents


  1. Introduction

     1.1 Status of this Memo
     1.2 Copyright Notice

  2. UNIX syslog as a de facto standard logging protocol

  3. Current practice

  4. Improved practice

     4.1 Basic security enhancements
     4.2 Authentication filtering enhancements
        4.2.1 Authentication field within message text
        4.2.2 Nonce field within message text
        4.2.3 Chained authentication

  5. Security Considerations

  6. References

  7. Author's Address



  ______________________________________________________________________

  11..

  IInnttrroodduuccttiioonn

  11..11..

  SSttaattuuss ooff tthhiiss MMeemmoo

  This document is a draft of an Internet Draft.  Distribution of this
  memo is unlimited.


  11..22..

  CCooppyyrriigghhtt NNoottiiccee

  Copyright (C) The Internet Society (2000).  All Rights Reserved.




  22..  UUNNIIXX ssyysslloogg aass aa ddee ffaaccttoo 
ssttaannddaarrdd llooggggiinngg pprroottooccooll

  As a result of the close relationship between the UNIX operating
  system and the Internet protocols, the UNIX syslog service has become
  a de facto logging protocol for network systems, despite severe
  deficiencies as a protocol, either for a persistent storage service or
  for protection of critical information about device and service
  status.  This is because the syslog service was provided initially for
  local event logging within a UNIX host, and only later grew into a
  general network log service.

  (Because of this close relationship, the following description assumes
  a UNIX system environment.  Other system environments also have
  implementations of syslog, notably Windows PCs servers and clients in
  network devices such as routers, switches, and firewalls.)

  UNIX syslog is both an API and a very simple protocol, for persistent
  storage of text messages, used throughout UNIX network service
  software.  The protocol and its security issues are described in
  [LOG00].

  In early UNIX and Internet practice, syslog was primarily a local UNIX
  logging mechanism, which provided a convenient debugging and
  monitoring facility for software in all parts of the system -- kernel,
  system applications, and user applications.  Logging was often carried
  out only to the hard-copy system console, to capture transient events
  leading to a system failure that would destroy the event record before
  it reached a file.

  Syslog is now widely used in network operations to record
  authentication events, originating both in the authentication agents
  of UNIX network server applications such as login(1), su(1M),
  getty(1M), ftp(1) and others, and in network devices such as remote
  dialup access servers.  It has therefore become a security feature of
  UNIX networks, and is often used in supporting access from user
  networks of non-UNIX personal computers.

  As network installation size grows, and administrators are responsible
  for more and more system activity, forwarding of syslog messages over
  more than one hop is widely used to relay event records to a central
  system, where scripts and other offline analysis tools can be used
  either periodically scheduled, or interactively, to identify attack
  sequences.  The integrity of both the syslog configuration files, as
  well as the syslog output logfiles, are therefore also security
  concerns.  Resource limitations for log message traffic on the
  network, and especially log storage on disk, are significant security
  vulnerabilities, primarily due to lack of authentication, which would
  permit a log server to discard bogus messages.


  33..  CCuurrrreenntt pprraaccttiiccee

  Syslog is still the most widespread and usable tool for network event
  logging, and it is useful for embedded network devices because it is a
  low-cost protocol that can be easily added to even the smallest
  devices.  While improved security event logging mechanisms such as
  [IAP00] can provide far better solutions in the long run, these
  mechanisms require more cryptographic resources in the originating
  device than an embedded device can easily afford, as well as
  coordinated deployment of analyzer and reporting facilities.  The
  following recommendations are for cautious interim use of an existing
  insecure syslog infrastructure, and are not intended to provide an
  alternative to a fully secure network logging and intrusion alert
  facility.


  Best common practice strategies for cautious use of syslog include:


  +o  Provide syslog servers with CPU and disk capacity far exceeding
     normal needs.

  +o  Check file permissions for all logfiles and syslog.conf at each log
     host.

  +o  Design network to limit access for udp/514 syslog, and isolate
     syslog regions within a network as well as inside from outside.


  44..  IImmpprroovveedd pprraaccttiiccee

  Recommended improved practies include:


  +o  Add basic security and authentication information to message text
     in syslog client implementations.

  +o  Add filtering of messages based on basic security and
     authentication information in text, to syslog server
     implementations.


  44..11..

  BBaassiicc sseeccuurriittyy eennhhaanncceemmeennttss


  +o  Add IP address or DNS FQDN of originator to message text so it's
     not lost in forwarding.

  +o  Use an IP access list for syslogd to permit receiver to filter all
     packets not claiming to be from a valid source address, either in
     header or in message text.


  44..22..

  AAuutthheennttiiccaattiioonn ffiilltteerriinngg 
eennhhaanncceemmeennttss

  A cryptographic hash in the message text using a secret shared between
  client and server can provide authentication, making it possible to
  filter out falsified syslog messages.  (The shared secret string must
  be initialized in the originating device in some secure way during
  installation.)  By adding chaining of hash codes in a sequence of
  authenticated messages, missing messages can be detected and falsified
  messages can be dropped.  Use of chained hash codes for authentication
  of message sequences is discussed in detail in [CSL98], [SAL99], and
  [RAL99].

  Crypto hash functions, e.g. HMAC-MD5 [RFC1321], are fast and small,
  and are often present in even the smallest network devices and
  therefore pose little additional code burden.  A hash value can be
  added by the client to existing log message text, as an optional
  feature, and interpreted by a syslogd filter, or by a postprocessor
  filter.

  The following are examples of security enhancement extensions to both
  client and server (or analysis filters) in a syslog environment.
  Syntax of the examples follows the general approach of [ULM99].  (Long
  hex string values are line-wrapped for presentation here only.)


  44..22..11..

  AAuutthheennttiiccaattiioonn ffiieelldd wwiitthhiinn 
mmeessssaaggee tteexxtt

  If a shared secret is provided between log client and log host, a
  message authentication code (MAC, e.g. HMAC-MD5) field can be appended
  to the message text by the log client as an optional extension,
  computed over the message text excluding the MAC field, and the shared
  secret (in this case the string "notobvious"):

  Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
    for user abrown by (uid=0) md5=02ebc80d6d165fb6cdd4cc2520e8192f




  The log host syslogd can filter on this MAC in real time so that bogus
  messages never reach the logfiles, or filtering can take place
  offline.  A table of shared secrets for all log sources must be
  available; this table is security critical information.


  44..22..22..

  NNoonnccee ffiieelldd wwiitthhiinn mmeessssaaggee tteexxtt

  If more than one message with the same text occurs (as is common in
  syslog) the authentication field can have the same value; this makes a
  variety of spoofing attacks possible.  To reduce the likelihood of
  messages with identical text, a nonrepeating nonce can be placed in
  plaintext in the message (same secret):


  Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
    for user abrown by (uid=0) nonce=941841456 \
    md5=227c40a6cde84f49bfad43c412490110





  44..22..33..

  CChhaaiinneedd aauutthheennttiiccaattiioonn

  The nonce may be replaced with the last MAC sent from the log client,
  making it possible to detect an insertion or gap in the syslog stream
  from a client (same secret):

  ...
  Nov  5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
    for user abrown by (uid=0) chain=227c40a6cde84f49bfad43c412490110 \
     md5=a6739e57964c9dec7613d663f049c0f7
  Nov  5 14:14:55 zorilla PAM_pwdb[509]: (login) session closed \
    for user abrown chain=a6739e57964c9dec7613d663f049c0f7 \
    md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
  ...




  Each individual record can still be authenticated independently from
  all others, but also can be sequenced by verifying the "chain" field.
  The log host syslogd or filter must retain the previous MAC value for
  each log source.  The first record from each source will be
  unsequenceable, because no prior MAC value is available.  A missing or
  corrupted record or a gap can be identified but not recovered.

  55..  SSeeccuurriittyy CCoonnssiiddeerraattiioonnss

  This document is primarily concerned with security issues in network
  logging.  Other related issues in UNIX system and network
  administration are not within its scope.


  66..  RReeffeerreenncceess


       [LOG00]
            C. Lonvick, "Syslog Protocol."
            The Internet Society, July 2000. Available from
            ftp.ietf.org/internet-drafts/draft-ietf-syslog-syslog-0.3.txt
       [IAP00]
            D.Gupta, "Intrusion Alert Protocol - IAP"
            The Internet Society, March 2000. Available from
            ftp.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
       [ULM99]
            J. Abela and T. Debeaupis, "Universal Format for Logger Messages."
            The Internet Society, May 1999. Available from
            ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt.
       [CSL98]
            B. Schneier and J. Kelsey, "Cryptographic Support for Secure
            Logs on Untrusted Machines", The Seventh USENIX Security
            Symposium Proceedings, USENIX Press, January 1998, pp. 53-62.
            http://www.counterpane.com/secure-logs.html
       [SAL99]
            B. Schneier and J. Kelsey, "Secure Audit Logs to Support
            Computer Forensics", ACM Transactions on Information and
            System Security, v. 1, n. 3, 1999.
            http://www.counterpane.com/audit-logs.html
       [RAL99]
            B. Schneier and J. Kelsey, "Minimizing Bandwidth for Remote
            Access to Cryptographically Protected Audit Logs", Second
            International Workshop on the Recent Advances in Intrusion
            Detection (RAID '99), September 1999.
            http://www.counterpane.com/auditlog2.html
       [RFC1321]
            R. Rivest, "The MD5 Message-Digest Algorithm".
            The Internet Society, April 1992. Available from
            ftp://ftp.isi.edu/in-notes/rfc1321.txt




  77..  AAuutthhoorr''ss AAddddrreessss


  Alex Brown
  3Com Corporation
  Three 3Com Drive
  Marlborough MA 01752

  Phone: (508) 323-2283

  EMail: [EMAIL PROTECTED]