It's coming from Atomic repository. I've checked and I saw there is a version 2.6-5.el5.art available. I'll try to upgrade tomorrow.
The configuration of this ossec server is basic, it's just forwarding all the received messages to another ossec server. <!-- OSSEC example config --> <ossec_config> <global> <email_notification>no</email_notification> <logall>yes</logall> </global> <syslog_output> <server>Z.Z.Z.Z</server> </syslog_output> <rules> <include>rules_config.xml</include> <include>pam_rules.xml</include> <include>sshd_rules.xml</include> <include>telnetd_rules.xml</include> <include>syslog_rules.xml</include> <include>arpwatch_rules.xml</include> <include>symantec-av_rules.xml</include> <include>symantec-ws_rules.xml</include> <include>pix_rules.xml</include> <include>named_rules.xml</include> <include>smbd_rules.xml</include> <include>vsftpd_rules.xml</include> <include>pure-ftpd_rules.xml</include> <include>proftpd_rules.xml</include> <include>ms_ftpd_rules.xml</include> <include>ftpd_rules.xml</include> <include>hordeimp_rules.xml</include> <include>roundcube_rules.xml</include> <include>wordpress_rules.xml</include> <include>cimserver_rules.xml</include> <include>vpopmail_rules.xml</include> <include>vmpop3d_rules.xml</include> <include>courier_rules.xml</include> <include>web_rules.xml</include> <include>apache_rules.xml</include> <include>nginx_rules.xml</include> <include>php_rules.xml</include> <include>mysql_rules.xml</include> <include>postgresql_rules.xml</include> <include>ids_rules.xml</include> <include>squid_rules.xml</include> <include>firewall_rules.xml</include> <include>cisco-ios_rules.xml</include> <include>netscreenfw_rules.xml</include> <include>sonicwall_rules.xml</include> <include>postfix_rules.xml</include> <include>sendmail_rules.xml</include> <include>imapd_rules.xml</include> <include>mailscanner_rules.xml</include> <include>dovecot_rules.xml</include> <include>ms-exchange_rules.xml</include> <include>racoon_rules.xml</include> <include>vpn_concentrator_rules.xml</include> <include>spamd_rules.xml</include> <include>msauth_rules.xml</include> <include>mcafee_av_rules.xml</include> <include>trend-osce_rules.xml</include> <include>ms-se_rules.xml</include> <include>zeus_rules.xml</include> <include>solaris_bsm_rules.xml</include> <include>vmware_rules.xml</include> <include>ms_dhcp_rules.xml</include> <include>asterisk_rules.xml</include> <include>ossec_rules.xml</include> <include>attack_rules.xml</include> <include>local_rules.xml</include> <!-- <include>policy_rules.xml</include> --> </rules> <syscheck> <!-- Frequency that syscheck is executed default every 20 hours --> <frequency>72000</frequency> <!-- Directories to check (perform all possible verifications) --> <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories> <directories check_all="yes">/bin,/sbin</directories> <!-- Files/directories to ignore --> <ignore>/etc/mtab</ignore> <ignore>/etc/hosts.deny</ignore> <ignore>/etc/mail/statistics</ignore> <ignore>/etc/random-seed</ignore> <ignore>/etc/adjtime</ignore> <ignore>/etc/httpd/logs</ignore> </syscheck> <rootcheck> <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans> </rootcheck> <global> <white_list>127.0.0.1</white_list> <white_list>X.X.X.X</white_list> </global> <remote> <connection>secure</connection> </remote> <remote> <connection>syslog</connection> <allowed-ips>Y.Y.Y.Y</allowed-ips> <allowed-ips>Y.Y.Y.Y</allowed-ips> <allowed-ips>Y.Y.Y.Y</allowed-ips> </remote> <alerts> <!--<log_alert_level>2</log_alert_level>--> <log_alert_level>0</log_alert_level> </alerts> <command> <name>host-deny</name> <executable>host-deny.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command> <command> <name>firewall-drop</name> <executable>firewall-drop.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command> <command> <name>firewall-drop-22</name> <executable>firewall-drop-22.sh</executable> <expect>srcip</expect> <timeout_allowed>yes</timeout_allowed> </command> <command> <name>disable-account</name> <executable>disable-account.sh</executable> <expect>user</expect> <timeout_allowed>yes</timeout_allowed> </command> <!-- Active Response Config --> <active-response> <command>firewall-drop-22</command> <location>local</location> <rules_id>5720,5712</rules_id> <timeout>600</timeout> </active-response> <!-- Files to monitor (localfiles) --> <localfile> <log_format>syslog</log_format> <location>/var/log/messages</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/authlog</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/secure</location> </localfile> <localfile> <log_format>syslog</log_format> <location>/var/log/maillog</location> </localfile> </ossec_config> -----Message d'origine----- De : ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] De la part de dan (ddp) Envoyé : mardi 10 janvier 2012 15:39 À : ossec-list@googlegroups.com Objet : Re: [ossec-list] Re: Concern about the ossec-csyslogd daemon On Tue, Jan 10, 2012 at 9:16 AM, Bruno Plantier <bruno.plant...@lyra-network.com> wrote: > Hi > > It's ossec 2.4-1 coming with Centos 5.6 (Final) distribution. > That's pretty old. You should look into upgrading. > ossec-hids-server-2.4-1.el5.art > ossec-hids-2.4-1.el5.art > What repository did you get these from? > kernel version is 2.6.18-238.9.1.el5 x86_64 GNU/Linux > Configuration? > Regards, > > Bruno > > -----Message d'origine----- > De : ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] > De la part de dan (ddp) Envoyé : lundi 9 janvier 2012 16:21 À : > ossec-list@googlegroups.com Objet : Re: [ossec-list] Re: Concern about > the ossec-csyslogd daemon > > OSSEC version? Platform? Configuration? > > On Mon, Jan 9, 2012 at 8:18 AM, Bruno Plantier > <bruno.plant...@lyra-network.com> wrote: >> Hello folks. >> >> I'm facing the same problem with ossec-csyslogd daemon. >> Every time I start the process, it crashes after a few minutes. >> >> I've tried to get some gdb traces as asked and here is what I get: >> > > I don't know if it will make the backtrace useful, but did you try > "set follow-fork-mode child" in gdb before running? > >> Starting program: /var/ossec/bin/ossec-csyslogd >> warning: no loadable sections found in added symbol-file >> system-supplied DSO at 0x2aaaaaaab000 [New process 503] Program >> received signal SIGSEGV, Segmentation fault. >> [Switching to process 504] >> 0x000000000040219f in inet_addr () >> >> >> (gdb) backtrace >> #0 0x000000000040219f in inet_addr () >> #1 0x00000000004024bd in inet_addr () >> #2 0x000000000040289f in inet_addr () >> #3 0x00000031c081d994 in __libc_start_main () from /lib64/libc.so.6 >> #4 0x0000000000401d79 in inet_addr () >> #5 0x00007fffffffea38 in ?? () >> #6 0x0000000000000000 in ?? () >> >> The version installed is : >> Thanks, >> >> Regards >> - >> Bruno >> >> -----Message d'origine----- >> De : ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] >> De la part de blacklight Envoyé : mardi 7 juin 2011 23:43 À : >> ossec-list Objet : [ossec-list] Re: Concern about the ossec-csyslogd >> daemon >> >> If I were to put this daemon under gdb, I am concerned that I could >> be accumulating debugger data this for weeks before this daemon >> crashes > again. >> Hopefully, this daemon crash is a once in a blue moon event. On the >> other hand, once in a blue moon events are very hard to troubleshoot. >> If it's indeed a once in a blue moon event, I'll live with that. BTW, >> I haven't found anything in the /var/log/messages that even hint at a >> crash. And from reading the /var/ossec/logs/ossec.log at the time of >> the crash, you'd think that the OSSEC service was the picture of health. >> >> On Jun 7, 2:16 pm, Daniel Cid <daniel....@gmail.com> wrote: >>> It shouldn't segfault even during a package update... If any of you >>> can run it under gdb, it would be awesome :) >>> >>> thanks, >>> >>> On Tue, Jun 7, 2011 at 1:44 PM, Jefferson, Shawn >>> >>> >>> >>> >>> >>> >>> >>> <shawn.jeffer...@bcferries.com> wrote: >>> > I looked back through my logs and here is the alert: >>> >>> > ossec-alerts-06.log:Jun 6 10:12:55 bcfossec kernel: >>> > [501421.634671] >>> > ossec-csyslogd[3014]: segfault at 0 ip b7775821 sp bfc4ffbc error >>> > 4 in libc-2.11.1.so[b7702000+153000] >>> >>> > To the original poster: what OS are you running your OSSEC server on? >> I'm on Ubuntu 10.04.2 LTS. I wonder if the segfault was caused by >> some package being updated/upgraded? >>> >>> > -----Original Message----- >>> > From: ossec-list@googlegroups.com >>> > [mailto:ossec-list@googlegroups.com] On Behalf Of Daniel Cid >>> > Sent: Monday, June 06, 2011 6:48 PM >>> > To: ossec-list@googlegroups.com >>> > Subject: Re: [ossec-list] Concern about the ossec-csyslogd daemon >>> >>> > At least OSSEC is reporting it :) And yes, try to run it under gdb >>> > so we can see where it is crashing. Or try the latest snapshot to >>> > see if it works there. >>> >>> > Thanks, >>> >>> > On Mon, Jun 6, 2011 at 6:58 PM, dan (ddp) <ddp...@gmail.com> wrote: >>> >> Please try running it under gdb: >>> >>> >> gdb ossec-csyslogd >>> >>> >> (gdb) set follow-fork-mode child >>> >> (gdb) run >>> >>> >> On Mon, Jun 6, 2011 at 5:50 PM, Jefferson, Shawn >>> >> <shawn.jeffer...@bcferries.com> wrote: >>> >>> Hey, I had the same crash too! >>> >>> >>> -----Original Message----- >>> >>> From: ossec-list@googlegroups.com >>> >>> [mailto:ossec-list@googlegroups.com] On Behalf Of blacklight >>> >>> Sent: Monday, June 06, 2011 2:36 PM >>> >>> To: ossec-list >>> >>> Subject: [ossec-list] Concern about the ossec-csyslogd daemon >>> >>> >>> Hello Folks, >>> >>> >>> I have a concern about the csyslogd demon: >>> >>> >>> 2011 Jun 04 13:51:03 Rule Id: 151601 level: 7 >>> >>> Location: ossec-server->/var/log/messages Grouping of kernel >>> >>> error rules. >>> >>> Jun 4 13:51:02 ossec-server kernel: ossec-csyslogd[21507]: >>> >>> segfault at >>> >>> 0000000000000000 rip 0000003dd8479a30 rsp 00007fff23ba3a88 error >>> >>> 4 >>> >>> >>> The ossec-csyslogd daemon crashed over the weekend over a single >>> >>> segfault. I have no idea what caused this segfault. I am worried >>> >>> that this daemon is less than rock solid. >>> >>> >>> Regards, >> >