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,
>>
>
