[auditd]: syscall matching is only name based and fails with the number
Opened this issue · 1 comments
nicholasberlin commented
Integration Name
Auditd Logs [auditd]
Dataset Name
auditd.log
Integration Version
3.20.0
Agent Version
8.15.0
Agent Output Type
elasticsearch
Elasticsearch Version
8.15.0
OS Version and Architecture
Linux
Software/API Version
No response
Error Message
No response
Event Original
No response
What did you do?
default config
What did you see?
This auditd log message:
"node=praorem001 type=SYSCALL msg=audit(1723109482.048:4981103): arch=c000003e syscall=87 success=yes exit=0 a0=7f1118081d10 a1=7f1118081d10 a2=242 a3=180 items=2 ppid=560201 pid=560348 auid=1561577791 uid=2012 gid=2007 euid=2012 suid=2012 fsuid=2012 egid=2007 sgid=2007 fsgid=2007 tty=(none) ses=126 comm=\"httpd\" exe=\"/app/ogc101/app/dllogc/product/13.5.0/mw_100/ohs/bin/httpd\" key=\"delete\"\u001dARCH=x86_64 SYSCALL=unlink AUID=\"na-uoradbdba03\" UID=\"dllogc\" GID=\"oinstall\" EUID=\"dllogc\" SUID=\"dllogc\" FSUID=\"dllogc\" EGID=\"oinstall\" SGID=\"oinstall\" FSGID=\"oinstall\"
It is a file delete message but parsing results in:
"event" : {
"action" : "syscall",
"category" : [
"process"
],
"type" : [
"info"
]
}
What did you expect to see?
I expect to see:
"event" : {
"action" : [
"deleted"
]
"category" : [
"file"
],
"type" : [
"deletion"
]
}
This is caused because
syscall=87
from the message.
If regenerating the painless syscalls param is not possible because syscall numbers change from arch to arch, falling back in the painless script to the enriched SYSCALL=unlink
could fix this particular example.
Anything else?
No response
elasticmachine commented
Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)