ossec protocol help being offered

[Dave S]

I've been working with OSSEC and this group for several months.
It seems to me one of the weak areas in ossec's design is the agent/
server protocol. We've all seen several threads presenting various
problems regarding "agents disconnecting" etc. One recent such
problem was fixed by disabling the replay counter because the agent
had fallen out of sync with the server. There have been other issues
that may be related to dropped messages due to the use of UDP. We
should not have to disable security features to make the system more
stable.

These issues point to potential weaknesses in the protocol being
used. If they are not fixed, ossec will continue to suffer from their
effects. I am a believer in ossec, and I am an experienced sockets
software developer in the security/crypto area.

I would like to offer my services to analyze the existing protocol to
see if there are ways to make it more robust. Unfortunately, there is
no published documentation on the technical details of this protocol.
Would it be possible to be furnished with this information?

Respectfully,
Dave Stycos

[Michael Starks]

On Wed, 26 May 2010 07:48:14 -0700 (PDT), Dave S <dst...@comcast.net>
wrote:

> I've been working with OSSEC and this group for several months.
> It seems to me one of the weak areas in ossec's design is the agent/
> server protocol. We've all seen several threads presenting various
> problems regarding "agents disconnecting" etc. One recent such
> problem was fixed by disabling the replay counter because the agent
> had fallen out of sync with the server. There have been other issues
> that may be related to dropped messages due to the use of UDP. We
> should not have to disable security features to make the system more
> stable.

Hello Dave,

While I am sure Daniel would welcome your help, I'm not so sure the common
issues that users face are necessarily protocol-related. Consider:

1. I haven't seen any discussion of dropped messages due to the stateless
nature of UDP. While we all know this is a possibility, and maybe even a
probability on a busy network, there has been no discussion of empirical
evidence showing this is a issue in most environments. Furthermore, the use
of UDP on a busy network may be a better option than UDP, even if some
messages get dropped, simply because it could keep up with an active attack
faster. The use of TCP could actually cause significant delay in delivery
from an attacked system to the trusted host, and that translates to a
higher risk of the not knowing what happened.

2. The replay issue is usually caused by uninstalling/reinstalling agents,
or maybe cloning systems. I think it can be improved, but the rids
generally do not get out of sync on their own. It's an important feature,
since UDP is being used, to prevent replay attacks. I think users just need
a better understanding of how this works. Perhaps a simple rule to alert
someone of the issue with a solution pointing to a Wiki page...

3. I think the TCP option should be explored, primarily because if we use
TCP there are more options for a robust key-management system. Key
management, especially in large enterprises, is a big issue for ossec right
now. Maybe TCP and UDP could both be used: TCP for status, key management,
etc, and UDP for message delivery. Or maybe both TCP and UDP can be an
option for message delivery so the user can choose the appropriate one
based on their needs (speed vs. message delivery robustness).

At any rate, I look forward to your thoughts and contributions.

--
[I] Immutable Security
Information Security, Privacy and Personal Liberty
http://www.immutablesecurity.com

[Dave S]

Hey Michael, thanks for your response.
A few things to your points:

Just so there's no misunderstanding, I've no intentions of replacing
UDP. I think it has a vital role to play as well.
What I'm concerned about is whether the protocol is robust enough to
handle the possibility of a dropped message, regardless of the
transport protocol used.
It seems to me that if replay protection is enabled, and we lose a
message, there's no way to get back in synch, and that should not be
the case.

The other reason for this initiative of mine is because as an admin, I
understand there can be alot of sensitive information in my logs, and
right now I'm trusting the security of this protocol sight-unseen.
How does it protect the integrity and confidentiality of these
messages? I dunno. I trust Dan did his best, but as we know in the
security world, openness is the best defense. This protocol should be
published so other eyes can examine it for weaknesses, and
troubleshoot problems should connectivity issues arise. This is no
different from any other protocol in common use today.

- Dave

[Michael Starks]

On Fri, 28 May 2010 07:23:42 -0700 (PDT), Dave S <dst...@comcast.net>

> Just so there's no misunderstanding, I've no intentions of replacing
> UDP. I think it has a vital role to play as well.
> What I'm concerned about is whether the protocol is robust enough to
> handle the possibility of a dropped message, regardless of the
> transport protocol used.
> It seems to me that if replay protection is enabled, and we lose a
> message, there's no way to get back in synch, and that should not be
> the case.

Without deleting the rids, that's pretty much true. One thing to consider,
though, is that if an admin can replay logs, then an attacker probably can,
too.

I think a bigger problem at the moment is that the agent is easily
stopped, and when it is started again, my understanding is that it doesn't
read logs from the point at which it left off. It will read new logs,
potentially leaving an critical gap. But this is no worse than most
solutions. Syslog, for example, could be stopped before the attacker did
bad things. I think it's an interesting problem.

We can make the agent harder to stop. In the case of Windows, maybe a
well-constructed SACL could make it difficult, but that also takes control
away from the admin. What if it shoots to 100% CPU because of a bug? Tricky
problem to solve.

> The other reason for this initiative of mine is because as an admin, I
> understand there can be alot of sensitive information in my logs, and
> right now I'm trusting the security of this protocol sight-unseen.
> How does it protect the integrity and confidentiality of these
> messages? I dunno. I trust Dan did his best, but as we know in the
> security world, openness is the best defense. This protocol should be
> published so other eyes can examine it for weaknesses, and
> troubleshoot problems should connectivity issues arise. This is no
> different from any other protocol in common use today.

No argument there. I think we would all welcome any deficiencies being
identified and corrected. That just makes it better for everyone.