# Hatchet LOGGING
# v 0.9.2
# Jason Dixon <jason@dixongroup.net>
# http://www.dixongroup.net/hatchet/
#

Hatchet parses PF logs and saves the events in a simple
SQLite database.  The average PF user should already be
familiar with the logging features in PF, but it bears
mention here as well.

Logging is enabled on a per-rule basis using the "log"
keyword.  The use of this option should be considered
carefully, as it is very easy to overwhelm your firewall
with useless event logging.  I have seen users with a 
"pass log all" default match, then complain on the Hatchet
mailing list about slow response time in their web interface.
This is an easy way to subscribe yourself to my /dev/null.

Utilize the log feature to your benefit, not your detriment.
Keep in mind that the purpose of good logs are to keep an
audit trail of unwanted traffic, and more specifically,
notify you of possible attacks (although an IDS is the
correct tool for that task).  The "noise ratio" should not
become so problematic that useful events are overlooked or
ignored.

Bad example:
    block in log

Good example:
    block in
    block in on $ext_if
    block in log on $ext_if inet proto tcp port 445

Although the filter results are the same, the 2nd example
takes advantage of the "last match" philosophy.  It will
only log TCP packets destined for port 445 on the external
interface.  The previous example will log every silly
packet that isn't explicitly passed, including those on
the local LAN.

Good luck and happy logging!

