> Enable custom AuditD rules to watch anything it touches outside of it's sandbox.
Is auditd capitalized like SunnyD for any particular reason?
But really, what should one of these auditd rules look like? I'm imagining something like below, where *lil-agent* is the user for our agent. This would create audit logs if the user messed with any paths outside its home.
What can this rule tell me though? Since you advise running agents in an isolated machine, that ideally only has the user for the agent, the only paths the agent could mess with are system files if it had an exploit, but at that point it's game over. You'd have to hope it didn't tamper with the audit logs.
Is auditd capitalized like SunnyD for any particular reason?
Habbit. I changed it for you.
What can this rule tell me though?
The purpose of something like auditd is to capture evidence of actions to help paint a picture for investigators. By itself that may not be enough. That is why I suggest confining all the agent content into its own device and forcing all that traffic through a Squid SSL Bump MitM proxy and also logging DNS. Squid can log URL's, methods (GET|POST|PUT) etc... and permit/deny access to domains and URL's. That may also not be enough but it's more than what most people have today. If behavior starts to look suspicious then one can start doing deeper forensic capture of data using sysdig, OSSEC, eBPF, strace, perf and other tools. I should add a small blurb about using OSSEC so that people can configure diffs and alerts on important files that are not expected to change dynamically. OSSEC is a very big topic. OR one need not wait for suspicious behavior, just know that forensic security tools can use a great deal of resources. Some companies already do this but do not rely on them to be the watchdogs. It is very likely they are not permitted to disclose internal security incidents without going through a myriad of teams such as legal, PR, compliance, security and many other internal organizations. They will only be watching out for themselves.
- The most important take-away in my opinion is having an isolated node that only has the data the LLM is explicitly expected to access and nothing else. This can limit the blast radius or financial damage an LLM can do. It becomes much easier to answer questions like, "What data did this thing have access to?" That gets back to your auditd rule. If a file was read at a particular time and Squid logged that there was a POST of a particular size to a third party site that may provide enough correlation to dig deeper and try to reverse engineer the logic that led to the action.
If I start documenting how to use sysdig people will assume I am shilling or grifting a commercial product. I have been sticking with things anyone can research, install, tune and tweak to their needs.
In regards to log file tampering the risk can be reduced by sending logs real time to a remote syslog server that the LLM agent node does not have access to. Auditd rules can also be set immutable meaning a reboot is required to change them but use care with that option. I will let you research what that option is. If set on many nodes and if the rules become chatty that can become rather expensive if logs are going to Splunk.
There is a module [1] that can be enabled in auditd to send data to syslog. Rsyslog for example can do local spooling in the event the syslog server is not available and then send all the data to the remote syslog server(s) that the LLM agent node may not remotely log into. Rsyslog can be configured to filter out noisy events to avoid alert fatigue and minimize disk usage especially for expected repetitive events. There are also plugins that can be use to send auditd data in different formats to syslog or other end-points.
> Enable custom AuditD rules to watch anything it touches outside of it's sandbox.
Is auditd capitalized like SunnyD for any particular reason?
But really, what should one of these auditd rules look like? I'm imagining something like below, where *lil-agent* is the user for our agent. This would create audit logs if the user messed with any paths outside its home.
What can this rule tell me though? Since you advise running agents in an isolated machine, that ideally only has the user for the agent, the only paths the agent could mess with are system files if it had an exploit, but at that point it's game over. You'd have to hope it didn't tamper with the audit logs.Is auditd capitalized like SunnyD for any particular reason?
Habbit. I changed it for you.
What can this rule tell me though?
The purpose of something like auditd is to capture evidence of actions to help paint a picture for investigators. By itself that may not be enough. That is why I suggest confining all the agent content into its own device and forcing all that traffic through a Squid SSL Bump MitM proxy and also logging DNS. Squid can log URL's, methods (GET|POST|PUT) etc... and permit/deny access to domains and URL's. That may also not be enough but it's more than what most people have today. If behavior starts to look suspicious then one can start doing deeper forensic capture of data using sysdig, OSSEC, eBPF, strace, perf and other tools. I should add a small blurb about using OSSEC so that people can configure diffs and alerts on important files that are not expected to change dynamically. OSSEC is a very big topic. OR one need not wait for suspicious behavior, just know that forensic security tools can use a great deal of resources. Some companies already do this but do not rely on them to be the watchdogs. It is very likely they are not permitted to disclose internal security incidents without going through a myriad of teams such as legal, PR, compliance, security and many other internal organizations. They will only be watching out for themselves.
- The most important take-away in my opinion is having an isolated node that only has the data the LLM is explicitly expected to access and nothing else. This can limit the blast radius or financial damage an LLM can do. It becomes much easier to answer questions like, "What data did this thing have access to?" That gets back to your auditd rule. If a file was read at a particular time and Squid logged that there was a POST of a particular size to a third party site that may provide enough correlation to dig deeper and try to reverse engineer the logic that led to the action.
If I start documenting how to use sysdig people will assume I am shilling or grifting a commercial product. I have been sticking with things anyone can research, install, tune and tweak to their needs.
In regards to log file tampering the risk can be reduced by sending logs real time to a remote syslog server that the LLM agent node does not have access to. Auditd rules can also be set immutable meaning a reboot is required to change them but use care with that option. I will let you research what that option is. If set on many nodes and if the rules become chatty that can become rather expensive if logs are going to Splunk.
There is a module [1] that can be enabled in auditd to send data to syslog. Rsyslog for example can do local spooling in the event the syslog server is not available and then send all the data to the remote syslog server(s) that the LLM agent node may not remotely log into. Rsyslog can be configured to filter out noisy events to avoid alert fatigue and minimize disk usage especially for expected repetitive events. There are also plugins that can be use to send auditd data in different formats to syslog or other end-points.
[1] - https://linux.die.net/man/8/audisp-remote