Re: [ossec-list] Re: Ossec RPM installation - Local/Standalone mode

[Darin Perusich]

Christian,

As I mentioned in my comment in the ossec-hids package, that package
was only built for client/server operations, not a local only
installation. If you're feeling so inclined, you can branch the OBS
package and update it to additionally build and provide a -local
package. I've never had a need for the local installation so never
looked into how the build is performed.

--
Later,
Darin


On Thu, Nov 3, 2016 at 2:23 PM, Christian Bourque
 wrote:
> Hello Vibin,
>
> Did you ever find an answer to this problem? Because I'm facing the exact
> same issue on openSUSE Leap!
>
> Thanks,
>
> Christian
>
> On Tuesday, October 20, 2015 at 8:53:58 AM UTC-4, Vibin wrote:
>>
>> Hello Friends,
>>
>> I've got a simple question of how to install OSSEC using RPM in
>> local/standalone mode.
>>
>> I checked the latest available ossec-hids rpm but not all the required
>> files are there in the package.
>>
>> I meant to say mainly the ossec.conf sample file is missing, at least we
>> can create it using ossec-configure command.
>>
>> But the strange thing I do not see the daemons or the startup scripts in
>> the package.
>>
>> Do we have any other RPM named ossec-hids-local or something ?
>>
>> Eagerly awaiting your comments/response - thanks.
>>
>> --
>> Regards,
>>
>> Vibin
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: Integrity of the OSSEC agent

[Darin Perusich]

If you're primary concern is ensuring the integrity of a firewall, or
any system for that matter, perhaps the more simple approach of
limiting local access to the system and further limiting who elevated
privileges to install/patch/update the system, in addition to file
level integrity checking, would be a place to start to ensure a strong
security posture.

In addition to OSSEC, you can also use AIDE to check file integrity,
and you can layer FreeBSDs TrustedBSD MAC framework on top of that.
While auditd(8) is the Linux Audit Daemon, I'm sure there's an
equivalent in FreeBSD, which you can use to audit any file access, and
bring the system to a grinding halt w/the amount of logs generated,
and alert locally with SEC, and ship those logs off to
splunk/greylog2/syslog to ensure they're not fiddled with in the event
of local compromise. Since this is a FreeBSD I'd also run ZFS for the
file systems and use a snapper(8) like tool to create a file system
snapshot for roleback purposes after updates.

I'm not trying to be an ass, I'm simply pointing out that one needs to
have a layered and  methodical approach to securing ones systems and
there is no silver bullet. At some point you need to trust whoever is
managing said systems, the vendors you're getting your software from,
which is easier when they're based on open source code and you can
review the sources code.

--
Later,
Darin


On Tue, Apr 12, 2016 at 7:33 AM, dan (ddp) <ddp...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 2:57 PM, John Jenkins <jenkinsjohn...@gmail.com> 
> wrote:
>> Good point Dan.
>>
>> So here's a thought that maybe getting into the realms of silliness - how
>> about mounting (read-only) the entire filesystem of the "untrusted" machine
>> (via SSHFS) onto a a "trusted" machine, and run OSSEC locally on the trusted
>> machine?
>>
>
> Scale that out to 30,000 hosts of varying architectures, operating
> systems, and versions.
> At multiple locations with varying internet connection qualities.
>
>> On Monday, April 11, 2016 at 6:23:09 PM UTC+1, dan (ddpbsd) wrote:
>>>
>>> On Mon, Apr 11, 2016 at 1:07 PM, John Jenkins <jenkins...@gmail.com>
>>> wrote:
>>> > Yeah I did read up on samhain but I prefer the simplicity of OSSEC.
>>> >
>>> > For me, the main goal is to have integrity checking on a FreeBSD based
>>> > firewall/router.
>>> >
>>> > I'm thinking the best option is to use rkhunter and/or chkrootkit on the
>>> > router, and then use a remote OSSEC in agentless mode to verify file
>>> > integrity of the entire system - unless there is a simpler way to do
>>> > this :)
>>> >
>>>
>>> The agentless support will probably have the same problems, because I
>>> believe it uses the system's hashing programs.
>>>
>>> > On Monday, April 11, 2016 at 5:26:28 PM UTC+1, Darin Perusich wrote:
>>> >>
>>> >> One mechanism would be to recreated what samhain, another OSSEC type
>>> >> tool, does and add a compiled-in key that is used to verify the
>>> >> integrity of the binary. In the case where it was being packaged by an
>>> >> outside source, i.e. some distribution repo, you could add additional
>>> >> key material to verify the integrity for a sites deployment.
>>> >>
>>> >> http://www.la-samhna.de/samhain/manual/keypad.html
>>> >> --
>>> >> Later,
>>> >> Darin
>>> >>
>>> >>
>>> >> On Mon, Apr 11, 2016 at 10:47 AM, John Jenkins <jenkins...@gmail.com>
>>> >> wrote:
>>> >> > .. I forgot to mention that if anyone did go down this route of
>>> >> > static
>>> >> > linking it would have disadvantages as well such as not getting any
>>> >> > security
>>> >> > updates in the libraries until the next time you re-compile.
>>> >> >
>>> >> >
>>> >> > On Monday, April 11, 2016 at 3:15:36 PM UTC+1, John Jenkins wrote:
>>> >> >>
>>> >> >> Thanks for the info.
>>> >> >>
>>> >> >> I did think one way round this would be to verify the integrity of
>>> >> >> the
>>> >> >> ossec binaries before the check is run. This could be done remotely
>>> >> >> by
>>> >> >> comparing the hashes of some locally stashed known good binaries
>>> >> >> against
>>> >> >> what is on the agent machine.
>>> &g

Re: [ossec-list] Re: Integrity of the OSSEC agent

[Darin Perusich]

One mechanism would be to recreated what samhain, another OSSEC type
tool, does and add a compiled-in key that is used to verify the
integrity of the binary. In the case where it was being packaged by an
outside source, i.e. some distribution repo, you could add additional
key material to verify the integrity for a sites deployment.

http://www.la-samhna.de/samhain/manual/keypad.html
--
Later,
Darin


On Mon, Apr 11, 2016 at 10:47 AM, John Jenkins  wrote:
> .. I forgot to mention that if anyone did go down this route of static
> linking it would have disadvantages as well such as not getting any security
> updates in the libraries until the next time you re-compile.
>
>
> On Monday, April 11, 2016 at 3:15:36 PM UTC+1, John Jenkins wrote:
>>
>> Thanks for the info.
>>
>> I did think one way round this would be to verify the integrity of the
>> ossec binaries before the check is run. This could be done remotely by
>> comparing the hashes of some locally stashed known good binaries against
>> what is on the agent machine.
>>
>> However, just checking some of the binaries on FreeBSD from the
>> osssec-client pkg and a lot of them are dynamically linked for some reason.
>>
>> This would mean if you wanted to be absolutely sure you'd need to compare
>> the hashes of all the linked libraries as well. It starts to become a
>> headache.
>>
>> On Monday, April 11, 2016 at 9:58:54 AM UTC+1, John Jenkins wrote:
>>>
>>> Apologies if this has been answered before but I couldn't find any
>>> information about this. I'm also new to OSSEC.
>>>
>>> How does an agent based install of OSSEC detect or prevent the
>>> modification of the agent itself?
>>>
>>> For example, what's to stop someone replacing the agent with their own
>>> custom binary to do god-knows what?
>>>
>>> Are there any best practices to prevent this?
>>>
>>> I'm aware that an agentless install can help mitigate this however the
>>> sshd binary would possibly be a weak point there. Also you lose some
>>> of the nicer features of the agent based install.
>>>
>>> Also am I right in thinking the file integrity database is also stored
>>> locally and open to modification in a local only install?
>>>
>>> John.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] anyone interested in OSSEC RPMs?

[Darin Perusich]

--
Later,
Darin


On Wed, Mar 4, 2015 at 11:13 PM, autodidactic theoriginalg...@gmail.com wrote:


 On Wednesday, March 4, 2015 at 3:35:08 PM UTC-8, Darin Perusich wrote:


 I just enabled building that package on CentOS-6, being a repo
 maintainer has it's privileges;-),  but it's failing due to
 unresolvable packages, update-alternatives and apache2-devel which
 aren't available on the OS. I know apache2 is httpd-devel but I'm not
 sure about update-alternatives. Either way they it should be trivial
 to fix those.


 I've never had to manage a RPM/yum repo before. What tools do you use to
 maintain/manage it?

createrepo.

 I don't know what update-alternatives does on OpenSUSE, but the
 'alternatives' command is part of chkconfig package in EL6.

update-alternatives manages links to determine default commands, and
is probably the same as alternatives on RH.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] anyone interested in OSSEC RPMs?

[Darin Perusich]

On Wed, Mar 4, 2015 at 11:46 AM, Cliftyman clifty...@gmail.com wrote:
 I know quite a bit about building msi's, but I'm a noob when it comes to RPM
 packaging

 Can you put dependencies in your RPM package and install them in a custom
 location?

No. Any dependencies needs to be available to the package manager,
zypper or yum, from a package repository available on the system.

 We haven't been able to install OSSEC on some of our older systems running
 redhat because the versions of inotify, gcc, etc. required by the installer
 would conflict with previously installed versions of those packages and we
 were afraid if we changed the versions it would break some custom apps we
 had on the system.

 If we could install from an RPM that had inotify, gcc, etc. built in that
 installed in a custom location we wouldn't disturb the pre-existing versions
 and OSSEC would be able to install and run properly.  Is that a possibility?

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] anyone interested in OSSEC RPMs?

[Darin Perusich]

On Wed, Mar 4, 2015 at 2:50 PM, The O.G. theoriginalg...@gmail.com wrote:


 On Wed, Mar 4, 2015 at 5:43 AM, Darin Perusich da...@darins.net wrote:

 I package and maintain rpm packages for openSUSE/SLES which are
 available in the openSUSE Build System, see the link below for the
 project/package. While OBS supports all linux distributions I
 currently do have have RHEL distro's enabled since I use the Atomic
 repos for the few RHEL systems I manage. Updating the .spec to support
 RHEL sysetms should be fairly straight forward if you're interested in
 taking a stab at it.

 I mostly follow what install.sh does but I go beyond what it does
 since I wanted packages for the various SQL backends, made OSSEC
 install directory LSB complient, /var/lib/ossec, and patch it to NOT
 use the supplied zlib but rather zlib which is distributed w/the OS.


 https://build.opensuse.org/package/show/server:monitoring/ossec-hids
 --
 Later,
 Darin


 Thanks Darin! I hope you don't mind, but I'd like to compare what you've
 done in your spec file and compare to mine to see if I can learn a better
 way to do some things I'm doing.

 The way I'm building the RPM for EL6 platform is similar to what you're
 doing. I have subpackages for the mysql and postgresql support. That was the
 main reason I didn't like the Atomicorp version, they disabled postgresql
 support and applied a patch that used MySQL specific SQL. I also created a
 subpackage meant for 'local' or standalone installations and not just the
 agent/server setup. I'm also now considering separating the signatures and
 decoders/rules into a subpackage so that they can be updated
 independently...


I just enabled building that package on CentOS-6, being a repo
maintainer has it's privileges;-),  but it's failing due to
unresolvable packages, update-alternatives and apache2-devel which
aren't available on the OS. I know apache2 is httpd-devel but I'm not
sure about update-alternatives. Either way they it should be trivial
to fix those.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] anyone interested in OSSEC RPMs?

[Darin Perusich]

I package and maintain rpm packages for openSUSE/SLES which are
available in the openSUSE Build System, see the link below for the
project/package. While OBS supports all linux distributions I
currently do have have RHEL distro's enabled since I use the Atomic
repos for the few RHEL systems I manage. Updating the .spec to support
RHEL sysetms should be fairly straight forward if you're interested in
taking a stab at it.

I mostly follow what install.sh does but I go beyond what it does
since I wanted packages for the various SQL backends, made OSSEC
install directory LSB complient, /var/lib/ossec, and patch it to NOT
use the supplied zlib but rather zlib which is distributed w/the OS.


https://build.opensuse.org/package/show/server:monitoring/ossec-hids
--
Later,
Darin


On Tue, Mar 3, 2015 at 7:03 PM, autodidactic theoriginalg...@gmail.com wrote:
 Hello OSSEC users:

 I have been working on building RPM packages for OSSEC. I know Atomicorp
 already has a set of RPMs for OSSEC, but after looking at their spec file, I
 realized that they make extensive changes (like disabing pgsql and standard
 SQL support in favor of MySQL) and I wanted some RPMs that were closer to
 the original OSSEC project. With that philosophy in mind, I've been working
 on an RPM spec file meant to work with EL6 platforms that closely follows
 the install.sh script in the way OSSEC is setup; with some deviations, but
 fully compatible with the original intent of the OSSEC project. I also plan
 to build for EL7 too, but one step at at time.

 A few friends and myself are currently testing the packages out, but if
 anyone else would like to try them out and give me feedback, I'm more than
 happy to share.

 Also, is this something that the broader ossec user community would find
 useful? Or, are most content with the Atomicorp RPMs? I'm wondering if the
 RPM packaging I'm doing would be worth while to contribute back to the
 project or no one cares?

 Please let me know... thanks!

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] How to install ossec in a custom directory

[Darin Perusich]

These are relative to the basedir of unpacked source, adjust to taste ;-)

# fix for FHS
sed -i 's%/var/ossec%/var/lib/ossec%' src/LOCATION
sed -i 's%/var/ossec%/var/lib/ossec%' src/headers/defs.h

# don't forget the init script and init config
sed -i 's%/var/ossec%/var/lib/ossec%' src/init/ossec-hids-suse.init
sed -i 's%/var/ossec%/var/lib/ossec%' /etc/ossec-init.conf

--
Later,
Darin


On Thu, Dec 11, 2014 at 10:52 AM, christophe.egron
christophe.eg...@ca-silca.fr wrote:
 Hi All,

 I meet difficulties to install ossec agent in a directory different of
 /var/ossec.
 During the installation I indicated a new target directory /mycustomdir.

 I find it in :~/ossec-hids-2.8.1/src/Config.OS

 CEXTRA= -DDEFAULTDIR=\/mycustomdir\ -DCLIENT

 However the makefile of generation of the binary does not seem to use this
 parameter and they always make a reference in /var/ossec
 i.e. error log message :  ossec-agentd(1402): ERROR: Authentication key file
 '/var/ossec/etc/client.keys' not found.

 To solve this problem I have to make a symbolic link /var/ossec ==
 /mycustomdir.
 This symbolic link works for OSSEC on Solaris and AIX but not on Linux
 RedHat.

 Did I forget a parameter of configuration ?

 Thanks

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] ossec-hids-2.8.1 openSUSE/SLES packages

[Darin Perusich]

Hello All,

I wanted to announce the availability openSUSE and SLE
ossec-hids-2.8.1 packages from the openSUSE Build Service
server:monitoring repository. If you have any question ping me off
list or if you're interested in contributing see the Project URL
below.

Packages are available for the following versions:
openSUSE: 12.2, 12.3, 13.1, 13.2, Tumbleweed
SLE:  10-SP4, 11-SP2, 11-SP3, 12

Top Level Repository URL:
http://download.opensuse.org/repositories/server:/monitoring/

Project URL:
https://build.opensuse.org/package/show/server:monitoring/ossec-hids

--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Puppet module with audit rule configuration

[Darin Perusich]

Hi Andrew,

I really thought I'd published my ossec Puppet module but it's not in
the forge, I'll need to dig into this later, however it's on github if
you want to take a look.

It sounds like you've put in a bit of work but, FWIW, my module will
cover nearly all aspects of ossec's client and server configurations
from passing around the client keys between client and server, can set
all configuration options, alert definitions, syscheck options,
localfile opts, etc, etc.

It supports SUSE and Redhat but adding support for other systems would
be trivial, all you need it an ossec package to install.

https://github.com/deadpoint/ossec
--
Later,
Darin


On Thu, Oct 9, 2014 at 7:05 PM, Andrew Wood mongolsamu...@gmail.com wrote:
 I'm working on a puppet module for managing ossec. I'm pretty new to this
 software but I've spent a good part of the last two weeks digging through it
 and I'm starting to understand it. However, I have some questions I can't
 seem to get answers to on the wiki, so I'm hoping to find some answers here.
 I'm also interested in any feedback from more experienced users about the
 design of this puppet module.
 I started with this module: https://forge.puppetlabs.com/jgazeley/ossec
 It doesn't seem to have any support for managing agent files however,
 besides what's already built into ossec. I need to be able to support a
 pretty diverse infrastructure across multiple platforms, so I need to be
 able to enable and disable system audit rules (among other things) on a
 per-host and per-role basis.

 My current question is, can someone tell me what /etc/shared/merged.mg is,
 how it's generated, and what it's used for?

 I may find further questions, which I'll add to this thread. I'm also
 interested in hearing from anyone who would be interested in using a puppet
 module like this, or who has suggestions for the best approach to mass
 deployment and configuration of ossec infrastructures.

 For anyone who's interested in this project, here's a list of what my needs
 are (and what my module is intended to support):
 - Inheritable puppet resources to add or remove items to/from the rootcheck
 and system audit rule files (e.g. remove samba audit from servers with file
 server role, add additional ssh sanity checks to root bastions, etc.)
 - Automatic, intelligent agent registration to ossec server
 - Automatic updating of rootcheck rules (probably by pulling the latest
 release tarball from source, pulling out the files in question, and much
 sed/diff)
 - Centrally generated and deployed audit rule files using puppet and ossec
 master

 Things I don't intend to work with:
 - Log monitoring (I already have logstash/kibana and nagios, so this isn't a
 high-value feature for me)
 - Active response (I have other solutions in place for some of this. I would
 like to play with it eventually, but it's not a priority for me yet)

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] SLES

[Darin Perusich]

It's on my hit list, but not very high up at the moment. Feel free to
branch the package update it yourself;-) I'm the repo/package
maintainer and will accept updates as long as they're clean.

https://build.opensuse.org/package/show/server:monitoring/ossec-hids
--
Later,
Darin


On Mon, Sep 15, 2014 at 1:53 PM, Jason Graham
jason.michael.gra...@gmail.com wrote:
 Has anyone created a 2.8.1 client install RPM for SLES yet? Specifically
 SLES 11sp2 32 bit.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] logging all, but not commands?

[Darin Perusich]

Seriously? OSSEC is FAR from a replacement for centralized syslog
server, and to think it is folly IMO. Can OSSEC guarantee it will
receive all incoming logs? Can OSSEC store those logs in multiple
format, text, sql database? How does OSSEC handle the archival of said
logs? I could go on and on.

Syslog can be used to centralize your httpd logs by adding 2 lines for
your apache config. I push this to 100+ apache web servers and my
syslog server happily takes them all, archives them in a structure of
$year/$month/$day/$facility/$facility.log, and stuff them into a SQL
database simultaneously without loosing a message, regardless of how
much it's receiving.

/etc/apache2/conf.d/syslog.conf
ErrorLog syslog:local6
CustomLog |/bin/logger -t httpd2-prefork -i -p local7.info vhost_combined

--
Later,
Darin


On Wed, Jun 18, 2014 at 10:22 AM, Janelle janellenicol...@gmail.com wrote:
 I think people forget that when you put OSSEC on a server, it really does
 not make sense to run a syslog-type daemon sending data to a central log
 host at the same time OSSEC is doing it. Wastes bandwidth and since OSSEC
 can actually deliver more than just standard syslogs - it is much more
 useful. For example, syslog is not typically going to centralize your HTTPD
 logging and OSSEC can. It makes sense to add a little more flexibility in
 the output of the logall feature..



 On Wednesday, June 18, 2014 5:06:31 AM UTC-7, James M. Pulver wrote:

 Maybe I’m crazy, but I think OSSEC is like a log daemon +…

 It’s cross platform, it includes encryption, it has built in filtering and
 can do active response. Why would it make sense to duplicate log shipping if
 you need it to do the security stuff? I.e. OSSEC ought to be a good log
 aggregator to serve it’s primary security goal IMO.



 --

 James Pulver

 CLASSE Computer Group

 Cornell University



 From: ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] On
 Behalf Of Jeremy Rossi
 Sent: Wednesday, June 18, 2014 7:50 AM
 To: ossec...@googlegroups.com
 Subject: Re: [ossec-list] logging all, but not commands?



 We would Very much welcome it. Some suggestions, but nothing more for the
 branch :).



 Agent - master:



 json and use first char of { to pick new code path for processing the
 messages. This will allow master to work with legacy agents and new agents
 cleanly.



 Master-agent:



 This is harder but something I am working now as part of the work on
 actice response. Reasons it is harder is that unless we change the method if
 encryption/communication at the same time we have no concept of agent
 version so no idea what formats of messages are acceptable.  I still don't
 know the best method for dealing with this and love ideas.



 Logall:



 Side note this log all feature comes up all the time and is confusing I
 think and maybe something we should solve better.  But I am worried about
 turning ossec from security to a log daemon as other tools have solved that
 problem.










 On Jun 18, 2014, at 12:30 AM, Janelle janelle...@gmail.com wrote:

 I guess I need to start a new brach and work on a way to do this :-)

 On Tuesday, June 17, 2014 2:57:34 PM UTC-7, Michael Starks wrote:

 On 2014-06-17 16:31, Janelle wrote:
  Trying to send archives to a syslog server for archival, and it
  can't handle all the extraneous code.

 Ah, yes. I have done this as well and had this problem with keepalives
 and such. Another issue is that the ossec log format isn't syslog. It
 looks like syslog but it's not. Then there's this:

 Agentless:
  mmm dd hh:mm:ss (script_name) username-agentless ossec: agentless:
 Change detected

 Command output:
  mmm dd hh:mm:ss agentname-command

 Syscheck:
  mmm dd hh:mm:ss (agent_name) agent_ip-syscheck

 Windows:
  mmm dd hh:mm:ss (agent_name) agent_ip-log_name log_name_again

 Agent IP could be the IP or it could be any.

 What I wish was that:

 1. This was syslog formatted (or something else nice like JSON)
 2. In the syslog header, the hostname could be either the agent name or
 the actual hostname
 3. Newlines were removed or otherwise handled gracefully

 And/or that raw logs could be sent over to a syslog server like alerts
 are now, in addition to being analyzed. You could even strip off the
 ossec header at that point and the syslog server wouldn't know the
 difference.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

 --

 ---
 You received this message because you are subscribed to the Google 

Re: [ossec-list] Red Hat 7.0 and OSSEC

[Darin Perusich]

The ossec package I maintain for OpenSUSE has full systemd support and
it works without issue, it is after all a drop in replacement for
sysvinit and maintains full backwards comparability.

https://build.opensuse.org/package/show/server:monitoring/ossec-hids
--
Later,
Darin


On Tue, Jun 3, 2014 at 8:10 AM, Jeremy Rossi jer...@jeremyrossi.com wrote:
 * dan (ddp) ddp...@gmail.com [2014-06-03 08:01:37 -0400]:


 On Tue, Jun 3, 2014 at 7:38 AM, Aaron Hunter aaron.hunt...@gmail.com
 wrote:

 I wanted to know if the introduction of systemd and journald cause any
 problems for OSSEC. I am preparing to test RHEL 7.0 and was hoping to
 hear
 from others about any issues they may have encountered.


 As long as the system still writes logs in the standard syslog
 formats, there shouldn't be any issues*.


 Reading the Rhel beta docs things will be fine for the most part ;) some
 tuning will be needed like everything that changes, but overall and for
 most things it will just work.
 OSSEC does not talk directly to systemd or its children processes, but
 if someone would like to it add we always welcome patchs/pull requests.
 --

 --- You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC Suse Patch

[Darin Perusich]

There's a mailing list thread regarding that patch with all the gory
details. This patch has been applied upstream, commit
9152f88ad1af49f1ad78bcaa4751e696254f4a26, so whenever I get around to
packaging 2.8 it will be removed.

https://www.mail-archive.com/ossec-list@googlegroups.com/msg18930.html
--
Later,
Darin


On Tue, Jun 3, 2014 at 9:59 AM, Jeremy Rossi jer...@jeremyrossi.com wrote:
 The ossec package I maintain for OpenSUSE has full systemd support and
 it works without issue, it is after all a drop in replacement for
 sysvinit and maintains full backwards comparability.

 https://build.opensuse.org/package/show/server:monitoring/ossec-hids


 This is great.  I did not know about this.  I do have some questions if
 you don't mind?

 https://build.opensuse.org/package/view_file/server:monitoring/ossec-hids/ossec-remoted.patch?expand=1
 What is this patch needed?  The logic does not change (may a w
 bit of an optimizaion, but i don't think much).
 Have you been following along with 2.8?
 Thank you, -Jeremy Rossi

 --
 Later,
 Darin


 --

 --- You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Red Hat 7.0 and OSSEC

[Darin Perusich]

journald and syslog, whichever your flavor, coexist without issue so I
wouldn't be too concerned about it.
--
Later,
Darin


On Tue, Jun 3, 2014 at 12:30 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Jun 3, 2014 at 12:00 PM, Aaron Hunter aaron.hunt...@gmail.com wrote:
 It's journald that concerns me the most. journald replaces (r)syslog
 entirely. It does not provide syslog format log files nor even text based
 log files. Instead, as I understand it, journald uses only a binary log
 format. This means that the text format based OSSEC rules will no longer
 work on a pure journald system. OSSEC would have to talk directly to
 journald (through D-BUS?) and its rules would have to be re-written for the
 new binary format. That sounds like a significant undertaking which is why I
 raised this question. journald is a wholesale replacement of the current
 syslog based logging system with an entirely different paradigm.

 I think syslog can still be installed and connected to journald as a
 work-around but I'm not certain.


 OSSEC does not have any support for journald. I'd skip it, or start
 working on adding support. But preferably skip journald.

 --Aaron




 On Tuesday, June 3, 2014 9:16:19 AM UTC-4, Darin Perusich wrote:

 The ossec package I maintain for OpenSUSE has full systemd support and
 it works without issue, it is after all a drop in replacement for
 sysvinit and maintains full backwards comparability.

 https://build.opensuse.org/package/show/server:monitoring/ossec-hids
 --
 Later,
 Darin


 On Tue, Jun 3, 2014 at 8:10 AM, Jeremy Rossi jer...@jeremyrossi.com
 wrote:
  * dan (ddp) ddp...@gmail.com [2014-06-03 08:01:37 -0400]:
 
 
  On Tue, Jun 3, 2014 at 7:38 AM, Aaron Hunter aaron@gmail.com
  wrote:
 
  I wanted to know if the introduction of systemd and journald cause any
  problems for OSSEC. I am preparing to test RHEL 7.0 and was hoping to
  hear
  from others about any issues they may have encountered.
 
 
  As long as the system still writes logs in the standard syslog
  formats, there shouldn't be any issues*.
 
 
  Reading the Rhel beta docs things will be fine for the most part ;) some
  tuning will be needed like everything that changes, but overall and for
  most things it will just work.
  OSSEC does not talk directly to systemd or its children processes, but
  if someone would like to it add we always welcome patchs/pull requests.
  --
 
  --- You received this message because you are subscribed to the Google
  Groups ossec-list group.
  To unsubscribe from this group and stop receiving emails from it, send
  an
  email to ossec-list+...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

 --

 ---
 You received this message because you are subscribed to the Google Groups 
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: Send Alert when a process CPU usage is more than 90%

[Darin Perusich]

Use a really  monitoring solution like Nagios
--
Later,
Darin


On Fri, May 16, 2014 at 3:36 PM, Ashok ashokkumari...@gmail.com wrote:
 Is there any other way?


 On Saturday, May 17, 2014 12:49:04 AM UTC+5:30, Ashok wrote:

 Is it possible to send alert when a process uses more cpu like 80% or
 above.

 or Can I monitor a particular process and report if its cpu usage
 increases more than 80%

 How can I do it?

 I tried it like

 localfile
 log_formatcommand/log_format
 commanddf -h/command
 /localfile

 rule id=”100101″ level=”7″
 if_sid530/if_sid
 matchossec: output: ‘top/match
 regex100/regex
 descriptionProcess reached 100% CPU usage/description
 /rule

 it doesn't work


 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] how do you know certainly server get the logs from agent. because it uses UDP port 1514

[Darin Perusich]

On Tue, May 13, 2014 at 10:51 AM, Michael Starks
ossec-l...@michaelstarks.com wrote:
 On 2014-05-13 9:44, Darin Perusich wrote:

 If you want reliable syslog retrieval I recommend you abandon using
 OSSEC and use rsyslog with the RELP module enabled. Then if you want
 to do post processing your logs looking for events use a tool 'sec',
 simple event correlator, or splunk, or elastisearch, etc, etc.

 http://www.rsyslog.com/doc/imrelp.html
 http://simple-evcorr.sourceforge.net/


 RELP looks interesting. Or use a TCP-based and maybe encrypted syslog daemon
 for the log delivery and analyze the logs on the manager with OSSEC, and use
 the agents for file integrity monitoring and rootkit detection. SEC is nice
 but doesn't have the analysis capabilities that OSSEC does.

TCP base syslog still doesn't guarantee your message will be delivered
to the loghost. Say you have a chatty host sending whatever to you
loghost and the loghost crashes and has a significant amount of
downtime. After whatever the time-out value for your tcp enabled log
client is reached you're going to lose those logs, with RELP they'll
be stored on the client and transmitted whenever the loghost comes
back online so nothing gets lost.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC Cloud Rollout

[Darin Perusich]

If you're using Puppet to manage the configuration of your systems the
ossec puppet module I wrote does just what you're looking for.

https://github.com/deadpoint/ossec
--
Later,
Darin


On Sun, Apr 6, 2014 at 1:14 PM, Joshua Garnett josh.garn...@gmail.com wrote:
 All,

 I'm looking for best practices for rolling out OSSEC to cloud based
 environments such as AWS.  One of the biggest problems I'd like to address
 is developer environments that may be constantly going up and down.  Ideally
 I'd be able to put together a prebaked AMI that has an OSSEC agent already
 installed and preconfigured to talk to an OSSEC server.

 One idea I had was to setup a Serf cluster, http://www.serfdom.io/, for
 OSSEC, which would use a shared secret and monitor join/leave events to
 correctly populate the client.keys.

 --Josh

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC Cloud Rollout

[Darin Perusich]

the client.keys file is managed by puppet which uses Puppet
storeconfigs, i.e. PuppetDB, to pass them around. Basically the client
comes up creates it's key and sends it off to the puppet server which
in turn sends it to the ossec server. It's entirely hands off and
requires no intervention.
--
Later,
Darin


On Mon, Apr 7, 2014 at 11:36 AM, Joshua Garnett josh.garn...@gmail.com wrote:
 Kai,

 I would argue yes.  Unless your development environment is 100% isolated
 from production it could be used to compromise other systems.  That said,
 there is auto-scaling to keep in mind also.  You may spin up 50 extra web
 servers during peak traffic on a daily basis.

 Darin, how do you get the keys on the server without explicitly adding them
 to your server manifest?

 Here is the design I've roughed out using Serf:

 General Notes

 OSSEC requires a shared secret to be installed on both the client and server

 /var/ossec/etc/client.keys format:   agent id agent name ip range
 cipher

 cipher is 2 md5sum concatenated

 Build base AMI, which includes OSSEC Agent  Serf, teams should use this
 base AMI

 Script this with packer, provide interface for getting latest AMI

 Most likely run OSSEC servers with an Auto Scale Group with the settings
 1/1/1

 Agent Instance Start Workflow

 On instance start, using AWS tags, look for a running OSSEC server

 If no OSSEC server found, look for a running agent
 If no Agent found, error and wait X minutes to retry

 Instance joins serf cluster
 OSSEC server sees member-join event

 Generates client.keys entry
 Sends user event INSTALL_CLIENT_KEYS to agent
 Agent installs client.keys and restarts service

 OSSEC server sees member-leave event

 Removes server from client.keys

 Server Instance Start Workflow

 On instance start, using AWS tags, look for a running Agent

 If found, instance joins serf cluster
 If not found, instance starts serf cluster

 Running agents see member-join event, member is the new OSSEC Server

 Stops OSSEC
 Deletes client.keys
 Agent sends user event REQUEST_CLIENT_KEY to OSSEC server
 OSSEC server generates key, sends user event INSTALL_CLIENT_KEYS to agent
 Agent installs client.keys and starts service

 --Josh



 On Mon, Apr 7, 2014 at 9:07 AM, Darin Perusich da...@darins.net wrote:

 If you're using Puppet to manage the configuration of your systems the
 ossec puppet module I wrote does just what you're looking for.

 https://github.com/deadpoint/ossec
 --
 Later,
 Darin


 On Sun, Apr 6, 2014 at 1:14 PM, Joshua Garnett josh.garn...@gmail.com
 wrote:
  All,
 
  I'm looking for best practices for rolling out OSSEC to cloud based
  environments such as AWS.  One of the biggest problems I'd like to
  address
  is developer environments that may be constantly going up and down.
  Ideally
  I'd be able to put together a prebaked AMI that has an OSSEC agent
  already
  installed and preconfigured to talk to an OSSEC server.
 
  One idea I had was to setup a Serf cluster, http://www.serfdom.io/, for
  OSSEC, which would use a shared secret and monitor join/leave events to
  correctly populate the client.keys.
 
  --Josh
 
  --
 
  ---
  You received this message because you are subscribed to the Google
  Groups
  ossec-list group.
  To unsubscribe from this group and stop receiving emails from it, send
  an
  email to ossec-list+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] ossec with nagios

[Darin Perusich]

Why not do a process check for remoted?
On Mar 13, 2014 4:41 PM, Gaurav Rajput gx1...@gmail.com wrote:

 Hi,

 I have an ossec-server along with a nagios-server. All i want, is to
 monitor the ossec-remoted from nagios. But the main problem is that,
 ossec-remoted uses UDP protocol, so it never echoes back. So how would I
 ensure that my ossec-server is up and running (with or without using
 nagios) ?

 Also, i tried nagios-plugin check_udp, but, while tackling the UDP, we
 must pass the send string and expect string as parameters to this
 command. I couldn't find any way to do this. I tried netcat too but its
 not giving me the desired result (as it was echoing the same thing for all
 UDP ports [0-65535]). So is there any specific string that i can send and
 receive some expected string ? ( I don't have enough time to open the code
 right now ).

 Thanks.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC HIDS client 2.7 not installing via RPM on SUSE 11

[Darin Perusich]

I've packaged ossec for suse and the rpm packages are available from the
server:monitoring repo. Grab them for your release at the below link.

http://software.opensuse.org/package/ossec-hids
On Mar 11, 2014 3:33 PM, Cliftyman clifty...@gmail.com wrote:

 I'm trying to install ossec-hids-client-2.7-20.el5.art.x86-64 from
 atomicorp.  I was able to install the server RPM just fine with rpm -ivh
 rpm.

 When I try to install the client I received the following
 error: failed dependencies
 librypto.so.6()(64bit)
 libssl.so.6()(64bit)

 I've installed the openssl-0.9.8j-0.26.1.x86-64.rpm and when I run
 openssl version the system reports that openssl is installed.

 I'm assuming the ossec hids rpm is looking to a specific folder path for
 openssl and not finding it.  I'm not sure what I need to install or modify
 to get the ossec client installed.  I've tried to compile from source but
 its missing cpp, gcc, etc. and when I try to install all the dependencies
 to compile the list gets longer and longer.

 This server does not have internet access so I can't install using yum

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Idea Proposal: Manager supported on Modern Unixes only

[Darin Perusich]

I would think that as long as the code is POSIX compliant it would
build on any system following that standard, which is nearly all
modern UNIX system.
--
Later,
Darin


On Wed, Feb 19, 2014 at 11:03 AM, Jeremy Rossi jer...@jeremyrossi.com wrote:
 Making sure that all code in OSSEC compiles and runs on all Unixes is
 hard, and limiting.  I would like to support the Manager only on Modern
 Unixes:

 - Recent versions of BSD's
 - Recent versions of Darwin
 - Recent versions of Linux

 This proposal is only for the manager.  The agent should run on anything
 that we can get it to compile on.

 I would like to make this change so that we are able to bring in more
 libraries, tools, and tricks from Modern Unixes to the OSSEC manager.

 I just want to start the conversation on the Mailing list before I start
 writing anything up and get peoples feedback.

 Thank you,




 --

 --- You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] Idea Proposal: Manager supported on Modern Unixes only

[Darin Perusich]

Also, perhaps moving to a build system like GNU autotools or CMake and
away from the existing cludgy make system would make building ossec
more portable. As someone who builds and maintains lots of packages,
generating packages for ossec was not straight forward and took a lot
of time to get right, see my RPM .spec from the OpenSUSE Build Service
linked below.

When using a build system, I reference autotools since i use it the
most, it will automatically find dependencies based on the development
libraries available when running configure and build accordingly. Or
say you want to set an alternate ossec basedir other than /var/ossec,
currently you need to modify src/LOCATION, src/headers/defs.h, and sed
a bunch of files. If using a build system one could simply run
configure --basedir=/whatever/ossec and be on their way.

https://build.opensuse.org/package/view_file/home:deadpoint/ossec-hids/ossec-hids.spec?expand=1
--
Later,
Darin


On Wed, Feb 19, 2014 at 11:03 AM, Jeremy Rossi jer...@jeremyrossi.com wrote:
 Making sure that all code in OSSEC compiles and runs on all Unixes is
 hard, and limiting.  I would like to support the Manager only on Modern
 Unixes:

 - Recent versions of BSD's
 - Recent versions of Darwin
 - Recent versions of Linux

 This proposal is only for the manager.  The agent should run on anything
 that we can get it to compile on.

 I would like to make this change so that we are able to bring in more
 libraries, tools, and tricks from Modern Unixes to the OSSEC manager.

 I just want to start the conversation on the Mailing list before I start
 writing anything up and get peoples feedback.

 Thank you,




 --

 --- You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] Idea Proposal: Manager supported on Modern Unixes only

[Darin Perusich]

On Wed, Feb 19, 2014 at 11:56 AM, dan (ddp) ddp...@gmail.com wrote:
 On Wed, Feb 19, 2014 at 11:54 AM, Darin Perusich da...@darins.net wrote:
 Also, perhaps moving to a build system like GNU autotools or CMake and
 away from the existing cludgy make system would make building ossec
 more portable. As someone who builds and maintains lots of packages,
 generating packages for ossec was not straight forward and took a lot
 of time to get right, see my RPM .spec from the OpenSUSE Build Service
 linked below.

 When using a build system, I reference autotools since i use it the
 most, it will automatically find dependencies based on the development
 libraries available when running configure and build accordingly. Or
 say you want to set an alternate ossec basedir other than /var/ossec,
 currently you need to modify src/LOCATION, src/headers/defs.h, and sed
 a bunch of files. If using a build system one could simply run
 configure --basedir=/whatever/ossec and be on their way.


 I think autotools are the wrong direction, but that's fairly off topic.

I have no preference, its simply widely used and makes for easy examples ;-)

 https://build.opensuse.org/package/view_file/home:deadpoint/ossec-hids/ossec-hids.spec?expand=1
 --
 Later,
 Darin


 On Wed, Feb 19, 2014 at 11:03 AM, Jeremy Rossi jer...@jeremyrossi.com 
 wrote:
 Making sure that all code in OSSEC compiles and runs on all Unixes is
 hard, and limiting.  I would like to support the Manager only on Modern
 Unixes:

 - Recent versions of BSD's
 - Recent versions of Darwin
 - Recent versions of Linux

 This proposal is only for the manager.  The agent should run on anything
 that we can get it to compile on.

 I would like to make this change so that we are able to bring in more
 libraries, tools, and tricks from Modern Unixes to the OSSEC manager.

 I just want to start the conversation on the Mailing list before I start
 writing anything up and get peoples feedback.

 Thank you,




 --

 --- You received this message because you are subscribed to the Google
 Groups ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

 --

 ---
 You received this message because you are subscribed to the Google Groups 
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

 --

 ---
 You received this message because you are subscribed to the Google Groups 
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] Re: OSSEC HA settings

[Darin Perusich]

On Sun, Feb 16, 2014 at 2:27 PM, Joshua Garnett josh.garn...@gmail.com wrote:
 My plan is to look at potentially using haproxy to help facilitate the
 fallover with some better mechanism to keep the data in sync.

You may find csync2 is ideal for sync'ing data across clusters

http://oss.linbit.com/csync2/

--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ossec-list] ossec puppet module...looking for testers

[Darin Perusich]

Hello List,

I'm in the process of a large ossec role and since I'm an avid Puppet
user, and not being satisfied with the existing modules, I've written
my own and figured I'd share and hopefully get some feedback.

The module is fairly complete and manages all aspects of an ossec
server or client/agent configuration. It requires puppet storeconfigs
be enabled as it automatically registers the clients with the server
and generates keys and populate client.keys.

It also expects the ossec package be available from an installation
source available to the OS packaging system. So on SuSE zypper in
ossec-hids ossec-hids-server or RHEL yum install ossec-hids
ossec-hids-client will install the packages. Please do not submit
patches which install ossec outside of the native packaging systems,
they'll be denied.

I wont' get into all the options, see the module README for that. The
readme does need some work but it'll get people started and I'll be
updating it as time allows.

I haven't published the module to Puppet Forge yet so it can be gotten
from the github repo, link below.

Enjoy!

https://github.com/deadpoint/ossec

--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

RE: [ossec-list] ossec puppet module...looking for testers

[Darin Perusich]

I don't have any windows systems but feel free to add support for them.
On Feb 6, 2014 5:25 PM, James M. Pulver jmp...@cornell.edu wrote:

 I'm going to take a look, but I also need to do this on Windows, and it
 looks like this omits Windows completely for the agent...

 --
 James Pulver
 CLASSE Computer Group
 Cornell University


 -Original Message-
 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
 Behalf Of Darin Perusich
 Sent: Thursday, February 06, 2014 3:22 PM
 To: ossec-list@googlegroups.com
 Subject: [ossec-list] ossec puppet module...looking for testers

 Hello List,

 I'm in the process of a large ossec role and since I'm an avid Puppet
 user, and not being satisfied with the existing modules, I've written my
 own and figured I'd share and hopefully get some feedback.

 The module is fairly complete and manages all aspects of an ossec server
 or client/agent configuration. It requires puppet storeconfigs be enabled
 as it automatically registers the clients with the server and generates
 keys and populate client.keys.

 It also expects the ossec package be available from an installation source
 available to the OS packaging system. So on SuSE zypper in ossec-hids
 ossec-hids-server or RHEL yum install ossec-hids ossec-hids-client will
 install the packages. Please do not submit patches which install ossec
 outside of the native packaging systems, they'll be denied.

 I wont' get into all the options, see the module README for that. The
 readme does need some work but it'll get people started and I'll be
 updating it as time allows.

 I haven't published the module to Puppet Forge yet so it can be gotten
 from the github repo, link below.

 Enjoy!

 https://github.com/deadpoint/ossec

 --
 Later,
 Darin

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] OSSEC and Nagios integration

[Darin Perusich]

Have you asked Google?
--
Later,
Darin


On Wed, Feb 5, 2014 at 6:47 AM, Michiel van Es vanesmich...@gmail.com wrote:
 Hello,

 I was wondering if someone already used the OSSEC and Nagios to generate
 alerts ?
 I have the following idea in my head: alert of level 11+ will be seen by a
 monitor/swatch script tailing the /var/ossec/logs/alerts/alerts.log logfile
 and generates an alert/trigger and sends it to Nagios.
 Nagios generates an alert, shows in on a dashboard.
 Engineer fixes the issue or filters the alert (in case of a false positive)
 and OK/ACK the alert in Nagios.

 Or has someone else a better idea how to integrate these 2 together?

 All tips are more then welcome!

 Michiel

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] OSSEC Compatibility Issue

[Darin Perusich]

Did you installed ossec from source or from a package on your openSUSE
system? I'm in the process is packaging and deploying ossec to a large
number of openSUSE  systems, 12.1, 12.3, 13.1 and SLE_11, and ossec
certainly works just fine across all those platforms.

From your post on the forum you're saying ossec doesn't start on boot.
What is the output of the following command:

sudo /etc/init.d/ossec-hids status

and

ps -aef |grep ossec

This will tell us if there any ossec process running and the init status.

FYI..the ossec-hids rpm build package links, to
home:deadpoint/ossec-hids, from the forum posts are to my repository
and package. That package, at least for the moment, is outdated and
incomplete and if memory serves me doesn't work so don't use it. I
have a working RPM package which I'm fine tuning the packaging but
haven't made the sources publicly available yet.
--
Later,
Darin


On Tue, Jan 28, 2014 at 1:24 PM, BMor brandon.morri...@sjsu.edu wrote:
 OSSEC installs well on many Linux operating systems.  Recently, I
 have begun using OpenSUSE (13.1 x64) and tried to use OSSEC on that
 system.  For some reason it creates multiple new users, none of which
 are able to be used, and does not start up in boot, even though the
 installation confirms that the int file was modified to accomplish
 this task.  I can logon to my account, but I am forced to issue the
 start command every time I want to start the program.

 I am new to the system, and do not consider myself a programmer.  I
 only program for scientific purposes, and do not know many of the
 specifics that professional programmers do.  Having said this, I posted
 a question on the OpenSUSE forum regarding this issue, and one person
 seems to suggest that it is a compatibility issue with OpenSUSE, and
 thus the program would need modification.  I wish I could tell you what
 caused this issue, but I don't have that knowledge.  Nevertheless,
 OpenSUSE is a popular distribution and I wanted to let you know of this
 issue.

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ossec-list] authentication key limitations

[Darin Perusich]

Hello,

I'm automating the creation of agent key and want to know if there's
an limitations to the number of characters the authentication key? I'm
planning to generate a unique hash which is 80 characters long.

client.keys xample:

003f0671 host1 7a056288d97ce78511cf601e5d736f5e0942d999cfa82d9563e4ce55cb14fe33

Thanks!
--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ossec-list] breaking up ossec.conf into smaller files

[Darin Perusich]

Hello All,

Is is possible to break the various ossec configuration options into
individual files and include them in the main ossec.conf? Say I put
syscheck opts into syscheck.xml, localfile opts in localfile.xml, etc.

I'm not finding anything about this from google nor a quick review of
the os_xml code.

Thanks!

--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Wed, Nov 27, 2013 at 12:23 PM, Darin Perusich da...@darins.net wrote:
 On Wed, Nov 27, 2013 at 12:22 PM, Darin Perusich da...@darins.net wrote:
 --
 Later,
 Darin


 On Wed, Nov 27, 2013 at 12:11 PM, dan (ddp) ddp...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 11:41 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 2:15 PM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net 
 wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


 Looks I spoke to soon, I'm still getting the segfault with
 ossec-remoted built against the provided zlib. This is giving me a bit
 of a headache. Let me keep poking around and see if I can come up with
 anything else.

 Ok, so I'm looking at this again and ossec-remoted is built with the
 provided zlib and it's still segfaulting. What other info can I
 provide to keep this moving, any additional gdb output, valgrind,
 building w/specify debug flags (other then -g)?


 Is the trace in gdb the same?


 It is but's here's the output again.

 # gdb /var/ossec/bin/ossec-remoted
 GNU gdb (GDB) SUSE (7.5.1-2.1.1)
 Copyright (C) 2012 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-suse-linux.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/27 12:21:22 ossec-remoted: DEBUG: Starting ...
 [New process 3486]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3487]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3488]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 3489)]
 [New Thread 0x767d7700 (LWP 3490)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 3488)]
 0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 warning: Source file is more recent than executable.
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 (gdb) where
 #0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 #1  0x00404845 in HandleSecure () at secure.c:85
 #2  0x00404708 in HandleRemote (position=0, uid=493) at remoted.c:102
 #3  0x00403234 in main (argc=2, argv=0x7fffe1d8) at main.c:151
 (gdb) list
 84  if(!keys-keyentries[i]-fp)
 85  {
 86  int my_error = errno;
 87
 88  /* Just in case we run out of file descriptiors */
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 90  {
 91  fclose(keys-keyentries[i -1]-fp);
 92
 93  if(keys-keyentries[i -2]-fp)


 (gdb) bt full
 #0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 my_error = 13
 i = 0
 rids_file =
 /queue/rids/001\000\000\256\377\377\377\177\000\000\022*\226R\000\000\000\000\340\347\273\367\377\177\000\000\300\325e\000\000\000\000\000\260\256\377\377\377\177\000\000!tB,
 '\000' repeats 13 times, BLC, '\000' repeats 13 times,
 \020\000\000\000\060\000\000\000\300\256\377\377\377\177\000\000\000\256\377\377\377\177\000\000\000\000\000\000\000\000\000\000@KC\000\000\000\000\000H\000\000\000\000\000\000\000@\002\000\000\000\000\000\000\001\000\000\000\000\000\000\000\005,
 '\000' repeats 88 times\256,
 \377\377\377\177\000\000צ\377\377\377\177\000\000
 #1  0x00404845 in HandleSecure () at secure.c:85
 agentid = 0
 buffer = '\000' repeats 1928 times,
 \002\030\336\367\377\177, '\000' repeats 67 times\300,
 \000\000\000\000\000\000\254\260\000\000\000\000\000\000\254\260,
 '\000' repeats 14 times, \005\000\000\000\000\000\000\000\000\260
 \000\000\000\000\000\000\320 \000\000\000\000\000\030\303
 \000\000\000\000\000H\307
 \000\000\000\000\000\000\260\000\000\000\000\000\000\003, '\000'
 repeats 31 times\320, \004, '\000' repeats 14 times, P, '\000'
 repeats 39 times,
 \003\000\000\000\060\000\000\000

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Mon, Dec 2, 2013 at 3:10 PM, Darin Perusich da...@darins.net wrote:
 On Wed, Nov 27, 2013 at 12:23 PM, Darin Perusich da...@darins.net wrote:
 On Wed, Nov 27, 2013 at 12:22 PM, Darin Perusich da...@darins.net wrote:
 --
 Later,
 Darin


 On Wed, Nov 27, 2013 at 12:11 PM, dan (ddp) ddp...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 11:41 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 2:15 PM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net 
 wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


 Looks I spoke to soon, I'm still getting the segfault with
 ossec-remoted built against the provided zlib. This is giving me a bit
 of a headache. Let me keep poking around and see if I can come up with
 anything else.

 Ok, so I'm looking at this again and ossec-remoted is built with the
 provided zlib and it's still segfaulting. What other info can I
 provide to keep this moving, any additional gdb output, valgrind,
 building w/specify debug flags (other then -g)?


 Is the trace in gdb the same?


 It is but's here's the output again.

 # gdb /var/ossec/bin/ossec-remoted
 GNU gdb (GDB) SUSE (7.5.1-2.1.1)
 Copyright (C) 2012 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-suse-linux.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/27 12:21:22 ossec-remoted: DEBUG: Starting ...
 [New process 3486]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3487]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3488]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 3489)]
 [New Thread 0x767d7700 (LWP 3490)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 3488)]
 0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 warning: Source file is more recent than executable.
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 (gdb) where
 #0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at 
 msgs.c:89
 #1  0x00404845 in HandleSecure () at secure.c:85
 #2  0x00404708 in HandleRemote (position=0, uid=493) at 
 remoted.c:102
 #3  0x00403234 in main (argc=2, argv=0x7fffe1d8) at main.c:151
 (gdb) list
 84  if(!keys-keyentries[i]-fp)
 85  {
 86  int my_error = errno;
 87
 88  /* Just in case we run out of file descriptiors */
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 90  {
 91  fclose(keys-keyentries[i -1]-fp);
 92
 93  if(keys-keyentries[i -2]-fp)


 (gdb) bt full
 #0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 my_error = 13
 i = 0
 rids_file =
 /queue/rids/001\000\000\256\377\377\377\177\000\000\022*\226R\000\000\000\000\340\347\273\367\377\177\000\000\300\325e\000\000\000\000\000\260\256\377\377\377\177\000\000!tB,
 '\000' repeats 13 times, BLC, '\000' repeats 13 times,
 \020\000\000\000\060\000\000\000\300\256\377\377\377\177\000\000\000\256\377\377\377\177\000\000\000\000\000\000\000\000\000\000@KC\000\000\000\000\000H\000\000\000\000\000\000\000@\002\000\000\000\000\000\000\001\000\000\000\000\000\000\000\005,
 '\000' repeats 88 times\256,
 \377\377\377\177\000\000צ\377\377\377\177\000\000
 #1  0x00404845 in HandleSecure () at secure.c:85
 agentid = 0
 buffer = '\000' repeats 1928 times,
 \002\030\336\367\377\177, '\000' repeats 67 times\300,
 \000\000\000\000\000\000\254\260\000\000\000\000\000\000\254\260,
 '\000' repeats 14 times, \005\000\000\000\000\000\000\000\000\260
 \000\000\000\000\000\000\320 \000\000\000\000\000\030\303
 \000\000\000\000\000H\307
 \000\000\000\000\000\000\260\000\000\000\000\000\000\003, '\000'
 repeats 31 times\320, \004, '\000

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Tue, Nov 26, 2013 at 2:15 PM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


 Looks I spoke to soon, I'm still getting the segfault with
 ossec-remoted built against the provided zlib. This is giving me a bit
 of a headache. Let me keep poking around and see if I can come up with
 anything else.

Ok, so I'm looking at this again and ossec-remoted is built with the
provided zlib and it's still segfaulting. What other info can I
provide to keep this moving, any additional gdb output, valgrind,
building w/specify debug flags (other then -g)?

Thanks!

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Wed, Nov 27, 2013 at 12:22 PM, Darin Perusich da...@darins.net wrote:
 --
 Later,
 Darin


 On Wed, Nov 27, 2013 at 12:11 PM, dan (ddp) ddp...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 11:41 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 2:15 PM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


 Looks I spoke to soon, I'm still getting the segfault with
 ossec-remoted built against the provided zlib. This is giving me a bit
 of a headache. Let me keep poking around and see if I can come up with
 anything else.

 Ok, so I'm looking at this again and ossec-remoted is built with the
 provided zlib and it's still segfaulting. What other info can I
 provide to keep this moving, any additional gdb output, valgrind,
 building w/specify debug flags (other then -g)?


 Is the trace in gdb the same?


 It is but's here's the output again.

 # gdb /var/ossec/bin/ossec-remoted
 GNU gdb (GDB) SUSE (7.5.1-2.1.1)
 Copyright (C) 2012 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-suse-linux.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/27 12:21:22 ossec-remoted: DEBUG: Starting ...
 [New process 3486]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3487]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 3488]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 3489)]
 [New Thread 0x767d7700 (LWP 3490)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 3488)]
 0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 warning: Source file is more recent than executable.
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 (gdb) where
 #0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
 #1  0x00404845 in HandleSecure () at secure.c:85
 #2  0x00404708 in HandleRemote (position=0, uid=493) at remoted.c:102
 #3  0x00403234 in main (argc=2, argv=0x7fffe1d8) at main.c:151
 (gdb) list
 84  if(!keys-keyentries[i]-fp)
 85  {
 86  int my_error = errno;
 87
 88  /* Just in case we run out of file descriptiors */
 89  if((keys-keyentries[i -1]-fp)  (i  10))
 90  {
 91  fclose(keys-keyentries[i -1]-fp);
 92
 93  if(keys-keyentries[i -2]-fp)


(gdb) bt full
#0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
my_error = 13
i = 0
rids_file =
/queue/rids/001\000\000\256\377\377\377\177\000\000\022*\226R\000\000\000\000\340\347\273\367\377\177\000\000\300\325e\000\000\000\000\000\260\256\377\377\377\177\000\000!tB,
'\000' repeats 13 times, BLC, '\000' repeats 13 times,
\020\000\000\000\060\000\000\000\300\256\377\377\377\177\000\000\000\256\377\377\377\177\000\000\000\000\000\000\000\000\000\000@KC\000\000\000\000\000H\000\000\000\000\000\000\000@\002\000\000\000\000\000\000\001\000\000\000\000\000\000\000\005,
'\000' repeats 88 times\256,
\377\377\377\177\000\000צ\377\377\377\177\000\000
#1  0x00404845 in HandleSecure () at secure.c:85
agentid = 0
buffer = '\000' repeats 1928 times,
\002\030\336\367\377\177, '\000' repeats 67 times\300,
\000\000\000\000\000\000\254\260\000\000\000\000\000\000\254\260,
'\000' repeats 14 times, \005\000\000\000\000\000\000\000\000\260
\000\000\000\000\000\000\320 \000\000\000\000\000\030\303
\000\000\000\000\000H\307
\000\000\000\000\000\000\260\000\000\000\000\000\000\003, '\000'
repeats 31 times\320, \004, '\000' repeats 14 times, P, '\000'
repeats 39 times,
\003\000\000\000\060\000\000\000[\000\000\000n\000\000\000w\000\000\000|,
'\000' repeats 11 times,
@\226\273\367\377\177\000\000\031

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

--
Later,
Darin


On Wed, Nov 27, 2013 at 12:11 PM, dan (ddp) ddp...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 11:41 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 2:15 PM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


 Looks I spoke to soon, I'm still getting the segfault with
 ossec-remoted built against the provided zlib. This is giving me a bit
 of a headache. Let me keep poking around and see if I can come up with
 anything else.

 Ok, so I'm looking at this again and ossec-remoted is built with the
 provided zlib and it's still segfaulting. What other info can I
 provide to keep this moving, any additional gdb output, valgrind,
 building w/specify debug flags (other then -g)?


 Is the trace in gdb the same?


It is but's here's the output again.

# gdb /var/ossec/bin/ossec-remoted
GNU gdb (GDB) SUSE (7.5.1-2.1.1)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-suse-linux.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /var/ossec/bin/ossec-remoted...done.
(gdb) set follow-fork-mode child
(gdb) run -d
Starting program: /var/ossec/bin/ossec-remoted -d
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
2013/11/27 12:21:22 ossec-remoted: DEBUG: Starting ...
[New process 3486]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New process 3487]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New process 3488]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New Thread 0x76fd8700 (LWP 3489)]
[New Thread 0x767d7700 (LWP 3490)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fdf700 (LWP 3488)]
0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
warning: Source file is more recent than executable.
89  if((keys-keyentries[i -1]-fp)  (i  10))
(gdb) where
#0  0x00424726 in OS_StartCounter (keys=0x6525a0 keys) at msgs.c:89
#1  0x00404845 in HandleSecure () at secure.c:85
#2  0x00404708 in HandleRemote (position=0, uid=493) at remoted.c:102
#3  0x00403234 in main (argc=2, argv=0x7fffe1d8) at main.c:151
(gdb) list
84  if(!keys-keyentries[i]-fp)
85  {
86  int my_error = errno;
87
88  /* Just in case we run out of file descriptiors */
89  if((keys-keyentries[i -1]-fp)  (i  10))
90  {
91  fclose(keys-keyentries[i -1]-fp);
92
93  if(keys-keyentries[i -2]-fp)

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Mon, Nov 25, 2013 at 11:04 AM, Darin Perusich da...@darins.net wrote:


 On Monday, November 25, 2013 10:18:58 AM UTC-5, dan (ddpbsd) wrote:

 On Mon, Nov 25, 2013 at 10:13 AM, Andrew Strozyk astro...@gmail.com
 wrote:
  We actually are running 2.7.1. And since i am new to ossec i did not
  create
  any specific remoted configuration. I just used all the defaults.
 

 And that configuration would be what exactly? (help me out so I don't
 have to do a fresh install just to see the final configuration)


   remote
 connectionsecure/connection
   /remote



 If you run `/var/ossec/bin/ossec-remoted -d` are there any more useful
 logs (possibly in /var/ossec/logs/ossec.log)?


 Here's the logs with debug turned on, doesn't tell us much.

 2013/11/25 10:58:36 ossec-remoted: DEBUG: Starting ...
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4314).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Forking remoted: '0'.
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4315).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Running manager_init
 2013/11/25 10:58:36 ossec-remoted: INFO: (unix_domain) Maximum send buffer
 set to: '212992'.
 2013/11/25 10:58:36 ossec-remoted(4111): INFO: Maximum number of agents
 allowed: '256'.
 2013/11/25 10:58:36 ossec-remoted(1410): INFO: Reading authentication keys
 file.
 2013/11/25 10:58:36 ossec-remoted: DEBUG: OS_StartCounter.
 2013/11/25 10:58:36 ossec-remoted: OS_StartCounter: keysize: 1



 Does it crash immediately?


 Yes, it crashes immediately on startup.


 Is udp port 1514 currently occupied?


 It it not being used.


 Can you run it under gdb?
 gdb /var/ossec/bin/ossec-remoted
 set follow-fork-mode child
 run -d
 CRASH
 bt


 gdb /var/ossec/bin/ossec-remoted
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/25 11:02:34 ossec-remoted: DEBUG: Starting ...
 [New process 4494]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4495]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4496]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 4497)]
 [New Thread 0x767d7700 (LWP 4498)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 4496)]
 0x00420002 in OS_StartCounter (keys=0x64b5a0 keys) at msgs.c:89
 89  msgs.c: No such file or directory.


 Interesting if I run  strace -f /var/ossec/bin/ossec-remoted the daemon
 will start, and I'm not sure why that is yet.

Any thoughts on what's going on with remoted?


  On Friday, November 22, 2013 2:58:07 PM UTC-5, dan (ddpbsd) wrote:
 
  On Fri, Nov 22, 2013 at 2:47 PM, Andrew Strozyk astro...@gmail.com
  wrote:
   Hi,
  
   I am running into some problems with ossec. I am testing out some
   HIDS
   pilots at my work as we are in need of one for our systems. I am very
   interested in using ossec but i have been having problems connecting
   the
   agents to the server. I checked on the server in /var/log/messages
   and
   this
   is the output i get:
  
  [3886011.217396] ossec-remoted[20994]:
   segfault
   at 61 ip 00420002 sp 7fff6b9e5ca0 error 4 in
   ossec-remoted[40+4b000]
  
   The remoted service keeps crashing. I restart it manually using
   /var/ossec/bin/ossec-control restart and then the above error shows
   up.
   We
   currently use openSUSE-12.3 on all our systems.
  
 
  Try 2.7.1. Also, please provide your remoted configuration.
 
   Just for more information, the agent is sending this error back as
   well:
  
   2013/11/22 14:44:28 ossec-agentd: INFO: Trying to connect to server
   (10.100.90.58:1514).
   2013/11/22 14:44:28 ossec-agentd: INFO: Using IPv4 for: 10.100.90.58
   .
   2013/11/22 14:44:38 ossec-agentd(1218): ERROR: Unable to send message
   to
   server.
   2013/11/22 14:44:50 ossec-agentd(1218): ERROR: Unable to send message
   to
   server.
   2013/11/22 14:44:51 ossec-agentd(4101): WARN: Waiting for server
   reply
   (not
   started). Tried: '10.100.90.58'.
  
   10.100.90.58 is the server's correct ip address.
  
   Appreciate any incite on this. Thanks!
  
   --
  

 --

 ---
 You received this message because you are subscribed to the Google Groups
 ossec-list group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to ossec-list+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Tue, Nov 26, 2013 at 10:18 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 10:07 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 8:22 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Nov 25, 2013 at 11:04 AM, Darin Perusich da...@darins.net wrote:


 On Monday, November 25, 2013 10:18:58 AM UTC-5, dan (ddpbsd) wrote:

 On Mon, Nov 25, 2013 at 10:13 AM, Andrew Strozyk astro...@gmail.com
 wrote:
  We actually are running 2.7.1. And since i am new to ossec i did not
  create
  any specific remoted configuration. I just used all the defaults.
 

 And that configuration would be what exactly? (help me out so I don't
 have to do a fresh install just to see the final configuration)


   remote
 connectionsecure/connection
   /remote



 If you run `/var/ossec/bin/ossec-remoted -d` are there any more useful
 logs (possibly in /var/ossec/logs/ossec.log)?


 Here's the logs with debug turned on, doesn't tell us much.

 2013/11/25 10:58:36 ossec-remoted: DEBUG: Starting ...
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4314).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Forking remoted: '0'.
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4315).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Running manager_init
 2013/11/25 10:58:36 ossec-remoted: INFO: (unix_domain) Maximum send buffer
 set to: '212992'.
 2013/11/25 10:58:36 ossec-remoted(4111): INFO: Maximum number of agents
 allowed: '256'.
 2013/11/25 10:58:36 ossec-remoted(1410): INFO: Reading authentication keys
 file.
 2013/11/25 10:58:36 ossec-remoted: DEBUG: OS_StartCounter.
 2013/11/25 10:58:36 ossec-remoted: OS_StartCounter: keysize: 1



 Does it crash immediately?


 Yes, it crashes immediately on startup.


 Is udp port 1514 currently occupied?


 It it not being used.


 Can you run it under gdb?
 gdb /var/ossec/bin/ossec-remoted
 set follow-fork-mode child
 run -d
 CRASH
 bt


 gdb /var/ossec/bin/ossec-remoted
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/25 11:02:34 ossec-remoted: DEBUG: Starting ...
 [New process 4494]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4495]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4496]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 4497)]
 [New Thread 0x767d7700 (LWP 4498)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 4496)]
 0x00420002 in OS_StartCounter (keys=0x64b5a0 keys) at msgs.c:89
 89  msgs.c: No such file or directory.


 How many agents do you have? What limits are you setting on file 
 descriptors?

 One agent.

 Here are the limits, nofile defaults to 1024 but I've increased it to 8196.

 ulimit -a
 core file size  (blocks, -c) 0
 data seg size   (kbytes, -d) unlimited
 scheduling priority (-e) 0
 file size   (blocks, -f) unlimited
 pending signals (-i) 47683
 max locked memory   (kbytes, -l) 64
 max memory size (kbytes, -m) unlimited
 open files  (-n) 8196
 pipe size(512 bytes, -p) 8
 POSIX message queues (bytes, -q) 819200
 real-time priority  (-r) 0
 stack size  (kbytes, -s) 8192
 cpu time   (seconds, -t) unlimited
 max user processes  (-u) 47683
 virtual memory  (kbytes, -v) unlimited
 file locks  (-x) unlimited



 Interesting if I run  strace -f /var/ossec/bin/ossec-remoted the daemon
 will start, and I'm not sure why that is yet.


 Has the strace provided any clues?

 I'm not familiar with this distro, could selinux or apparmor be
 crashing remoted?


Neither selinux or apparmor are enabled or running. The strace isn't
telling my much, othen then when I tell it to chase forks the forks
are running as root and not ossecr.

One thing I'm doing differently is I'm not building w/the provided
zlib but using what's included in the distro, version 1.2.7. I'm doing
this so it can eventually be included in the distro.

Here's the full backtrack, I just realize I didn't include it before.

# gdb /var/ossec/bin/ossec-remoted
GNU gdb (GDB) SUSE (7.5.1-2.1.1)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-suse-linux.
For bug reporting instructions, please see:
http

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Tue, Nov 26, 2013 at 10:51 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 10:39 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 10:18 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 10:07 AM, Darin Perusich da...@darins.net wrote:
 On Tue, Nov 26, 2013 at 8:22 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Nov 25, 2013 at 11:04 AM, Darin Perusich da...@darins.net wrote:


 On Monday, November 25, 2013 10:18:58 AM UTC-5, dan (ddpbsd) wrote:

 On Mon, Nov 25, 2013 at 10:13 AM, Andrew Strozyk astro...@gmail.com
 wrote:
  We actually are running 2.7.1. And since i am new to ossec i did not
  create
  any specific remoted configuration. I just used all the defaults.
 

 And that configuration would be what exactly? (help me out so I don't
 have to do a fresh install just to see the final configuration)


   remote
 connectionsecure/connection
   /remote



 If you run `/var/ossec/bin/ossec-remoted -d` are there any more useful
 logs (possibly in /var/ossec/logs/ossec.log)?


 Here's the logs with debug turned on, doesn't tell us much.

 2013/11/25 10:58:36 ossec-remoted: DEBUG: Starting ...
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4314).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Forking remoted: '0'.
 2013/11/25 10:58:36 ossec-remoted: INFO: Started (pid: 4315).
 2013/11/25 10:58:36 ossec-remoted: DEBUG: Running manager_init
 2013/11/25 10:58:36 ossec-remoted: INFO: (unix_domain) Maximum send 
 buffer
 set to: '212992'.
 2013/11/25 10:58:36 ossec-remoted(4111): INFO: Maximum number of agents
 allowed: '256'.
 2013/11/25 10:58:36 ossec-remoted(1410): INFO: Reading authentication 
 keys
 file.
 2013/11/25 10:58:36 ossec-remoted: DEBUG: OS_StartCounter.
 2013/11/25 10:58:36 ossec-remoted: OS_StartCounter: keysize: 1



 Does it crash immediately?


 Yes, it crashes immediately on startup.


 Is udp port 1514 currently occupied?


 It it not being used.


 Can you run it under gdb?
 gdb /var/ossec/bin/ossec-remoted
 set follow-fork-mode child
 run -d
 CRASH
 bt


 gdb /var/ossec/bin/ossec-remoted
 Reading symbols from /var/ossec/bin/ossec-remoted...done.
 (gdb) set follow-fork-mode child
 (gdb) run -d
 Starting program: /var/ossec/bin/ossec-remoted -d
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 2013/11/25 11:02:34 ossec-remoted: DEBUG: Starting ...
 [New process 4494]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4495]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New process 4496]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib64/libthread_db.so.1.
 [New Thread 0x76fd8700 (LWP 4497)]
 [New Thread 0x767d7700 (LWP 4498)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x77fdf700 (LWP 4496)]
 0x00420002 in OS_StartCounter (keys=0x64b5a0 keys) at msgs.c:89
 89  msgs.c: No such file or directory.


 How many agents do you have? What limits are you setting on file 
 descriptors?

 One agent.

 Here are the limits, nofile defaults to 1024 but I've increased it to 8196.

 ulimit -a
 core file size  (blocks, -c) 0
 data seg size   (kbytes, -d) unlimited
 scheduling priority (-e) 0
 file size   (blocks, -f) unlimited
 pending signals (-i) 47683
 max locked memory   (kbytes, -l) 64
 max memory size (kbytes, -m) unlimited
 open files  (-n) 8196
 pipe size(512 bytes, -p) 8
 POSIX message queues (bytes, -q) 819200
 real-time priority  (-r) 0
 stack size  (kbytes, -s) 8192
 cpu time   (seconds, -t) unlimited
 max user processes  (-u) 47683
 virtual memory  (kbytes, -v) unlimited
 file locks  (-x) unlimited



 Interesting if I run  strace -f /var/ossec/bin/ossec-remoted the daemon
 will start, and I'm not sure why that is yet.


 Has the strace provided any clues?

 I'm not familiar with this distro, could selinux or apparmor be
 crashing remoted?


 Neither selinux or apparmor are enabled or running. The strace isn't
 telling my much, othen then when I tell it to chase forks the forks
 are running as root and not ossecr.

 One thing I'm doing differently is I'm not building w/the provided
 zlib but using what's included in the distro, version 1.2.7. I'm doing
 this so it can eventually be included in the distro.


 Try it with the correct zlib to see if that fixes things.

This fixed remoted. What's so special about this included zlib,
other then being 8.5 years old and getting ever more unmaintained? I
haven't had a chance to diff it against upstream yet.

--
Later,
Darin

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from

Re: [ossec-list] ossec remoted - segfault error

[Darin Perusich]

On Tue, Nov 26, 2013 at 12:59 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:57 PM, Darin Perusich da...@darins.net wrote:
 This fixed remoted. What's so special about this included zlib,
 other then being 8.5 years old and getting ever more unmaintained? I
 haven't had a chance to diff it against upstream yet.


 I don't know actually. I remember the Debian folks mentioning
 differences and possibly trying to push some upstream.


Looks I spoke to soon, I'm still getting the segfault with
ossec-remoted built against the provided zlib. This is giving me a bit
of a headache. Let me keep poking around and see if I can come up with
anything else.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.