OpenBSD Journal

New PF reporting tool: Hatchet

Contributed by jose on from the tools dept.

fuzzyping writes: "Introducing the initial release of Hatchet, a PF reporting tool. Features include parsing and viewing of PF logfiles (up to 7 days' worth) and pfstat graphs for viewing network utilization. Written in Perl, it offers an attractive and simple interface for viewing firewall activity.

More information can be found at the Hatchet website ."

(Comments are closed)

Comments

  1. By Jim () on

    I haven't downloaded or run your software, but from looking at the install document, you could change step 6 to HTML::Template in the ports tree...

    Just a thought.

    Comments

    1. By fuzzyping () jason_NO_SPAM@dixongroup_NO_SPAM.net on http://www.dixongroup.net/hatchet/

      Wasn't aware it was in ports. Either way will work fine. If it ever appears that the non-ported version of HTML::Template has problems, I'll defer to the ports version. For now, I see no real reason to change.

      Comments

      1. By Jim () on

        Not to beat a dead horse, but I will anyway... :-)

        When you make your app a port, you can specify the HTML::Template port as a build dependency.

        I always try to stand on the shoulders of giants where possible.

        Cheers.

        Comments

        1. By fuzzyping () jason_NO_SPAM@dixongroup_NO_SPAM.net on http://www.dixongroup.net/hatchet/

          Hey, I'd love to make it into a port, but I've never done one. I've glanced at the documentation on the OpenBSD and FreeBSD sites, but I really don't have the desire/patience/motivation to go through all that right now.

          Hopefully some day. :)

  3. By Matt Van Mater () on

    First off, I think it looks like a great little app. I haven't installed or run it yet, so excuse me if this functionality is already there. Some features i'd like to see:

    Sorting based upon your column headers
    Collapseexpand groups of similar data (ie sort by src ip, expand to show all traffic generated by that ip). Easier said than done I know :)

    Comments

    1. By fuzzyping () jason_NO_SPAM@dixongroup_NO_SPAM.net on http://www.dixongroup.net/hatchet/

      I agree, this has been on my mind lately as a future enhancement. Unfortunately, this suggests a CGI. Imagine trying to load/parse a fairly large pflog, on the fly, and generating the HTML output. Not pretty.

      The alternative would be to dump everything in a database, but that's not really ideal for logs either. Any other ideas?

      Comments

      1. By marco () on

        any reason they need to be parsed on the fly?

        why not build the html and images ahead of time
        (ala cron), store them, and then (if one must)
        rely on dynamic pages to reference static material?

        Comments

        1. By fuzzyping () jason_NO_SPAM@dixongroup_NO_SPAM.net on http://www.dixongroup.net/hatchet/

          I don't really see how that could be done. There aren't any images to speak of. The HTML is the log data. The idea is to click on a header, which requests the data sorted in a different way. How would you propose pre-sorting the data of 7 different columns? If each page were a static view, that would require a hell of a lot of different page layouts.

          The alternative would be to use embedded frames for each column (ugh!), sourcing the pre-sourted pages. That's even uglier.

          Perhaps you could point me in the direction of a good example tutorial, or clarify where I'm not thinking clearly.

          Comments

          1. By Jon () on

            It'd be a nice feature... but .. this really sounds like a job for a database. I kinda like how your app is going so far, nice and simple. Involving a DB and CGI would just make things bloated I think.

            Unless you want to go that route :) I'll be interested to see what you come up with.

            Comments

            1. By Anonymous Coward () on

              What about sending the data to a remote database. Then possibly integrate it into ACID, or another such front end to help with correlation...

          2. By marco () on

            my bad. i lapsed.

            i too think a db would be bloat, but perhaps sqllite? the data would still have to get sorted tho, so even something like LIMIT 0,25 still kind of defeats the purpose. hmm.

            i plan on playing with it tomorrow though. maybe i won't lapse this time.

            looks excellent btw!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]