Dan, Since the wui is a dead project, and you suggest "using a modern and maintained Project", can you give suggestions as to what some of those are? I have looked at the Ossec-Slunk project, but it seems almost as dead, the maintainer doesn't answer any questions and there isn't a newsgroup like this one to get help from other users. Base+Ossec also seems to be a dead project as it requires mysql hooks that no longer work with 2.6 and it isn't maintained any longer either.
So, what else is there? The wui is where I want managers to get stats and reports and keep them off the command line. Thanks, Patrick -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of dan (ddp) Sent: Wednesday, September 28, 2011 7:23 AM To: [email protected] Subject: Re: [ossec-list] Client ossec.conf log_alert_levels On Wed, Sep 28, 2011 at 6:27 AM, Andrew Shepherd <[email protected]> wrote: > Hi Dan, thanks for the reply. > > Do you know of any material that will help with the following please as I am > drawing blanks (or a lack of coffee is breaking my ability to google)... > > The changes which have to be made to the WebUI to allow it to read entries > in syslog format instead of /logs/alerts/alerts.log (as defined in WebUI > lib/os_lib_alerts.php). > I have no idea. I don't use the wui. It's a dead project and doesn't function properly with ossec 2.6. I'd use a modern and maintained project. > I'm struggling to understand who is responsible for encryption in the syslog > multi server setup, is it an ossec flag/feature... do you have to use > stunnel.... is rsyslog still called and that service is responsible etc > OSSEC's client syslog does not do encryption. I recommend pointing it at a local rsyslog or syslog-ng instance. syslog-ng or rsyslog can then do reliable and encrypted delivery to another rsyslog/syslog-ng installation on the other end. OSSEC can then read the logfiles produced by that syslog. > Thanks, Andy > > ________________________________ > Date: Wed, 28 Sep 2011 05:38:54 -0400 > Subject: Re: [ossec-list] Client ossec.conf log_alert_levels > From: [email protected] > To: [email protected] > > Agents don't send alerts to servers, they send logs. If you want to limit > the data going from the site, you should setup a local manager and forward > alerts to your central ossec manager. > On Sep 28, 2011 5:36 AM, "Andrew Shepherd" <[email protected]> wrote: >> >> >> I've bought/read the Syngress book, read ossec.net and dcid.me, and had a >> good look through this group but so far no luck. >> >> The >> problem I'm facing is the <log_alert_level> in ossec.conf for >> clients doesn't seem to have an effect. I've read somewhere that >> <log_alert_level> can be used on the server AND the client to >> limit alerts that are sent to the server. >> >> However even when I set this to 9 (for example) on the client... >> <alerts> >> <log_alert_level>9</log_alert_level> >> <email_alert_level>12</email_alert_level> >> </alerts> >> >> ...there >> is still an almost constant UDP stream from client to server, and the >> log on the ossec server keeps receiving/logging level 6 alerts etc. >> >> Project details: >> -Server is on a site with limited bandwidth and will not support constant >> reporting of ALL alerts by EVERY client >> -All traffic MUST be encrypted >> -I'm >> avoiding syslog as I'm not a fan of the format syslog will store in >> (not sure how to parse that back to a WebUI) and I can't see many tuts >> on the best way for encryption >> -client version ossec-hids-2.5.1-1 >> >> I've read >> http://dcid.me/2008/08/multi-server-architecture/ >> But can't see any follow up of the 'same communication channel' but I may >> be missing something. >> >> Any help greatly appreciated. >> Andy > ----------------------------------------- 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.
