I am using ossec 2.2 on Solaris and Aix in a multiserver failover 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... On 14 jun, 17:09, "Chris Kolb" <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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...- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven -
