Cannot get new logs for IPFW in /var/log/security

N

networklabs

Hello,

I enabled logging on the 4th of May for IPFW. And now when I try to see the logs, I get
Code: 
[root@ns1 /var/log]# cat security
May  4 13:00:00 ns1 newsyslog[3228]: logfile turned over due to size>100K

When I enabled logs, I was getting the live logs. My syslog.conf is

Code: 
[root@ns1 /etc]# cat syslog.conf
# $FreeBSD: src/etc/syslog.conf,v 1.28.24.1 2010/12/21 17:10:29 kensmith Exp $
#
#       Spaces ARE valid field separators in this file. However,
#       other *nix-like systems still insist on using tabs as field
#       separators. If you are sharing this file between systems, you
#       may want to use only tabs as field separators here.
#       Consult the syslog.conf(5) manpage.
*.err;kern.warning;auth.notice;mail.crit                /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
security.*                                      /var/log/security
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
ftp.info                                        /var/log/xferlog
cron.*                                          /var/log/cron
*.=debug                                        /var/log/debug.log
*.emerg                                         *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info                                   /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.*                                            /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*                                            @loghost
# uncomment these if you're running inn
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
!startslip
*.*                                             /var/log/slip.log
!ppp
*.*                                             /var/log/ppp.log

My newsyslog.conf is:

Code: 
[root@ns1 /etc]# cat newsyslog.conf
# configuration file for newsyslog
# $FreeBSD: src/etc/newsyslog.conf,v 1.50.24.1 2010/12/21 17:10:29 kensmith Exp $
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCGJNUWZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner]    mode count size when  flags [/pid_file] [sig_num]
/var/log/all.log                        600  7     *    @T00  J
/var/log/amd.log                        644  7     100  *     J
/var/log/auth.log                       600  7     100  *     JC
/var/log/console.log                    600  5     100  *     J
/var/log/cron                           600  3     100  *     JC
/var/log/daily.log                      640  7     *    @T00  JN
/var/log/debug.log                      600  7     100  *     JC
/var/log/kerberos.log                   600  7     100  *     J
/var/log/lpd-errs                       644  7     100  *     JC
/var/log/maillog                        640  7     *    @T00  JC
/var/log/messages                       644  5     100  *     JC
/var/log/monthly.log                    640  12    *    $M1D0 JN
/var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid
/var/log/ppp.log        root:network    640  3     100  *     JC
/var/log/security                       640  10    100  *     JC
/var/log/sendmail.st                    640  10    *    168   B
/var/log/slip.log       root:network    640  3     100  *     JC
/var/log/weekly.log                     640  5     1    $W6D0 JN
/var/log/wtmp                           644  3     *    @01T05 B
/var/log/xferlog                        600  7     100  *     JC

As I'm new to freeBSD FreeBSD, can you please help me out?
 
I'm still relatively new to FreeBSD (and most certainly to newsyslog) myself, but let's see how far we can go here.

You're using another version of FreeBSD than me it seems; which is it? That can most certainly help people to more easily recognize a possible cause (sometimes problems are tied into a certain release).

The most obvious thing I'd start with is to check if the logfile rotation really occurred (do you really have a /var/log/security.0.bz entry?) and if the syslog program is actually still running. Try something like # ps ax | grep syslog and check the results.

Another possibility is a problem with the permissions of the newly created file. I noticed that in your newsyslog.conf the permission mask is set to 640 (read/write for user, read for group, none for other), but what exactly is the current owner of /var/log/security? More importantly: does this differ from the rotated logfile?

That's where I'd start looking.
 
Hi

I am using FreeBSD 7.4-RELEASE #6. It did create /var/log/security.0.bz (all ten files were created on 4th May itself). Syslog is running . I have checked ps -aux. About permissions, initially it had 600 and so did the logfiles.

I changed it to 640 but with no results.:(
 
networklabs said:
I am using FreeBSD 7.4-RELEASE #6
Click to expand...
Then I strongly suggest to start with an upgrade of this release because it is no longer supported since a few months, it's End Of Life ("EOL") date was last February.

To my knowledge that support only consisted of security updates, no bugfixes or such, so it is possible that you ran into a bug of some sort. If that's the case then your only option is to upgrade. In my opinion this is something you really need to consider nonetheless.

networklabs said:
About permissions, initially it had 600 and so were the logfiles.

I changed it to 640 but with no results.:(
Click to expand...
You didn't answer my question here; are the owner and group id still the same when comparing the current /var/log/security entry with the rotated file?

My assumption at this time is that you ran into a permission problem or a bug.
 
Hi,

I deleted the roatated files by mistake :-( The current owner and group are
Code: 
-rw-r-----  1 root  wheel         74 May  8 05:40 security
And it could not be a bug. Other log files are getting rotated. Moreover, it rotated on day 1, where I had all the ten files. But then it stopped working.

So. I guess it will not able to delete old logs. I do not know if I am clear.
 
Update the security entry in /etc/newsyslog.conf to something like:
Code: 
/var/log/security	root:wheel	640	13	*	$M1D0	JC

That will rotate /var/log/security once per month, keep 13 copies (so 1 year + 1 month), and compress the old copies using bzip2.

The default is to rotate the log once it reaches 100 KB in size, which (IMO) is stupid.

In fact, I change my newsyslog.conf to rotate every log monthly, keep 13 copies, and compress with bzip2. And I edit /etc/crontab to tell newsyslog(8) to keep the old logs in a separate folder (/var/log/archived) to keep /var/log/ clean.
 
Hi,

The problem here is I am not getting any logs now. I am trying to get logs of IPFW. It was logging on 4th May.
 
networklabs said:
The problem here is I am not getting any logs now.
Click to expand...
If syslogd is actually running (you said you checked using ps) and also actually logging (does it work for other logfiles?) then there seems to be only one option left, and that's the firewall itself.

What does # ipfw show tell you? Do you still have any rules active which require logging?

Another possibility could be the net.inet.ip.alias.sctp.log_level option which specifies how much detail should be used with logging. From 0 (minimal) to 5 (maximum debug). So you might want to check that value as well using $ sysctl net.inet.ip.alias.sctp.log_level.
 
What happens if you clear the IPFW counters via
# ipfw zero

IPFW only logs the first X packets that match a rule, where X is listed in one of the IPFW sysctls.
 
It's resolved and what a stupid mistake:

Code: 
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5

was missing from sysctl.conf. It was there, I do not know when I lost it. Maybe a reboot.

But thank you guys for help.
 
You must log in or register to reply here.
Back
Top