RE: [ossec-list] custom rules

2012-01-19 Thread Nelson, James
Thank you for the quick response.

Here is the part of the manual I was using:

http://www.ossec.net/doc/manual/rules-decoders/create-custom.html

The confusion came in for me because it doesn't really address the agent
manager relationship and appears to assume a local installation, same thing
with Chapter 4 of the book on the site. Something as simple as what you just
said would help clarify, "All rules live on the manager. All log files you
want to manage live on the agent."

Thanks again.

-Original Message-
From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
Behalf Of dan (ddp)
Sent: Thursday, January 19, 2012 4:31 PM
To: ossec-list@googlegroups.com
Subject: Re: [ossec-list] custom rules

All rules live on the manager. What part of the documentation is
confusing? I'd like to fix it. :)

On Thu, Jan 19, 2012 at 5:08 PM, Nelson, James  wrote:
> This may be a dumb question , but do custom rules reside on the agent or
> master?  I have a specific log file I want to work with on an agent, no
other
> agent has it.  I've added it to the ossec.conf and created a
local_rules.xml
> parser for it.  However, I see there is no ossec-logtest installed on the
> agent and no rules directory, which leads me to believe I need to put the
> local_rules.xml and decoders on the master.  The documentation makes it
sound
> like it should reside on the local machine.
>
> Thanks,
> James


Re: [ossec-list] custom rules

2012-01-19 Thread dan (ddp)
All rules live on the manager. What part of the documentation is
confusing? I'd like to fix it. :)

On Thu, Jan 19, 2012 at 5:08 PM, Nelson, James  wrote:
> This may be a dumb question , but do custom rules reside on the agent or
> master?  I have a specific log file I want to work with on an agent, no other
> agent has it.  I've added it to the ossec.conf and created a local_rules.xml
> parser for it.  However, I see there is no ossec-logtest installed on the
> agent and no rules directory, which leads me to believe I need to put the
> local_rules.xml and decoders on the master.  The documentation makes it sound
> like it should reside on the local machine.
>
> Thanks,
> James


[ossec-list] custom rules

2012-01-19 Thread Nelson, James
This may be a dumb question , but do custom rules reside on the agent or
master?  I have a specific log file I want to work with on an agent, no other
agent has it.  I've added it to the ossec.conf and created a local_rules.xml
parser for it.  However, I see there is no ossec-logtest installed on the
agent and no rules directory, which leads me to believe I need to put the
local_rules.xml and decoders on the master.  The documentation makes it sound
like it should reside on the local machine.

Thanks,
James


Re: [ossec-list] Not seeing changes in an updated cdb

2012-01-19 Thread dan (ddp)
Sorry for the delay. I'm seeing the same behavior. I'll try to look at
it later, but between moving and the code complexity it might be
beyond me right now.

On Tue, Jan 10, 2012 at 9:42 AM, Andy Jack  wrote:
> Hello Dan.  ossec-makelists does report that it is making a new .cdb:
>
> * File lists/employees.cdb need to be updated
>
> The longest I was waiting was 3-5 minutes.
>
> On a related note, I was trying to figure out if there was a format for
> comments in the text version of the list.  ossec-makelists appeared to
> put lines with leading '#' into the .cdb file (according to strings).  I
> guess I could come up with a simple Makefile to manage comments though.
>
> Thanks, Andy
>
> On Mon, Jan 09, 2012 at 08:33:59PM -0500, dan (ddp) wrote:
>> On Mon, Jan 9, 2012 at 4:27 PM, Andy Jack  wrote:
>> > Hello list!  So I'm working on a cdb list of users so there can be rules
>> > that differentiate when a user on the list vs. not on the list logs in,
>> > as described here:
>> >
>> > http://www.ossec.net/doc/manual/rules-decoders/rule-lists.html
>> >
>> > After confirming that the list is being read and the two rules are being
>> > alerted correctly (one for on-the-list, and the other for
>> > not-on-the-list), I tried modifying the text list and re-running
>> > bin/ossec-makelists to see if the alerts change when a user is taken off
>> > the list:
>> >
>> > 1) user1 and user2, are on the list, user3 is not.  run
>> > bin/ossec-makelists.  run ossec-control start.
>> > 2) logging in as either user1 or user2 alerts the on-the-list rule.
>> > logging in as user3 alerts the not-on-the-list rule.
>> > 3) modify the list, removing the line for user2.  re-run
>> > bin/ossec-makelists.  leave ossec running as-is.
>> > 4) logging in as user2 alerts the on-the-list rule still.
>> >
>> > According to the URL above, updating the cdb file should invalidate the
>> > mmap and make the analysis daemon re-read the db from disk as needed,
>> > but this doesn't appear to be happening.  Could I have something
>> > configured incorrectly?  Permissions issue perhaps?  Or do I have to
>> > wait a period of time for ossec to notice or purge a cache or something?
>> >
>> > root@pegasus:/var/ossec# ls -ld /var/ossec
>> > dr-xr-x--- 14 root ossec 4096 2012-01-09 14:13 /var/ossec
>> > root@pegasus:/var/ossec# ls -ld /var/ossec/lists
>> > drwxr-xr-x 2 root ossec 4096 2012-01-09 16:08 /var/ossec/lists
>> > root@pegasus:/var/ossec# ls -l /var/ossec/lists
>> > total 8
>> > -rw-r--r-- 1 root ossec   77 2012-01-09 16:08 employees
>> > -rw-r--r-- 1 root ossec 2345 2012-01-09 16:08 employees.cdb
>> >
>> > I just tried adding user4 to the list and remaking the cdb, and ossec
>> > still alerts as though user4 is not on the list.  The behavior seems to
>> > indicate that ossec isn't re-reading the updated lists.  I guess
>> > restarting ossec is a workaround but that's a pain for every list
>> > modification.
>> >
>> > Thanks,
>> > Andy
>>
>> I don't know the answer off hand, but how long do you wait?
>> Does ossec-makelists indicate that it's rebuilding the list?


RE: [ossec-list] ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread Nelson, James
Yes, each agent has a 1 unique IP and both are listed correctly in
manage_agents.

The agent log output was from agent 002.  However, the same logs appear in
agent 001.

The tcpdump was from the manager.

I don't believe I need syslog and secure.  I just went with the defaults and
then have been trying suggestions found in the list and online.

I had not tried debug. Here is the output:

2012/01/19 13:06:56 2 : rule:502, level 3, timeout: 0
2012/01/19 13:06:56 2 : rule:503, level 3, timeout: 0
2012/01/19 13:06:56 2 : rule:504, level 3, timeout: 0
2012/01/19 13:06:56 2 : rule:591, level 3, timeout: 0
2012/01/19 13:06:56 1 : rule:509, level 0, timeout: 0
2012/01/19 13:06:56 2 : rule:510, level 7, timeout: 0
2012/01/19 13:06:56 3 : rule:511, level 0, timeout: 0
2012/01/19 13:06:56 3 : rule:515, level 0, timeout: 0
2012/01/19 13:06:56 3 : rule:513, level 9, timeout: 0
2012/01/19 13:06:56 3 : rule:512, level 3, timeout: 0
2012/01/19 13:06:56 3 : rule:516, level 3, timeout: 0
2012/01/19 13:06:56 3 : rule:514, level 2, timeout: 0
2012/01/19 13:06:56 4 : rule:518, level 9, timeout: 0
2012/01/19 13:06:56 1 : rule:554, level 0, timeout: 0
2012/01/19 13:06:56 1 : rule:580, level 8, timeout: 0
2012/01/19 13:06:56 1 : rule:581, level 8, timeout: 0
2012/01/19 13:06:56 1 : rule:550, level 7, timeout: 0
2012/01/19 13:06:56 1 : rule:551, level 7, timeout: 0
2012/01/19 13:06:56 1 : rule:552, level 7, timeout: 0
2012/01/19 13:06:56 1 : rule:553, level 7, timeout: 0
2012/01/19 13:06:56 ossec-analysisd: INFO: Total rules enabled: '1250'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/mtab'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/mnttab'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/hosts.deny'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'/etc/mail/statistics'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/random-seed'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/adjtime'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/httpd/logs'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/utmpx'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/wtmpx'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/cups/certs'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/dumpdates'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: '/etc/svc/volatile'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/System32/LogFiles'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: 'C:\WINDOWS/Debug'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/WindowsUpdate.log'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/iis6.log'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/system32/wbem/Logs'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/system32/wbem/Repository'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/Prefetch'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/PCHEALTH/HELPCTR/DataColl'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/SoftwareDistribution'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file: 'C:\WINDOWS/Temp'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/system32/config'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/system32/spool'
2012/01/19 13:06:56 ossec-analysisd: INFO: Ignoring file:
'C:\WINDOWS/system32/CatRoot'
2012/01/19 13:06:56 ossec-analysisd: INFO: Chrooted to directory:
/home/var/ossec, using user: ossec
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing IP: '127.0.0.1'
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing IP: 'x.x.x.x'
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing IP: 'x.x.x.x'
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing IP: 'x.x.0.2'
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing IP: 'x.x.1.2'
2012/01/19 13:06:56 ossec-analysisd: INFO: 5 IPs in the white list for active
response.
2012/01/19 13:06:56 ossec-analysisd: INFO: White listing Hostname:
'localhost.localdomain'
2012/01/19 13:06:56 ossec-analysisd: INFO: 1 Hostname(s) in the white list
for active response.
2012/01/19 13:06:56 ossec-analysisd: INFO: Started (pid: 26001).
2012/01/19 13:06:56 ossec-analysisd: SyscheckInit completed.
2012/01/19 13:06:56 ossec-analysisd: RootcheckInit completed.
2012/01/19 13:06:56 ossec-analysisd: OS_CreateEventList completed.
2012/01/19 13:06:56 ossec-analysisd: DEBUG: FTSInit completed.
2012/01/19 13:06:56 ossec-remoted: INFO: (unix_domain) Maximum send buffer
set to: '114688'.
2012/01/19 13:06:56 ossec-remoted: INFO: (unix_domain) Maximum send buffer
set to: '114688'.
2012/01/19 13:06:56 ossec-remoted(4111): INFO: Maximum number of agents
allowed: '256'.
2012/01/19 13:06:56 ossec-remoted(1410): INFO: Reading authentication keys
file.
2012/01/19 13:06:56 ossec-re

Re: [ossec-list] Windows Event 529 - logging against INETINFO

2012-01-19 Thread dan (ddp)
Running those through ossec-logtest gives me a bunch of 3800s, not 529:

**Phase 1: Completed pre-decoding.
   full event: '2012-01-08 04:02:23 222.35.140.244 jzebnk.com
SMTPSVC1 ASERVER 192.168.1.2 0 EHLO - +jzebnk.com 250 0 304 15 0 SMTP
- - - -'
   hostname: 'ix'
   program_name: '(null)'
   log: '2012-01-08 04:02:23 222.35.140.244 jzebnk.com SMTPSVC1
ASERVER 192.168.1.2 0 EHLO - +jzebnk.com 250 0 304 15 0 SMTP - - - -'

**Phase 2: Completed decoding.
   decoder: 'windows-date-format'
   srcip: '222.35.140.244'
   action: 'EHLO'
   id: '250'

**Phase 3: Completed filtering (rules).
   Rule id: '3800'
   Level: '0'
   Description: 'Grouping of Exchange rules.'


**Phase 1: Completed pre-decoding.
   full event: '2012-01-08 04:02:50 222.35.140.244 jzebnk.com
SMTPSVC1 ASERVER 192.168.1.2 0 QUIT - jzebnk.com 240 26891 76 10 5484
SMTP - - - -'
   hostname: 'ix'
   program_name: '(null)'
   log: '2012-01-08 04:02:50 222.35.140.244 jzebnk.com SMTPSVC1
ASERVER 192.168.1.2 0 QUIT - jzebnk.com 240 26891 76 10 5484 SMTP - -
- -'

**Phase 2: Completed decoding.
   decoder: 'windows-date-format'
   srcip: '222.35.140.244'
   action: 'QUIT'
   id: '240'

**Phase 3: Completed filtering (rules).
   Rule id: '3800'
   Level: '0'
   Description: 'Grouping of Exchange rules.'


On Tue, Jan 10, 2012 at 7:58 PM, Andy Cockroft (andic)
 wrote:
> Hi Dan
>
> Below are a typical few entries - the log file is typically 1/2 Mb per day 
> when these events are occurring - otherwise less than 50K per day
>
> A useless 529 event log is raised just after each "QUIT"
>
> Under the SMPT logging properties, all extended options are enabled
>
> I have manually banned this offending IP for now, but who knows when it will 
> re-emerge from another source
>
> Any help appreciated
>
> Andy
>
> 2012-01-08 04:02:23 222.35.140.244 jzebnk.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +jzebnk.com 250 0 304 15 0 SMTP - - - -
> 2012-01-08 04:02:50 222.35.140.244 jzebnk.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - jzebnk.com 240 26891 76 10 5484 SMTP - - - -
> 2012-01-08 04:02:53 222.35.140.244 zqkjhp.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +zqkjhp.com 250 0 304 15 0 SMTP - - - -
> 2012-01-08 04:03:19 222.35.140.244 zqkjhp.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - zqkjhp.com 240 26890 76 10 5484 SMTP - - - -
> 2012-01-08 04:03:22 222.35.140.244 xmgemovn.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 EHLO - +xmgemovn.com 250 0 304 17 0 SMTP - - - -
> 2012-01-08 04:03:49 222.35.140.244 xmgemovn.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 QUIT - xmgemovn.com 240 26938 76 10 5500 SMTP - - - -
> 2012-01-08 04:03:51 222.35.140.244 knpivkp.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +knpivkp.com 250 0 304 16 0 SMTP - - - -
> 2012-01-08 04:04:18 222.35.140.244 knpivkp.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - knpivkp.com 240 27000 76 10 5515 SMTP - - - -
> 2012-01-08 04:04:21 222.35.140.244 qzrespbcv.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 EHLO - +qzrespbcv.com 250 0 304 18 0 SMTP - - - -
> 2012-01-08 04:04:48 222.35.140.244 qzrespbcv.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 QUIT - qzrespbcv.com 240 27188 76 10 5719 SMTP - - - -
> 2012-01-08 04:04:51 222.35.140.244 cqdbqxjlg.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 EHLO - +cqdbqxjlg.com 250 0 304 18 0 SMTP - - - -
> 2012-01-08 04:05:21 222.35.140.244 cqdbqxjlg.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 QUIT - cqdbqxjlg.com 240 30937 76 10 5953 SMTP - - - -
> 2012-01-08 04:05:24 222.35.140.244 kgttmy.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +kgttmy.com 250 0 304 15 0 SMTP - - - -
> 2012-01-08 04:05:52 222.35.140.244 kgttmy.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - kgttmy.com 240 27765 76 10 5656 SMTP - - - -
> 2012-01-08 04:05:54 222.35.140.244 nvqpxaom.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 EHLO - +nvqpxaom.com 250 0 304 17 0 SMTP - - - -
> 2012-01-08 04:06:22 222.35.140.244 nvqpxaom.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 QUIT - nvqpxaom.com 240 27719 76 10 5766 SMTP - - - -
> 2012-01-08 04:06:24 222.35.140.244 ucvmxoz.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +ucvmxoz.com 250 0 304 16 0 SMTP - - - -
> 2012-01-08 04:06:52 222.35.140.244 ucvmxoz.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - ucvmxoz.com 240 27860 76 10 5985 SMTP - - - -
> 2012-01-08 04:06:55 222.35.140.244 qebrvgye.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 EHLO - +qebrvgye.com 250 0 304 17 0 SMTP - - - -
> 2012-01-08 04:07:23 222.35.140.244 qebrvgye.com SMTPSVC1 ASERVER 192.168.1.2 
> 0 QUIT - qebrvgye.com 240 28812 76 10 5812 SMTP - - - -
> 2012-01-08 04:07:26 222.35.140.244 bwwhgkm.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +bwwhgkm.com 250 0 304 16 0 SMTP - - - -
> 2012-01-08 04:07:54 222.35.140.244 bwwhgkm.com SMTPSVC1 ASERVER 192.168.1.2 0 
> QUIT - bwwhgkm.com 240 28578 76 10 6078 SMTP - - - -
> 2012-01-08 04:07:57 222.35.140.244 naylnwu.com SMTPSVC1 ASERVER 192.168.1.2 0 
> EHLO - +naylnwu.com 250 0 304 16 0 SMTP - - - -
> 2012-01-08 04:08:25 222.35.140.244 nayl

Re: [ossec-list] Re: Auto removal of client agents?

2012-01-19 Thread dan (ddp)
On Wed, Jan 18, 2012 at 10:20 AM, maz  wrote:
> I think the easiest way to go about this would be to just add a delete
> flag in the agent-auth binary.  I'm not a developer but I can't
> imagine it would be all that difficult to just reverse the function
> the addition of an agent.
>

You skipped over the authentication part. ;)

I'm wondering if a password and/or the client key would be enough
(agent passing the key to the manager as validation that it is who it
says it is).

> On Jan 18, 10:06 am, "dan (ddp)"  wrote:
>> On Wed, Jan 18, 2012 at 9:59 AM, maz  wrote:
>> > Unfortunately this is something that will keep coming up because of
>> > cloud architecture and devops projects that move forward at a somewhat
>> > fast pace.  What you're saying right now is that there is no way to
>> > really work around this limitation?
>>
>> I realize it will be an issue more and more. There's currently nothing
>> planned to deal with this limitation, but it is being thought about.
>> I like the idea of an independent script querying AWS to see which
>> instances are still alive. It solves the problem of an "agent" having
>> to report itself as deceased (and the authentication necessary for
>> that to happen).
>> So, it is being thought about, but it isn't considered high priority
>> (by me anyhow). Any ideas are welcome, especially good ones! ;)
>>
>>
>>
>>
>>
>>
>>
>> > On Jan 18, 8:35 am, "dan (ddp)"  wrote:
>> >> On Wed, Jan 18, 2012 at 7:49 AM, maz  wrote:
>> >> > I'm glad that there is now a way for ossec clients to automatically
>> >> > register with the server.  This is great within any cloud
>> >> > architecture.  While auto scaling is not ready to be implemented
>> >> > within the application I'm currently helping design (I do all the back
>> >> > end linux/cloud stuff, not the coding of the application) one of our
>> >> > contracts requires that we have some form of IDS.  This is what
>> >> > brought me to ossec in the first place.  I can auto add agents as they
>> >> > spin up through my configuration management by utilizing agent-auth
>> >> > and it works wonderfully.  The down side is I see no way to actually
>> >> > have an agent tell the server daemon to remove itself.
>>
>> >> > ./agent-auth -h
>>
>> >> > OSSEC HIDS ossec-authd: Connects to the manager to extract the agent
>> >> > key.
>> >> > Available options:
>> >> >        -h                  This help message.
>> >> >        -m      Manager IP Address.
>> >> >        -p            Manager port (default 1515).
>> >> >        -A      Agent name (default is the hostname).
>> >> >        -D       Location where OSSEC is installed.
>>
>> >> > For now I have been having to manually remove each agent within a test
>> >> > environment which I find endlessly annoying.  Starting to seem like I
>> >> > need to write a script that occasionally goes through /var/ossec/etc/
>> >> > client.keys and then utilize an AWS query to gather information
>> >> > regarding which instances of a machine class are running then remove
>> >> > the lines that are no longer relelvant what so ever?
>>
>> >> > Has someone come up with a solution for having completely stateless
>> >> > machines that can come up and disappear at the notice of a moment?
>>
>> >> I think authenticating the removal is the hard part. Adding a new
>> >> agent isn't generally a big deal, removing one is huge.


Re: [ossec-list] Re: Override Decoder from decoder.xml

2012-01-19 Thread dan (ddp)
On Wed, Jan 18, 2012 at 10:21 PM, JB  wrote:
> My Internet Security software blocked URL at "devio DOT us", saying it
> is "dangerous".
> I am not able to verify it, but consider this a warning.
>

This isn't a surprise. It's a shell server, so there are probably a
bunch of sites on there.

Maybe I'll come up with something better in the future.

> On Dec 13 2011, 12:14 pm, "dan (ddp)"  wrote:
>> On Mon, Dec 12, 2011 at 9:30 PM, Chris Decker  wrote:
>> > As the subject suggests, is there a way to override a particular
>> > decoder in decoder.xml?  I have a few tweaks I want to make and
>> > obviously want to make sure that future upgrades to smoothly (so I
>> > want to keep everything in local_decoder.xml).
>>
>> > (Thanks in advance, Dan, for the response  ;))
>>
>> > Sent from my iPhone
>>
>> Not really. You can eliminate the decoder.xml file and load only
>> custom decoder files using  and  in the 
>> section of the ossec.conf:http: // devio . us 
>> /~ddp/ossec/docs/syntax/head_ossec_config.rules.html
>>
>> I think if you use  without specifying decoder.xml, then
>> decoder.xml will not be used. I'll double check and update the docs
>> though (I'm almost positive this is the case with ).


Re: [ossec-list] ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread dan (ddp)
There are a bunch of examples of this in the archives.

Does each agent have a unique IP?
Is the unique IP correctly setup in manage_agents on the manager?
Does each agent have only 1 IP? Or is the correct IP the one
communicating with the manager?

More below.

On Thu, Jan 19, 2012 at 10:25 AM, kcjames  wrote:
> I’m pulling my hair out here.  I have a new install of ossec server
> and it is working great.  I’ve incorporated the webui and splunk and
> that is all working great.  However, I can not get any agents
> connecting.  I have tried just about every solution I could find and I
> am still getting nowhere.
>
>
>
> Here is the relevant log portions from the agents:
>
>
>

Which agent is this from?

> ossec-agent(4101): WARN: Waiting for server reply (not started).
> Tried: 'x.x.x.1'.
>
>
>
> On the server here are the relevant log portions for ossec-remoted:
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8606).
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8608).
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> from: 'x.x.0.0/24'
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> from: 'x.x.1.2'
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8607).
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted(4111): INFO: Maximum
> number of agents allowed: '256'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted(1410): INFO: Reading
> authentication keys file.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous counter
> available for 'agent001'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning counter
> for agent agent001: '0:0'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous sender
> counter.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning sender
> counter: 0:0
>
> ossec.log:2012/01/18 15:56:49 ossec-remoted(1213): WARN: Message from
> 127.0.0.1 not allowed.
>

That's interesting, I wonder what's trying to communicate on loopback.
Did you try turning on debug mode on the manager?
`/var/ossec/bin/ossec-control enable debug &&
/var/ossec/bin/ossec-control restart`

>
>
> Tcpdump data shows traffic from agents to server, but no server
> response.
>
>
>

Did you do the dump on the agent or the manager?

> # tcpdump -ni eth0 port 1514
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
>
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535
> bytes
>
> 08:15:15.627737 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:21.628234 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:25.628378 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:30.628481 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:36.628707 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
>
>
>
>
> Netstat output shows remoted to binded to 1514:
>
>
>
> 8608/ossec-remoted
>
> udp        0      0 *:syslog
> *:*
>
> 8607/ossec-remoted
>
> udp        0      0 *:39324
> *:*
>
> Iptables is open on port 1514 in and all out ports are open.  I also
> turned iptables off altogether and still no traffic from the ossec
> server to the agents:
>
> # iptables –L
> Chain INPUT (policy DROP)
> target     prot opt source               destination
> ACCEPT     udp  --  anywhere             anywhere             udp
> dpt:syslog
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:
> 8089
> …
> Chain FORWARD (policy DROP)
> target     prot opt source               destination
> LOG        all  --  anywhere             anywhere             limit:
> avg 3/min burst 5 LOG level warning tcp-options ip-options prefix
> "SFW2-FWD-ILL-ROUTING "
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere
>
> Here are the lines in the conf for the agent IPs:
>
>  
>    127.0.0.1
>    ^localhost.localdomain$
>     x.x.x.8
>     x.x.x.10
>     x.x.x.10
>     x.x.1.2
>  
>

Do you need both syslog and secure options?

>  
>    syslog
>    x.x.0.0/24
>    x.x.1.2
>  
>
>  
>    secure
>  
>
> I am not behind any NAT and I am not using any firewalls on the
> agents, though I see no traffic even being sent from the server to the
> agents, so I am relatively sure that isn’t a problem anyway.
>
> Any help would be much appreciated!
>
> James
>
>


[ossec-list] Re: ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread kcjames
No dice.

  
secure
x.x.x.1
1514
  

Any other ideas?


On Jan 19, 12:07 pm, Nick Green  wrote:
> I've see this before and got around it by setting the two directives below:
> local_ip and port. Although defaults ...setting this explicitly worked.
>
>  
>    secure
>    x.x.x.x
>    1514
>  
>
> /nick
>
>
>
> On Thu, Jan 19, 2012 at 3:25 PM, kcjames  wrote:
> > I’m pulling my hair out here.  I have a new install of ossec server
> > and it is working great.  I’ve incorporated the webui and splunk and
> > that is all working great.  However, I can not get any agents
> > connecting.  I have tried just about every solution I could find and I
> > am still getting nowhere.
>
> > Here is the relevant log portions from the agents:
>
> > ossec-agent(4101): WARN: Waiting for server reply (not started).
> > Tried: 'x.x.x.1'.
>
> > On the server here are the relevant log portions for ossec-remoted:
>
> > ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> > 8606).
>
> > ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> > 8608).
>
> > ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> > from: 'x.x.0.0/24'
>
> > ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> > from: 'x.x.1.2'
>
> > ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> > 8607).
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted(4111): INFO: Maximum
> > number of agents allowed: '256'.
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted(1410): INFO: Reading
> > authentication keys file.
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous counter
> > available for 'agent001'.
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning counter
> > for agent agent001: '0:0'.
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous sender
> > counter.
>
> > ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning sender
> > counter: 0:0
>
> > ossec.log:2012/01/18 15:56:49 ossec-remoted(1213): WARN: Message from
> > 127.0.0.1 not allowed.
>
> > Tcpdump data shows traffic from agents to server, but no server
> > response.
>
> > # tcpdump -ni eth0 port 1514
>
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> > decode
>
> > listening on eth0, link-type EN10MB (Ethernet), capture size 65535
> > bytes
>
> > 08:15:15.627737 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> > 08:15:21.628234 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> > 08:15:25.628378 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> > 08:15:30.628481 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> > 08:15:36.628707 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> > Netstat output shows remoted to binded to 1514:
>
> > 8608/ossec-remoted
>
> > udp        0      0 *:syslog
> > *:*
>
> > 8607/ossec-remoted
>
> > udp        0      0 *:39324
> > *:*
>
> > Iptables is open on port 1514 in and all out ports are open.  I also
> > turned iptables off altogether and still no traffic from the ossec
> > server to the agents:
>
> > # iptables –L
> > Chain INPUT (policy DROP)
> > target     prot opt source               destination
> > ACCEPT     udp  --  anywhere             anywhere             udp
> > dpt:syslog
> > ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:
> > 8089
> > …
> > Chain FORWARD (policy DROP)
> > target     prot opt source               destination
> > LOG        all  --  anywhere             anywhere             limit:
> > avg 3/min burst 5 LOG level warning tcp-options ip-options prefix
> > "SFW2-FWD-ILL-ROUTING "
>
> > Chain OUTPUT (policy ACCEPT)
> > target     prot opt source               destination
> > ACCEPT     all  --  anywhere             anywhere
>
> > Here are the lines in the conf for the agent IPs:
>
> >  
> >    127.0.0.1
> >    ^localhost.localdomain$
> >     x.x.x.8
> >     x.x.x.10
> >     x.x.x.10
> >     x.x.1.2
> >  
>
> >  
> >    syslog
> >    x.x.0.0/24
> >    x.x.1.2
> >  
>
> >  
> >    secure
> >  
>
> > I am not behind any NAT and I am not using any firewalls on the
> > agents, though I see no traffic even being sent from the server to the
> > agents, so I am relatively sure that isn’t a problem anyway.
>
> > Any help would be much appreciated!
>
> > James- Hide quoted text -
>
> - Show quoted text -


RE: [ossec-list] ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread Nelson, James
No dice.

 

  

secure

x.x.x.1

1514

  

 

Any other ideas?

 



From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
Behalf Of Nick Green
Sent: Thursday, January 19, 2012 12:07 PM
To: ossec-list@googlegroups.com
Subject: Re: [ossec-list] ossec-agent(4101): WARN: Waiting for server reply
(not started). Tried: 'x.x.x.1'.

 

I've see this before and got around it by setting the two directives below:
local_ip and port. Although defaults ...setting this explicitly worked.

 

 
   secure

   x.x.x.x

   1514
 

 

 

/nick

 

On Thu, Jan 19, 2012 at 3:25 PM, kcjames  wrote:

I'm pulling my hair out here.  I have a new install of ossec server
and it is working great.  I've incorporated the webui and splunk and
that is all working great.  However, I can not get any agents
connecting.  I have tried just about every solution I could find and I
am still getting nowhere.



Here is the relevant log portions from the agents:



ossec-agent(4101): WARN: Waiting for server reply (not started).
Tried: 'x.x.x.1'.



On the server here are the relevant log portions for ossec-remoted:

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8606).

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8608).

ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
from: 'x.x.0.0/24'

ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
from: 'x.x.1.2'

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8607).

ossec.log:2012/01/18 15:40:19 ossec-remoted(4111): INFO: Maximum
number of agents allowed: '256'.

ossec.log:2012/01/18 15:40:19 ossec-remoted(1410): INFO: Reading
authentication keys file.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous counter
available for 'agent001'.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning counter
for agent agent001: '0:0'.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous sender
counter.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning sender
counter: 0:0

ossec.log:2012/01/18 15:56:49 ossec-remoted(1213): WARN: Message from
127.0.0.1 not allowed.



Tcpdump data shows traffic from agents to server, but no server
response.



# tcpdump -ni eth0 port 1514

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes

08:15:15.627737 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:21.628234 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:25.628378 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:30.628481 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:36.628707 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73





Netstat output shows remoted to binded to 1514:



8608/ossec-remoted

udp0  0 *:syslog
*:*

8607/ossec-remoted

udp0  0 *:39324
*:*

Iptables is open on port 1514 in and all out ports are open.  I also
turned iptables off altogether and still no traffic from the ossec
server to the agents:

# iptables -L
Chain INPUT (policy DROP)
target prot opt source   destination
ACCEPT udp  --  anywhere anywhere udp
dpt:syslog
ACCEPT tcp  --  anywhere anywhere tcp dpt:
8089
...
Chain FORWARD (policy DROP)
target prot opt source   destination
LOGall  --  anywhere anywhere limit:
avg 3/min burst 5 LOG level warning tcp-options ip-options prefix
"SFW2-FWD-ILL-ROUTING "

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere

Here are the lines in the conf for the agent IPs:

 
   127.0.0.1
   ^localhost.localdomain$
x.x.x.8
x.x.x.10
x.x.x.10
x.x.1.2
 

 
   syslog
   x.x.0.0/24
   x.x.1.2
 

 
   secure
 

I am not behind any NAT and I am not using any firewalls on the
agents, though I see no traffic even being sent from the server to the
agents, so I am relatively sure that isn't a problem anyway.

Any help would be much appreciated!

James



 



Re: [ossec-list] Multiple packages updated/erased/installed?

2012-01-19 Thread dan (ddp)
On Thu, Jan 19, 2012 at 1:28 AM, Jakov Sosic  wrote:
> Hi
>
> Is there a way to write a rule where OSSEC would wait a bit and then
> report updated packages? I have a problem whenever a machine is being
> updated, OSSEC sends massive number of emails with information about
> updated packages (I use CentOS and yum).
>
> I tried something like this:
>
> 
>        2933
>        no_log
>        Yum package updated
> 
> 
>        330991
>        Multiple yum packages installed.
> 
>
>
> But that's not it... It won't report one or two packages updated
> (because of frequency) and it won't group more than 3 log enteries in
> one alert.
>
>
> So I would basically like for OSSEC to report even if only one package
> is updated/erased/installed, but also if there is a mass update going on
> then to send one email of all packages updated in some timeframe, for
> example 5 minutes.
>
> I didn't try this:
>
> 
>
> because documentation says timeframe goes with frequency. Maybe it can
> work standalone?
>

Not sure, give it a shot. I don't know if you'll be able to get a
delay, a roundup might be the best you can hope for in this case.

> --
> Jakov Sosic
> www.srce.unizg.hr


[ossec-list] Re: Now on to AIX .. error compiling 2.6

2012-01-19 Thread Kat
You don't have all the "pieces" to the gcc compiler installed fully.
You need the compiler and the supporting libraries, etc. That is where
you are getting the cc1 errors.

On Jan 19, 10:02 am, "Swartz, Patrick H"
 wrote:
>    Hi All,
> Well, with RH, SuSE, and Solaris10 out of the way.. now on to AIX5.3...
>
> I tried compiling the OSSEC package on a AIX 5.3 system
>   and I get these errors
>   5- Installing the system
>  - Running the Makefile
>
>  *** Making zlib (by Jean-loup Gailly and Mark Adler)  ***
>         gcc -c -g -Wall -I../../ -I../../headers
> -DDEFAULTDIR=\"/opt/ossec\" -DCLIENT -DUSE_OPENSSL -DAIX -DHIGHFIRST
> -DARGV0=\"zlib\" -DXML_VAR=\"var\" -DOSSECHIDS *.c
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> make: 1254-004 The error code from the last command is 1.


Re: [ossec-list] ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread Nick Green
I've see this before and got around it by setting the two directives below:
local_ip and port. Although defaults ...setting this explicitly worked.

 
   secure
   x.x.x.x
   1514
 


/nick


On Thu, Jan 19, 2012 at 3:25 PM, kcjames  wrote:

> I’m pulling my hair out here.  I have a new install of ossec server
> and it is working great.  I’ve incorporated the webui and splunk and
> that is all working great.  However, I can not get any agents
> connecting.  I have tried just about every solution I could find and I
> am still getting nowhere.
>
>
>
> Here is the relevant log portions from the agents:
>
>
>
> ossec-agent(4101): WARN: Waiting for server reply (not started).
> Tried: 'x.x.x.1'.
>
>
>
> On the server here are the relevant log portions for ossec-remoted:
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8606).
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8608).
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> from: 'x.x.0.0/24'
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
> from: 'x.x.1.2'
>
> ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
> 8607).
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted(4111): INFO: Maximum
> number of agents allowed: '256'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted(1410): INFO: Reading
> authentication keys file.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous counter
> available for 'agent001'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning counter
> for agent agent001: '0:0'.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous sender
> counter.
>
> ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning sender
> counter: 0:0
>
> ossec.log:2012/01/18 15:56:49 ossec-remoted(1213): WARN: Message from
> 127.0.0.1 not allowed.
>
>
>
> Tcpdump data shows traffic from agents to server, but no server
> response.
>
>
>
> # tcpdump -ni eth0 port 1514
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
>
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535
> bytes
>
> 08:15:15.627737 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:21.628234 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:25.628378 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:30.628481 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
> 08:15:36.628707 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73
>
>
>
>
>
> Netstat output shows remoted to binded to 1514:
>
>
>
> 8608/ossec-remoted
>
> udp0  0 *:syslog
> *:*
>
> 8607/ossec-remoted
>
> udp0  0 *:39324
> *:*
>
> Iptables is open on port 1514 in and all out ports are open.  I also
> turned iptables off altogether and still no traffic from the ossec
> server to the agents:
>
> # iptables –L
> Chain INPUT (policy DROP)
> target prot opt source   destination
> ACCEPT udp  --  anywhere anywhere udp
> dpt:syslog
> ACCEPT tcp  --  anywhere anywhere tcp dpt:
> 8089
> …
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> LOGall  --  anywhere anywhere limit:
> avg 3/min burst 5 LOG level warning tcp-options ip-options prefix
> "SFW2-FWD-ILL-ROUTING "
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
>
> Here are the lines in the conf for the agent IPs:
>
>  
>127.0.0.1
>^localhost.localdomain$
> x.x.x.8
> x.x.x.10
> x.x.x.10
> x.x.1.2
>  
>
>  
>syslog
>x.x.0.0/24
>x.x.1.2
>  
>
>  
>secure
>  
>
> I am not behind any NAT and I am not using any firewalls on the
> agents, though I see no traffic even being sent from the server to the
> agents, so I am relatively sure that isn’t a problem anyway.
>
> Any help would be much appreciated!
>
> James
>
>
>


[ossec-list] Now on to AIX .. error compiling 2.6

2012-01-19 Thread Swartz, Patrick H

   Hi All,
Well, with RH, SuSE, and Solaris10 out of the way.. now on to AIX5.3... 

I tried compiling the OSSEC package on a AIX 5.3 system 
  and I get these errors 
  5- Installing the system
 - Running the Makefile

 *** Making zlib (by Jean-loup Gailly and Mark Adler)  ***
gcc -c -g -Wall -I../../ -I../../headers
-DDEFAULTDIR=\"/opt/ossec\" -DCLIENT -DUSE_OPENSSL -DAIX -DHIGHFIRST
-DARGV0=\"zlib\" -DXML_VAR=\"var\" -DOSSECHIDS *.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
make: 1254-004 The error code from the last command is 1.


Stop.
cp -pr zlib.h zconf.h ../../headers/
cp -pr libz.a ../
cp: libz.a: A file or directory in the path name does not exist.
make: 1254-004 The error code from the last command is 1.


Stop.



 *** Making os_xml ***

gcc -DXML_VAR=\"var\" -g -Wall -I../ -I../headers
-DDEFAULTDIR=\"/opt/ossec\" -DCLIENT -DUSE_OPENSSL -DAIX -DHIGHFIRST
-DARGV0=\"os_xml\" -DXML_VAR=\"var\" -DOSSECHIDS -c os_xml.c
os_xml_access.c os_xml_node_access.c os_xml_variables.c os_xml_writer.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
gcc: error trying to exec 'cc1': execvp: No such file or directory
make: 1254-004 The error code from the last command is 1.


Stop.

Error Making os_xml
make: 1254-004 The error code from the last command is 1.


Stop.

 Error 0x5.
 Building error. Unable to finish the installation.

I wasn't sure if this was related to openssl, so I thought would include
the paths here...
root@a9tvir982:/# find / -name opensslconf.h*
/opt/freeware/include/openssl/opensslconf.h
/usr/include/openssl/opensslconf.h
   

I appreciate any and all help,
Patrick Swartz


-
The information in this message may be proprietary and/or
confidential, and protected from disclosure.  If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify First Data
immediately by replying to this message and deleting it from your
computer.


[ossec-list] ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: 'x.x.x.1'.

2012-01-19 Thread kcjames
I’m pulling my hair out here.  I have a new install of ossec server
and it is working great.  I’ve incorporated the webui and splunk and
that is all working great.  However, I can not get any agents
connecting.  I have tried just about every solution I could find and I
am still getting nowhere.



Here is the relevant log portions from the agents:



ossec-agent(4101): WARN: Waiting for server reply (not started).
Tried: 'x.x.x.1'.



On the server here are the relevant log portions for ossec-remoted:

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8606).

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8608).

ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
from: 'x.x.0.0/24'

ossec.log:2012/01/18 15:40:18 ossec-remoted: Remote syslog allowed
from: 'x.x.1.2'

ossec.log:2012/01/18 15:40:18 ossec-remoted: INFO: Started (pid:
8607).

ossec.log:2012/01/18 15:40:19 ossec-remoted(4111): INFO: Maximum
number of agents allowed: '256'.

ossec.log:2012/01/18 15:40:19 ossec-remoted(1410): INFO: Reading
authentication keys file.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous counter
available for 'agent001'.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning counter
for agent agent001: '0:0'.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: No previous sender
counter.

ossec.log:2012/01/18 15:40:19 ossec-remoted: INFO: Assigning sender
counter: 0:0

ossec.log:2012/01/18 15:56:49 ossec-remoted(1213): WARN: Message from
127.0.0.1 not allowed.



Tcpdump data shows traffic from agents to server, but no server
response.



# tcpdump -ni eth0 port 1514

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes

08:15:15.627737 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:21.628234 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:25.628378 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:30.628481 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73

08:15:36.628707 IP x.x.1.2.4476 > x.x.x.1.1514: UDP, length 73





Netstat output shows remoted to binded to 1514:



8608/ossec-remoted

udp0  0 *:syslog
*:*

8607/ossec-remoted

udp0  0 *:39324
*:*

Iptables is open on port 1514 in and all out ports are open.  I also
turned iptables off altogether and still no traffic from the ossec
server to the agents:

# iptables –L
Chain INPUT (policy DROP)
target prot opt source   destination
ACCEPT udp  --  anywhere anywhere udp
dpt:syslog
ACCEPT tcp  --  anywhere anywhere tcp dpt:
8089
…
Chain FORWARD (policy DROP)
target prot opt source   destination
LOGall  --  anywhere anywhere limit:
avg 3/min burst 5 LOG level warning tcp-options ip-options prefix
"SFW2-FWD-ILL-ROUTING "

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere

Here are the lines in the conf for the agent IPs:

  
127.0.0.1
^localhost.localdomain$
 x.x.x.8
 x.x.x.10
 x.x.x.10
 x.x.1.2
  

  
syslog
x.x.0.0/24
x.x.1.2
  

  
secure
  

I am not behind any NAT and I am not using any firewalls on the
agents, though I see no traffic even being sent from the server to the
agents, so I am relatively sure that isn’t a problem anyway.

Any help would be much appreciated!

James




[ossec-list] Multiple packages updated/erased/installed?

2012-01-19 Thread Jakov Sosic
Hi

Is there a way to write a rule where OSSEC would wait a bit and then
report updated packages? I have a problem whenever a machine is being
updated, OSSEC sends massive number of emails with information about
updated packages (I use CentOS and yum).

I tried something like this:


2933
no_log
Yum package updated


330991
Multiple yum packages installed.



But that's not it... It won't report one or two packages updated
(because of frequency) and it won't group more than 3 log enteries in
one alert.


So I would basically like for OSSEC to report even if only one package
is updated/erased/installed, but also if there is a mass update going on
then to send one email of all packages updated in some timeframe, for
example 5 minutes.

I didn't try this:



because documentation says timeframe goes with frequency. Maybe it can
work standalone?

-- 
Jakov Sosic
www.srce.unizg.hr