redirecting firewall logs

[bustthis]

i am trying to redirect my firewall logs to /var/log/ipfw.log in 10.3.4 server.... i followed this article: http://www.macosxhints.com/article.p...&query=syslogd

it seems that this doesn't work right under 10.3.4 server, at least not completely. my firewall logs seem to go to ipfw.log, but they still are getting logged to system.log and console.log. the weird thing about it, only some messages are logged to these logs and they seem garbled...

for example:

a log to /var/log/ipfw.log would look like this:

kernel: ipfw: 1000 Accept TCP 127.0.0.1:934 127.0.0.1:1033 in via lo0

the same entry that appears in system.log and console.log would look like this:

kernel: cept TCP 127.0.0.1:934 127.0.0.1:1033 in via lo0
or
P 127.0.0.1:934 127.0.0.1:1033 in via lo0

my syslog.conf seems to be right, or is it? can someone offer any advice?

# Exclude log messages that you want to go elsewhere from appearing in
# the console.log and system.log files.
# Leave programs off list if you want entries in these files also.
!-ipfw

*.err;kern.*;auth.notice;authpriv,remoteauth,install.none;mail.crit /dev/console
*.notice;*.info;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit /var/log/system.log

# End program block
!*

# Send messages normally sent to the console also to the serial port.
# To stop messages from being sent out the serial port, comment out this line.
#*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit /dev/tty.serial

# The authpriv log file should be restricted access; these
# messages shouldn't go to terminals or publically-readable
# files.
authpriv.*;remoteauth.crit /var/log/secure.log

# Direct all ipfw log messages to ipfw.log
!ipfw
*.* /var/log/ipfw.log
!*

lpr.info /var/log/lpr.log
mail.* /var/log/mail.log
ftp.* /var/log/ftp.log
netinfo.err /var/log/netinfo.log
install.* /var/log/install.log
install.* @127.0.0.1:32376

*.emerg *

local6.notice /private/var/log/mailaccess.log

[yellow]

Ipfw entries are also kern.* entries, which is why they are getting still getting logged to syslog and console. And you should NOT (not not not not) stop kernel messages from going to those to logs.

The reason that you get partial entries in your ipfw logs is that the entries come so fast and furious, that they sometimes only get partially written. This can render the logging fairly useless. I gave up on trying to log ipfw to another destination back in the days of 10.1 for just the same problem. I'd rather have (quasi) complete logs (it still happens in system.log once in a while) then partial ones.

So I've been using this for a few years as a crontab entry:

grep ipfw /var/log/system.log | sort > ~yellow/logs/ipfw.log

That coupled with a log rotation script written into /etc/daily.local, and I can paruse a few months worth of logs if need be.

[bustthis]

sweet... that's something i didn't think of!!!! exactly what i was looking for! i spent hours trying to get syslog.conf to do this... i suppose you dump the logs to ipfw.log right before they are to rotate via cron? it would make a nice perl script to turn off logging, append to ipfw.log, archive, then turn on logging again, sort of a mailstore backup script i've been using.

do you find when firewall logging is enabled and going to both system.log and console.log over a couple of days, a decrease in performance? i am trying to stay on top of my firewall, since my server was broken into a couple of months ago, and i am quite obsessive about monitoring my logs.

thanks much,

[yellow]

I just run that command in the crontab at midnight or so (right before "periodic daily" runs in the crontab). That way the entire day's worth of ipfw traffic someplace I can get to, and it'a automatically rotated by some scripting I put in /etc/daily.local. During the day, I make sure to look at my logs frequently. It's pretty easy to grep ipfw traffic from your system.log. I also couple it with an IDS to make a more complete safety net.

No, I don't see exsessive speed loss with growing logs. Remember that system.log and console.log are rotated daily (or should be!) so they shouldn't impact your performance for more then 24 hours. You should consider elongating your script rotation, so you are keeping more logs for longer.

I also don't long things that I know are pointless and just fill my logs to the bursting point. Like UDP. I probably SHOULD log all UDP, but in my environment, there's a bajillion WinTelThons yammering away and Windows is just plain CHATTY on UDP.

[bustthis]

this is what i just set up under /etc/periodic/daily/, it runs right before system.log rotates and seems to work good after a couple of tests.

#!/bin/sh
#
# Dump ipfw messages from system.log to /var/log/ipfw/ipfw.log

PATH=/bin:/sbin:/usr/sbin:/usr/bin:/usr/libexec
export PATH

echo ""
echo "Dumping ipfw logs"
grep ipfw /var/log/system.log | sort > /var/log/ipfw/ipfw.log


echo ""
echo -n "Rotating ipfw files:"
cd /var/log/ipfw
for i in ipfw.log; do
if [ -f "${i}" ]; then
echo -n " ${i}"
if [ -x /usr/bin/gzip ]; then gzext=".gz"; else gzext=""; fi
if [ -f "${i}.6${gzext}" ]; then mv -f "${i}.6${gzext}" "${i}.7${gzext}"; fi
if [ -f "${i}.5${gzext}" ]; then mv -f "${i}.5${gzext}" "${i}.6${gzext}"; fi
if [ -f "${i}.4${gzext}" ]; then mv -f "${i}.4${gzext}" "${i}.5${gzext}"; fi
if [ -f "${i}.3${gzext}" ]; then mv -f "${i}.3${gzext}" "${i}.4${gzext}"; fi
if [ -f "${i}.2${gzext}" ]; then mv -f "${i}.2${gzext}" "${i}.3${gzext}"; fi
if [ -f "${i}.1${gzext}" ]; then mv -f "${i}.1${gzext}" "${i}.2${gzext}"; fi
if [ -f "${i}.0${gzext}" ]; then mv -f "${i}.0${gzext}" "${i}.1${gzext}"; fi
if [ -f "${i}" ]; then mv -f "${i}" "${i}.0" && if [ -x /usr/bin/gzip ]; then gzip -9 "${i}.0"; fi; fi
touch "${i}" && chmod 640 "${i}" && chown root:admin "${i}"
fi
done

i decided to make a seperate ipfw folder for neatness. i am not positive my console.log rotates though, is this something i need to do myself or is it done with one of the other cron jobs? just curious.... i must say, i haven't had too much uptime lately and i haven't noticed them being rotated.

thanks for your time,

[yellow]

Yep, that's what I've done as well. You might want to try and keep your logs for longer then a week though.
And sorry, I misspoke, console.log get rotated on what appears to be a reboot. But I don't think it should be impacting your performance at all.