RE: [fw-wiz] Log checking?

From: Mark Teicher (mht3_at_earthlink.net)
Date: 10/02/04

  • Next message: Dale W. Carder: "Re: [fw-wiz] DMZ Ideas"
    To: firewall-wizards@honor.icsalabs.com
    Date: Sat, 2 Oct 2004 10:50:39 -0600 (GMT-06:00)
    
    

    I would like to add to the this thread.

    At 09:11 AM 10/1/2004, Marcus J. Ranum wrote:
    Paul D. Robertson wrote:
    >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...)

    Ranum's first law of Log Analysis:
            - Never keep more than you can conceive of possibly looking at
    <What devices are we referring to, are we just speaking of log generating devices (i.e. firewalls, intrustion detection, intrusion prevention, etc) or are you referring to any networked devices that could reside on a network from a VoIP Media Server, Wireless Access Points, PBX equipment that is IP enabled. ??

    Ranum's second law of Log Analysis:
            - The number of times an uninteresting thing happens is an interesting
                    thing
    <not all devices count uninteresting things correctly, or interesting things correctly, what is your formula to determine uninteresting things from interesting things, and what determines an uninteresting thing ??
    Determing the interesting items in the following log output:

    0746 0001 7 9 811 5063041 70116 5 0 450 0
    0746 0023 7 9 812 17195987656 70696 5 0 150 4
    0747 0009 7 9 811 5328937 70400 5 0 320 4
    0747 0005 7 9 812 12026854119 70349 5 0 210 4
    0747 0010 7 9 811 18002304898 70485 5 0 360 4
    0747 0007 7 9 811 5530473 47642 5 0 190 4
    0747 0062 7 9 812 17036970821 47088 5 0 690 4
    0747 0046 7 9 812 17034184437 47896 5 0 170 4
    0747 0056 7 9 812 2461768 70592 5 0 680 4
    0747 0010 7 9 812 17036812341 70625 5 0 100 4
    0747 0232 7 9 812 17578360959 70475 5 0 230 4
    0747 0023 7 9 811 2315291 70177 5 0 560 4
    0747 0007 7 9 811 5428927 47870 5 0 420 0
    0747 0015 7 9 811 2604840 70415 5 0 130 0
    0747 0002 7 9 812 8060271 47969 5 0 060 0
    0748 0008 7 9 811 18009748885 47361 5 0 450 0
    0748 0003 7 9 812 18585416800 47717 5 0 680 0
    0748 0004 7 9 811 5328937 70400 5 0 480 4
    0748 0020 7 9 812 17036966815 47085 5 0 610 4
    0748 0006 7 9 812 17036928096 47991 5 0 620 0
    0748 0037 7 9 811 2241757 47980 5 0 500 4
    0748 0029 7 9 811 5422207 47651 5 0 540 0
    0748 0003 7 9 812 18586542217 47396 5 0 170 4
    0748 0001 7 9 811 5458440 47046 5 0 130 4
    0748 0022 7 9 812 7255321 47963 5 0 580 0
    0748 0001 7 9 812 18588265076 70308 5 0 640 4
    0748 0031 7 9 811 01181468252211# 47569 5 0 010 4
    0748 0025 7 9 811 18007721213 70410 5 0 270 0
    0748 0004 7 9 811 18889973741 70524 5 0 320 0
    0748 0011 7 9 811 2224013 70363 5 0 460 4
    0748 0013 7 9 812 18582920872 47380 5 0 210 0
    0748 0000 7 9 812 5720140 47389 5 0 060 4
    0748 0006 7 9 812 17654642829 70470 5 0 230 0
    0748 0012 7 9 812 7587840 47239 5 0 570 0
    0748 0008 7 9 811 2678661 47347 5 0 290 4
    0749 0013 7 9 812 17575586864 70556 5 0 120 4
    0749 0002 7 9 812 17604928009 70308 5 0 610 4
    0749 0022 A 80 2682221 70207 5 0 030 0
    0749 0006 7 9 811 411# 47718 5 0 420 0
    0749 0005 7 9 811 18007721213 70410 5 0 460 0
    0749 0044 7 9 812 7256619 47182 5 0 140 4
    0749 0027 7 9 812 18585463737 70244 5 0 110 0
    0749 0035 7 9 811 18006883462 70311 5 0 240 0
    0749 0011 7 9 812 18582446800 47717 5 0 680 0
    0749 0030 7 9 811 4656639 70346 5 0 410 4
    0749 0006 7 9 811 8575588 47337 5 0 500 0

    and here is the parse routine to sift out interesting things from uninteresting things:

    <RECORD_SEPARATOR>
    # Single Line format, records are separated by <CR>
    \r\n
    </RECORD_SEPARATOR>

    <CALL_RECORD>
    # Grab the end time
    (\d{4})
    #
    # space
    \s
    #
    # duration (discard 1/10s of minutes)
    (\d{3})\d
    #
    # spaces
    \s
    #
    # Channel parse
    (\d)
    #
    # space(+)
    \s+
    #
    # unknown field
    \d
    #
    # space
    \s
    #
    # Parse the extension
    (\d{3})
    #
    # spaces
    \s+
    # dialed digits
    (\d+)
    #
    </CALL_RECORD>

    <TIME_FIELD_FORMAT = HHmm>
    <DURATION_FIELD_FORMAT = Hmms>
    <STATION_FIELD = 4>
    <DIALED_DIGITS_FIELD = 5>
    <END_TIME_FIELD = 1>
    <DURATION_FIELD = 2>
    <CHANNEL_FIELD = 3>

    DESCRIPTION "The content type for the call."
                    SYNTAX INTEGER {
                            fax(0),
                            modem(1),
                            voice(2),
                            undetermined(3),
                            stuData(4),
                            stuVoice(5),
                            stu(6),
                            busy(7),
                            unanswered(8),
                            data(9),
                            wideBandVideo(10),
                            offHook(11),
                            modemEnergy(12)
                    }

    Ranum's third law of Log Analysis:
            - Keep everything you possibly can except for where you come
                    into conflict with the First Law

    [#insert plug for my log analysis tutorial at USENIX and SANS
    see http://www.loganalysis.org/news/tutorials for details]

    >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.

    <Again, not all network devices, all for log retention or is a bit more archaic than one thinks, some legacy devices (i.e. PBX's) still dump to a CRT or a printer, unless one devices a way to split the output via SMDR Y-Cable and configure the capture device to save data to some sort of media format.

    The number of times an uninteresting thing happens is an interesting
    thing. The number 5,000 in your example above is an interesting
    number and you wouldn't have it available to you if you hadn't
    counted it. It might, for example, be interesting if it went to 10,000.
    It might be even MORE interesting if it went to 0. ;)

    <In the example, it refers to a somewhat interesting attack, but what about sifting through 100,000 lines of VoIP calls looking for the interesting thing?

    >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.

    <Each legal jurisdiction may be different, and the way evidence has to be presented can also be time consuming and laborious, check with a internet saavy legal type person before going through the above exercise.

    1) Judges are getting a log better about not allowing massive
            fishing expeditions
    2) Who cares if someone wants to discover what you rightly
            describe as "script kiddie" activity? Give 'em a terabyte
            and let them have fun with it!

    The problem is that you're not analyzing the problem methodically.
    If you care about that kind of stuff, just keep internal logs differently
    from external, etc. You might just keep counts of one type of
    data, versus actual data in another case - and you need to make
    these decisions rationally based on your site's security
    needs, bandwidth usage, event load, and legal concerns - not
    just because someone on Firewall-Wizards said to or not to. ;)

    >Only you can make a determination for your organization if say logging
    >automated probes where there are no accessible systems is "worth it."

    <logging probes are not that interesting but finding an small financial accounting error can take one a very long journey, as described in detail by Clifford Stoll.

    Right!

    mjr.

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

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


  • Next message: Dale W. Carder: "Re: [fw-wiz] DMZ Ideas"