Re: [logs] firewall logging and rulesets

From: Bill Mathews (billford@private)
Date: Tue Oct 21 2003 - 19:02:27 PDT

  • Next message: Chris Brenton: "Re: [logs] firewall logging and rulesets"

    Check Point logs the rule number (there are no rule names in CP) but since
    the rule number changes every time you insert or delete a rule, so 6
    months to a year it won't be very helpful.  The way I do it is to use
    Check Point's API to document my rulebase in a text file and time/date
    stamp it (also keep it in CVS). That way, when / if I need to review the
    logs, I have documentation from what the rulebase looked like that day. CP
    now has revision control built in so it's a little easier but I still like
    the CVS for the text file. IPTables logs everything to syslog unless
    otherwise instructed.
    Bill Mathews
    Open Source Software Advocate
    The wise and noble Tina Bird spiteth forth upon the land, these thoughts:
    > On Tue, 21 Oct 2003, Chris Brenton wrote:
    >> Its *very* product specific, but with iptables you can do something like
    >> this:
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j LOG
    >> --log-prefix " SYNFINSCAN "
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j REJECT
    >> --reject-with icmp-host-unreachable
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
    >> 1433:1434 -j LOG --log-prefix " MS_SQL "
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
    >> 1433:1434 -j REJECT --reject-with icmp-host-unreachable
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
    >> 17300 -j LOG --log-prefix " KUANG2_SCAN "
    >> iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport
    >> 17300 -j REJECT --reject-with icmp-host-unreachable
    >> and the logs come out looking like this:
    >> Oct 19 07:58:36 gw1 kernel:  KUANG2_SCAN IN=eth0 OUT=eth1
    >> SRC= DST= LEN=48 TOS=0x00 PREC=0x00 TTL=115
    >> ID=37626 DF PROTO=TCP SPT=1899 DPT=17300 WINDOW=8192 RES=0x00 SYN URGP=0
    >> Oct 19 10:52:03 gw1 kernel:  KUANG2_SCAN IN=eth0 OUT=eth1
    >> SRC= DST= LEN=48 TOS=0x00 PREC=0x00 TTL=112
    >> ID=32450 DF PROTO=TCP SPT=4579 DPT=17300 WINDOW=16384 RES=0x00 SYN
    >> URGP=0
    >> Makes it pretty clear as to what was dropped and why.
    > but this still sort of depends on your having given the rule a sensible
    > name, right?  that is, it's clear that i've dropped something because it's
    > a kuang2_scan, but if my firewall admin (for instance, me) named a rule
    > something like FTP_internal_external (which i tend to do --
    > prot_source_dest), i have to sort of determine that it was an allow rule
    > based on the fact that it got allowed.
    > anyhow, part of the point here is that if you name your rules in a
    > sensible way, you can get the information you need out of the name and not
    > have to worry about making sense of it later.  a fine bit of advice and
    > one which will get added to my notes directly.
    > here's another question -- does iptables log configuration changes --
    > in particular, ruleset changes -- to syslog?  if not, does it log them
    > anywhere at all?  if yes, could you please send me some sample data?
    > one of the current projects is to collect specific instances of generic
    > events (like dropped/allowed connections, config changes, etc) for
    > categories of devices (firewalls, web servers, etc) and get that all on
    > the loganalysis web site...
    >> > in the long run, does it matter much?  that is, if i decide i need to
    >> make
    >> > sense of a set of connections in six months or a year, do i really
    >> need to
    >> > know what rule caused the action?
    >> I personally have not run into this (usually pretty clear from the
    >> traffic pattern as to why it was permitted or dropped) but what I do use
    >> it for is daily log review. With all the above traffic patterns neatly
    >> labeled, it becomes far easier to parse the logs with automated scripts
    >> as well as setup keyword centralized alerting.
    > got scripts you'd like to share?  ;-)
    > helps immensely -- tbird
    > _______________________________________________
    > LogAnalysis mailing list
    > LogAnalysis@private
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Oct 22 2003 - 01:37:41 PDT