Re: [logs] intrusion detection and log analysis [was: book advice]

From: Chris Brenton (cbrenton@private)
Date: Tue Nov 04 2003 - 04:10:16 PST

  • Next message: Bruce Potter: "[logs] Re: [TSG] intrusion detection and log analysis [was: book advice]"

    On Tue, 2003-11-04 at 02:45, The Goddess Tina Bird quotes Eric Johanson
    as saying:
    >
    > > I suspect we'll start seeing products in a few years that are focused on
    > > 'whitelisting' traffic.  Anything that doesn't match this pattern, kill
    > > it.
    
    I think that day is a ways off as most environments are an evolving
    animal. With new products hitting the market and specs constantly being
    updated, what's "normal" today is not the same as it was three months or
    even three weeks ago.
    
    _Detection_ of abnormal events is already here however. NFR can be
    programmed with normal traffic patterns and report anything that falls
    outside of this range. If you are familiar with Snort, check out:
    
    http://www.sysd.com/
    
    They bundle Snort with their own port scan detector and anomaly engine.
    I've had excellent luck with this product.
    
    > > As for Rodney's comment:  For Network based ISDs, I think we need to not
    > > look at attacks, but look at abnormal traffic.  EG: my web server should
    > > not do dns lookups.  My mail server should not be ftping out.  Nobody
    > > should be sshing/tsing into the DB server in the DMZ.   My server should
    > > only send SYNACKs on port X,Y and Z.
    > >
    > > I'm pretty sure that snort could be made to do this - - but it doesn't do
    > > this today without some major rule foo.
    
    Actually, you can do this with your firewall. I just dumped a couple of
    papers on Tina for the loganalysis site that describe the process. 
    
    > had a fascinating talk with microsoft today about getting them to modify
    > their patch installer (the thing that windows update >runs<, not windows
    > update itself) so that in addition to creating a registry key for a patch
    > when it >begins< an install, it also generates a checksum for the new
    > files it's installed when it >finishes<, and then put that into the event
    > log where i can centralize it and monitor it and have a higher level of
    > confidence that the damn patch succeeded...
    
    I *really* like this idea. One of the problems you can run into is you
    patch some file and then install software off the CD, thus reversing the
    patch. An audit trail of checksums would be a far more accurate way of
    verifying if the system is properly patched. This certainly beats
    looking for the existence of a registry key entry.
    
    Thanks Tina!
    C
    
    
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysis@private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Tue Nov 04 2003 - 09:06:20 PST