I'm trying to track down the source cause of a breakin on a serverhosting customer's website.

auditd is a great help in showing me what directory to look in when yet another bit of malware (the site is something of a mess, but not mine to clear up even if I wanted to) activates and screws up the site, but the audit logs are tricky to read because it also logs the ssh activity from a monitoring script that connects every two minutes to check various statuses, as well as another monitoring system that's triggered by cron.

I've made several attempts in auditctl to tell it to stop reporting these:

root@zelia:/var/log/audit# auditctl -l 
-a never,user -F auid=116
-a never,task -F auid=116
-a never,exit -S all -F auid=116
-a never,exit -S all -F uid=116

(UID 116, user 'meminfo' is the one I want to suppress)

However, every few minutes I still get the following:

type=USER_ACCT msg=audit(1491386883.189:462708): pid=1502 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="meminfo" exe="/usr/sbin/sshd" hostname=prtg.systemec.nl addr= terminal=ssh res=success'
type=CRED_ACQ msg=audit(1491386883.189:462709): pid=1502 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="meminfo" exe="/usr/sbin/sshd" hostname=monitor.company.internal addr= terminal=ssh res=success'
type=LOGIN msg=audit(1491386883.189:462710): pid=1502 uid=0 old-auid=4294967295 auid=116 old-ses=4294967295 ses=368164 res=1
type=USER_ACCT msg=audit(1491386883.197:462711): pid=1504 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="meminfo" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1491386883.197:462712): pid=1504 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open acct="meminfo" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1491386883.213:462713): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="user@116" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1491386883.365:462714): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="user@116" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

As a result, audit logs keep filling up and I'm missing important backlog.

On the other hand, while I don't think the breakin is happening via SSH, a log of who logs onto the server when may be useful to have handy.

Obviously, the rules I attempted to add to keep meminfo suppressed don't work correctly. What am I doing wrong?

ADDENDUM For some reason, adding auditctl -a never,task afterwards causes the never,task rule to be loaded first and everything gets suppressed, including what I really did want to see.

ADDENDUM #2 As explained in this question, the messages I'm trying to suppress are generated by default by the PAM subsystems and not by additional rules in audit.rules, so that's an additional problem...


In your logfile, uid=0 on these lines means these processes are started by the root, not meminfo.


The auid field records the Audit user ID, that is the loginuid. This ID is assigned to a user upon login and is inherited by every process even when the user's identity changes (for example, by switching user accounts with the su - john command).


The uid field records the user ID of the user who started the analyzed process. The user ID can be interpreted into user names with the following command: ausearch -i --uid UID. In this case, 500 is the user ID of user shadowman.

This may be caused by running the program from root users crontab or if the process invokes a service that must be first started as root (with setuid) to enable it to use privileged ports <1024.

Probably you do not want to suppress all auid=0 activity as it would suppress something meaningful.

If your auditd can filter by process name i.e. exe=, like RHEL7 since BZ#1135562, suppressing sshd started by root should be safe IF you also have PermitRootLogin no:

    -a never,user -F auid=0 -F exe="/usr/sbin/sshd"
    -a never,task -F auid=0 -F exe="/usr/sbin/sshd"

However, in most cases -F is limited to fields outside msg=' ' and only has operators that won't allow regular expressions: -F [n=v | n!=v | n<v | n>v | n<=v | n>=v | n&v | n&=v].

One option is to increase the max_log_file or num_logs to keep more history, if the log size is not a problem. You don't have to read the log format directly, as you have aureport and ausearch.

| improve this answer | |
  • That explains, yes. Unfortunately, I was kind of hoping to be able to differentiate between ssh sessions for user meminfo (suppress) and ssh sessions for everyone else (log). But if that's not in the cards... I'll see what works. Thanks. – Shadur Apr 5 '17 at 11:53
  • Looks like the version of auditd in debian Jessie does not include exe= as a possible field. – Shadur Apr 5 '17 at 11:55
  • It may only be available in RHEL 7. It would be so nice and easy to be able to filter by exe= , comm= and acct= . You could send a letter to Santa. – Esa Jokinen Apr 5 '17 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.