Re: [logs] firewall logging and rulesets

From: Tina Bird (tbird@precision-guesswork.com)
Date: Tue Oct 21 2003 - 18:23:27 PDT

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

    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=172.170.221.49 DST=10.10.10.10 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=69.132.76.152 DST=10.10.10.10 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
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



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