may be disappearing to. On a low load development machine I've been finding that I don't appear to be entries in the
table for some connections, whereas others are just fine. I was wondering if someone could point me in the right direction of how to debug this a bit further? 🧵
, and not eBPF and There's no auditd installed on the machine.
set to true.
are set to false . I've used
to get the installed rules when osquery is running and I'm able to see the osquery installed rule(s) for
at syscall exit.
temporarily on this machine to
as a "just in case".
I correctly see an entry in the
a few moments later:
osquery> select path,remote_address from socket_events where remote_port = '443'; +---------------+----------------+ | path | remote_address | +---------------+----------------+ | /usr/bin/curl | 22.214.171.124 | +---------------+----------------+
osquery and look for all
events, I can see an audit event for the associated
syscall being sent over the audit socket to osquery. Apologies for the screen grab but it's a bit easier to visualise.
to Google shows up in the
table shortly before, but the outbound connection for TCP/1234 doesn't appear to ever appear in the
- which might assist here or am I in "attach a debugger" territory? 🙂
I0805 15:45:11.034433 9994 auditdnetlink.cpp:778] 1300, audit(1628178308.957:370181): arch=c000003e syscall=42 success=no exit=-115 a0=3 a1=c00008402c a2=10 a3=0 items=0 ppid=10035 pid=10064 auid=4294967295 uid=998 gid=1002 euid=998 suid=998 fsuid=998 egid=1002 sgid=10 02 fsgid=1002 tty=pts6 ses=4294967295 comm="shell" exe="/home/ssm-user/shell/shell" key=(null)
. Looking at the fields in the audit message it appears that it may be non-blocking as result seems to indicate the exit code as
. Looking at
for Kernel 5.4 it appears this is
calls are "invisible" to osquery due to the issue mentioned above, at least for the time being? 🙂