Do OSSEC agents cache events when offline?
Stefano Pedretti
i want known if OSSEC keep events happened when manager is offline/
unreacheable.
I known there is a lock status but seems that some events can be
losts.
Is this true? There is a way to avoid event losses in lack of network
cases?
thank you
roger
Is there a way to have OSSEC deliver over TCP rather than UDP?
On Feb 16, 1:39 am, Stefano Pedretti <stefano.pedre...@gmail.com>
wrote:
Daniel Cid
When the agent detects that the manager is offline, it will stop
processing new events,
and will only resume reading them when the manager is back up.
So, those events will not be lost. However, we don't queue them in
memory, we just
keep the file descriptors open and waiting to be read again. If the manager goes
offline for a while (or the agent is rebooted), you lose everything in
the middle...
Using TCP wouldn't help on those situations anyway..
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
Chris Kolb
Chris Kolb
Manager of Information Security
GDSX, Ltd.
Phone: 972-612-7121
Fax: 972-612-7021
Confidentiality Notice: This e-mail contains information that is confidential. It is intended for the exclusive use of the individual or entity to whom it is addressed. If you are not the named recipient, disclosure or distribution of the information transmitted herewith is strictly prohibited and may be subject to legal restriction or sanction. Please notify the sender, by return e-mail or telephone, of any unintended recipients and delete the original message without making any copies.
Stefano Pedretti
Use of TCP could assure data delivery?
Dave S
Use of TCP will only help to prevent the loss of a packet once it is
sent over the network.
It does not prevent any loss of data the agent hasn't sent. That's a
separate issue.
UDP is used because the agent sends data at random times to the
server, and the cost of setting up a TCP link for each event becomes
too high.
Same reason syslog uses UDP. However, to gain that performance, we
lose the ability to confirm delivery of the packet (at least at the
network layer), so it would be possible that events could be lost in-
transit to the server.
What Stefano is asking about, in my opinion, is what does the agent do
when it wants to send an event, but knows it cannot because the
server's offline?
In this case, the agent will not send a packet because it knows it
will not be received, so the UDP/TCP choice is irrelevant. So the
question is, how does the agent handle this situation?
Daniel's explanation is a little unclear (Sorry dcid). I understand
the agent doesn't hold those events in memory, and I understand an
agent reboot would lose those events. But I'm unclear if the agent
actually catches up when the server comes back online. It's also
unclear with things such as Windows events, where the agent is not
looking at a file, but instead uses an API. Does it catch up with
these as well?
Stefano Pedretti
On 24 Feb, 17:06, Dave S <dsty...@comcast.net> wrote:
> I want to clarify some confusion here.
>
> Use of TCP will only help to prevent the loss of a packet once it is
> sent over the network.
> It does not prevent any loss of data the agent hasn't sent. That's a
> separate issue.
Not so true.
>
> UDP is used because the agent sends data at random times to the
> server, and the cost of setting up a TCP link for each event becomes
> too high.
> Same reason syslog uses UDP. However, to gain that performance, we
> lose the ability to confirm delivery of the packet (at least at the
> network layer), so it would be possible that events could be lost in-
> transit to the server.
>
> What Stefano is asking about, in my opinion, is what does the agent do
> when it wants to send an event, but knows it cannot because the
> server's offline?
> In this case, the agent will not send a packet because it knows it
> will not be received, so the UDP/TCP choice is irrelevant. So the
> question is, how does the agent handle this situation?
>
Ok, but transport layer is important for assure delivery. Tcpdump
shows me that ossec manager doesn't send a ACK packet and agent.
In this configuration the agent can't fell the manager's fault and no
retransmission will be performed.
If we want to keep UDP layer and we want assure data delivery, the
only way is to create a feedback system or an hearthbeat at sufficient
small period.
It's impossible to keep a single TCP session for all the time? Again
trasport layer is important.
> Daniel's explanation is a little unclear (Sorry dcid). I understand
> the agent doesn't hold those events in memory, and I understand an
> agent reboot would lose those events. But I'm unclear if the agent
> actually catches up when the server comes back online. It's also
> unclear with things such as Windows events, where the agent is not
> looking at a file, but instead uses an API. Does it catch up with
> these as well?
Tricky question...
Dave S
Stefano Pedretti
> Good question. Does the server ACK every event an agent sends to it?
I don't think so. The problem is here. To ensure data delivery ACK is
mandatory.
Chris Kolb
I've been reading off and on and I haven't seen any more discussion on this issue. In a nutshell, has anything been done or planned to address these two issues:
1. Resiliency in the agent to never give up in attempts to deliver messages to the server
2. Resiliency in the network layer (whether through some kind of UDP ACK or switching to TCP) to avoid loss of alerts due to packet loss
I am able confirm through inspection of local log files vs alerts logged on the OSSEC server side that messages that should be getting through are not arriving when the network is congested. This results in some important alerts being missed, which in my opinion compromises OSSEC's position as a solution for compliance.
Chris Kolb
Manager of Information Security
GDSX, Ltd.
Phone: 972-612-7121
Fax: 972-612-7021
Come see us this summer at NBTA in Houston August 8 - 11! Booth #1277
Confidentiality Notice: This e-mail contains information that is confidential. It is intended for the exclusive use of the individual or entity to whom it is addressed. If you are not the named recipient, disclosure or distribution of the information transmitted herewith is strictly prohibited and may be subject to legal restriction or sanction. Please notify the sender, by return e-mail or telephone, of any unintended recipients and delete the original message without making any copies.
-----Original Message-----
From: ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] On Behalf Of Stefano Pedretti
Sent: Thursday, February 25, 2010 3:35 AM
To: ossec-list
Subject: [ossec-list] Re: Do OSSEC agents cache events when offline?
Dave S
of server/agent communications.
I've been trying to obtain some information on the details of the
protocol so I can review it (see
http://groups.google.com/group/ossec-list/browse_thread/thread/3a8aee9fffd942e1/c36bde94b28b4fa2
) but not having any luck.
Any body know of any technical docs in this area?
spacekiwi
architecture.
I agree with Chris Kolb not only in case of a networkcongestion, but
also when the server himself is down (or under attack) we will need
some guarantee that no logs or events are lost.
However, I have just tested this hypothesis, and I think the events
are indeed lost.
My client is configured to send his alerts to 4 OSSEC-servers. When
the connected server is killed it takes approx. 20 minutes before the
client attempts to contact the second server in line. (would like to
know why 20 minutes...)
Meanwhile I have launched faked ssh sessions to my client, but these
events are nowhere to be found.
After the connection to the second server is established the ssh
events are rightly posted to the second server, but no trace of the in-
between-events...
>
> - Tekst uit oorspronkelijk bericht weergeven -