Description of problem: I posted a patch (Bug 174954) for /usr/share/logwatch/scripts/services/iptables with a small bug in December last year. The bug occurs when an icmp packet is an error response that includes an offending tcp or udp packet. In that case netfilter logs both the icmp type and the destination port. The current iptables script preferentially extracts the dest port, but should preferentially extract the icmp type. Version-Release number of selected component (if applicable): logwatch-7.2.1-1.fc5 I checked upstream, and the bug still exists in logwatch-7.3, so fc6test is probably affected, too. (Sorry, I haven't been testing fc6.) How reproducible: Always Steps to Reproduce: 1. log icmp packets with included tcp or udp packets (example below) 2. run logwatch Actual results: (example) From 68.142.193.5 - 1 packet to icmp(33499) Expected results: (example) From 68.142.193.5 - 1 packet to icmp(11) Additional info: The above examples are derived from an example syslog entry as follows. kernel: iptables ACCEPT: IN=ppp0 OUT=eth0 SRC=68.142.193.5 DST=192.168.1.9 LEN=56 TOS=0x00 PREC=0xC0 TTL=240 ID=44656 PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.1.9 DST=209.191.93.52 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=37595 PROTO=UDP SPT=32768 DPT=33499 LEN=18 ] The included patch corrects the bug. Port numbers for actual tcp and udp packets have no type, so their reporting is not affected. I submitted the same patch to logwatch-patches, so it may come downstream eventually.
Created attachment 133009 [details] patch for /usr/share/logwatch/scripts/services/iptables