/var/log/audit/audit.log entries not being forwarded to server

[Aleksandr Zaldak]

Hi Guys, have a weird one. Can't make audit log to be read by agent and forwarded it to a server. Please see my config below:

#Agent 

#Log file (/var/log/audit/audit.log): Sample entry

# -rw------- 1 root root 5353526 Mar  4 22:01 /var/log/audit/audit.log

type=PATH msg=audit(1488663556.514:79647): item=1 name="/etc/pki/tls/private/REPLACED1_REPLACED2.key" inode=214745677 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 objtype=DELETE #Unauthorised delete attempt..

#Agent Ossec config

<ossec_config>

  ...

  <!-- Log analysis -->

  <localfile>

  ....

    <localfile>

    <log_format>audit</log_format>

    <location>/var/log/audit/audit.log</location>

  </localfile>

  ...

  </ossec_config>

#Agent /etc/audit/rules.d/audit.rules

# This file contains the auditctl rules that are loaded

# whenever the audit daemon is started via the initscripts.

# The rules are simply the parameters that would be passed

# to auditctl.

# First rule - delete all

-D

# Increase the buffers to survive stress events.

# Make this bigger for busy systems

-b 320

#2.6.2.4.11 Ensure auditd Collects Files Deletion Events by User (successful and unsuccessful)

-a always,exit -F arch=b64 -S unlink -S rmdir -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete

-a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid=0 -k delete

#Server side

/var/ossec/logs/alerts/alerts.json << no records for auditd events

/var/ossec/logs/alerts/alerts.log  << no records for auditd events

*/ruleset/rules/0365-auditd_rules.xml presents

  

##Env

 #Agent

 CentOS Linux release 7.3.1611 (Core)#3.10.0-327.4.5.el7.x86_64

 wazuh-agent-2.0-1.el7.x86_64

 #Server

 CentOS Linux release 7.3.1611 (Core) #3.10.0-514.6.1.el7.x86_64

 Wazuh v2.0

Any ideas ?

Thanks

[Jesus Linares]

Hi Aleksandr,

your configuration seems right. Let's debug the process:

1. Manager: Enable <logall>: we want to see the audit events in archives.log.
   
2. Agent:
• Configure the agent to collect audit events (<log_format>audit</log_format>)
• Restart ossec
• Review if there are errors in ossec.log
• Generate an audit event and check if the event is in /var/log/audit/audit.log.
3. Manager: Review if the audit events are in archives.log. Also, check alerts.log.

Let us know if you get errors or see the events in archives.log.

I hope it help.

Regards.

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/45555a54-0854-4593-a090-29e7cc19066f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jesus Linares

IT Security Engineer

[Aleksandr Zaldak]

Hi Jesus,

After enabling the "logall" on server, I got the following in the ../logs/archives/archives.json

{"rule":{},"agent":{"id":"002","name":"AAAAA","ip":"X.X.X.0"},"manager":{"name":"localhost.localdomain"},"full_log":"type=SYSCALL msg=audit(1488716672.216:80669): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=7560c0 a2=0 a3=7ffe2eb6ee90 items=2 ppid=57426 pid=57453 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm=\"rm\" exe=\"/usr/bin/rm\" key=\"delete\" type=CWD msg=audit(1488716672.216:80669):  cwd=\"/var/ossec/bin\" type=PATH msg=audit(1488716672.216:80669): item=0 name=\"/etc/\" inode=134320321 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT type=PATH msg=audit(1488716672.216:80669): item=1 name=\"/etc/ossec-init.conf\" inode=165346229 dev=fd:00 mode=0100640 ouid=0 ogid=993 rdev=00:00 objtype=DELETE","audit":{"type":"SYSCALL","id":"80669","syscall":"263","success":"no","exit":"-13","ppid":"57426","pid":"57453","auid":"0","uid":"1007","gid":"1007","euid":"1007","suid":"1007","fsuid":"1007","egid":"1007","sgid":"1007","fsgid":"1007","tty":"pts0","session":"10376","command":"rm","exe":"/usr/bin/rm","key":"delete","cwd":"/var/ossec/bin","directory":{"name":"/etc/","inode":"134320321","mode":"040755"},"file":{"name":"/etc/ossec-init.conf","inode":"165346229","mode":"0100640"}},"decoder":{"parent":"auditd","name":"auditd"},"timestamp":"2017-03-05T12:24:30+0000","location":"/var/log/audit/audit.log"}

So it seems the server does receive the notification! nevertheless ,nothing in /var/ossec/logs/alerts/alerts.json or /var/ossec/logs/alerts/alerts.log though.

[Victor Fernandez]

Hi Aleksandr,

the event is arriving correctly but there is no specific rule for that event. If you extract the "full_event" field and paste it into utility /var/ossec/bin/ossec-logtest, you will get:

root@host:~# ossec-logtest

type=SYSCALL msg=audit(1488716672.216:80669): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=7560c0 a2=0 a3=7ffe2eb6ee90 items=2 ppid=57426 pid=57453 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete" type=CWD msg=audit(1488716672.216:80669):  cwd="/var/ossec/bin" type=PATH msg=audit(1488716672.216:80669): item=0 name="/etc/" inode=134320321 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT type=PATH msg=audit(1488716672.216:80669): item=1 name="/etc/ossec-init.conf" inode=165346229 dev=fd:00 mode=0100640 ouid=0 ogid=993 rdev=00:00 objtype=DELETE

**Phase 1: Completed pre-decoding.

       full event: 'type=SYSCALL msg=audit(1488716672.216:80669): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=7560c0 a2=0 a3=7ffe2eb6ee90 items=2 ppid=57426 pid=57453 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete" type=CWD msg=audit(1488716672.216:80669):  cwd="/var/ossec/bin" type=PATH msg=audit(1488716672.216:80669): item=0 name="/etc/" inode=134320321 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT type=PATH msg=audit(1488716672.216:80669): item=1 name="/etc/ossec-init.conf" inode=165346229 dev=fd:00 mode=0100640 ouid=0 ogid=993 rdev=00:00 objtype=DELETE'

       hostname: 'ubuntu'

       program_name: '(null)'

       log: 'type=SYSCALL msg=audit(1488716672.216:80669): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=7560c0 a2=0 a3=7ffe2eb6ee90 items=2 ppid=57426 pid=57453 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete" type=CWD msg=audit(1488716672.216:80669):  cwd="/var/ossec/bin" type=PATH msg=audit(1488716672.216:80669): item=0 name="/etc/" inode=134320321 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT type=PATH msg=audit(1488716672.216:80669): item=1 name="/etc/ossec-init.conf" inode=165346229 dev=fd:00 mode=0100640 ouid=0 ogid=993 rdev=00:00 objtype=DELETE'

**Phase 2: Completed decoding.

       decoder: 'auditd'

       audit.type: 'SYSCALL'

       audit.id: '80669'

       audit.syscall: '263'

       audit.success: 'no'

       audit.exit: '-13'

       audit.ppid: '57426'

       audit.pid: '57453'

       audit.auid: '0'

       audit.uid: '1007'

       audit.gid: '1007'

       audit.euid: '1007'

       audit.suid: '1007'

       audit.fsuid: '1007'

       audit.egid: '1007'

       audit.sgid: '1007'

       audit.fsgid: '1007'

       audit.tty: 'pts0'

       audit.session: '10376'

       audit.command: 'rm'

       audit.exe: '/usr/bin/rm'

       audit.key: 'delete'

       audit.cwd: '/var/ossec/bin'

       audit.directory.name: '/etc/'

       audit.directory.inode: '134320321'

       audit.directory.mode: '040755'

       audit.file.name: '/etc/ossec-init.conf'

       audit.file.inode: '165346229'

       audit.file.mode: '0100640'

**Phase 3: Completed filtering (rules).

       Rule id: '80700'

       Level: '0'

       Description: 'Audit: messages grouped.'

As you can see, the matched rule has level 0, so it is not being put into the alert log. So you should write a rule for this event. If you have any problem with this write back to us.

Kind regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/0d393dc4-c946-4d18-a2a4-0ee0d3948419%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Victor M. Fernandez-Castro

IT Security Engineer

Wazuh Inc.

[Aleksandr Zaldak]

I see. I had a feeling this could be a culprit really. I assumed the */rules/0365-auditd_rules.xml on the server handles this :)

Thanks

[Aleksandr Zaldak]

I have double checked, checked the logfile and some messages, can and should be parsed! 

#/var/log/audit/audit.log

type=SYSCALL msg=audit(1488793321.267:81789): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=1d140c0 a2=0 a3=7ffc9a1f14f0 items=2 ppid=65480 pid=65495 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete"

type=CWD msg=audit(1488793321.267:81789):  cwd="/var/ossec/bin"

type=PATH msg=audit(1488793321.267:81789): item=0 name="/etc/" inode=134320321 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 objtype=PARENT

type=PATH msg=audit(1488793321.267:81789): item=1 name="/etc/ossec-init.conf" inode=165346229 dev=fd:00 mode=0100640 ouid=0 ogid=993 rdev=00:00 objtype=DELETE

type=USER_END msg=audit(1488793322.802:81790): pid=65479 uid=0 auid=0 ses=10376 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_xauth acct="test5" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success'

type=CRED_DISP msg=audit(1488793322.802:81791): pid=65479 uid=0 auid=0 ses=10376 msg='op=PAM:setcred grantors=pam_rootok acct="test5" exe="/usr/bin/su" hostname=? addr=?

terminal=pts/0 res=success'

#results via ./ossec-logtest

type=SYSCALL msg=audit(1488793321.267:81789): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=1d140c0 a2=0 a3=7ffc9a1f14f0 items=2 ppid=65480 pid=65495 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete"

**Phase 1: Completed pre-decoding.

       full event: 'type=SYSCALL msg=audit(1488793321.267:81789): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=1d140c0 a2=0 a3=7ffc9a1f14f0 items=2 ppid=65480 pid=65495 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete"'

       hostname: 'localhost'

       program_name: '(null)'

       log: 'type=SYSCALL msg=audit(1488793321.267:81789): arch=c000003e syscall=263 success=no exit=-13 a0=ffffffffffffff9c a1=1d140c0 a2=0 a3=7ffc9a1f14f0 items=2 ppid=65480 pid=65495 auid=0 uid=1007 gid=1007 euid=1007 suid=1007 fsuid=1007 egid=1007 sgid=1007 fsgid=1007 tty=pts0 ses=10376 comm="rm" exe="/usr/bin/rm" key="delete"'

**Phase 2: Completed decoding.

       decoder: 'auditd'

       audit.type: 'SYSCALL'

       audit.id: '81789'

       audit.syscall: '263'

       audit.success: 'no'

       audit.exit: '-13'

       audit.ppid: '65480'

       audit.pid: '65495'

       audit.auid: '0'

       audit.uid: '1007'

       audit.gid: '1007'

       audit.euid: '1007'

       audit.suid: '1007'

       audit.fsuid: '1007'

       audit.egid: '1007'

       audit.sgid: '1007'

       audit.fsgid: '1007'

       audit.tty: 'pts0'

       audit.session: '10376'

       audit.command: 'rm'

       audit.exe: '/usr/bin/rm'

**Phase 3: Completed filtering (rules).

       Rule id: '80700'

       Level: '0'

       Description: 'Audit: messages grouped.'

So why this is not reflected in alert.json then?

[Pedro Sanchez]

Hi Aleksandr,

As Victor told you on the last email, the rule level is "0", meaning that no alert will be generated.

OSSEC will generate an alert only if rule level is greater than 3, you could configure it at ossec.conf in "log_alert_level" setting.

If you really want to log every Auditd event (no matter if there is a rule for it or the rule level), increase the "rule level" for Rule ID 80700 from 0 to 3.

Open 0365-auditd_rules.xml:

<rule id="80700" level="0"> -> <rule id="80700" level="3">

 

You could also modify local_rules.xml and overwrite Auditd rule as follow:

<rule id="80700" level="3" overwrite="yes">
<decoded_as>auditd</decoded_as>
<description>Audit: messages grouped.</description>
</rule>

Regards,

Pedro 'snaow' Sanchez. 

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/8931de08-f133-4bfb-9b7f-dabe5f8a4f2e%40googlegroups.com.

[Aleksandr Zaldak]

Ahh, sorry, completely missed the level 0 clause. Makes sense really.

P.S.

I definitely don't'; want/need to monitor ANY event, but I think

#oscap.scan.benchmark.id: xccdf_org.ssgproject.content_benchmark_RHEL-7

#oscap.check.oval.id: oval:ssg-audit_rules_file_deletion_events:def:1 #Ensure auditd Collects File Deletion Events by User,

is useful to have out of the box :)

[Santiago Bassett]

Hi Aleksandr,

totally agree with you. I believe it would make sense to develop a new rule for those specific events only. We will take a look at it when possible, making them available in our public repo. If you do that first please share :-)

Best regards

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/e8840f23-f826-4c9c-b899-873914c96e96%40googlegroups.com.