Re: [logs] SDSC Secure Syslog

From: Marcus J. Ranum (mjrat_private)
Date: Thu Dec 05 2002 - 13:48:33 PST

  • Next message: Marcus J. Ranum: "Re: [logs] reinventing syslog [was: Secure Central Log Host]"

    Tom Perrine wrote:
    >It was a bad idea when you heard of it, and its still a bad idea, AT
    >LEAST FOR SYSLOG.  I can easily see places where multiple virtual
    >channels over a single TCP connection could be useful.  The
    >"stackable" session profiles is kinda a nice idea.  If I was going to
    >do a fourth generation TELNET, BEEP would be a good answer, if there
    >were some libraries...
    
    It's a bad idea _in_  _general_.
    
    Remember LAT? It was a DECNet terminal multiplexing thingie used by
    DEC Terminal servers in the 70's and 80's. It sucked. Why? Because
    it's _REALLY_ hard to apply security filtering to multiplexing protocols -
    the protocols get extended and the next thing you know you've got file
    transfer and sharing and IP-over-multiplexed-channels and everything
    gets very grotty very fast.
    
    The ostensible reason for having those kind of multiplexed protocols
    is usually something like "that way we don't have to have as many
    sockets open" which is a silly argument when you consider that Web
    Services have caused a lot of changes to Unix (and Windows) kernel
    internals to make lookups on sockets and management of large
    numbers of sockets more efficient. It's probably easier for a modern
    BSD system to handle 10,000 live sockets today than it was for an 80's
    BSD kernel to handle 1,000.
    
    I suspect it was similar concerns that led the "designers" of syslog-1
    to use UDP - no need to have a daemon that could effectively cope with
    large numbers of connected-state sockets. So, the braindamage began -
    I guess it was too hard to look up the man pages for shared memory
    system calls, or to just put it all in the /dev/log driver (and had a
    tamper-resistant-kernel-mode system logging facility like most REAL
    operating systems...)
    
    I'm consistently amazed that people worry about syslog performance. ;)
    How can you, when 99% of syslog implementations share the common
    performance improvement mechanism of dropping the UDP packets
    when the transmit queue on the client overflows. (See earlier posts by
    me in this list regarding how bad it can get under loads...)  Making
    something that can _receive_ all those packets is straightforward -
    fixing all the broken syslog clients is a much more serious problem.
    If the standards process actually worked, the entire syslog protocol
    (especially the UDP client side) would be deprecated. *sigh*
    
    Re-reading this before I hit "send" I muse briefly about the possibility
    of becoming a "software historian" - I don't think anyone's done that, yet.
    Hmmm...  "Social and economic factors and their influence on the
    development of logging protocols in California during the early 1980's..."
    I can see it already...
    
    mjr.
    ---
    Marcus J. Ranum - Computer and communications Security Expertise
    mjrat_private  (http://www.ranum.com)
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysisat_private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Thu Dec 05 2002 - 14:11:06 PST