On Mon, Dec 8, 2014 at 12:13 PM, Michael Starks < ossec-l...@michaelstarks.com> wrote:
> With real-time checks enabled, it's a time-based security problem. Can the > agent send the hashes to the manager before the attacker can alter or stop > them? Yes: stop OSSEC, start your own agent. This is precisely the use case I'm concerned about, as this is the use case of a malicious user or a compromised SSH key. In all other cases -- where OSSEC is not stopped first -- a standalone OSSEC agent with real-time monitoring will catch pretty much anything. Using agents and a centralized manager doesn't address this head-on, but does make it more likely the attacker would flag something. > This is one of the problems that mandatory labels attempt to solve. > Technologies like SELinux on 'nix or Mandatory Integrity Control on Windows > could protect the hashes on the agent even if the attacker has > administrative access. I'm not sure about Windows, but I think SELinux at > least can be configured such that relabeling requires a reboot first. The > agent files could be configured with these labels. > I'm fairly familiar with SELinux, and I'm not entirely sure how it can help. Can you expand a bit, please? What is it that SELinux would actually be protecting (aka can you clarify "protect the hashes on the agent"), and how would it do so? > Of course there are plenty of "but-ifs and what-ifs" here. The real > question is: is the way OSSEC behaves likely to be sufficient for most use > cases and will the hashes sent to the manager be trustworthy? I think the > answer in the vast majority of cases is "yes." Agreed, with the exception of the use case (root-level compromise) we identified above. This isn't limited to OSSEC; this is an issue with pretty much all in-OS indicators of compromise: if the context in which you're running is also the context in which you were compromised, you're going to have a bad time. In other words, and to underline the point I was making: in the cases where the hashes are trustworthy (non-root compromise), so, too, would a local database be trustworthy. In the cases where we would benefit from having a remote database that is not directly accessible from the agent (root compromise), the benefits of doing so would be slim, as we can no longer trust the hashes. There are definitely still cases where this indirect database access helps, yes. (I've taken this conversation off into the weeds; I apologize.) -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
