Hi Patrick, Yes, that's basically what Dan explained. Removing the counters would allow for someone inside your network to replay the events into ossec.
However, if you are using syslog internally, you will have this problem anyway... So even using this option would not protect you. I disable this many times on internal networks because it makes easy to manage and use with multiple servers (they don't have to be in sync anymore). Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Mon, May 17, 2010 at 11:25 AM, dan (ddp) <ddp...@gmail.com> wrote: > Not Daniel, but... The counters help protect against replay attacks. > The counter should be incremented after every message sent from the > agent to the server. If the server gets a message with the counter set > lower than the current counter on the server it will reject the > message. > > On Mon, May 17, 2010 at 9:11 AM, Swartz, Patrick H > <patrick.swa...@firstdata.com> wrote: >> Hi Daniel, >> Could you expand on the effects of disabling the counters? Understand the >> consequences would help us decide the best path to follow. >> >> Thank you for all you do! >> >> Patrick Swartz >> UNIX Planning & Engineering (DSUSSE) >> First Data >> 402-777-7337 desk >> 402-871-8981 cell >> >> -----Original Message----- >> From: ossec-list@googlegroups.com [mailto:ossec-l...@googlegroups.com] On >> Behalf Of Daniel Cid >> Sent: Friday, May 14, 2010 11:43 AM >> To: ossec-list@googlegroups.com >> Subject: Re: [ossec-list] RE: All UNIX/LINUX agents disconnecting >> >> Hi Lucio, >> >> There is two issues in this thread. One, the agent disconnects and >> then reconnects >> by itself. That's fine and can happen on high load environment or when a >> message >> gets dropped. >> >> The second issue that Mike mentioned happens when the counters get out of >> sync and the agent never reconnects. For this problem, you have to either >> clean >> the "rids" directory on the manager or disable the counters. To disable it, >> set >> verify_msg_id to 0 on the internal_options.conf file: >> >> # Verify msg id (set to 0 to disable it) >> remoted.verify_msg_id=0 >> >> Thanks, >> >> -- >> Daniel B. Cid >> dcid ( at ) ossec.net >> >> >> On Thu, May 13, 2010 at 1:21 PM, Lucio Emanuel Soldo <luxie...@gmail.com> >> wrote: >>> Hi Mike, how are you? Could you post the final solution your team has >>> produced in order to fix its problem? >>> >>> Thanx alot! >>> >>> On Tue, May 11, 2010 at 6:56 PM, Pendergrast, Michael L >>> <michael.l.pendergr...@boeing.com> wrote: >>>> >>>> Yes we have >>>> >>>> although we have v1.6 >>>> >>>> I don't have the details as my team has worked the problem and is >>>> currently deployed. >>>> >>>> What we did find is that there is a counter in the agent and in the >>>> manager and if they get out of sequence the agent will stop (basicaqlly >>>> they >>>> get out of sequence). We also found that at startup of the UNIX agents >>>> that >>>> if multiple agents all start at the same time, the agents will stop. In >>>> this case, for initial startup we had to sequence the startup in about 10 >>>> min increments. >>>> >>>> Mike >>>> ________________________________ >>>> From: ossec-list@googlegroups.com [mailto:ossec-l...@googlegroups.com] On >>>> Behalf Of Griffith, Robert >>>> Sent: Tuesday, May 11, 2010 12:26 PM >>>> To: 'ossec-l...@ossec.net' >>>> Subject: [ossec-list] All UNIX/LINUX agents disconnecting >>>> Importance: High >>>> >>>> We have been running the new version of Ossec 2.4 in our environment for >>>> 3 weeks. Yesterday all of our UNIX/LINUX client agents started >>>> disconnecting. None of our Windows Server client agents have disconnected. >>>> Has anyone experienced this and/or found a resolution for this issue. >>>> >>>> Thank you, >>>> Robert >>>> >>> >> >> ----------------------------------------- >> The information in this message may be proprietary and/or >> confidential, and protected from disclosure. If the reader of this >> message is not the intended recipient, or an employee or agent >> responsible for delivering this message to the intended recipient, >> you are hereby notified that any dissemination, distribution or >> copying of this communication is strictly prohibited. If you have >> received this communication in error, please notify First Data >> immediately by replying to this message and deleting it from your >> computer. >> >
