Hi list, 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-list@googlegroups.com [mailto:ossec-l...@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? 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...
