RE: [fw-wiz] Log checking?

From: Paul D. Robertson (
Date: 10/01/04

  • Next message: Kevin: "Re: [fw-wiz] DMZ Ideas"
    To: FW Wizards Mailing List <>
    Date: Fri, 1 Oct 2004 06:58:33 -0400 (EDT)

    On Thu, 30 Sep 2004, FW Wizards Mailing List wrote:

    > While I've really enjoyed reading this communication regarding logging,
    > I'm a little concerned. I think that all incoming traffic that is
    > dropped should be logged. An accept for an incoming ftp request would

    There's a good case to be made for logging *everything*- but there are
    mitigating concerns (it's all discoverable, there's a lot of it, you need
    to be able to deal with the analysis...)

    While I generally recommend folks log as much as possible, with specific
    sunsets on retention, if you have 5,000 script kiddie attacks a day, you
    tend to evaluate where and what logging is important in a different light.
    It didn't take me long to decide that dropping anything out of band at the
    border was organizationally more palatable than building an
    infrastructure to keep up with logging and analyzing that much "attack"
    traffic when it wasn't going to be successful anyway. If it got past the
    outer screens, then I logged it and analyzed it, but I was still a lot
    more interested in what got through than what was blocked at that stage.

    Now, if you're not sued often, the idea of discoverable information may
    not be all that much of an issue- but if you've dealt with fulfilling
    discovery motions, you'll not want to have to excerpt terabytes of logs
    for every fishing expedition a lawyer might mount. That's probably the
    biggest danger in logging permitted traffic too, especially if you're a
    target of hostile workplace fishing expeditions, or trade secret ones.
    That's to say that there's risk even in logging, which needs to be
    evaluated against the benefits.

    Maybe it's the nature of the incidents I generally deal with, but while
    I've been happy to analyze a year's worth of firewall denied logs, the
    times I've been frustrated have been the times that I haven't had
    application logs from that same time period (stuff that was permitted
    through the firewall).

    > look legitimate, when logging drops would show that an attempt on a
    > blocked port took place prior to that "legitimate" ftp traffic.
    > Additionally, for legal purposes it would be important to have
    > documentation of all drops that a firewall had from a specific

    If you have evidence of an intrusion, that's always been sufficient in my
    experience to get discovery motions approved by a judge, or search
    warrants in criminal cases. While showing defeated attempts may help
    paint a "better picture," records of successful malicious activity always
    win in my experience. I've done some denied logging excepts to paint that
    picture for Web server attacks, but these days, I think judges in most
    jurisdictions have had enough cases that it's icing, not the cake, and
    denied application logs (allowed through the firewall, blocked by the
    application) have generally been the key (there's an argument that a
    smarter application firewall would put those in the denied log bucket.)

    While I'm waiting on a criminal case to see if the suspect accepts a plea
    bargain, in everything else I've done that hasn't been dropped for other
    reasons, settlements always happened for insider stuff where we didn't
    have denied firewall traffic logs or denied logs with any relevant data.

    Don't get me wrong, it's always cool to say something like "attempted 5000
    different ID/password combinations, then attacked...," but it only makes
    the case if you want to prosecute complete failures (that may be
    appropriate for some organizations)- if it's successful, then you *need*
    the successful traffic or evidence of it, unsuccessful attempts are most
    helpful in early discovery when going after unsuccessful attackers.

    It's also possible that if there have been forensics issues with a
    workstation (shared credentials, overwritten files, etc.) then having
    off-box evidence is a really good thing, even if it's stuff that was
    blocked, or to correlate activity (here's where the FTP command is in the
    command history, here's where it hits the firewall...) But again, "here's
    the command, here's where it goes through the firewall to the other
    company" is still way better for getting a settlement or plea agreement.

    > destination. I don't think there is ever too much "noise." You need to
    > filter your logs to provide you with the information you need. I do
    > agree that it is vital to monitor your employee's behavior. The only
    > traffic that I wouldn't want to log is NetBIOS traffic, etc, being
    > dropped by the internal interface on the firewall. A proper IDS
    > configuration (one on the inside and one on the outside) will help you
    > to audit your security policy. Without proper logging, how can your
    > security policy be as effective as it could be? Personally, I'm all for
    > logs that will provide the information desired upon need. I'd hate not
    > to get enough information when it is needed from a firewall.

    If you have lots of failed attempts, and limited bandwidth to deal with
    things, then you have to make a trade-off. Ignoring the script kiddie
    events hasn't bitten me yet, but I've always been able to have a
    conservative security policy that allowed a very small number of systems
    to communicate with the world at large, so attacking or tunneling over a
    small number allowed protocols was my only major attack vector left open.

    Only you can make a determination for your organization if say logging
    automated probes where there are no accessible systems is "worth it."
    Same with Windows pop-up message stuff where you have bunch of Sun
    servers. There's enough "background noise" these days that you'll pay
    pretty significantly in terms of logging infrastructure and backup
    infrastructure to log things that'll never succede if you have a good
    chunk of real estate to protect (even a single /16 these days gets lots of
    probes)- it may be a different answer than if you have fewer visible

    Paul D. Robertson "My statements in this message are personal opinions which may have no basis whatsoever in fact." Director of Risk Assessment TruSecure Corporation
    firewall-wizards mailing list

  • Next message: Kevin: "Re: [fw-wiz] DMZ Ideas"

    Relevant Pages

    • Re: [fw-wiz] Log checking?
      ... > While I've really enjoyed reading this communication regarding logging, ... > filter your logs to provide you with the information you need. ... > dropped by the internal interface on the firewall. ... were worm traffic on the standard microsoft file sharing ports. ...
    • Possible Compromise - Need Suggestions
      ... I've set up my firewall to log but accept outbound traffic to ... at this but a quick browse through the logs showed my box was also trying ... port 21 on this IP. ... Set up an iptables firewall blocking and logging all incoming traffic and ...
    • RE: [fw-wiz] Log checking?
      ... While I've really enjoyed reading this communication regarding logging, ... filter your logs to provide you with the information you need. ... dropped by the internal interface on the firewall. ... A proper IDS ...
    • RE: Data Mining for PIX Firewall Logs
      ... Data Mining for PIX Firewall Logs ... Fast forward to my current company, which went with a Cisco PIX ... Can anyone here please suggest to me some type of logging and more ...
    • Re: Strange WAN Activity
      ... > firewall logs for a possible TCP FIN scan that keeps ... > company's intranet server IP and its port 80 across our ... > My firewall is a Sonicwall Pro 200 and I'm running W2K ... It's difficult to be sure without inspecting the web server for signs of ...