Re: [fw-wiz] Firewall Log Analysis - Computer vs. Human

From: Kevin (kkadow_at_gmail.com)
Date: 07/06/05

  • Next message: Devdas Bhagat: "Re: [fw-wiz] Cisco PIX Version 6.3(3) SMTP Problem"
    To: firewall-wizards@icsalabs.com
    Date: Wed, 6 Jul 2005 13:27:46 -0500
    
    

    Another approach is to look at what are the things that a computer can
    do a lot better than a human?

    Computers don't get bored, nor do they get tired of the sentinel that
    continually "cries wolf" and just start ignoring future alarms. Software
    can exactly count the rate of connections or other events, and track
    trends in these rates over very short of very long time periods.

    On 7/5/05, Adrian Grigorof <adi@grigorof.com> wrote:
    > We are trying to develop a log analyzer that would "replicate" a human's
    > approach to log analysis - by that I mean the fact that a human can
    > correlate information in the log with other factors (like - "hmm, the log
    > says that the firewall was restarted at 12:03 PM"... oh, yeah, it was that
    > UPS failure yesterday around noon). For this particular example, the log
    > analyzer could say in the report: "12:03 PM - Firewall restarted - Possible
    > power failure, power disconnection or manual restart" - a bit vague I agree
    > but it is better than nothing - and in fact, this is what the firewall
    > admin would go through, right? Thinking, "Why would there be a restart? I
    > did not restart it.. anything happened at noon? The UPS failure!".

    This type of "event correlation" is definitely something that can be (has been?)
    written into a program.

    > Or for example, instead of saying IP 123.123.123.123 was denied for protocol
    > TCP/8543 and let the firewall admin worry about it maybe the analyzer should
    > do a bit of analysis, check the "history", see that this protocol is not
    > something commonly used, it's not one of the common worms and decide to
    > report that it is in fact a stray TCP packet caused by Internet latency (TCP
    > port higher than 1024, not a "known protocol", coming from an IP address
    > that is typically accessed by internal IPs via HTTP - all this information
    > is should be obtainable from the logs).

    Better yet, if your logs are _really_ complete, the analyzer could look back
    through the history of TCP connections, determine that port 8543 was
    recently used as the local source of a connection out towards port 80 of
    the host 123.123.123.123, and determine that it is safe to ignore a stray
    ACK/RST packet from that host, within a reasonable window.

    I've found in log analysis that it's usually not difficult to write a program to
    summarize and strip out the "noise", so the human analyst can concentrate
    on the unusual events; not just denied attempts, but also permitted actions
    where the connection rate or throughput is significantly higher or lower than
    the baseline, or the sources and destination (or pattern of src/dst) differ
    from the norm, sort of like 'traffic analysis" in the old school spycraft sense.

    > Now, the question is, what are the things (in your opinion) that only a
    > human can do?

    A human can interpret a sequence of seemingly random actions and make
    a good guess as to the existence and intent of the human on the other end.

    Beyond that, humans are hardwired for pattern recognition (sometimes too
    well, seeing patterns where none actually exist).

    One way to look at event analysis is to approach it like the "machine vision"
    problem -- it's really difficult to write software that recognizes objects in a
    cluttered visual field, much less to approach the ability of a person in
    that regard. That doesn't stop programmers from writing software to do
    edge detection and image enhancement, or video motion alarm detection
    software for CCTV security systems.

    Kevin Kadow
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: Devdas Bhagat: "Re: [fw-wiz] Cisco PIX Version 6.3(3) SMTP Problem"

    Relevant Pages

    • Re: cant get Remote desktop to Work
      ... How do you allow TCP connections via port 3389 (I would like to keep the ... firewall going) - but will this make my PC vulnerable if 3389 is open? ... Remote Desktop is very much like PC Anywhere, without all the bloat of added ...
      (microsoft.public.windowsxp.network_web)
    • Re: cant get Remote desktop to Work
      ... How do you allow TCP connections via port 3389 (I would like to keep the ... firewall going) - but will this make my PC vulnerable if 3389 is open? ... Remote Desktop is very much like PC Anywhere, without all the bloat of added ...
      (microsoft.public.windowsxp.general)
    • Re: Could it be a hacker ?
      ... The PIX firewall logged that SERVER1 was trying to reach ... The firewall guy thought the server was ... TCP SERVER1:1072 134.252.155.227:http FIN_WAIT_1 ... > address in a TCP connections, due to the requirement of the three way TCP ...
      (microsoft.public.security)
    • Long-running connections sometimes lock up (ie. AIM/ICQ/Yahoo Messenger) on a FreeBSD 5.1R firewall/
      ... HTTP connections across the firewall work fine and ... $fwcmd add divert natd all from any to any via $outside_if ... $fwcmd add allow tcp from me to any out via lo0 setup keep-state ...
      (comp.unix.bsd.freebsd.misc)
    • Long-running connections sometimes lock up (ie. AIM/ICQ/Yahoo Messenger) on a FreeBSD 5.1R firewall/
      ... HTTP connections across the firewall work fine and ... $fwcmd add divert natd all from any to any via $outside_if ... $fwcmd add allow tcp from me to any out via lo0 setup keep-state ...
      (comp.security.firewalls)