My shorewall dropped packets arent logged anymore.
When I read my log, it began after a syslog reload, so I may have
changed syslog configuration, but dont remember nor see anything weird
in syslog.conf.
/var/log/messages
Oct 5 19:13:03 kim kernel: Shorewall:net2fw:DROP:IN=eth0 OUT=
MAC=00:1c:c0:65:22:3d:00:0f:90:98:e1:02:08:00 SRC=77.75.35.146
DST=91.121.169.122 LEN=40 TOS=0
x00 PREC=0x00 TTL=244 ID=13716 PROTO=TCP SPT=3025 DPT=1039 WINDOW=4096
RES=0x00 SYN URGP=0
Oct 5 19:21:18 kim exiting on signal 15
Oct 5 19:21:19 kim syslogd 1.4.1#18: restart.
Oct 5 19:41:19 kim -- MARK --
If I understand the output of shorewall show, packets dropped ARE logged
but they dont show in /var/log/messages. I added a specific kern.info
log file which remains desperatetly empty.
I attach the related sections of conofig files and a shorewall dump output
syslog.conf
[...]
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
kern.info /var/log/kern.info
[...]
Logging to kern.info works
root@kim:/var/log# logger -p kern.info "test syslog"
root@kim:/var/log# tail -n 1 /var/log/messages
Nov 8 11:39:15 kim root: test syslog
shorewall.conf
[...]
LOGFORMAT="Shorewall:%s:%s:"
LOGTAGONLY=No
LOGRATELOGBURSTLOGALLNEW=info
BLACKLIST_LOGLEVELMACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=info
RFC1918_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
LOG_MARTIANS=No
[...]
[...]
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"
[...]
/etc/shorewall/policy
$FW net ACCEPT
net $FW DROP info
net all DROP info
all all REJECT info
root@kim:/var/log# /sbin/shorewall version
4.0.14
root@kim:/var/log# ip addr show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:1c:c0:65:22:3d brd ff:ff:ff:ff:ff:ff
inet 91.121.169.122/24 brd 91.121.169.255 scope global eth0
inet 91.121.42.145/32 brd 91.255.255.255 scope global eth0:0
inet 91.121.46.150/32 brd 91.255.255.255 scope global eth0:1
inet 91.121.43.206/32 brd 91.255.255.255 scope global eth0:2
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 06:e6:3f:82:5c:3a brd ff:ff:ff:ff:ff:ff
4: tunl0: <NOARP> mtu 1480 qdisc noop
link/ipip 0.0.0.0 brd 0.0.0.0
5: gre0: <NOARP> mtu 1476 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
root@kim:/var/log# ip route show
91.121.169.0/24 dev eth0 proto kernel scope link src 91.121.169.122
default via 91.121.169.254 dev eth0
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer''s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Guy Marcenac wrote:> My shorewall dropped packets arent logged anymore. > When I read my log, it began after a syslog reload, so I may have > changed syslog configuration, but dont remember nor see anything weird > in syslog.conf. > > /var/log/messages > Oct 5 19:13:03 kim kernel: Shorewall:net2fw:DROP:IN=eth0 OUT> MAC=00:1c:c0:65:22:3d:00:0f:90:98:e1:02:08:00 SRC=77.75.35.146 > DST=91.121.169.122 LEN=40 TOS=0 > x00 PREC=0x00 TTL=244 ID=13716 PROTO=TCP SPT=3025 DPT=1039 WINDOW=4096 > RES=0x00 SYN URGP=0 > Oct 5 19:21:18 kim exiting on signal 15 > Oct 5 19:21:19 kim syslogd 1.4.1#18: restart. > Oct 5 19:41:19 kim -- MARK -- > > If I understand the output of shorewall show, packets dropped ARE logged > but they dont show in /var/log/messages. I added a specific kern.info > log file which remains desperatetly empty. > > I attach the related sections of conofig files and a shorewall dump outputIs klogd running? Do ''Shorewall'' messages show up if you type ''dmesg''? This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any control over where the log messages go (or if they go) when the LOG target is used. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> Guy Marcenac wrote: >> My shorewall dropped packets arent logged anymore. >> When I read my log, it began after a syslog reload, so I may have >> changed syslog configuration, but dont remember nor see anything weird >> in syslog.conf. >> >> /var/log/messages >> Oct 5 19:13:03 kim kernel: Shorewall:net2fw:DROP:IN=eth0 OUT>> MAC=00:1c:c0:65:22:3d:00:0f:90:98:e1:02:08:00 SRC=77.75.35.146 >> DST=91.121.169.122 LEN=40 TOS=0 >> x00 PREC=0x00 TTL=244 ID=13716 PROTO=TCP SPT=3025 DPT=1039 WINDOW=4096 >> RES=0x00 SYN URGP=0 >> Oct 5 19:21:18 kim exiting on signal 15 >> Oct 5 19:21:19 kim syslogd 1.4.1#18: restart. >> Oct 5 19:41:19 kim -- MARK -- >> >> If I understand the output of shorewall show, packets dropped ARE logged >> but they dont show in /var/log/messages. I added a specific kern.info >> log file which remains desperatetly empty. >> >> I attach the related sections of conofig files and a shorewall dump output > > Is klogd running? Do ''Shorewall'' messages show up if you type ''dmesg''? >Yes to both> This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any > control over where the log messages go (or if they go) when the LOG > target is used.I agree, I likely did some silly thing to my syslog configuration, but cant figure out which Sorry for the noise Tom -- Guy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> Guy Marcenac wrote: >> My shorewall dropped packets arent logged anymore. >> When I read my log, it began after a syslog reload, so I may have >> changed syslog configuration, but dont remember nor see anything weird >> in syslog.conf. >> >> /var/log/messages >> Oct 5 19:13:03 kim kernel: Shorewall:net2fw:DROP:IN=eth0 OUT>> MAC=00:1c:c0:65:22:3d:00:0f:90:98:e1:02:08:00 SRC=77.75.35.146 >> DST=91.121.169.122 LEN=40 TOS=0 >> x00 PREC=0x00 TTL=244 ID=13716 PROTO=TCP SPT=3025 DPT=1039 WINDOW=4096 >> RES=0x00 SYN URGP=0 >> Oct 5 19:21:18 kim exiting on signal 15 >> Oct 5 19:21:19 kim syslogd 1.4.1#18: restart. >> Oct 5 19:41:19 kim -- MARK -- >> >> If I understand the output of shorewall show, packets dropped ARE logged >> but they dont show in /var/log/messages. I added a specific kern.info >> log file which remains desperatetly empty. >> >> I attach the related sections of conofig files and a shorewall dump output > > Is klogd running? Do ''Shorewall'' messages show up if you type ''dmesg''? > > This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any > control over where the log messages go (or if they go) when the LOG > target is used.And if I had to guess, I would say that there is something wrong with klogd. klogd is the daemon that monitors the kernel''s ring buffer and forwards the messages to syslogd. Your test with ''logger'' uses the ''syslog()'' API which doesn''t go through the ring buffer. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Guy Marcenac wrote:> Tom Eastep wrote: >> Guy Marcenac wrote: >>> My shorewall dropped packets arent logged anymore. >>> When I read my log, it began after a syslog reload, so I may have >>> changed syslog configuration, but dont remember nor see anything weird >>> in syslog.conf. >>> >>> /var/log/messages >>> Oct 5 19:13:03 kim kernel: Shorewall:net2fw:DROP:IN=eth0 OUT>>> MAC=00:1c:c0:65:22:3d:00:0f:90:98:e1:02:08:00 SRC=77.75.35.146 >>> DST=91.121.169.122 LEN=40 TOS=0 >>> x00 PREC=0x00 TTL=244 ID=13716 PROTO=TCP SPT=3025 DPT=1039 WINDOW=4096 >>> RES=0x00 SYN URGP=0 >>> Oct 5 19:21:18 kim exiting on signal 15 >>> Oct 5 19:21:19 kim syslogd 1.4.1#18: restart. >>> Oct 5 19:41:19 kim -- MARK -- >>> >>> If I understand the output of shorewall show, packets dropped ARE logged >>> but they dont show in /var/log/messages. I added a specific kern.info >>> log file which remains desperatetly empty. >>> >>> I attach the related sections of conofig files and a shorewall dump output >> Is klogd running? Do ''Shorewall'' messages show up if you type ''dmesg''? >> > Yes to bothSo the problem is not in Shorewall/Netfilter -- but then we already knew that because the packet count on your LOG rules were incrementing.> I agree, I likely did some silly thing to my syslog configuration, but > cant figure out whichCheck the output of ''cat /proc/sys/kernel/printk'' and refer to Shorewall FAQ 16. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> > Check the output of ''cat /proc/sys/kernel/printk'' and refer to Shorewall > FAQ 16.Sorry -- please disregard that advice; it has to do with console logging, not forwarding to syslogd. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> Tom Eastep wrote: >> >> This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any >> control over where the log messages go (or if they go) when the LOG >> target is used. > > And if I had to guess, I would say that there is something wrong with > klogd. klogd is the daemon that monitors the kernel''s ring buffer and > forwards the messages to syslogd. Your test with ''logger'' uses the > ''syslog()'' API which doesn''t go through the ring buffer. >What I do not understand is that info messages from postfix, for instance, are normally logged -- Guy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Guy Marcenac wrote:> Tom Eastep wrote: >> Tom Eastep wrote: >>> This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any >>> control over where the log messages go (or if they go) when the LOG >>> target is used. >> And if I had to guess, I would say that there is something wrong with >> klogd. klogd is the daemon that monitors the kernel''s ring buffer and >> forwards the messages to syslogd. Your test with ''logger'' uses the >> ''syslog()'' API which doesn''t go through the ring buffer. >> > What I do not understand is that info messages from postfix, for > instance, are normally logged >Have you restarted klogd? It is KERNEL logging that isn''t working so you need to focus on that path. Testing with logger or noting that postfix logging works simply validates that the problem is NOT WITH SYSLOGD. -Tom -- Tom Eastep \ The ultimate result of shielding men from the Shoreline, \ effects of folly is to fill the world with fools. Washington, USA \ -Herbert Spencer http://shorewall.net \________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
Tom Eastep wrote:> Guy Marcenac wrote: >> Tom Eastep wrote: >>> Tom Eastep wrote: >>>> This ISN''T a Shorewall problem. Neither Shorewall nor Netfilter have any >>>> control over where the log messages go (or if they go) when the LOG >>>> target is used. >>> And if I had to guess, I would say that there is something wrong with >>> klogd. klogd is the daemon that monitors the kernel''s ring buffer and >>> forwards the messages to syslogd. Your test with ''logger'' uses the >>> ''syslog()'' API which doesn''t go through the ring buffer. >>> >> What I do not understand is that info messages from postfix, for >> instance, are normally logged >> > > Have you restarted klogd? It is KERNEL logging that isn''t working so you > need to focus on that path. Testing with logger or noting that postfix > logging works simply validates that the problem is NOT WITH SYSLOGD. >I was completly focussed on syslogd and restarting klogd did the trick. Thank you Tom -- Guy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer''s challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/