Score:0

How to disable crontab list entries in cron log?

do flag

I have a script on server that runs every few min, and among other things checks if some malicious crontab entries have been injected. In order to do this I check crontabs of all users, which works all good, but my /var/log/cron file gets filled up with entries of the all crontab listings, so everytime I run the script it would log all crontab lists like this:

Nov 30 17:16:02 myserv crontab[348610]: (root) LIST (root)
Nov 30 17:16:02 myserv crontab[348611]: (root) LIST (bin)
Nov 30 17:16:02 myserv crontab[348612]: (root) LIST (daemon)
Nov 30 17:16:02 myserv crontab[348613]: (root) LIST (adm)
Nov 30 17:16:02 myserv crontab[348614]: (root) LIST (lp)
Nov 30 17:16:02 myserv crontab[348615]: (root) LIST (sync)
Nov 30 17:16:02 myserv crontab[348616]: (root) LIST (shutdown)
Nov 30 17:16:02 myserv crontab[348617]: (root) LIST (halt)
Nov 30 17:16:02 myserv crontab[348618]: (root) LIST (mail)
Nov 30 17:16:02 myserv crontab[348619]: (root) LIST (operator)
Nov 30 17:16:02 myserv crontab[348620]: (root) LIST (games)
Nov 30 17:16:02 myserv crontab[348621]: (root) LIST (ftp)
Nov 30 17:16:02 myserv crontab[348622]: (root) LIST (smb)
Nov 30 17:16:02 myserv crontab[348623]: (root) LIST (named)
Nov 30 17:16:02 myserv crontab[348624]: (root) LIST (postgres)
Nov 30 17:16:02 myserv crontab[348625]: (root) LIST (mysql)
.....

so it fills up log file unnecessarily. I played with different selectors but it seems when choosing cron.info it shows all info, whereas cron.notice it doesn't show when crontab has been edited nor executed, which again I like in my logs.

# Log cron stuff
cron.*                                                  /var/log/cron

cron.* seems to be the same as cron.info Any Ideas how to exclude "LIST" entries? so /var/log/cron would look like:

Nov 30 17:24:02 mysrv CROND[349831]: (root) CMDEND (/etc/cron.b/check nout >/dev/null 2>&1)
Nov 30 17:28:01 mysrv CROND[350781]: (root) CMD (/etc/cron.b/check nout >/dev/null 2>&1)
Score:1
pe flag

Try with cron.none . If you use * an asterisk ( * ) matches zero or more occurrences.

Now your can modify the rule in order to move the log to another file /path/to/another/file

UPDATE

Compare-Operations

The following compare-operations are currently supported:

contains

Checks if the string provided in value is contained in the property. There must be an exact match, wildcards are not supported.

isequal

Compares the “value” string provided and the property contents. These two values must be exactly equal to match. The difference to contains is that contains searches for the value anywhere inside the property value, whereas all characters must be identical for isequal. As such, isequal is most useful for fields like syslogtag or FROMHOST, where you probably know the exact contents.

startswith

Checks if the value is found exactly at the beginning of the property value. For example, if you search for “val” with

:msg, startswith, "val"

it will be a match if msg contains “values are in this message” but it won’t match if the msg contains “There are values in this message” (in the later case, “contains” would match). Please note that “startswith” is by far faster than regular expressions. So even once they are implemented, it can make very much sense (performance-wise) to use “startswith”.

regex

Compares the property against the provided POSIX BRE regular expression.

ereregex

Compares the property against the provided POSIX ERE regular expression.

You can use the bang-character (!) immediately in front of a compare-operation, the outcome of this operation is negated. For example, if msg contains “This is an informative message”, the following sample would not match:

:msg, contains, "error"

but this one matches:

:msg, !contains, "error"

Using negation can be useful if you would like to do some generic processing but exclude some specific events. You can use the discard action in conjunction with that. A sample would be:

*.* /var/log/allmsgs-including-informational.log
:msg, contains, "informational"  ~
*.* /var/log/allmsgs-but-informational.log

Do not overlook the tilde in line 2! In this sample, all messages are written to the file allmsgs-including-informational.log. Then, all messages containing the string “informational” are discarded. That means the config file lines below the “discard line” (number 2 in our sample) will not be applied to this message. Then, all remaining lines will also be written to the file allmsgs-but-informational.log.

DenisZ avatar
do flag
if I use cron.none then I don't get any log entries which is not what I want. I just want to exclude crontab LIST entries from log
Arden Smith avatar
pe flag
Create another rule to move the log to another location as suggest you in my answer in order to have a log entries more clean and easy.
DenisZ avatar
do flag
Thanks I was studying documentation and came up with solution bellow
Score:0
do flag

I found solution with filter, for anyone that's interested. I inserted a statement above cron.info, to remove unwanted messages. so my solution looks like:

:msg, contains, "(root) LIST"                           ~
cron.*                                                  /var/log/cron

now all lines with entries with "(root) LIST" will be discarded.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.