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 billford@private 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=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 > _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Oct 22 2003 - 01:37:41 PDT