Re: [ossec-list] ossec server 2.9.0 WinEvt problems

[dan (ddp)]

On Feb 10, 2017 8:13 AM, "Chris Snyder"  wrote:

My only counter argument to your response is that if I do the same tests
with a 2.8.3 ossec server all the tests pass with the expected match of a
windows log type.  So something changed somewhere in the ossec server.
Whether this is a new bug recently introduced between 2.8.3 and 2.9.0 or it
was broken before and now correctly works, I'm not sure, but definitely
something changed.



Software changes between versions. It's the nature of the beast.


On Thursday, February 9, 2017 at 3:37:13 PM UTC-5, dan (ddpbsd) wrote:

> On Thu, Feb 9, 2017 at 3:25 PM, Chris Snyder  wrote:
> > You're new windows decoder rules work great!  I'm going to throw them at
> my
> > hosts right now (better than what I've got at the moment!).
> >
> > However, I'm thinking there's a bug somewhere in some pattern matching
> code
> > somewhere. However, I don't know yet if it's a bug in the current atomic
> > RPMs or the ossec code.  But, I did some further testing and here's what
> I
> > found.
> >
>
> I think it's a quirk.More details inline.
>
-- 

---
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 server 2.9.0 WinEvt problems

[dan (ddp)]

On Thu, Feb 9, 2017 at 4:09 PM, Chris Snyder  wrote:
> update on your new code.
>
> I replaced the following code:
>
> 
>   windows
>   ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog:
> 
>   ^\.+: (\w+)\((\d+)\): (\.+): 
>   (\.+): \.+: (\S+): 
>   status, id, extra_data, user, system_name
>   name, location, user, system_name
> 
>
> with what you sent me and restarted the server,
>
> Now, I'm getting matches for windows stuff (and they all looks correct so
> far), but when it does find something to alert on, it send a notice of
> multiple audit failures when there aren't multiple items:
>
> Received From: (testbox01.EXAMPLE.COM) 192.168.20.45->WinEvtLog
> Rule: 18153 fired (level 10) -> "Multiple Windows audit failure events."
> User: (no user)
> Portion of the log(s):
>
> 2017 Feb 09 16:00:54 WinEvtLog: Security: AUDIT_FAILURE(4771):
> Microsoft-Windows-Security-Auditing: (no user): no domain:
> testbox01.EXAMPLE.COM: Kerberos pre-authentication failed. Account
> Information:  Security ID:  S-1-5-21-963706601-603035142-3281641605-1106
> Account Name:  user1  Service Information:  Service Name:
> krbtgt/EXAMPLE.COM  Network Information:  Client Address:
> :::192.168.20.9  Client Port:  60429  Additional Information:  Ticket
> Options:  0x10  Failure Code:  0x18  Pre-Authentication Type: 2  Certificate
> Information:  Certificate Issuer Name:Certificate Serial Number:
> Certificate Thumbprint:Certificate information is only provided if a
> certificate was used for pre-authentication.  Pre-authentication types,
> ticket options and failure codes are defined in RFC 4120.  If the ticket was
> malformed or damaged during transit and could not be decrypted, then many
> fields in this event might not be present.
> 2017 Feb 09 16:02:23 WinEvtLog: Security: AUDIT_SUCCESS(4624): successful
> windows logging stuff from different host #2
> 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4634): successful
> windows logging stuff from different host #3
> 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4769): successful
> windows logging stuff from different host #2
> 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4769): successful
> windows logging stuff from different host #2
> 2017 Feb 09 16:00:44 WinEvtLog: Security: AUDIT_SUCCESS(4634): successful
> windows logging stuff from different host #2
>
> Any idea why it seems to see multiple failures here when there's only one
> failure and a bunch of successes? It didn't do that before.
>

No clue. Without log samples it's difficult to track down as well. I
avoid the Windows stuff as much as I can.

> On Thursday, February 9, 2017 at 2:57:57 PM UTC-5, dan (ddpbsd) wrote:
>>
>> Thanks for pointing this out. It's definitely shown me a(nother) gap
>> in our rules testing setup.
>> I'm guessing a 2.9.1 will be coming in shortly with the changes we
>> made to the windows decoders backported from master.
>> Here are the new decoders if you want to give them a spin:
>> 
>>   windows
>>   ^WinEvtLog
>> 
>>
>> 
>>   windows
>>   windows
>>   ^\.+: (\w+)\((\d+)\): (\.+): 
>>   (\.+): \.+: (\S+): 
>>   status, id, extra_data, user, system_name
>>   name, location, system_name
>> 
>>
>> 
>>   windows
>>   windows
>>Source Network Address: (\S+)
>>   srcip
>> 
>>
>> 
>>   windows
>>   windows
>>Account Name: (\S+) Account
>>   user
>> 
>>
>>
>> On Thu, Feb 9, 2017 at 10:50 AM, Chris Snyder  wrote:
>> > I just updated my CentOS 6 OSSEC server using the Atomic RPMs from
>> > 2.8.3-53
>> > to 2.9.0-48.
>> >
>> > Before the updates, my Windows server logs were process fine. After the
>> > updates, ALL my windows logs are no longer being decoded correctly.
>> >
>> > Using ossec-logtest, and a test log entry of
>> >
>> > 2017 Feb 08 19:00:00 WinEvtLog: Security: AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):
>> >
>> > With 2.8.3-53, logtest reports:
>> >
>> > **Phase 1: Completed pre-decoding.
>> >full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>> >hostname: 'mybox'
>> >program_name: '(null)'
>> >log: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):'
>> >
>> > **Phase 2: Completed decoding.
>> >decoder: 'windows'
>> >
>> > With 2.9.0, logtest reports:
>> >
>> > **Phase 1: Completed pre-decoding.
>> >full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>> >hostname: 'mybox'
>> >program_name: 'WinEvtLog'
>> >log: 'Security: AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):'
>> >
>> > **Phase 2: Completed decoding.
>> >No decoder matched.
>> >
>> > BUT! If I drop off the date stamp prefix and just use the rest of the
>> > line,
>> > IT 

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

[dan (ddp)]

On Thu, Feb 9, 2017 at 3:25 PM, Chris Snyder  wrote:
> You're new windows decoder rules work great!  I'm going to throw them at my
> hosts right now (better than what I've got at the moment!).
>
> However, I'm thinking there's a bug somewhere in some pattern matching code
> somewhere. However, I don't know yet if it's a bug in the current atomic
> RPMs or the ossec code.  But, I did some further testing and here's what I
> found.
>

I think it's a quirk.More details inline.

> Set up fresh install of ossec server 2.9.0, edited ossec.conf and removed
> all rules and then created an empty etc/decoder.xml with following:
>
> 
>   windows
>   ^\d\d\d\d \w\w\w \d\d \d\d:\d\d
> 
>
> 
>
>
> Then fired up 'ossec-logtest -vd' and executed the following test entries
> against it:
>
>
> full test with a string that should work - complete fail
>
> 2017 Feb 08 19:00:00 WinEvtLog
>
> **Phase 1: Completed pre-decoding.
>full event: '2017 Feb 08 19:00:00 WinEvtLog'
>hostname: 'gopher-test'
>program_name: '(null)'
>log: 'WinEvtLog'
>

In this case the "log" field only sees "WinEvtLog." Your decoder
doesn't match because the log doesn't include what you're looking for
in the prematch.

> **Phase 2: Completed decoding.
>No decoder matched.
>
>
>
> short string - remove everything except the date stamp, no whitespace at end
> – everything works
>
> 2017 Feb 08 19:00:00
>
> **Phase 1: Completed pre-decoding.
>full event: '2017 Feb 08 19:00:00'
>hostname: 'gopher-test'
>program_name: '(null)'
>log: '2017 Feb 08 19:00:00'
>

In this case the log event doesn't include enough to determine that
the timestamp is part of the metadata, so it's included in the log
field.

> **Phase 2: Completed decoding.
>decoder: 'windows'
>
>
> same short string - ADD ONE SPACE AT END - EVERYTHING FAILS. That pattern
> match should NOT be puking because of an extra space at the end as far as I
> can tell.
>
>
> 2017 Feb 08 19:00:00
>
> **Phase 1: Completed pre-decoding.
>full event: '2017 Feb 08 19:00:00 '
>hostname: 'gopher-test'
>program_name: '(null)'
>log: ''
>

Empty log field, apparently the space was enough for analysisd to
recognize the timestamp for what it is.

> **Phase 2: Completed decoding.
>No decoder matched.
>
>
> Anyway, thanks for the help!  I'll keep you posted if there's any more
> headaches with my windows logs.
>
>
>
>
> On Thursday, February 9, 2017 at 2:57:57 PM UTC-5, dan (ddpbsd) wrote:
>>
>> Thanks for pointing this out. It's definitely shown me a(nother) gap
>> in our rules testing setup.
>> I'm guessing a 2.9.1 will be coming in shortly with the changes we
>> made to the windows decoders backported from master.
>> Here are the new decoders if you want to give them a spin:
>> 
>>   windows
>>   ^WinEvtLog
>> 
>>
>> 
>>   windows
>>   windows
>>   ^\.+: (\w+)\((\d+)\): (\.+): 
>>   (\.+): \.+: (\S+): 
>>   status, id, extra_data, user, system_name
>>   name, location, system_name
>> 
>>
>> 
>>   windows
>>   windows
>>Source Network Address: (\S+)
>>   srcip
>> 
>>
>> 
>>   windows
>>   windows
>>Account Name: (\S+) Account
>>   user
>> 
>>
>>
>> On Thu, Feb 9, 2017 at 10:50 AM, Chris Snyder  wrote:
>> > I just updated my CentOS 6 OSSEC server using the Atomic RPMs from
>> > 2.8.3-53
>> > to 2.9.0-48.
>> >
>> > Before the updates, my Windows server logs were process fine. After the
>> > updates, ALL my windows logs are no longer being decoded correctly.
>> >
>> > Using ossec-logtest, and a test log entry of
>> >
>> > 2017 Feb 08 19:00:00 WinEvtLog: Security: AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):
>> >
>> > With 2.8.3-53, logtest reports:
>> >
>> > **Phase 1: Completed pre-decoding.
>> >full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>> >hostname: 'mybox'
>> >program_name: '(null)'
>> >log: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):'
>> >
>> > **Phase 2: Completed decoding.
>> >decoder: 'windows'
>> >
>> > With 2.9.0, logtest reports:
>> >
>> > **Phase 1: Completed pre-decoding.
>> >full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
>> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>> >hostname: 'mybox'
>> >program_name: 'WinEvtLog'
>> >log: 'Security: AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):'
>> >
>> > **Phase 2: Completed decoding.
>> >No decoder matched.
>> >
>> > BUT! If I drop off the date stamp prefix and just use the rest of the
>> > line,
>> > IT WORKS!
>> >
>> > WinEvtLog: Security: AUDIT_SUCCESS(4738):
>> > Microsoft-Windows-Security-Auditing: (no user):
>> >
>> > **Phase 1: Completed pre-decoding.
>> >full 

Re: [ossec-list] Debugging Unprocessed Log Entries

[dan (ddp)]

On Thu, Feb 9, 2017 at 9:48 AM, Quintin Beukes  wrote:
> Hi group,
>
> Server uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Agent uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> I am generating 5 log messages at 2 second intervals to trigger rule 1002.
> 16:40:43 [quintinb@ho-pri-vm-quintindev ~]$ for x in {11..15}; do logger
> test error$x; date; sleep 2; done
> Thu Feb  9 16:40:48 SAST 2017
> Thu Feb  9 16:40:50 SAST 2017
> Thu Feb  9 16:40:52 SAST 2017
> Thu Feb  9 16:40:54 SAST 2017
> Thu Feb  9 16:40:56 SAST 2017
> A tcpdump on the server indicates all 5 are received:
> 16:40:49.197974 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121
> 16:40:51.200118 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121
> 16:40:53.202224 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121
> 16:40:55.204480 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121
> 16:40:57.206407 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121
>
> Though alerts.log only shows 3 of the 5.
> ** Alert 1486651295.2432248: mail  - syslog,errors,
> 2017 Feb 09 16:41:35 (quintindev) 10.10.10.100->/var/log/messages
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Feb  9 16:40:48 ho-pri-vm-quintindev quintinb: test error11
>
> ** Alert 1486651298.2432494: mail  - syslog,errors,
> 2017 Feb 09 16:41:38 (quintindev) 10.10.10.100->/var/log/messages
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Feb  9 16:40:52 ho-pri-vm-quintindev quintinb: test error13
>
> ** Alert 1486651305.2432740: mail  - syslog,errors,
> 2017 Feb 09 16:41:45 (quintindev) 10.10.10.100->/var/log/messages
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Feb  9 16:40:56 ho-pri-vm-quintindev quintinb: test error15
>
>
> Sometimes it alerts on all 5. Though upon inspection it seems OSSEC misses
> 50%+ of my messages, even though I see the packets delivered to the server.
>
> Is there an explanation for this?  Any way I can get more verbose logging on
> this to investigate deeper?
>

OSSEC does discard some duplicate messages, and I'm not sure if the
timestamp is taken into account or not off hand.

> Quintin
>
> --
>
> ---
> 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 server 2.9.0 WinEvt problems

[dan (ddp)]

Thanks for pointing this out. It's definitely shown me a(nother) gap
in our rules testing setup.
I'm guessing a 2.9.1 will be coming in shortly with the changes we
made to the windows decoders backported from master.
Here are the new decoders if you want to give them a spin:

  windows
  ^WinEvtLog



  windows
  windows
  ^\.+: (\w+)\((\d+)\): (\.+): 
  (\.+): \.+: (\S+): 
  status, id, extra_data, user, system_name
  name, location, system_name



  windows
  windows
   Source Network Address: (\S+)
  srcip



  windows
  windows
   Account Name: (\S+) Account
  user



On Thu, Feb 9, 2017 at 10:50 AM, Chris Snyder  wrote:
> I just updated my CentOS 6 OSSEC server using the Atomic RPMs from 2.8.3-53
> to 2.9.0-48.
>
> Before the updates, my Windows server logs were process fine. After the
> updates, ALL my windows logs are no longer being decoded correctly.
>
> Using ossec-logtest, and a test log entry of
>
> 2017 Feb 08 19:00:00 WinEvtLog: Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):
>
> With 2.8.3-53, logtest reports:
>
> **Phase 1: Completed pre-decoding.
>full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
> AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>hostname: 'mybox'
>program_name: '(null)'
>log: '2017 Feb 08 19:00:00 WinEvtLog: Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):'
>
> **Phase 2: Completed decoding.
>decoder: 'windows'
>
> With 2.9.0, logtest reports:
>
> **Phase 1: Completed pre-decoding.
>full event: '2017 Feb 08 19:00:00 WinEvtLog: Security:
> AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):'
>hostname: 'mybox'
>program_name: 'WinEvtLog'
>log: 'Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):'
>
> **Phase 2: Completed decoding.
>No decoder matched.
>
> BUT! If I drop off the date stamp prefix and just use the rest of the line,
> IT WORKS!
>
> WinEvtLog: Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):
>
> **Phase 1: Completed pre-decoding.
>full event: 'WinEvtLog: Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):'
>hostname: 'tmgweb01'
>program_name: '(null)'
>log: 'WinEvtLog: Security: AUDIT_SUCCESS(4738):
> Microsoft-Windows-Security-Auditing: (no user):'
>
> **Phase 2: Completed decoding.
>decoder: 'windows'
>
> I've tried to play with the windows WinEvt decoder definition but I haven't
> had any luck getting it to match with the date stamp.
>
> I will say that my Windows servers are still running the 2.8.3 clients
> because I can't find an install package for 2.9.0 yet.
>
> Any ideas what's going on here? Help!
>
> --
>
> ---
> 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: ossec-active response, how to refere files? [Linux]

[dan (ddp)]

On Wed, Feb 8, 2017 at 2:06 PM, Nil  wrote:
> so i can't interact with the file that triggered the alert? seems kinda
> pointless then
>

Feel free to submit a pull request adding the functionality.

>
> El martes, 7 de febrero de 2017, 18:45:39 (UTC+1), Nil escribió:
>>
>> Hi, I would like to know how can i reference the file that triggered an
>> alert in order to use it with the commands
>> i.e   If file X were modified, I would like to do a `cp  /full/path/of/X
>> /some/other/path`
>>
> --
>
> ---
> 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] Duplicate counts - Difference between global/local and saved global/local

[dan (ddp)]

On Mon, Feb 6, 2017 at 1:49 PM, Steve Dimoff  wrote:
> Hey everyone,
>
> I've been searching through this group and I couldn't find any reference of
> someone explaining the difference between global / local and then saved.
>
> I'm trying to figure out WHY the duplicate error is happening, I know how to
> fix it... just trying to understand it more.
>
> Here is a message:
>
> ossec-remoted: WARN: Duplicate error:  global: 88640, local: 356, saved
> global: 88642, saved local:4574
>
>
> A couple weeks ago I had enabled debug for a short period of time and when
> digging around today, I found this:
>
> ossec-remoted: INFO: Assigning counter for agent xx: '85808:2777'
>
>
> Is global/local the counts returned from the AGENT for server counts / agent
> counts and then saved is what the SERVER has stored for server counts /
> agent counts ?
>
> If this is the case, then local being 356 would show the counts got reset on
> the AGENT side, correct?
>

I believe this is correct, but I don't know much about how Daniel Cid
had this all setup.
On the server, I think the highest response from the agent is kept in
`/var/ossec/queue/rids/agent_id` and the msg counter for the server is
kept in sender_counter.
But again, I haven't dug into all that yet.

> Thanks for your help!
>
> --
>
> ---
> 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] Debugging agent connectivity

[dan (ddp)]

On Wed, Feb 8, 2017 at 7:36 AM, Quintin Beukes  wrote:
> Hi group,
>
> I'm trying to debug why my agent's are always showing disconnected. They
> would work for a bit, and then randomly stop working. Some agents will
> disconnect permanently, some intermittently switch between
> connected/disconnected. Any advice on how to increase logging verbosity or
> why my agents are not working properly.
>
> I enabled debugging which had no increase in logging verbosity. I did so by
> editing internal_options.conf and setting
> on server: remoted.debug=2 run "/var/ossec/bin/ossec-control enable debug"
> and restart service
> on agent: agent.debug=2, and restart service
>
> This is happening with many agents both outside and inside the OSSEC subnet.
> I disabled both iptables firewalls for this test.
>
> Server IP: 10.10.12.171
> Agent IP: 10.10.12.170
>
> Server uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Agent uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> My agent always shows disconnected:
>ID: 003, Name: safetynet1, IP: 10.10.12.170, Disconnected
>
> The ossec server log doesn't show anything related.
>
> The ossec agent log just repeatedly shows:
> -
> 2017/02/08 12:20:29 ossec-agentd: INFO: Trying to connect to server
> ossec.jeoffice, port 1514.
> 2017/02/08 12:20:29 INFO: Connected to ossec.jeoffice at address
> 10.10.12.171, port 1514
> 2017/02/08 12:20:50 ossec-agentd(4101): WARN: Waiting for server reply (not
> started). Tried: 'ossec.jeoffice'.
> -
>
> Content of server /etc/ossec-init.conf
> -
> DIRECTORY="/var/ossec"
> VERSION="2.9.0"
> DATE="Wed Jan 25 09:55:39 EST 2017"
> TYPE="server"
> -
>
> Content of server /etc/ossec-init.conf
> -
> DIRECTORY="/var/ossec"
> VERSION="2.9.0"
> DATE="Wed Jan 25 09:55:39 EST 2017"
> TYPE="agent"
> -
>
> A server tcpdump shows:
> -
> 14:14:54.281902 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:14:59.280963 ARP, Request who-has 10.10.12.171 tell 10.10.12.170, length
> 28
> 14:14:59.280987 ARP, Reply 10.10.12.171 is-at f2:1e:73:71:3e:c8, length 28
> 14:15:00.282405 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:04.282833 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:09.283445 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:15.284415 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:32.803559 IP 10.10.12.171.1514 > 10.10.12.170.50637: UDP, length 73
> -
>
> An agent dump shows:
> -
> 14:14:54.280480 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:00.281305 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:04.281914 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:09.282433 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:15.283291 IP 10.10.12.170.50637 > 10.10.12.171.1514: UDP, length 73
> 14:15:32.803186 IP 10.10.12.171.1514 > 10.10.12.170.50637: UDP, length 73
> -
>

So it looks like there is some communication, and if nothing about
that agent shows up in the ossec server's ossec.log I'd think that
things are working.
Check the permissions of
`/var/ossec/queue/agent-info/safetynet1-10.10.12.170` My agents info
files are:
-rw-r--r--  1 ossecr  ossec  137 Feb  8 13:45 buzzell-192.168.17.8
-rw-r--r--  1 ossecr  ossec  105 Feb  8 13:42 ipyr-172.16.17.10
-rw-r--r--  1 ossecr  ossec  107 Feb  8 13:43 junction-192.168.17.17



> Quintin
>
> --
>
> ---
> 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-active response, how to refere files? [Linux]

[dan (ddp)]

On Tue, Feb 7, 2017 at 12:40 PM, Nil  wrote:
> Hi, I would like to know how can i reference the file that triggered an
> alert in order to use it with the commands
> i.e   If file X were modified, I would like to do a `cp  /full/path/of/X
> /some/other/path`
>

I don't believe this information is passed to the AR script.

> --
>
> ---
> 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] Decoder with parent and two prematches for avira virus software

[dan (ddp)]

On Feb 7, 2017 6:28 AM, "Dominik"  wrote:

I would like to write a decoder for a logfile with entries of the following
kind:


27.01.2017,09:06:17 [INFO] Engine-Version:  8.3.42.156
27.01.2017,09:06:17 [INFO] VDF-Version:  8.12.150.34
27.01.2017,09:06:17 [INFO] APC-Version:  2.7.1.3
27.01.2017,09:06:17 [INFO] RDF-Version:  14.0.5.76
27.01.2017,09:06:17 [INFO] Echtzeit-Scanner-Version: 15.00.24.143
27.01.2017,09:06:18 [INFO] [ACP] Load Avira Communication Protocol and
initialize message broker
27.01.2017,09:06:18 [INFO] [ACP] Publish the ACP activity resource
27.01.2017,09:06:18 [INFO] [ACP] Start of the ACP message broker is triggered
27.01.2017,09:06:18 [INFO] Verwendete Konfiguration der Echtzeit-Scanner:
  - Geprüfte Dateien: Dateien von lokalen Laufwerken prüfen
  - Geprüfte Dateien: Dateierweiterungsliste verwenden: .386 .?HT*
.ACM .ADE .ADP .ANI .APK .APP .ASD .ASF .ASP .ASX .AWX .AX .BAS .BAT
.BIN .BOO .CDF .CHM .CLASS .CMD .CNV .COM .CPL .CPX .CRT .CSH .DEX
.DLL .DLO .DO* .DRV .EMF .EML .EXE* .FAS .FLT .FOT .HLP .HT* .INF .INI
.INS .ISP .J2K .JAR .JFF .JFI .JFIF .JIF .JMH .JNG .JP2 .JPE .JPEG
.JPG .JS* .JSE .LNK .LSP .MD? .MDB .MOD .MS? .NWS .OBJ .OCX .OLB .OSD
.OV? .PCD .PDF .PDR .PGM .PHP .PIF .PKG .PL* .PNG .POT* .PPAM .PPS*
.PPT* .PRG .RAR .REG .RPL .RTF .SBF .SCR .SCRIPT .SCT .SH .SHA .SHB
.SHS .SHTM* .SIS .SLD? .SPL .SWF .SYS .TLB .TSP .TTF .URL .VB? .VCS
.VLM .VXD .VXO .WIZ .WLL .WMD .WMF .WMS .WMZ .WPC .WSC .WSF .WSH .WWK
.XAR .XL* .XML .XXX .ZIP
  - Gerätemodus: Datei beim Öffnen durchsuchen, Datei nach
Schließen durchsuchen
  - Aktion: Benutzer fragen
  - Archive durchsuchen: Deaktiviert
  - Makrovirenheuristik: Aktiviert
  - Win32 Dateiheuristik: Erkennungsstufe mittel
  - Protokollierungsstufe: Standard
27.01.2017,09:06:18 [INFO] Online-Dienste stehen zur Verfügung.
27.01.2017,09:17:04 [INFO] Update-Auftrag gestartet!
27.01.2017,09:17:15 [INFO]
-
27.01.2017,09:17:15 [INFO] Engine-Version:  8.3.42.156
27.01.2017,09:17:15 [INFO] VDF-Version:  8.12.150.78
27.01.2017,09:17:15 [INFO] APC-Version:  2.7.1.3
27.01.2017,09:17:15 [INFO] RDF-Version:  14.0.5.76
27.01.2017,09:17:15 [INFO] Echtzeit-Scanner-Version: 15.00.24.143
27.01.2017,09:27:17 [WARNUNG] Der Zugriff auf die Datei
'H:\autorun.inf' wurde blockiert.



Currently, I do not care about the multi-line entries.

I managed to write the following decoders, which work fine:

  \d\d.\d\d.\d\d\d\d,\d\d:\d\d:\d\d [INFO]


  \d\d.\d\d.\d\d\d\d,\d\d:\d\d:\d\d [WARNUNG]


I would like to add a parent that matches the date and the time and two
child-decoders that distinguish WARNUNG and INFO. However, I was
unsuccessful with the following attempt:


  \d\d.\d\d.\d\d\d\d,\d\d:\d\d:\d\d [



  avira
  INFO


  avira
  WARNING


As a result, only the first decoder matches. How do I get this to run?
Tanks in advance!


Only the parent decoder is mentioned in ossec-logtest. The child decoders
might be matching, but it's tough to tell without pulling any fields 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/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] Central ossec.conf management question

[dan (ddp)]

On Wed, Feb 1, 2017 at 1:12 PM,   wrote:
> Just a note, I have had /var/ossec/etc/shared/agent.conf go from having
> content back to being blank a number of times here without having any
> interaction on the server. Has anyone else experienced this?
>

Did you install OSSEC from source, or from a package?

> On Wednesday, February 1, 2017 at 12:38:44 PM UTC-5, dan (ddpbsd) wrote:
>>
>> On Wed, Feb 1, 2017 at 12:25 PM,   wrote:
>> > Hello All,
>> >
>> > I am currently working on a central ossec.conf file which contains our
>> > Windows and Linux configurations for all clients. Here are a few
>> > background
>> > details:
>> >
>> > 1. We currently only have a few Linux deployments and roughly 6 Windows
>> > deployments as a POC
>> > 2. All clients have a custom config, specific to Windows or Linux
>> >
>> > Now, I'd like to manage clients going forward with a central config file
>> > using agent.conf within /var/ossec/etc/shared. I've followed these
>> > steps:
>> >
>> > 1.Created an agent.conf file, and ran verify-agent-conf without any
>> > issues.
>> > 2. Ran MD5SUM against the agent.conf and noted hash
>> > 3. Ran agent-control -R  against a few clients
>> > 4. Ran agent-control -i  and verified that the MD5 changed to match
>> > the
>> > agent.conf hash
>> > 5. I review the agent.conf file on a Windows client that had updated and
>> > it
>> > is blank
>> > 6. I review the merged.mg file on the same client and I do see within
>> > the
>> > file that the custom agent.conf from the server is present
>> > 7. I go back to the /var/ossec/etc/shared/agent.conf and now see that it
>> > is
>> > completely blank with a different MD5
>> >
>> > Can anyone explain why the agent.conf on the server would have the
>> > content
>> > removed? My guess is that if the client doesn't have this info in the
>> > agent.conf that it is only reading their local ossec.conf file?
>> >
>> > As a side note, do I need to re-deploy a new ossec.conf to clients out
>> > there
>> > with only the server IP configuration or will OSSEC merge the config
>> > with
>> > the agent.conf on the server?
>> >
>>
>> There shouldn't be anything in ossec that will blank the agent.conf on
>> the server.
>> If there is no agent.conf, the agent will use the ossec.conf.
>> The running configuration merges the ossec.conf and agent.conf.
>>
>> > Thanks all for the help!
>> >
>> > Eric
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] Central ossec.conf management question

[dan (ddp)]

On Wed, Feb 1, 2017 at 12:25 PM,   wrote:
> Hello All,
>
> I am currently working on a central ossec.conf file which contains our
> Windows and Linux configurations for all clients. Here are a few background
> details:
>
> 1. We currently only have a few Linux deployments and roughly 6 Windows
> deployments as a POC
> 2. All clients have a custom config, specific to Windows or Linux
>
> Now, I'd like to manage clients going forward with a central config file
> using agent.conf within /var/ossec/etc/shared. I've followed these steps:
>
> 1.Created an agent.conf file, and ran verify-agent-conf without any issues.
> 2. Ran MD5SUM against the agent.conf and noted hash
> 3. Ran agent-control -R  against a few clients
> 4. Ran agent-control -i  and verified that the MD5 changed to match the
> agent.conf hash
> 5. I review the agent.conf file on a Windows client that had updated and it
> is blank
> 6. I review the merged.mg file on the same client and I do see within the
> file that the custom agent.conf from the server is present
> 7. I go back to the /var/ossec/etc/shared/agent.conf and now see that it is
> completely blank with a different MD5
>
> Can anyone explain why the agent.conf on the server would have the content
> removed? My guess is that if the client doesn't have this info in the
> agent.conf that it is only reading their local ossec.conf file?
>
> As a side note, do I need to re-deploy a new ossec.conf to clients out there
> with only the server IP configuration or will OSSEC merge the config with
> the agent.conf on the server?
>

There shouldn't be anything in ossec that will blank the agent.conf on
the server.
If there is no agent.conf, the agent will use the ossec.conf.
The running configuration merges the ossec.conf and agent.conf.

> Thanks all for the help!
>
> Eric
>
> --
>
> ---
> 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] Monitoring syslog activity/traffic

[dan (ddp)]

On Wed, Feb 1, 2017 at 7:14 AM, Tibor Luth  wrote:
> Nothing at all. That's why I thought to monitor a command output. Primarily
> in the mentioned (ossec-server side) appliance. Thanks the reply. (I havent
> figured out any solution yet).
>

Well there should be alerts when an agent disconnects. Beyond that, I
think your only option is hacking something up with ELK or a similar
technology.
I have been thinking about these issues, but as always time is an issue.

> 2017. január 31., kedd 15:23:00 UTC+1 időpontban dan (ddpbsd) a következőt
> írta:
>>
>> On Mon, Jan 30, 2017 at 9:14 AM, Tibor Luth  wrote:
>> > Hi all!
>> >
>> > I have a few datasources sending remote syslog to an OSSIM appliance
>> > running
>> > Rsyslog (udp or tcp/514) and OSSEC server and local agent. First I would
>> > like to generate alerts or see in logs if a datasource (ossec-agents
>> > also)
>> > lost connection or stopped logging... (eg. misconfiguration happened,
>> > new
>> > firewall rule is blocking.. etc). Is it possible somehow? I thought to
>> > monitor a command with OSSEC like tcpdump, tshark, netstat or somehing
>> > like
>> > that for standard syslog protocoll and write a custom ossim plugin for
>> > local
>> > ossec.log.
>> > Ideas are welcomed! :)
>> > Thank you!
>> >
>>
>> Do you have any logs that indicate the system is no longer logging to
>> the intended destination?
>>
>> > T.
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] need help with a rule

[dan (ddp)]

On Tue, Jan 31, 2017 at 11:15 AM, SternData
 wrote:
> I'm getting hammered by probes for non-existent PHP files.
>
> Received From: sugaree->/var/log/httpd/xxx.c om_error_log
> Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
> Portion of the log(s):
>
> [Tue Jan 31 09:57:35.809951 2017] [proxy_fcgi:error] [pid 25770] [client
> 46.28.110.136:51282] AH01071: Got error 'Primary script unknown\n'
>
> What's the best way to make a rule to throw an active deny response for
> these after two attempts within 1 minute?
>

Running this through ossec-logtest gives me the following information:
**Phase 1: Completed pre-decoding.
   full event: '[Tue Jan 31 09:57:35.809951 2017]
[proxy_fcgi:error] [pid 25770] [client 46.28.110.136:51282] AH01071:
Got error 'Primary script unknown\n''
   hostname: 'ossec-test'
   program_name: '(null)'
   log: '[Tue Jan 31 09:57:35.809951 2017] [proxy_fcgi:error] [pid
25770] [client 46.28.110.136:51282] AH01071: Got error 'Primary script
unknown\n''

**Phase 2: Completed decoding.
   decoder: 'apache-errorlog'
   srcip: '46.28.110.136'
   srcport: '51282'
   id: 'AH01071'

**Phase 3: Completed filtering (rules).
   Rule id: '30301'
   Level: '0'
   Description: 'Apache error messages grouped.'

So creating a rule should be fairly straight forward.
Something like this (mostly untested):

  30301
  Primary script unknown
  Primary script unknown


  400017
  
  Multiple attempts to Primary script unknown


Then setup the active response to block based on sid 400018.

-- 

--- 
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] Unable to capture file integrity changes more than 3 times with auto_ignore

[dan (ddp)]

On Tue, Jan 31, 2017 at 7:06 AM, Abhijit Tikekar
 wrote:
> Hi,
>
> I am unable to make  work on our OSSEC instance for few
> directories which are set for Real Time monitoring. OSSEC Agent version is
> 2.8.3 and server is currently on 2.8.1.
>

Start by correcting this issue.

> I have tried to set no on both server and the
> agent, but OSSEC still keeps ignoring the checksum change after 3rd time.
>

This setting does nothing on the agent, AFAIK.

> Here is the directory monitoring configuration:
>
> 79200
> /usr/bin,/usr/sbin
> /bin,/sbin
> /root,/etc
> no
>

Make sure you restart the OSSEC processes on the server after making
these changes.

>
> And the file we are trying to monitor is /etc/odbcnew.ini
>
> When I check for the file changes, OSSEC always stops after 3rd change. I
> can reset it manually but it'll stop again eventually after next 3 changes.
>
> 2017 Jan 31 06:44:24,0 - /etc/odbcnew.ini
> File changed. - 1st time modified.
> Integrity checking values:
>Size: >682
>Perm: rw---
>Uid:  0
>Gid:  0
>Md5:  >bc47acc61dd3ac8f88d8a1197e3e9b1a
>Sha1: >02d20920310be144261d897d90d906e86a90225f
>
> 2017 Jan 31 06:47:15,2 - /etc/odbcnew.ini
> File changed. - 2nd time modified.
> Integrity checking values:
>Size: >770
>Perm: rw---
>Uid:  0
>Gid:  0
>Md5:  >087e76a102721db3c7218acb978720b2
>Sha1: >f5437d9ede1d2bb41cafbefce922d1c5997a3c13
>
> 2017 Jan 31 06:47:16,3 - /etc/odbcnew.ini
> File changed. - 3rd time modified.
> Integrity checking values:
>Size: >792
>Perm: rw---
>Uid:  0
>Gid:  0
>Md5:  >0ba151babde2a5adf64fb25b67628e9b
>Sha1: >266ff0c7ae1b19897046041da3df2beb598a1663
>
> I found an old thread referring to making a source code change for
> temporarily resolve this issue. Is that change still needed in the latest
> versions?
> https://groups.google.com/forum/#!topic/ossec-list/qk8Ch6DEIqk
>

Not that I'm aware of.

> On another thread, one example shows that OSSEC still records the fact that
> a file is being ignored.
> https://groups.google.com/forum/#!topic/ossec-list/qNnjYZGsWCs
>
> 2008 Jun 26 22:48:26,4 - /etc/squid/squid.conf
> File changed. - Being ignored (3 or more changes).
>
>
> We do not get this message. Does that mean agent itself is not sending the
> changes after 3rd time?
>

The agent doesn't care how many times it's changed. It doesn't even
really know the file has changed (unless there's an inotify event blah
blah).

I haven't noticed any issues with it, but I'll test it out a bit.

>
> Kindly assist
>
> Thanks,
>
> ~ Abhi
>
>
>
>
>
>
> --
>
> ---
> 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: Alerts generated despite level '0' rule being hit

[dan (ddp)]

On Fri, Jan 27, 2017 at 11:00 AM, Daniel B.  wrote:
>
> Yes, via ./ossec-control -r
>

root@ossec-test:/var/ossec/etc# /var/ossec/bin/ossec-control -r

Usage: /var/ossec/bin/ossec-control {start|stop|restart|status|enable|disable}

Try `/var/ossec/bin/ossec-control restart`

>
> On Thursday, January 26, 2017 at 4:41:20 PM UTC-5, Daniel B. wrote:
>>
>>
>>
>> full_log:
>>
>> Files hidden inside directory 
>> '/var/lib/docker/aufs/mnt/545d04c068f0f7ce19361a94d1c43b0c6686a0dfdd45e1803ccee569acc1767b/usr/share/locale'.
>>  Link count does not match number of files (54,70).
>>
>> I have a rule setup to ignore this, and it's actually being hit when I test 
>> the above line via ./ossec-logtest -v (see image)
>>
>> When I check the alerts, I see this as a level 7 alert.
>>

At some point was 76 level 7? Or are you seeing a different level 7 alert?

>> The rules are defined on the server. Any idea on why an alert would be 
>> generated despite the level 0 rule being hit?
>>
>> Decoder:

 

   Files hidden inside directory 

   (\p/var/lib/docker\.+)

   extra_data

 
>>
>>
>> Rule:
>>>
>>> 
>>>
>>> ignore_docker_mismatch
>>>
>>> Level 0 Alert -- Ignoring Docker Files 
>>> Mismatch
>>>
>>>   
>>>
>>>
>>
>>
>>
> --
>
> ---
> 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 2.8.3 create custom rule

[dan (ddp)]

On Mon, Jan 30, 2017 at 9:54 AM, Eli Tunkel  wrote:
> Hi Guys
>
>
> I am looking to create a new custom ossec rult to capture specific phrase in
> a log.
> I have added the required directory to the ossec.conf 
> monitoring.
>
> LOG Sample:
>
> 2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
> [.m.async.facade.Bootstrap] Became Leader!!!  |TAGS|
> 2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
> [.m.async.facade.Bootstrap] ## Leader election:
> Server is leader and starting ##  |TAGS|
>
> Looking to find
>
>
> Leader election: Server is leader and starting
>

I'm assuming you haven't tried, so here's a basic run down.

Start with ossec-logtest:
# echo '2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
[.m.async.facade.Bootstrap] ## Leader
election: Server is leader and starting ##
 |TAGS|' | /var/ossec/bin/ossec-logtest

**Phase 1: Completed pre-decoding.
   full event: '2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
[.m.async.facade.Bootstrap] ## Leader
election: Server is leader and starting ##
 |TAGS|'
   hostname: 'INFO'
   program_name: '(null)'
   log: ' [main-EventThread  ] [.m.async.facade.Bootstrap]
## Leader election: Server is leader and
starting ##  |TAGS|'

**Phase 2: Completed decoding.
   No decoder matched.

The "log" field is what we'll be working with mostly. So let's add a
basic rule to local_rules.xml:
  
m.async.facade.Bootstrap
Stuff
  

Re-run logtest:
**Phase 1: Completed pre-decoding.
   full event: '2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
[.m.async.facade.Bootstrap] ## Leader
election: Server is leader and starting ##
 |TAGS|'
   hostname: 'INFO'
   program_name: '(null)'
   log: ' [main-EventThread  ] [.m.async.facade.Bootstrap]
## Leader election: Server is leader and
starting ##  |TAGS|'

**Phase 2: Completed decoding.
   No decoder matched.

**Phase 3: Completed filtering (rules).
   Rule id: '41'
   Level: '1'
   Description: 'Stuff'
**Alert to be generated.

As we can see our new rule is matched. So let's look at more specific
details to get exactly what you want:
  
41
Leader election: Server is leader and starting
Leader election.
  

More logtest:
**Phase 1: Completed pre-decoding.
   full event: '2016-07-24 11:43:22,707 INFO  [main-EventThread  ]
[.m.async.facade.Bootstrap] ## Leader
election: Server is leader and starting ##
 |TAGS|'
   hostname: 'INFO'
   program_name: '(null)'
   log: ' [main-EventThread  ] [.m.async.facade.Bootstrap]
## Leader election: Server is leader and
starting ##  |TAGS|'

**Phase 2: Completed decoding.
   No decoder matched.

**Phase 3: Completed filtering (rules).
   Rule id: '42'
   Level: '1'
   Description: 'Leader election.'
**Alert to be generated.

Final rules:
   
m.async.facade.Bootstrap
m.async.facade.Bootstrap group 
  

   
41
Leader election: Server is leader and starting
Leader election.
  

Add those and restart the ossec processes on the master.

> Thanks ahead!!
>
>
> --
>
> ---
> 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] Create rules for custom decoder (netasq/stomshield firewall)

[dan (ddp)]

On Mon, Jan 30, 2017 at 10:46 AM, Bertrand Danos  wrote:
> Hello,
>
> I still have some problems with my customes rules.
> How to generate 3 differents alerts depending on the messages.
>
>
> Here are my steps :
>
> 1) Add log file to monitor
> * Edit the file etc/ossec.conf and add the following lines:
>   
> syslog
> /var/log/firewall.log
>   
>
>
> 2) Create a decoder
> * Add in file etc/local_decoder.xml the following lines :
>
> 
>   ^id=
> 
>
> 
>   netasq
>   logtype="auth"
>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ user="(\S+)" src=(\S+) \.+
> logtype="auth"
>   id, extra_data, user, srcip
> 
>
> 
>   netasq
>   logtype="filter"
>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)" ipproto=(\S+)
> proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+) dstport=(\d+) \.+
> logtype="(\S+)"
>   id, extra_data, extra_data, protocol, protocol, srcip, srcport,
> dstip, dstport

I think you have too many entries in  here. There's a limit,
apparently you reached it.
I segfaulted with this decoder, but removing the srcifname entry fixed
it for me.

> 
>
> 
>   netasq
>   logtype="alarm"
>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ msg="(\.+)" \.+
> logtype="alarm"
>   id, extra_data, extra_data, action
> 
>
>
> 3) Write custom rules :
> * Edit the file etc/ossec.conf and add in  the line :
> netasq.xml
>
> * Create file rules/netasq.xml
>
> 
>
>   

These IDs appear to be too large. Remove a 0.

> netasq-auth

All of the log messages decode as "netasq."

> Authentication failure on firewall
>   
>
>   
> netasq-filter
> Firewall has filtered some data
>   
>
>   
> netasq-alarm
> Firewall has gnerated an alarm
>   
>
> 
>
>
> For each sample I'd like to receive one of the 3 alerts :
>
> Dec  2 15:42:29 192.168.200.1 id=firewall time="2016-12-02 15:42:28"
> fw="test-fw" tz=+ startime="2016-12-02 15:42:28" user="admin"
> src=10.0.0.1 ruleid=0 method="PLAIN" error=4 msg="Authentication request
> invalid" logtype="auth"#015
>
> Dec  2 14:37:42 192.168.200.1 id=firewall time="2016-12-02 14:37:41"
> fw="test-fw" tz=+ startime="2016-12-02 14:37:40" pri=5 confid=01
> slotlevel=2 ruleid=1 srcif="Ethernet2" srcifname="eth2" ipproto=tcp
> proto=ssh src=10.0.0.2 srcport=33659 srcportname=ephemeral_fw_tcp
> srcname=admin dst=192.168.1.1 dstport=22 dstportname=ssh dstname=fw
> action=pass logtype="filter"#015
>
> Jan  9 14:54:32 192.168.200.1 id=firewall time="2017-01-09 14:53:49"
> fw="test-fw" tz=+ startime="2017-01-09 14:53:48" pri=4 confid=01
> slotlevel=2 ruleid=13 srcif="Ethernet2" srcifname="eth2" ipproto=icmp
> icmptype=8 icmpcode=0 proto=icmp src=10.0.0.2 dst=192.168.1.1 dstname=fw
> action=block msg="Filter alarm" class=filter classification=0
> logtype="alarm"#015
>

logtest output:
**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 15:42:29 192.168.200.1 id=firewall
time="2016-12-02 15:42:28" fw="test-fw" tz=+ startime="2016-12-02
15:42:28" user="admin" src=10.0.0.1 ruleid=0 method="PLAIN" error=4
msg="Authentication request invalid"
logtype="auth"#015'
   hostname: '192.168.200.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 15:42:28" fw="test-fw"
tz=+ startime="2016-12-02 15:42:28" user="admin" src=10.0.0.1
ruleid=0 method="PLAIN" error=4 msg="Authentication request invalid"
logtype="auth"#015'

**Phase 2: Completed decoding.
   decoder: 'netasq'
   id: 'firewall'
   extra_data: 'test-fw'
   dstuser: 'admin'
   srcip: '10.0.0.1'

**Phase 3: Completed filtering (rules).
   Rule id: '1002'
   Level: '2'
   Description: 'Unknown problem somewhere in the system.'
**Alert to be generated.




**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 14:37:42 192.168.200.1 id=firewall
time="2016-12-02 14:37:41" fw="test-fw" tz=+ startime="2016-12-02
14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 srcif="Ethernet2"
srcifname="eth2" ipproto=tcp proto=ssh src=10.0.0.2 srcport=33659
srcportname=ephemeral_fw_tcp srcname=admin dst=192.168.1.1 dstport=22
dstportname=ssh dstname=fw action=pass logtype="filter"#015'
   hostname: '192.168.200.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 14:37:41" fw="test-fw"
tz=+ startime="2016-12-02 14:37:40" pri=5 confid=01 slotlevel=2
ruleid=1 srcif="Ethernet2" srcifname="eth2" ipproto=tcp proto=ssh
src=10.0.0.2 srcport=33659 srcportname=ephemeral_fw_tcp srcname=admin
dst=192.168.1.1 dstport=22 dstportname=ssh dstname=fw action=pass
logtype="filter"#015'

**Phase 2: Completed decoding.
   decoder: 'netasq'
   id: 'firewall'
   extra_data: 'test-fw'
   proto: 'tcp'
   proto: 'ssh'
   srcip: '10.0.0.2'
   srcport: '33659'
   dstip: '192.168.1.1'
   dstport: '22'


**Phase 1: Completed pre-decoding.
   full event: 'Jan  9 14:54:32 192.168.200.1 id=firewall
time="2017-01-09 14:53:49" fw="test-fw" tz=+ startime="2017-01-09
14:53:48" pri=4 confid=01 slotlevel=2 ruleid=13 

Re: [ossec-list] how to modify the apache log decoder to accept dash in time

[dan (ddp)]

On Sun, Jan 29, 2017 at 2:54 PM,   wrote:
> My web servers logs are being decoded as 'pure-transfer' instead of as an
> apache log due to the time format, which includes a dash '-". If I remove
> the dash, then the logs are decoded as apache logs. I believe I have to
> options: 1) change the precedence of the decoders, giving priority to apache
> or 2) update the format of the logs in my apache config. Please explain how
> I would change the precedence or perhaps there is a better solution?
>
> My OSSEC server is running OSSEC HIDS v2.8.3.
>
> SAMPLE LOG FILE:
> 46.229.168.71 - - [29/Jan/2017:06:34:13 -0800] "GET
> /web/guest/community-action1%3BOldBars58@jsessionid%3D194335F9E14CFE295BDBAACC95467F6D
> HTTP/1.1" 404 27590 "-" "Mozilla/5.0 (compatible; SemrushBot/1.2~bl;
> +http://www.semrush.com/bot.html)"
>

On post 2.8 installs this seems to be picked up by the web-accesslog decoder:
**Phase 1: Completed pre-decoding.
   full event: '46.229.168.71 - - [29/Jan/2017:06:34:13 -0800]
"GET 
/web/guest/community-action1%3BOldBars58@jsessionid%3D194335F9E14CFE295BDBAACC95467F6D
HTTP/1.1" 404 27590 "-" "Mozilla/5.0 (compatible; SemrushBot/1.2~bl;
http://www.semrush.com/bot.html)"'
   hostname: 'ossec-test'
   program_name: '(null)'
   log: '46.229.168.71 - - [29/Jan/2017:06:34:13 -0800] "GET
/web/guest/community-action1%3BOldBars58@jsessionid%3D194335F9E14CFE295BDBAACC95467F6D
HTTP/1.1" 404 27590 "-" "Mozilla/5.0 (compatible; SemrushBot/1.2~bl;
http://www.semrush.com/bot.html)"'

**Phase 2: Completed decoding.
   decoder: 'web-accesslog'
   srcip: '46.229.168.71'
   url: 
'/web/guest/community-action1%3BOldBars58@jsessionid%3D194335F9E14CFE295BDBAACC95467F6D'
   id: '404'

**Phase 3: Completed filtering (rules).
   Rule id: '31101'
   Level: '5'
   Description: 'Web server 400 error code.'
**Alert to be generated.


> Thank you,
>
> Gil Vidals
> Etica, Inc.
>
> --
>
> ---
> 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] Monitoring syslog activity/traffic

[dan (ddp)]

On Mon, Jan 30, 2017 at 9:14 AM, Tibor Luth  wrote:
> Hi all!
>
> I have a few datasources sending remote syslog to an OSSIM appliance running
> Rsyslog (udp or tcp/514) and OSSEC server and local agent. First I would
> like to generate alerts or see in logs if a datasource (ossec-agents also)
> lost connection or stopped logging... (eg. misconfiguration happened, new
> firewall rule is blocking.. etc). Is it possible somehow? I thought to
> monitor a command with OSSEC like tcpdump, tshark, netstat or somehing like
> that for standard syslog protocoll and write a custom ossim plugin for local
> ossec.log.
> Ideas are welcomed! :)
> Thank you!
>

Do you have any logs that indicate the system is no longer logging to
the intended destination?

> T.
>
> --
>
> ---
> 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] Alerts generated despite level '0' rule being hit

[dan (ddp)]

On Thu, Jan 26, 2017 at 4:41 PM, Daniel B.  wrote:
>
>
>
> full_log:
>
> Files hidden inside directory 
> '/var/lib/docker/aufs/mnt/545d04c068f0f7ce19361a94d1c43b0c6686a0dfdd45e1803ccee569acc1767b/usr/share/locale'.
>  Link count does not match number of files (54,70).
>
> I have a rule setup to ignore this, and it's actually being hit when I test 
> the above line via ./ossec-logtest -v (see image)
>
> When I check the alerts, I see this as a level 7 alert.
>
> The rules are defined on the server. Any idea on why an alert would be 
> generated despite the level 0 rule being hit?
>

Did you restart the OSSEC processes on the server after adding your rule?

> Decoder:
>>>
>>> 
>>>
>>>   Files hidden inside directory 
>>>
>>>   (\p/var/lib/docker\.+)
>>>
>>>   extra_data
>>>
>>> 
>
>
> Rule:
>>
>> 
>>
>> ignore_docker_mismatch
>>
>> Level 0 Alert -- Ignoring Docker Files 
>> Mismatch
>>
>>   
>>
>>
>
>
>
> --
>
> ---
> 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: ossec-analysisd won't start, "could not create directory"

[dan (ddp)]

On Wed, Jan 25, 2017 at 3:05 PM, Kat  wrote:
> My bad - I should have explained "bind" a bit more.  This is actually part
> of the FUSE filesystem (http://bindfs.org)
> You will need to install fuse utils and Userspace programs -- example:
>
> #yum search fuse
>
>
> fuse.x86_64 : File System in Userspace (FUSE) utilities
>
>
> I could write it all up -- perhaps I will do a quick userguide doc that can
> be added to OSSEC.  I specifically use this method with sshfs to mount a
> larger file store on the backend of my OSSEC managers.
>

It would possibly be a good candidate for this section of the documentation:
https://ossec.github.io/docs/cookbooks/index.html (excuse the obvious
typo, it's being corrected)

> Kat
>
> On Friday, January 13, 2017 at 1:28:42 PM UTC-6, Joel wrote:
>>
>> hi all,
>>
>> man, not having a good day.
>>
>> I was starting to run out of space on my / volume as a result of ossec
>> logs piling up.   i need to keep the logs, so i added a new drive (to the
>> ossec VMW vm) mounted it and then moved the logs/ directory to the new
>> mount.
>>
>> now, when starting ossec, ossec-analysisd won't start.  I think it's
>> trying to chroot and can't cross the filesystem boundary...?
>>
>>> 2017/01/13 19:24:47 ossec-analysisd(1210): ERROR: Queue
>>> '/queue/alerts/ar' not accessible: 'Connection refused'.
>>> 2017/01/13 19:24:47 ossec-analysisd(1301): ERROR: Unable to connect to
>>> active response queue.
>>> 2017/01/13 19:24:50 ossec-analysisd(1210): ERROR: Queue
>>> '/queue/alerts/execq' not accessible: 'Connection refused'.
>>> 2017/01/13 19:24:50 ossec-analysisd(1301): ERROR: Unable to connect to
>>> active response queue.
>>> 2017/01/13 19:24:50 ossec-analysisd: DEBUG: Active response Init
>>> completed.
>>> 2017/01/13 19:24:50 ossec-analysisd(1107): ERROR: Could not create
>>> directory '/logs/archives/2017/' due to [(2)-(No such file or directory)].
>>
>>
>> and
>>
>>> [root@e-ossec-001: /var/ossec]# ls -ald /data/logs/ossec/
>>> drwxr-xr-x 6 ossec ossec 129 Jan 13 19:03 /data/logs/ossec/
>>> [root@e-ossec-001: /var/ossec]# ls -al /var/ossec/
>>> total 24
>>> dr-xr-x---  16 root  ossec 4096 Jan 13 18:55 .
>>> drwxr-xr-x. 20 root  root  4096 Jan 13 19:21 ..
>>> dr-xr-x---   3 root  ossec   16 Jan 12 22:05 active-response
>>> dr-xr-x---   2 root  ossec 4096 Oct  6 13:37 agentless
>>> drwxr-x---   3 root  ossec   19 Oct  6 13:37 backup
>>> dr-xr-x---   2 root  root  4096 Jan 12 18:43 bin
>>> dr-xr-x---   5 root  ossec 4096 Jan 13 16:34 etc
>>> drwxr-x---   2 root  ossec   34 Oct  6 13:37 integrations
>>> lrwxrwxrwx   1 root  root16 Jan 13 18:55 logs -> /data/logs/ossec
>>> dr-xr-x---   4 root  root34 Oct  6 13:37 lua
>>> dr-xr-x---  11 root  ossec  150 Oct  6 13:38 queue
>>> dr-xr-x---   2 root  ossec 4096 Oct 17 13:36 rules
>>> drwx--   2 root  ossec6 Oct  6 13:37 .ssh
>>> drwxr-x---   5 ossec ossec   61 Oct  6 13:57 stats
>>> dr-xr-x--T   2 root  ossec6 Oct  6 13:37 tmp
>>> dr-xr-x---   3 root  root20 Oct  6 13:37 update
>>> dr-xr-x---   3 root  ossec   16 Jan 13 19:24 var
>>
>>
>> do I need to keep it allon the same volume?
>>
>> thanks!
>>
>> Joel
>
> --
>
> ---
> 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: Issues with Multi-server architecture

[dan (ddp)]

On Thu, Jan 5, 2017 at 11:07 AM, Lisa Li  wrote:
> As an update, some incomplete rsyslog related alerts are seen so that makes
> me ask if my issue is related to decoders or even rules. These alerts are
> generated by server-1 and not its 100 clients. Client alerts are not seen at
> all on central, and they are seen on server-1.
>
> Alert on central
> ** Alert 1483629664.4125: mail  - syslog,errors,
> 2017 Jan 05 10:21:04 server-1-> 10.0.0.5|server-1->/var/log/messages
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> [try http://www.rsyslog.com/e/2088 ]
>
> When the actual alert seen on server-1 is
> ** Alert 1483629662.449834033: mail  - syslog,errors,
> 2017 Jan 05 09:21:02 server-1->/var/log/messages
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Jan  5 09:21:01 server-1 rsyslogd-2088: error: peer name not authorized -
> not permitted to talk to it. Names: CN: *.domain;  [try
> http://www.rsyslog.com/e/2088 ]
>


You can use tcpdump to see the actual data going to central.

Beyond that, would a hybrid install make more sense for this setup? I
think this is what it was designed for.

> --
>
> ---
> 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: ossec-analysisd won't start, "could not create directory"

[dan (ddp)]

On Tue, Jan 24, 2017 at 2:12 PM, Kat  wrote:
> There is a work-around which I have used.
> Dan is correct - you can't get to the folder outside of the chroot-ed jail.
> You can however, bring the folder in via:
>
> mount --bind /var/ossec/logs /data/logs/ossec
>
> The trick is to bind the directory so the system still thinks it is part of
> the jail.
>

Assuming you're using a system where this is supported:
[ddp@ix] :; man mount | grep bind
[ddp@ix] :;


> Cheers
> Kat
>
>
> On Friday, January 13, 2017 at 1:28:42 PM UTC-6, Joel wrote:
>>
>> hi all,
>>
>> man, not having a good day.
>>
>> I was starting to run out of space on my / volume as a result of ossec
>> logs piling up.   i need to keep the logs, so i added a new drive (to the
>> ossec VMW vm) mounted it and then moved the logs/ directory to the new
>> mount.
>>
>> now, when starting ossec, ossec-analysisd won't start.  I think it's
>> trying to chroot and can't cross the filesystem boundary...?
>>
>>> 2017/01/13 19:24:47 ossec-analysisd(1210): ERROR: Queue
>>> '/queue/alerts/ar' not accessible: 'Connection refused'.
>>> 2017/01/13 19:24:47 ossec-analysisd(1301): ERROR: Unable to connect to
>>> active response queue.
>>> 2017/01/13 19:24:50 ossec-analysisd(1210): ERROR: Queue
>>> '/queue/alerts/execq' not accessible: 'Connection refused'.
>>> 2017/01/13 19:24:50 ossec-analysisd(1301): ERROR: Unable to connect to
>>> active response queue.
>>> 2017/01/13 19:24:50 ossec-analysisd: DEBUG: Active response Init
>>> completed.
>>> 2017/01/13 19:24:50 ossec-analysisd(1107): ERROR: Could not create
>>> directory '/logs/archives/2017/' due to [(2)-(No such file or directory)].
>>
>>
>> and
>>
>>> [root@e-ossec-001: /var/ossec]# ls -ald /data/logs/ossec/
>>> drwxr-xr-x 6 ossec ossec 129 Jan 13 19:03 /data/logs/ossec/
>>> [root@e-ossec-001: /var/ossec]# ls -al /var/ossec/
>>> total 24
>>> dr-xr-x---  16 root  ossec 4096 Jan 13 18:55 .
>>> drwxr-xr-x. 20 root  root  4096 Jan 13 19:21 ..
>>> dr-xr-x---   3 root  ossec   16 Jan 12 22:05 active-response
>>> dr-xr-x---   2 root  ossec 4096 Oct  6 13:37 agentless
>>> drwxr-x---   3 root  ossec   19 Oct  6 13:37 backup
>>> dr-xr-x---   2 root  root  4096 Jan 12 18:43 bin
>>> dr-xr-x---   5 root  ossec 4096 Jan 13 16:34 etc
>>> drwxr-x---   2 root  ossec   34 Oct  6 13:37 integrations
>>> lrwxrwxrwx   1 root  root16 Jan 13 18:55 logs -> /data/logs/ossec
>>> dr-xr-x---   4 root  root34 Oct  6 13:37 lua
>>> dr-xr-x---  11 root  ossec  150 Oct  6 13:38 queue
>>> dr-xr-x---   2 root  ossec 4096 Oct 17 13:36 rules
>>> drwx--   2 root  ossec6 Oct  6 13:37 .ssh
>>> drwxr-x---   5 ossec ossec   61 Oct  6 13:57 stats
>>> dr-xr-x--T   2 root  ossec6 Oct  6 13:37 tmp
>>> dr-xr-x---   3 root  root20 Oct  6 13:37 update
>>> dr-xr-x---   3 root  ossec   16 Jan 13 19:24 var
>>
>>
>> do I need to keep it allon the same volume?
>>
>> thanks!
>>
>> Joel
>
> --
>
> ---
> 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] Generating alerts based on events outside a specific time slot

[dan (ddp)]

On Wed, Jan 25, 2017 at 6:00 AM, Bertrand Danos <mille...@gmail.com> wrote:
> Hello Dan,
>
> Thanks for the  option.
>
> I failed to used it.
> Here is what's I did :
>
> * Edit file etc/ossec.conf
> * Add in  the line : my_rules.xml
>
> * File rules/my_rules.xml :
>>
>> 
>>
>>   
>> 2501
>> 19:00 - 07:00
>> Not allowed time slot
>>   
>> 
>>
>> 
>
>
>
>
> I've tested the following messages with ossec-logtest :
>
>
> ===
> Dec  5 13:26:42 test-computer pam: gdm-password:
> pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0
> tty=:0 ruser= rhost=  user=foo
> ===
> **Phase 1: Completed pre-decoding.
>full event: 'Dec  5 13:26:42 test-computer pam: gdm-password:
> pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0
> tty=:0 ruser= rhost=  user=foo'
>hostname: 'test-computer'
>program_name: 'pam'
>log: 'gdm-password: pam_unix(gdm-password:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=foo'
>
> **Phase 2: Completed decoding.
>No decoder matched.
>
> **Phase 3: Completed filtering (rules).
>Rule id: '2501'
>Level: '5'
>Description: 'User authentication failure.'
> **Alert to be generated.
>
>
> It's the nominal case. all is ok.
>
>
> ===
> Dec  5 03:26:42 test-computer pam: gdm-password:
> pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0
> tty=:0 ruser= rhost=  user=foo
> ===
>
> **Phase 1: Completed pre-decoding.
>full event: 'Dec  5 03:26:42 test-computer pam: gdm-password:
> pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0
> tty=:0 ruser= rhost=  user=foo'
>hostname: 'test-computer'
>program_name: 'pam'
>log: 'gdm-password: pam_unix(gdm-password:auth): authentication
> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=foo'
>
> **Phase 2: Completed decoding.
>No decoder matched.
>
> **Phase 3: Completed filtering (rules).
>Rule id: '2501'
>Level: '5'
>Description: 'User authentication failure.'
> **Alert to be generated.
>
>
> Here, my rule doesn't work.
> Where I'm wrong?
>

I don't think OSSEC pays attention to the timestamp in the log
message, so you'd have to test this at the correct time to get it to
fire.

> Thanks in advance
>
>
>
>
> 2017-01-19 19:12 GMT+01:00 dan (ddp) <ddp...@gmail.com>:
>>
>> On Thu, Jan 19, 2017 at 11:18 AM, Bertrand Danos <mille...@gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Is it possible to generate alerts on events that are outside a specific
>> > time
>> > slot?
>> >
>> > By sample, detect each user that connect on a computer outside the
>> > (08:00 -
>> > 20:00) timeslot.
>> >
>> >> Jan 19 07:00:00 test-computer runuser: pam_unix(runuser:session):
>> >> session
>> >> opened for user foo by (uid=0)
>> >
>> >
>>
>> Perhaps the  option will help:
>> https://ossec.github.io/docs/syntax/head_rules.html#element-time
>>
>> >
>> > Thanks in advance for your help.
>> >
>> > --
>> >
>> > ---
>> > 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] Re: Update Wazuh with standard Ossec files

[dan (ddp)]

On Jan 22, 2017 4:16 PM, "Kat"  wrote:

The Wazuh fork is actually newer, but regardless there should never be a
conflict from 2.x to 2.x with agent and server. When


*With the caveat that this isn't explicitly tested.


you say "conflict" - can you be more specific on the error you are seeing?

Kat


On Friday, January 20, 2017 at 5:14:09 PM UTC-6, Alejandro M wrote:
>
> Hello all. I just installed the Wazuh fork in a server but after a bit of
> tinkering, I realized there were issues between a previously installed
> agent and this server.
>
> After searching for information, it seems the error is that the agent
> version(2.8.3) is newer than what what comes with Wazuh which apparently is
> 2.8 and it causes a conflict.
>
> Could I update Wazuh's OSSEC with the official ossec files so the server
> matches the agent, without risk of losing my configurations(logstash, etc)
> or I just should use the Wazuh files for agent installation?
>
-- 

---
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: Profiles and agents

[dan (ddp)]

On Fri, Jan 20, 2017 at 8:25 AM, Kat  wrote:
> I already did. :-)
> #1027
>

Thanks, I missed it. It's been merged.

> On Thursday, January 19, 2017 at 12:15:14 PM UTC-6, dan (ddpbsd) wrote:
>>
>> On Tue, Jan 17, 2017 at 3:06 PM, Kat  wrote:
>> > The problem is simple - the install.sh is where this is taken care of,
>> > but
>> > no one ever bothered to add the code when they added the variable of
>> > USER_AGENT_CONFIG_PROFILE.
>> >
>>
>> If you submit a pull request I'll bother with it right now.
>>
>> > Take a look at install.sh and find the top bit of code here -- and you
>> > will
>> > see the part I added to fix the PROFILE:
>> >
>> > echo "" > $NEWCONFIG
>> >
>> > echo "  " >> $NEWCONFIG
>> >
>> > if [ "X${IP}" != "X" ]; then
>> >
>> > echo "$IP" >> $NEWCONFIG
>> >
>> > elif [ "X${HNAME}" != "X" ]; then
>> >
>> > echo "$HNAME" >>
>> > $NEWCONFIG
>> >
>> > fi
>> >
>> > # add this block to check for and add a preset profile name for the
>> > agent (from preloaded-vars.conf)
>> >
>> > if [ "$X{USER_AGENT_CONFIG_PROFILE}" != "X" ]; then
>> >
>> >  PROFILE=${USER_AGENT_CONFIG_PROFILE}
>> >
>> >  echo "$PROFILE" >>
>> > $NEWCONFIG
>> >
>> > fi
>> >
>> > # end of added PROFILE block
>> >
>> > echo "  " >> $NEWCONFIG
>> >
>> > echo "" >> $NEWCONFIG
>> >
>> >
>> > Cheers
>> > Kat
>> >
>> > On Thursday, January 22, 2015 at 4:09:42 AM UTC-6, Slobodan Aleksić
>> > wrote:
>> >>
>> >> Hello list,
>> >>
>> >> I am having trouble setting up agent's ossec.conf by the install.sh
>> >> script correctly.
>> >> Setting "USER_AGENT_CONFIG_PROFILE" in "preloaded-vars.conf" to
>> >> something, doesn't create a  setting in ossec.conf ..
>> >>
>> >> Another thing: How to get a minimal ossec.conf on agents autmatically.
>> >> So that only server and profile settings are kept in ossec.conf and all
>> >> the rest only in agent.conf ?
>> >>
>> >> Thanks in advance
>> >>
>> >>
>> >> --
>> >> Slobodan
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] Re: Profiles and agents

[dan (ddp)]

On Tue, Jan 17, 2017 at 3:06 PM, Kat  wrote:
> The problem is simple - the install.sh is where this is taken care of, but
> no one ever bothered to add the code when they added the variable of
> USER_AGENT_CONFIG_PROFILE.
>

If you submit a pull request I'll bother with it right now.

> Take a look at install.sh and find the top bit of code here -- and you will
> see the part I added to fix the PROFILE:
>
> echo "" > $NEWCONFIG
>
> echo "  " >> $NEWCONFIG
>
> if [ "X${IP}" != "X" ]; then
>
> echo "$IP" >> $NEWCONFIG
>
> elif [ "X${HNAME}" != "X" ]; then
>
> echo "$HNAME" >> $NEWCONFIG
>
> fi
>
> # add this block to check for and add a preset profile name for the
> agent (from preloaded-vars.conf)
>
> if [ "$X{USER_AGENT_CONFIG_PROFILE}" != "X" ]; then
>
>  PROFILE=${USER_AGENT_CONFIG_PROFILE}
>
>  echo "$PROFILE" >> $NEWCONFIG
>
> fi
>
> # end of added PROFILE block
>
> echo "  " >> $NEWCONFIG
>
> echo "" >> $NEWCONFIG
>
>
> Cheers
> Kat
>
> On Thursday, January 22, 2015 at 4:09:42 AM UTC-6, Slobodan Aleksić wrote:
>>
>> Hello list,
>>
>> I am having trouble setting up agent's ossec.conf by the install.sh
>> script correctly.
>> Setting "USER_AGENT_CONFIG_PROFILE" in "preloaded-vars.conf" to
>> something, doesn't create a  setting in ossec.conf ..
>>
>> Another thing: How to get a minimal ossec.conf on agents autmatically.
>> So that only server and profile settings are kept in ossec.conf and all
>> the rest only in agent.conf ?
>>
>> Thanks in advance
>>
>>
>> --
>> Slobodan
>
> --
>
> ---
> 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] Date format in alerts.log (and alerts.json)

[dan (ddp)]

On Thu, Jan 19, 2017 at 12:20 PM, Marianne Härdh  wrote:
> Hello,
>
> I have a question about changing the date format in alerts.log if possible.
> At the moment, I get this as an alert:
>
> ** Alert 1484784302.1529: - pam,syslog,
> 2017 Jan 19 00:05:02 ossec-15->/var/log/secure
> Rule: 5502 (level 3) -> 'Login session closed.'
> Jan 00:005:02 ossec-15 su: pam_unix(su-l:session): session closed for user
> ec2-user
>
> I have tested an upgrade to 2.9 so we could have a log in json which is our
> standard (please note that it's not the identical alert but one of the same
> type):
>
> {"rule":{"level":3,"comment":"Login session
> closed.","sidid":5502,"firedtimes":2,"groups":["pam","syslog"],"PCI_DSS":["10.2.5"]},"full_log":"Jan
> 19 13:20:07 ossec-15 su: pam_unix(su-l:session): session closed for user
> ec2-user","program_name":"su","decoder":{"name":"pam"},"hostname":"ossec-15","timestamp":"2017
> Jan 19 13:20:08","location":"/var/log/secure"}
>
> We use filebeat to read alerts.json, filebeat sends to
> logstash/elasticsearch/kibana.
>
> My problem is the year (2017) that's added to the beginning of the timestamp
> field in the json log (which is added in the alerts.log as well). The
> logstash configuration we have written can't handle that. I know that we
> could rewrite the logstash configuration but would rather change closer to
> the source.
>
> Is this something that can be done in a decoder? Sorry for not RTFM but
> hoping someone can help before I start trawling through the documentation.
>

I believe you'll have to modify the OSSEC source, both analysisd's
output and any log reader's input.

> --
>
> ---
> 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] Generating alerts based on events outside a specific time slot

[dan (ddp)]

On Thu, Jan 19, 2017 at 11:18 AM, Bertrand Danos  wrote:
> Hello,
>
> Is it possible to generate alerts on events that are outside a specific time
> slot?
>
> By sample, detect each user that connect on a computer outside the (08:00 -
> 20:00) timeslot.
>
>> Jan 19 07:00:00 test-computer runuser: pam_unix(runuser:session): session
>> opened for user foo by (uid=0)
>
>

Perhaps the  option will help:
https://ossec.github.io/docs/syntax/head_rules.html#element-time

>
> Thanks in advance for your help.
>
> --
>
> ---
> 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] System Integrity Check questions

[dan (ddp)]

On Wed, Jan 18, 2017 at 3:27 PM, Nikki S  wrote:
> Hi,
>
> I have a couple of questions regarding FIM/System Integrity check. I'm
> hoping this would help others as well starting off with OSSEC.
>
> When a new agent is installed does it run the system integrity check
> automatically? or does the  option needs to be enabled?

If it is set to not scan on start, it should scan after the configured
number of seconds. I think scan_on_start is default though.

> I have kept the default for scan frequency (20 hours). How can I verify if
> the Integrity scan actually did run?
>

Check the ossec.log on the agent.

> I get "** No entries found" when the command - syscheck_control -i agentID
> is executed
> If I see the agent name under /var/ossec/queue/syscheck can I assume that an
> initial scan was run on the system?
>

You should be able to cat the file and see any entries for that system.
For syscheck_control, make sure you're using a valid id #. "000" is a
great test, as it is the OSSEC server.

> Do I need to setup a time for the scan to happen? 

It's not necessary.

> Can I stagger the scan time for the agents? aka create groups by agent name
> and scan them at different times?
>

You might be able to use agent profiles for this, but I haven't tried.

>
> Thank you again for the guidance!
>
> --
>
> ---
> 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] local_decoder.xml -- can't override (ignore) parent decoder

[dan (ddp)]

On Tue, Jan 17, 2017 at 2:53 PM, Daniel B.  wrote:
> We use weave which periodically causes a network interface to enter
> promiscuous mode to sniff network traffic. This is expected behavior, and as
> such, I'm looking to ignore it.
>
> For reference, the iptables decoder is set at
> https://github.com/ossec/ossec-hids/blob/592d681ea07f9a8bf2bedb039ee9493e6fbe3c26/etc/decoder.xml#L1135
>
> The log line I'm attempting to ignore looks like:
> Jan 16 20:46:57 machine_name kernel: [347956.184868] device veth9c8da7ba
> entered promiscuous mode
>
> Now, this is inserted into my local_decoder.xml file (with an appropriate
> local rule):
>
>
> 
>   iptables
>   device (veth\w+) entered promiscuous
> mode
>   kernel
>   
>   extra_data
> 
>

I know this is solved, but here's a decoder to do what the above is
attempting to do (I'm not sure about regex in the prematch field):

  iptables
  promiscuous mode$
  device (\S+) entered
  extra_data



>
> I've tried a lot of different variations on the above, including getting rid
> of the parent and prematch offsets (while temporarily deleting the original
> / parent iptables rule in
> etc/ossec_decoders/kernel-iptables_apparmor_decoders.xml
>
>
> Each time I run the log through ./ossec-logtest, it matches to the parent
> decoder, and as such an alert is fired.
>
> **Phase 1: Completed pre-decoding.
>full event: 'Jan 16 20:46:57 machine_name kernel: [347956.184868]
> device veth9c8da7ba entered promiscuous mode'
>hostname: 'machine_name'
>program_name: 'kernel'
>log: '[347956.184868] device veth9c8da7ba entered promiscuous mode'
>
> **Phase 2: Completed decoding.
>decoder: 'iptables'
>
> **Phase 3: Completed filtering (rules).
>Rule id: '5104'
>Level: '8'
>Description: 'Interface entered in promiscuous(sniffing) mode.'
> **Alert to be generated.
>
>
> Is there a way I can override the iptables decoder for this one specific log
> message?
>
> Any help is appreciated, 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.conf vs Agent.conf -- System Integrity check

[dan (ddp)]

On Jan 16, 2017 3:25 PM, "Nikki S"  wrote:

I read through some of the posts already on the list regarding this topic
but I would still like some clarification on this please.

I have added all the system integrity options of 'include' and 'ignore'  in
OSSEC.conf. Do I need to replicate this to agent.conf as well?


Nope. The options in both files should be combined into one configuration.
Duplicating directories in sycheck is also a bad idea and can cause issues.


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/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-analysisd won't start, "could not create directory"

[dan (ddp)]

On Jan 13, 2017 2:28 PM, "Joel"  wrote:

hi all,

man, not having a good day.

I was starting to run out of space on my / volume as a result of ossec logs
piling up.   i need to keep the logs, so i added a new drive (to the ossec
VMW vm) mounted it and then moved the logs/ directory to the new mount.

now, when starting ossec, ossec-analysisd won't start.  I think it's trying
to chroot and can't cross the filesystem boundary...?

2017/01/13 19:24:47 ossec-analysisd(1210): ERROR: Queue '/queue/alerts/ar'
> not accessible: 'Connection refused'.
> 2017/01/13 19:24:47 ossec-analysisd(1301): ERROR: Unable to connect to
> active response queue.
> 2017/01/13 19:24:50 ossec-analysisd(1210): ERROR: Queue
> '/queue/alerts/execq' not accessible: 'Connection refused'.
> 2017/01/13 19:24:50 ossec-analysisd(1301): ERROR: Unable to connect to
> active response queue.
> 2017/01/13 19:24:50 ossec-analysisd: DEBUG: Active response Init completed.
> 2017/01/13 19:24:50 ossec-analysisd(1107): ERROR: Could not create
> directory '/logs/archives/2017/' due to [(2)-(No such file or directory)].


and

[root@e-ossec-001: /var/ossec]# ls -ald /data/logs/ossec/
> drwxr-xr-x 6 ossec ossec 129 Jan 13 19:03 /data/logs/ossec/
> [root@e-ossec-001: /var/ossec]# ls -al /var/ossec/
> total 24
> dr-xr-x---  16 root  ossec 4096 Jan 13 18:55 .
> drwxr-xr-x. 20 root  root  4096 Jan 13 19:21 ..
> dr-xr-x---   3 root  ossec   16 Jan 12 22:05 active-response
> dr-xr-x---   2 root  ossec 4096 Oct  6 13:37 agentless
> drwxr-x---   3 root  ossec   19 Oct  6 13:37 backup
> dr-xr-x---   2 root  root  4096 Jan 12 18:43 bin
> dr-xr-x---   5 root  ossec 4096 Jan 13 16:34 etc
> drwxr-x---   2 root  ossec   34 Oct  6 13:37 integrations
> lrwxrwxrwx   1 root  root16 Jan 13 18:55 logs -> /data/logs/ossec
> dr-xr-x---   4 root  root34 Oct  6 13:37 lua
> dr-xr-x---  11 root  ossec  150 Oct  6 13:38 queue
> dr-xr-x---   2 root  ossec 4096 Oct 17 13:36 rules
> drwx--   2 root  ossec6 Oct  6 13:37 .ssh
> drwxr-x---   5 ossec ossec   61 Oct  6 13:57 stats
> dr-xr-x--T   2 root  ossec6 Oct  6 13:37 tmp
> dr-xr-x---   3 root  root20 Oct  6 13:37 update
> dr-xr-x---   3 root  ossec   16 Jan 13 19:24 var


do I need to keep it allon the same volume?


If you mounted the new drive under /var/ossec, you would probably be fine.
/data is outside of the chroot



thanks!

Joel

-- 

---
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: syslog facility when sending to remote syslog server?

[dan (ddp)]

On Fri, Jan 13, 2017 at 11:40 AM, Joel  wrote:
> Thanks Dan
>

Sorry I didn't have better news.
If you want to open an issue on the github
(https://github.com/ossec/ossec-hids), we can keep it in mind when we
find time to work on features.
I think having more options might be useful (and the defaults can
always be re-evaluated).

>
> On Friday, 13 January 2017 10:44:46 UTC-5, Joel wrote:
>>
>> Hi all,
>>
>> I've been using osssec for a while now and I really like it.
>>
>> I'm now trying to integrate ossec with a monitoring application.  I'd like
>> to have ossec send Alerts to a remote host via syslog.
>>
>> I have it all working, with one exception.  It looks like ossec forwards
>> ALL events as local0.warning.
>>
>> is this configurable?  is there a way to change it?
>>
>> what I'd really love is a way to set an Alert level to a specific facility
>> / severity so that the monitoring system can handle different events
>> differently without having to do much parsing of the message contents.
>>
>> Does anyone have any tips or pointers?
>>
>> thanks!
>>
>> J
>
> --
>
> ---
> 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] syslog facility when sending to remote syslog server?

[dan (ddp)]

On Fri, Jan 13, 2017 at 10:26 AM, Joel  wrote:
> Hi all,
>
> I've been using osssec for a while now and I really like it.
>
> I'm now trying to integrate ossec with a monitoring application.  I'd like
> to have ossec send Alerts to a remote host via syslog.
>
> I have it all working, with one exception.  It looks like ossec forwards ALL
> events as local0.warning.
>
> is this configurable?  is there a way to change it?
>
> what I'd really love is a way to set an Alert level to a specific facility /
> severity so that the monitoring system can handle different events
> differently without having to do much parsing of the message contents.
>
> Does anyone have any tips or pointers?
>

There's no configuration to change that, you'll have to modify the source code.

> thanks!
>
> J
>
> --
>
> ---
> 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: ossec logs redirect to local syslog

[dan (ddp)]

On Jan 11, 2017 3:10 PM, "Mike"  wrote:

Hi did anyone figure out how to do this.  We just started using OSSEC and I
have the same question as Ali?


I must be misunderstanding the question, but what happens when you point it
at the local syslog listener and setup syslog to log it to a
non-ossec-monitored file?



Thanks,
Mike


On Thursday, June 10, 2010 at 8:41:32 AM UTC-4, Ali wrote:
>
> Hi Ossec'ers;
>
> I need some help please. I would like the ossec server to log all
> alerts and messages to local syslog NOT to a remote syslog. I have
> rsyslog installed in the localhost, what changes do I make to /etc/
> rsyslog.conf and what changes do I make to /etc/ossec.conf?
>
> I have seen instruction for sending syslog to remote syslog host, but
> I do not want to do that, I want to record ossec logs to local syslog
> - say in /var/log/messages or /var/log/secure. How can I do this...
>
> Any help will be greatly appreciated.
>
>
> Thx
> Ali.

-- 

---
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 2.8.3 problems with ossec-maild

[dan (ddp)]

On Tue, Jan 10, 2017 at 1:57 AM, Rimvydas  wrote:
> Hi,
>
> I noticed one strange thing on one of my Debian 8 box'es. I saw that I'm not
> seeing mail notifications from ossec. Everything worked in the past on this
> server with this ossec installation. I checked process list and saw that I
> have at least 8 ossec-maild processes started. I restarted ossec killed all
> maild processes. Ossec started with one maild process but after short time I
> saw that second maild process was started. And I still can't see any ossec
> mail notifications. Can anyone help me to troubleshoot this issue? Thanks.
>

Try turning on the debug mode (`/var/ossec/bin/ossec-control enable
debug && /var/ossec/bin/ossec-control restart`) and watch for log
messages related to maild.

> --
>
> ---
> 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] Alert ID not present JSON logs, feature request?

[dan (ddp)]

On Mon, Jan 9, 2017 at 10:01 AM, Adam Tworkowski
 wrote:
> Hi,
>
> I am collecting OSSEC logs via JSON on several log collection systems (ELK,
> Graylog2) and am attempting to accomplish some basic reporting with respects
> to determining which host triggered an Active Response.  For example, if I
> have an alert id (i.e. 1483628458.3576646) from an AR alert
> (firewall-drop.sh), i.e.:
>
>   ** Alert 1483628460.3579808: mail  -
> local,syslog,active_response,pci_dss_11.4,
>   2017 Jan 05 10:01:00 (server2)
> 192.xx.xx.11->/var/ossec/logs/active-responses.log
>   Rule: 601 (level 3) -> 'Host Blocked by firewall-drop.sh Active Response'
>   Src IP: 123.30.37.44
>   Thu Jan  5 10:00:58 EST 2017
> /var/ossec/active-response/bin/firewall-drop.sh add - 123.30.37.44
> 1483628458.3576646 5712
>
> ...I am able to search alerts.log for all instances of the Alert ID which
> will include other AR alerts plus the "originating" alert with the alert ad
> following (** Alert :):
>
> ** Alert 1483628458.3576646: mail  -
> syslog,sshd,authentication_failures,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,
> 2017 Jan 05 10:00:58 (server1) 192.xx.xx.10->/var/log/messages
> Rule: 5712 (level 10) -> 'SSHD brute force trying to get access to the
> system.'
> Src IP: 123.30.37.44
> Jan  5 10:00:58 server1 sshd[17432]: Invalid user pi from 123.30.37.44
> Jan  5 10:00:56 server1 sshd[17430]: Failed password for invalid user admin
> from 123.30.37.44 port 50770 ssh2
> Jan  5 10:00:55 server1 sshd[17430]: Failed none for invalid user admin from
> 123.30.37.44 port 50770 ssh2
> Jan  5 10:00:49 server1 sshd[17428]: Failed password for invalid user root
> from 123.30.37.44 port 63117 ssh2
> Jan  5 10:00:49 server1 sshd[17428]: Failed none for invalid user root from
> 123.30.37.44 port 63117 ssh2
> Jan  5 10:00:42 server1 sshd[17425]: Failed password for invalid user user
> from 123.30.37.44 port 50598 ssh2
> Jan  5 10:00:42 server1 sshd[17425]: Failed none for invalid user user from
> 123.30.37.44 port 50598 ssh2
> Jan  5 10:00:42 server1 sshd[17425]: Invalid user user from 123.30.37.44
>
> In this case I know that server2 triggered the alert for server1 (and any
> number of other hosts including server1).
>
> So while I can make these correlations from within the alerts.log for, it
> does not transpose to the JSON version of the log as json.log does not
> include the the alert id and therefore not in the remote logging tools.
> Would anyone find this useful enough for inclusion in OSSEC?  I am not a
> coder so this is above my head but I would welcome any assistance.  I would
> also be interested to hear if anyone has devised other ways to achieve
> similar reporting.
>

It's something I keep meaning to look at, but low on the priority list.

> Thank you,
>
> Adam
>
> --
>
> ---
> 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-dbd keeps disconnecting

[dan (ddp)]

On Thu, Jan 5, 2017 at 6:59 PM, Sean Roe  wrote:
> Hi all,
>
> I am having some problems keeping ossec-dbd connected.  I am connecting to a
> mariadb 10.0.24 database and I am running ossec 2.8.3
>

Are there any clues in your mariadb logs?

> here is the info from the logs:
> 2017/01/05 16:46:51 ossec-dbd(5210): INFO: Attempting to reconnect to
> database.
> 2017/01/05 16:46:51 ossec-dbd: Connected to database 'ossec' at
> 'ppdc1lx0111'.
> 2017/01/05 16:46:51 ossec-dbd(5204): ERROR: Database error. Unable to run
> query.
> 2017/01/05 16:46:51 ossec-dbd(5203): ERROR: Error executing query 'INSERT
> INTO
> alert(id,server_id,rule_id,timestamp,location_id,src_ip,src_port,dst_ip,dst_port,alertid)
> VALUES ('847', '1', '502','1483660011', '1', '0', '0', '0', '0',
> '1483660008.1322638')'. Error: 'Duplicate entry '847-1' for key 'PRIMARY''.
> 2017/01/05 16:46:51 ossec-dbd(5209): INFO: Closing connection to database.
> 2017/01/05 16:46:51 ossec-dbd(5210): INFO: Attempting to reconnect to
> database.
> 2017/01/05 16:46:51 ossec-dbd: Connected to database 'ossec' at
> 'ppdc1lx0111'.
> 2017/01/05 16:46:51 ossec-dbd(5204): ERROR: Database error. Unable to run
> query.
> 2017/01/05 16:47:35 ossec-syscheckd: INFO: Starting syscheck scan
> (forwarding database).
> 2017/01/05 16:47:35 ossec-syscheckd: INFO: Starting syscheck database
> (pre-scan).
> 2017/01/05 16:48:16 ossec-dbd(5203): ERROR: Error executing query 'SELECT id
> FROM location WHERE name = '(dvsc1lx0037) 10.69.65.37->/var/log/secure' AND
> server_id = '1' LIMIT 1'. Error: 'Lost connection to MySQL server during
> query'.
> 2017/01/05 16:48:16 ossec-dbd(5209): INFO: Closing connection to database.
> 2017/01/05 16:48:16 ossec-dbd(5210): INFO: Attempting to reconnect to
> database.
> 2017/01/05 16:48:16 ossec-dbd: Connected to database 'ossec' at
> 'ppdc1lx0111'.
> 2017/01/05 16:48:20 ossec-dbd(5203): ERROR: Error executing query 'SELECT id
> FROM location WHERE name = '(dvsc1lx0037) 10.69.65.37->/var/log/secure' AND
> server_id = '1' LIMIT 1'. Error: 'Lost connection to MySQL server during
> query'.
> 2017/01/05 16:48:20 ossec-dbd(5209): INFO: Closing connection to database.
> 2017/01/05 16:48:20 ossec-dbd(5210): INFO: Attempting to reconnect to
> database.
> 2017/01/05 16:48:20 ossec-dbd: Connected to database 'ossec' at
> 'ppdc1lx0111'.
> 2017/01/05 16:48:20 ossec-dbd(5203): ERROR: Error executing query 'INSERT
> INTO data(id, server_id, user, full_log) VALUES ('848', '1', '(null)', 'Jan
> 5 16:48:00 dvsc1lx0037 polkitd(authority=local): Operator of
> unix-session:/org/freedesktop/ConsoleKit/Session2 FAILED to authenticate to
> gain authorization for action
> org.freedesktop.packagekit.system-network-proxy-configure for
> system-bus-name::1.38 [gpk-update-icon] (owned by unix-user:oracle)') '.
> Error: 'Duplicate entry '848-1' for key 'PRIMARY''.
> 2017/01/05 16:48:20 ossec-dbd(5209): INFO: Closing connection to database.
> 2017/01/05 16:48:20 ossec-dbd(5210): INFO: Attempting to reconnect to
> database.
> 2017/01/05 16:48:20 ossec-dbd: Connected to database 'ossec' at
> 'ppdc1lx0111'.
>
> I see the duplicate entry key error but am not sure how to fix it.  Any
> suggestions would be helpful.
>
> Thanks,
> Sean
>
> --
>
> ---
> 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 watching SQL

[dan (ddp)]

On Jan 8, 2017 8:19 AM, "Mike Hammett"  wrote:

My current centralized logging environment stores syslog in MySQL. Can
OSSEC watch a SQL database instead of a file?


Not at this time



-- 

---
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: ossec run away cat and tr process

[dan (ddp)]

On Tue, Dec 20, 2016 at 1:41 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Tue, Dec 20, 2016 at 1:40 PM, David Breise <dbre...@eticainc.com> wrote:
>> [root@turpentine ossec]# cat /etc/*release
>> CentOS release 6.8 (Final)
>> LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
>> CentOS release 6.8 (Final)
>> CentOS release 6.8 (Final)
>> You have new mail in /var/spool/mail/root
>>
>> The only evidence left behind is a long running "cat /dev/urandom" process
>> hogging CPU.
>>
>
> I've just setup a Centos 7 install (for something else), so I'll try
> with that first.
> Thanks for the info!
>


After correcting the spaces around the "=" issues in the hosts-deny.sh
script, it works fine on centos7.
(commit that fixed this:
https://github.com/ossec/ossec-hids/commit/3e46edf1c032d7b6c8d72e9cf1e443e33a92ce3b)

I'll try centos6.8 tomorrow.

>> On Tue, Dec 20, 2016 at 10:31 AM, dan (ddp) <ddp...@gmail.com> wrote:
>>>
>>> On Tue, Dec 20, 2016 at 1:19 PM, David Breise <dbre...@eticainc.com>
>>> wrote:
>>> > Tested commands manually, no errors returned.  This is still a problem
>>> > for
>>> > us.
>>> >
>>>
>>> Which distribution are you using? I'm wondering why mktemp isn't being
>>> used (or why it's failing).
>>>
>>> > On Wednesday, January 21, 2015 at 9:32:27 AM UTC-8, dan (ddpbsd) wrote:
>>> >>
>>> >> On Wed, Jan 21, 2015 at 11:11 AM, Gil Vidals <gvi...@gmail.com> wrote:
>>> >> > Thanks for the quick reply.
>>> >> >
>>> >> > I do see that mktemp exists and that the temp files have been created
>>> >> > successfully on more than one occasion as you can see below. What
>>> >> > other
>>> >> > reason could there be for cat and tr running astray and consuming
>>> >> > lots
>>> >> > of
>>> >> > CPU. (cat and tr will run for hours unless killed manually).
>>> >> >
>>> >> > # which mktemp
>>> >> > /bin/mktemp
>>> >> >
>>> >> > # ls -l /var/ossec/ossec-hosts.*
>>> >> > -rw--- 1 root ossec 0 Jan  2 01:15
>>> >> > /var/ossec/ossec-hosts.7aypDtwpES
>>> >> > -rw--- 1 root ossec 0 Dec  3 00:31
>>> >> > /var/ossec/ossec-hosts.IeJGMBWseD
>>> >> > -rw--- 1 root ossec 0 Nov  2 01:58
>>> >> > /var/ossec/ossec-hosts.IxQvPzkSbn
>>> >> > -rw--- 1 root ossec 0 Dec 10 23:31
>>> >> > /var/ossec/ossec-hosts.QV2a7VwilS
>>> >> > -rw--- 1 root ossec 0 Nov 10 23:32
>>> >> > /var/ossec/ossec-hosts.Rr0j0L3RTV
>>> >> > -rw--- 1 root ossec 0 Jan 17 02:23
>>> >> > /var/ossec/ossec-hosts.SKfz9m2LPG
>>> >> > -rw--- 1 root ossec 0 Jan 17 02:39
>>> >> > /var/ossec/ossec-hosts.SrSTWhUNH1
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tuesday, January 20, 2015 at 3:47:28 PM UTC-8, Gil Vidals wrote:
>>> >> >>
>>> >> >> We're running ossec 2.8 and are finding instances where cat and tr
>>> >> >> are
>>> >> >> consuming a lot of CPU. The cat and tr processes have to be killed
>>> >> >> with
>>> >> >> the
>>> >> >> kill command since restarting ossec doesn't kill them.
>>> >> >>
>>> >> >> How can the run away cat and tr process be prevented?
>>> >> >>
>>> >> >> I found the portion of the ossec code that calls the cat and tr
>>> >> >> functions:
>>> >> >>
>>> >> >> elif [ "x${ACTION}" = "xdelete" ]; then
>>> >> >>lock;
>>> >> >>TMP_FILE=`mktemp /var/ossec/ossec-hosts.XX`
>>> >> >>if [ "X${TMP_FILE}" = "X" ]; then
>>> >> >>  # Cheap fake tmpfile, but should be harder then no random data
>>> >> >>  TMP_FILE="/var/ossec/ossec-hosts.`cat /dev/urandom | tr -dc
>>> >> >> 'a-zA-Z0-9' | fold -w 32 | head -1 `"
>>> >> >>fi
>>> >> >>if

Re: [ossec-list] Re: Compile issue : undefined reference ?

[dan (ddp)]

On Sun, Dec 18, 2016 at 9:36 PM, Mohd Zainal Abidin Mamat
 wrote:
> I'm getting same error using ver 2.8.3 on centos 7. Still seeking solution.
>

Verify that you have the devel packages installed.
I just setup a Centos 7 VM, added the mysql community packages, and
installed OSSEC without any errors.

[root@localhost ossec-hids-2.8.3]# rpm -qa | grep -i mysql
mysql-community-devel-5.7.17-1.el7.x86_64
mysql-community-libs-5.7.17-1.el7.x86_64
mysql57-community-release-el7-9.noarch
mysql-community-libs-compat-5.7.17-1.el7.x86_64
mysql-community-client-5.7.17-1.el7.x86_64
mysql-community-common-5.7.17-1.el7.x86_64


> On Saturday, July 10, 2010 at 5:11:07 AM UTC+8, Jason 'XenoPhage' Frisvold
> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi all,
>>
>> I'm having a problem compiling ossec on a local server I have.
>> The
>> server is an CentOS 5.5 machine using the official MySQL RPMs rather
>> than the CentOS version.  Specifically, I have the following installed :
>>
>> MySQL-devel-community-5.0.67-0.rhel5
>> MySQL-shared-compat-5.0.67-0.rhel5
>> MySQL-server-community-5.0.67-0.rhel5
>> MySQL-client-community-5.0.67-0.rhel5
>>
>> The error I'm receiving is as follows :
>>
>>  *** Making os_dbd ***
>>
>> make[1]: Entering directory
>> `/usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd'
>> Compiling DB support with:
>> gcc -g -Wall -I../ -I../headers   -DUSE_OPENSSL -DUSEINOTIFY
>> - -DARGV0=\"ossec-dbd\" -DXML_VAR=\"var\" -DOSSECHIDS
>> - -I/usr/include/mysql  -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> - -fstack-protector --param=ssp-buffer-size=4 -m32
>> - -fasynchronous-unwind-tables -rdynamic -L/usr/lib/mysql -lmysqlclient
>> - -lz -lcrypt -lnsl -lm -DDBD -DUMYSQL  *.c ../config/lib_config.a
>> ../shared/lib_shared.a ../os_net/os_net.a ../os_regex/os_regex.a
>> ../os_xml/os_xml.a -o ossec-dbd
>> /tmp/ccKCtW2N.o: In function `mysql_osdb_connect':
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:164: undefined
>> reference to `mysql_init'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:178: undefined
>> reference to `mysql_options'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:183: undefined
>> reference to `mysql_options'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:186: undefined
>> reference to `mysql_real_connect'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:189: undefined
>> reference to `mysql_error'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:190: undefined
>> reference to `mysql_close'
>> /tmp/ccKCtW2N.o: In function `mysql_osdb_close':
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:204: undefined
>> reference to `mysql_close'
>> /tmp/ccKCtW2N.o: In function `mysql_osdb_query_insert':
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:215: undefined
>> reference to `mysql_query'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:218: undefined
>> reference to `mysql_error'
>> /tmp/ccKCtW2N.o: In function `mysql_osdb_query_select':
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:240: undefined
>> reference to `mysql_query'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:243: undefined
>> reference to `mysql_error'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:250: undefined
>> reference to `mysql_use_result'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:254: undefined
>> reference to `mysql_error'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:261: undefined
>> reference to `mysql_fetch_row'
>> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:268: undefined
>> reference to `mysql_free_result'
>> collect2: ld returned 1 exit status
>> make[1]: *** [default] Error 1
>> make[1]: Leaving directory
>> `/usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd'
>>
>> Error Making os_dbd
>> make: *** [all] Error 1
>>
>>
>> Yes, I'm compiling this as an RPM.  I get the same error compiling by
>> hand.
>>
>> I have run ldconfig with a -v and verified that the libmysqlclient
>> libraries are in there, I have verified the location of both the include
>> files and libraries for mysql.
>>
>> At this point, I'm not sure where to head.  Does anyone have any
>> thoughts on what's happening here?
>>
>> Thanks,
>>
>> - --
>> - ---
>> Jason 'XenoPhage' Frisvold
>> xeno...@godshell.com
>> - ---
>> "Any sufficiently advanced magic is indistinguishable from technology."
>> - - Niven's Inverse of Clarke's Third Law
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.14 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAkw3kGsACgkQ8CjzPZyTUTT5bgCghfUpNy7QkLr2DRagsf9fQxsT
>> dQgAnRW899SmJ2t1Izdp5dbYBZgK3+zv
>> =+876
>> -END PGP SIGNATURE-
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe 

Re: [ossec-list] Re: ossec run away cat and tr process

[dan (ddp)]

On Tue, Dec 20, 2016 at 1:40 PM, David Breise <dbre...@eticainc.com> wrote:
> [root@turpentine ossec]# cat /etc/*release
> CentOS release 6.8 (Final)
> LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
> CentOS release 6.8 (Final)
> CentOS release 6.8 (Final)
> You have new mail in /var/spool/mail/root
>
> The only evidence left behind is a long running "cat /dev/urandom" process
> hogging CPU.
>

I've just setup a Centos 7 install (for something else), so I'll try
with that first.
Thanks for the info!

> On Tue, Dec 20, 2016 at 10:31 AM, dan (ddp) <ddp...@gmail.com> wrote:
>>
>> On Tue, Dec 20, 2016 at 1:19 PM, David Breise <dbre...@eticainc.com>
>> wrote:
>> > Tested commands manually, no errors returned.  This is still a problem
>> > for
>> > us.
>> >
>>
>> Which distribution are you using? I'm wondering why mktemp isn't being
>> used (or why it's failing).
>>
>> > On Wednesday, January 21, 2015 at 9:32:27 AM UTC-8, dan (ddpbsd) wrote:
>> >>
>> >> On Wed, Jan 21, 2015 at 11:11 AM, Gil Vidals <gvi...@gmail.com> wrote:
>> >> > Thanks for the quick reply.
>> >> >
>> >> > I do see that mktemp exists and that the temp files have been created
>> >> > successfully on more than one occasion as you can see below. What
>> >> > other
>> >> > reason could there be for cat and tr running astray and consuming
>> >> > lots
>> >> > of
>> >> > CPU. (cat and tr will run for hours unless killed manually).
>> >> >
>> >> > # which mktemp
>> >> > /bin/mktemp
>> >> >
>> >> > # ls -l /var/ossec/ossec-hosts.*
>> >> > -rw--- 1 root ossec 0 Jan  2 01:15
>> >> > /var/ossec/ossec-hosts.7aypDtwpES
>> >> > -rw--- 1 root ossec 0 Dec  3 00:31
>> >> > /var/ossec/ossec-hosts.IeJGMBWseD
>> >> > -rw--- 1 root ossec 0 Nov  2 01:58
>> >> > /var/ossec/ossec-hosts.IxQvPzkSbn
>> >> > -rw--- 1 root ossec 0 Dec 10 23:31
>> >> > /var/ossec/ossec-hosts.QV2a7VwilS
>> >> > -rw--- 1 root ossec 0 Nov 10 23:32
>> >> > /var/ossec/ossec-hosts.Rr0j0L3RTV
>> >> > -rw--- 1 root ossec 0 Jan 17 02:23
>> >> > /var/ossec/ossec-hosts.SKfz9m2LPG
>> >> > -rw--- 1 root ossec 0 Jan 17 02:39
>> >> > /var/ossec/ossec-hosts.SrSTWhUNH1
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tuesday, January 20, 2015 at 3:47:28 PM UTC-8, Gil Vidals wrote:
>> >> >>
>> >> >> We're running ossec 2.8 and are finding instances where cat and tr
>> >> >> are
>> >> >> consuming a lot of CPU. The cat and tr processes have to be killed
>> >> >> with
>> >> >> the
>> >> >> kill command since restarting ossec doesn't kill them.
>> >> >>
>> >> >> How can the run away cat and tr process be prevented?
>> >> >>
>> >> >> I found the portion of the ossec code that calls the cat and tr
>> >> >> functions:
>> >> >>
>> >> >> elif [ "x${ACTION}" = "xdelete" ]; then
>> >> >>lock;
>> >> >>TMP_FILE=`mktemp /var/ossec/ossec-hosts.XX`
>> >> >>if [ "X${TMP_FILE}" = "X" ]; then
>> >> >>  # Cheap fake tmpfile, but should be harder then no random data
>> >> >>  TMP_FILE="/var/ossec/ossec-hosts.`cat /dev/urandom | tr -dc
>> >> >> 'a-zA-Z0-9' | fold -w 32 | head -1 `"
>> >> >>fi
>> >> >>if [ "X$UNAME" = "XFreeBSD" ]; then
>> >> >> cat /etc/hosts.allow | grep -v "ALL : ${IP} : deny$">
>> >> >> ${TMP_FILE}
>> >> >> mv ${TMP_FILE} /etc/hosts.allow
>> >> >>else
>> >> >> cat /etc/hosts.deny | grep -v "ALL:${IP}$"> ${TMP_FILE}
>> >> >> cat ${TMP_FILE} > /etc/hosts.deny
>> >> >> rm ${TMP_FILE}
>> >> >>fi
>> >> >>unlock;
>> >> >>exit 0;
>> >> >>
>> >> >> Thanks 

Re: [ossec-list] Re: ossec run away cat and tr process

[dan (ddp)]

On Tue, Dec 20, 2016 at 1:19 PM, David Breise  wrote:
> Tested commands manually, no errors returned.  This is still a problem for
> us.
>

Which distribution are you using? I'm wondering why mktemp isn't being
used (or why it's failing).

> On Wednesday, January 21, 2015 at 9:32:27 AM UTC-8, dan (ddpbsd) wrote:
>>
>> On Wed, Jan 21, 2015 at 11:11 AM, Gil Vidals  wrote:
>> > Thanks for the quick reply.
>> >
>> > I do see that mktemp exists and that the temp files have been created
>> > successfully on more than one occasion as you can see below. What other
>> > reason could there be for cat and tr running astray and consuming lots
>> > of
>> > CPU. (cat and tr will run for hours unless killed manually).
>> >
>> > # which mktemp
>> > /bin/mktemp
>> >
>> > # ls -l /var/ossec/ossec-hosts.*
>> > -rw--- 1 root ossec 0 Jan  2 01:15 /var/ossec/ossec-hosts.7aypDtwpES
>> > -rw--- 1 root ossec 0 Dec  3 00:31 /var/ossec/ossec-hosts.IeJGMBWseD
>> > -rw--- 1 root ossec 0 Nov  2 01:58 /var/ossec/ossec-hosts.IxQvPzkSbn
>> > -rw--- 1 root ossec 0 Dec 10 23:31 /var/ossec/ossec-hosts.QV2a7VwilS
>> > -rw--- 1 root ossec 0 Nov 10 23:32 /var/ossec/ossec-hosts.Rr0j0L3RTV
>> > -rw--- 1 root ossec 0 Jan 17 02:23 /var/ossec/ossec-hosts.SKfz9m2LPG
>> > -rw--- 1 root ossec 0 Jan 17 02:39 /var/ossec/ossec-hosts.SrSTWhUNH1
>> >
>> >
>> >
>> >
>> > On Tuesday, January 20, 2015 at 3:47:28 PM UTC-8, Gil Vidals wrote:
>> >>
>> >> We're running ossec 2.8 and are finding instances where cat and tr are
>> >> consuming a lot of CPU. The cat and tr processes have to be killed with
>> >> the
>> >> kill command since restarting ossec doesn't kill them.
>> >>
>> >> How can the run away cat and tr process be prevented?
>> >>
>> >> I found the portion of the ossec code that calls the cat and tr
>> >> functions:
>> >>
>> >> elif [ "x${ACTION}" = "xdelete" ]; then
>> >>lock;
>> >>TMP_FILE=`mktemp /var/ossec/ossec-hosts.XX`
>> >>if [ "X${TMP_FILE}" = "X" ]; then
>> >>  # Cheap fake tmpfile, but should be harder then no random data
>> >>  TMP_FILE="/var/ossec/ossec-hosts.`cat /dev/urandom | tr -dc
>> >> 'a-zA-Z0-9' | fold -w 32 | head -1 `"
>> >>fi
>> >>if [ "X$UNAME" = "XFreeBSD" ]; then
>> >> cat /etc/hosts.allow | grep -v "ALL : ${IP} : deny$"> ${TMP_FILE}
>> >> mv ${TMP_FILE} /etc/hosts.allow
>> >>else
>> >> cat /etc/hosts.deny | grep -v "ALL:${IP}$"> ${TMP_FILE}
>> >> cat ${TMP_FILE} > /etc/hosts.deny
>> >> rm ${TMP_FILE}
>> >>fi
>> >>unlock;
>> >>exit 0;
>> >>
>> >> Thanks in advance for any help you can provide in resolving this issue.
>> >
>>
>> Ok, what happens if you run that command manually?
>>
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] OSSEC Config Change alerts

[dan (ddp)]

On Dec 18, 2016 8:37 AM, "Nish"  wrote:

Hi,

Are changes made to the *OSSEC.conf *file logged somewhere in the system?
Asking because an admin inadvertently changed the notification email
address and we stopped getting the alerts for sometime and then corrected
it later...I have gone through some of the logs but cannot figure out the
change



You can add /var/ossec/etc to a syscheck directories entry to be alerted
when changes are made.


Regards,
Nish

-- 

---
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] Notification by Level

[dan (ddp)]

It's email_alert_level, I think. It's in the ossec.conf syntax documentation

On Dec 17, 2016 8:19 AM, "Mohd Zainal Abidin Mamat" 
wrote:

> Hi,
>
> I want to receive email alert from level 10 and upward. How to set in
> ossec.conf?
>
> 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] Check running process

[dan (ddp)]

On Wed, Dec 14, 2016 at 7:20 AM, Francesco Raimondi
 wrote:
> Greetings,
>
> I have some problem trying to detect a process running on the machine.
> Specifically, I want to detect the process "tor.exe" by using
> win_applications_rcl.txt
> Here's my directive:
>
> [P2P] [any] []
> p:=:tor.exe;
>
> Unfortunately, it's not working... there seems to be a problem with the =
> sign, if I use something like this:
>
> p:r:tor.exe;
>
> it works correctly. But then, since "r:" is used for regular expression, I
> get an alert for everything that contains "tor.exe", which is obviously not
> good.
>

I don't have much experience with this, but what about something like:
p:r:^tor.exe$


> Any idea on how I can improve this?
>
> Thanks,
> Francesco
>
> --
>
> ---
> 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] Firewall appliance : netasq/stormshield

[dan (ddp)]

On Wed, Dec 14, 2016 at 9:50 AM, Bertrand Danos <mille...@gmail.com> wrote:
> Without the action match and order, it's OK :
>

I feel like there was a limit in the number of entries in the 
field. Maybe it's 9?

What about something like this:


> 
> 
>   netasq
>   logtype="filter"
>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)"
> ipproto=(\S+) proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+)
> dstport=(\d+)
>   id, extra_data, extra_data, protocol, protocol, srcip,
> srcport, dstip, dstport
>
> 
> 
>

Splitting it into multiple decoders seems to work for me:

  netasq
  logtype="filter"
  ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)"
ipproto=(\S+) proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+)
dstport=(\d+) 
  id, extra_data, extra_data, protocol, protocol, srcip,
srcport, dstip, dstport



  netasq
  action=(\S+)
  action


**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 14:37:42 192.168.10.1 id=firewall
time="2016-12-02 14:37:41" fw="FW1" tz=+ startime="2016-12-02
14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 srcif="Ethernet2"
srcifname="port2" ipproto=tcp proto=ssh src=192.168.10.2 srcport=33659
srcportname=ephemeral_fw_tcp srcname=Routeur dst=192.168.10.1
dstport=22 dstportname=ssh dstname=FW action=pass
logtype="filter"#015'
   hostname: '192.168.10.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 14:37:41" fw="FW1" tz=+
startime="2016-12-02 14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1
srcif="Ethernet2" srcifname="port2" ipproto=tcp proto=ssh
src=192.168.10.2 srcport=33659 srcportname=ephemeral_fw_tcp
srcname=Routeur dst=192.168.10.1 dstport=22 dstportname=ssh dstname=FW
action=pass logtype="filter"#015'

**Phase 2: Completed decoding.
   decoder: 'netasq'
   id: 'firewall'
   extra_data: 'FW1'
   extra_data: 'port2'
   proto: 'tcp'
   proto: 'ssh'
   srcip: '192.168.10.2'
   srcport: '33659'
   dstip: '192.168.10.1'
   action: 'pass'




>
> result :
>
> **Phase 2: Completed decoding.
>decoder: 'netasq'
>id: 'firewall'
>extra_data: 'FW1'
>extra_data: 'port2'
>proto: 'tcp'
>proto: 'ssh'
>srcip: '192.168.10.2'
>srcport: '33659'
>dstip: '192.168.10.1'
>
>
>
> With the action match and order, it crash :
>
> strace ./ossec-logtest
>
> write(2, "\n**Phase 2: Completed decoding.", 31
> **Phase 2: Completed decoding.) = 31
> write(2, "\n", 1
> )   = 1
> write(2, "   decoder: 'netasq'", 24   decoder: 'netasq') = 24
> write(2, "\n", 1
> )   = 1
> write(2, "   id: 'firewall'", 21   id: 'firewall')   = 21
> write(2, "\n", 1
> )   = 1
> write(2, "   extra_data: 'FW1'", 24   extra_data: 'FW1') = 24
> write(2, "\n", 1
> )   = 1
> write(2, "   extra_data: 'port2'", 26   extra_data: 'port2') = 26
> write(2, "\n", 1
> )   = 1
> write(2, "   proto: 'tcp'", 19   proto: 'tcp') = 19
> write(2, "\n", 1
> )   = 1
> write(2, "   proto: 'ssh'", 19   proto: 'ssh') = 19
> write(2, "\n", 1
> )       = 1
> write(2, "   srcip: '192.168.10.2'", 28   srcip: '192.168.10.2') = 28
> write(2, "\n", 1
> )   = 1
> write(2, "   srcport: '33659'", 23   srcport: '33659') = 23
> write(2, "\n", 1
> )   = 1
> write(2, "   dstip: '192.168.10.1'", 28   dstip: '192.168.10.1') = 28
> write(2, "\n", 1
> )   = 1
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
>
>
>
> 2016-12-09 16:35 GMT+01:00 dan (ddp) <ddp...@gmail.com>:
>>
>>
>> On Dec 9, 2016 5:51 AM, "Bertrand Danos" <mille...@gmail.com> wrote:
>>
>> Hello Dan,
>>
>> Thank you very much for your help.
>>
>> I've a problem with the following decoder and sample. Its generates a
>> segfault in ossec-logtest :
>>
>> 
>>
>> 
>>   netasq
>>   logtype="filter"
>>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)"
>> ipproto=(\S+) proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+)
>> dstport=(\d+) \.+ action=(\S+)
>>   id, extra_data, extra_data, protocol, pr

Re: [ossec-list] OSSEC not Connecting to Graylog

[dan (ddp)]

On Thu, Dec 15, 2016 at 8:04 AM, Benbrahim Anass
 wrote:
> hi everyone,
>
> i have an ossec Forwarding Logs to a graylog in format CEF, the port on
> graylog is open, ossec telling me it's forwarding logs but when i check w\
> netstat, i dont see any connection

If you run tcpdump on the graylog2 side, do you see traffic coming
from the OSSEC system?

> i'm wondering if there is something more to do cause i followed exactly this
> : https://github.com/Graylog2/graylog-guide-ossec
>
> Thanks in advance.
>
> cheers
>
> Anas
>
> --
>
> ---
> 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: OSSEC not Connecting to Graylog

[dan (ddp)]

On Fri, Dec 16, 2016 at 7:54 AM, Benbrahim Anass
 wrote:
> What a Groupe Guys, Responding is so fast. well DONE!!
>

Well now I definitely want to help 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/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] remoted Dropping Events

[dan (ddp)]

On Tue, Dec 13, 2016 at 9:11 AM, Chris Decker  wrote:
> Victor,
>
> I'm at the point where my agents all have valid keys, so I'm unsure as to
> why I have ~ 750 clients and only ~225 are reported as "active" at any one
> time (all of the machines are alive and well, and generating mountains of
> log data  :)).  I wanted to give tcp communication a shot, but it appears
> that  isn't valid within the client tag:
>
> 2016/12/13 09:05:49 ossec-config(1230): ERROR: Invalid element in the
> configuration: 'protocol'.
>
> 2016/12/13 09:05:49 ossec-config(1202): ERROR: Configuration error at
> '/var/ossec/etc/ossec.conf'. Exiting.
>
> 2016/12/13 09:05:49 ossec-agentd(1215): ERROR: No client configured.
> Exiting.
>
>
> The documentation also doesn't make it appear that  is an option
> there:
>
> http://ossec.github.io/docs/syntax/head_ossec_config.client.html
>

I believe that's a wazuh extension.

>
> Is there something I am missing?
>
>
>
> On Friday, December 9, 2016 at 6:42:27 AM UTC-5, Victor Fernandez wrote:
>>
>> Hi,
>>
>> Agents should send a keepalive each 10 minutes (600 seconds) by default,
>> and this should be enough. But you can go down that time at the agent's
>> ossec.conf:
>>
>>
>> 
>>
>>   1.2.3.4
>>   60
>>
>>
>>
>> If you see any agent disconnected, check its ossec.log file.
>>
>> On the other hand, as Dan says, the manager will discard two identical
>> consecutive messages, so you should generate different messages for the logs
>> (using a random string or the date).
>>
>> If you think that there could be network congestion, you may try to
>> connect using TCP, adding, at the agent's ossec.conf:
>>
>> 
>>
>>   1.2.3.4
>>   tcp
>>
>>
>> And, on the manager's ossec.conf:
>>
>> 
>>   
>> secure
>> tcp
>>   
>>
>>
>> Please test it and write back to us if this doesn't solve the problem. All
>> feedback is welcome.
>>
>> Hope it helps.
>> Best regards.
>>
>>
>> On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote:
>>>
>>>
>>>
>>> On Dec 8, 2016 4:41 PM, "Chris Decker"  wrote:
>>>
>>> All,
>>>
>>> I have an OSSEC instance (running the latest/greatest Wuzuh code cloned
>>> from GitHub) that has about 1k active hosts.  I've noticed recently that
>>> hosts are flipping back and forth between Active and Disconnected.
>>>
>>>
>>> Perhaps the manager is too busy? I can't remember the host limit offhand,
>>> but I believe ossec limits the number of agents to a number smaller than
>>> 1000.
>>>
>>>
>>> I've also noticed that not all of the log messages from "Active" hosts
>>> are being received by the Manager.  For example, I have an agent that
>>> generates the same log message every second.  I have debug enabled on the
>>> Agent and I can see logcollector reading each message, but only some of the
>>> messages are received on the Manager (I monitored it for awhile and it's not
>>> that the messages show up later due to network congestion--I don't see the
>>> messages ever being received).  I tried disabling the agent ID checks on
>>> both the Manager and Agent but that didn't have any impact.
>>>
>>>
>>> Ossec will discard some repeated messages. I forget the timeframe offhand
>>> though.
>>>
>>>
>>>
>>> I suspect there is a misconfiguration or limit I am running into on my
>>> Manager running RHEL 7, but I haven't been able to track it down.  I did a
>>> simple netcat test between the same two hosts and there was no lag in
>>> transmissions.
>>>
>>> Any suggestions/thoughts from the community?
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Chris
>>>
>>> --
>>>
>>> ---
>>> 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.

Re: [ossec-list] Does Ossec support MariaDB?

[dan (ddp)]

On Mon, Dec 12, 2016 at 7:35 PM,   wrote:
> Hi,
>
> There hasn't been any action on this topic for over a year but it was never
> answered and I'm running into the same issue.  What libraries is it looking
> for?  Is there somewhere that I can look at, possibly edit the list?  Why
> does it look for particular libraries, couldn't I just specify the type of
> database (MySQL or PostgreSql) that I want to use?
>


I just did a quick test with mariadb and ossec MASTER, and it seems to
work just fine. I didn't do extensive testing though.

root@maria-test:~/src/ossec-hids/src# dpkg --list | grep maria
ii  libmariadbclient-dev 5.5.53-1ubuntu0.14.04.1
amd64MariaDB database development files
ii  libmariadbclient18:amd64 5.5.53-1ubuntu0.14.04.1
amd64MariaDB database client library
ii  mariadb-client   5.5.53-1ubuntu0.14.04.1
all  MariaDB database client (metapackage depending on the
latest version)
ii  mariadb-client-5.5   5.5.53-1ubuntu0.14.04.1
amd64MariaDB database client binaries
ii  mariadb-client-core-5.5  5.5.53-1ubuntu0.14.04.1
amd64MariaDB database core client binaries
ii  mariadb-common   5.5.53-1ubuntu0.14.04.1
all  MariaDB common metapackage
ii  mariadb-server   5.5.53-1ubuntu0.14.04.1
all  MariaDB database server (metapackage depending on the
latest version)
ii  mariadb-server-5.5   5.5.53-1ubuntu0.14.04.1
amd64MariaDB database server binaries
ii  mariadb-server-core-5.5  5.5.53-1ubuntu0.14.04.1
amd64MariaDB database core server files



A lot of the necessary bits should be in the Makefile after "ifdef DATABASE."



> Natassia
>
> On Tuesday, September 22, 2015 at 7:24:08 PM UTC-7, dan (ddpbsd) wrote:
>>
>> On Sat, Sep 19, 2015 at 10:42 AM, Kai Chung Lau 
>> wrote:
>> > I know Ossec supports PostgreSql and Mysql, but since MariaDb is the
>> > drop-in
>> > replacement for Mysql, can Ossec also work with Mariadb?
>> >
>> > I have tried recompiling Ossec but it doesn't work.
>> > [root@ju src]# make setdb;
>> >
>> > Error: PostgreSQL client libraries not installed.
>> >
>> > Error: DB libraries not installed.
>> >
>>
>> Perhaps your distro is putting things in places OSSEC doesn't expect?
>> You're not giving us much to go on.
>>
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] Email Alerts on Google Compute Instances

[dan (ddp)]

On Tue, Dec 13, 2016 at 6:37 AM, flippery_fish  wrote:
> Hi,
>
> Google Compute Engine does not allow outbound connections on ports 25, 465,
> and 587.
>
> As recommended by GCE, I have setup mailjet on 2525 which works fine for
> outbound mail relay.
>
> Is there a way to send the OSSEC email notifications to send on specific
> port (i.e. in.mailjet.com:2525 in my case)?
>
> If not, is there a workaround?  Of course i could do something like write
> the OSEC notifications to json file, parse that and send manually, but was
> hoping to avoid doing that.
>

Modify the source and recompile.

>
>
>
> --
>
> ---
> 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] Is/will journalctl supported

[dan (ddp)]

On Dec 9, 2016 11:56 AM, "Bill Price"  wrote:

We monitor a large variety of sites using ossec.
We were asked to monitor a Centos 7.2 site that is using journalctl.
Does Ossec 2.8.1 support log monitoring on a system using  journalctl?
If not, will 2.9 or any later version at sometime support it?


It is not currently supported, and I am not aware of any plans tonsupport
it. Journald can export to a proper log like syslog though



-- 

---
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] Firewall appliance : netasq/stormshield

[dan (ddp)]

On Dec 9, 2016 5:51 AM, "Bertrand Danos"  wrote:

Hello Dan,

Thank you very much for your help.

I've a problem with the following decoder and sample. Its generates a
segfault in ossec-logtest :




  netasq
  logtype="filter"
  ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)"
ipproto=(\S+) proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+)
dstport=(\d+) \.+ action=(\S+)
  id, extra_data, extra_data, protocol, protocol, srcip,
srcport, dstip, dstport, action


the segfaut appears before the display of dstport
For the 'action' item, I can't display it too.


Any ideas?



If you remove the action match and order, does it still segfault?

-- 

--- 
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] remoted Dropping Events

[dan (ddp)]

On Dec 9, 2016 9:17 AM, "Chris Decker"  wrote:

Victor,

On Friday, December 9, 2016 at 6:42:27 AM UTC-5, Victor Fernandez wrote:
>
> Hi,
>
> Agents should send a keepalive each 10 minutes (600 seconds) by default,
> and this should be enough. But you can go down that time at the agent's
> ossec.conf:
>
>
> 
>
>   1.2.3.4
>   *60*
>
>
>
> If you see any agent disconnected, check its ossec.log file.
>
> On the other hand, as Dan says, the manager will discard two identical
> consecutive messages, so you should generate different messages for the
> logs (using a random string or the date).
>
These events were from auditd and were unique enough that OSSEC should
treat them as such.


Sorry, I thought you wrote that the logs were the same.



> If you think that there could be network congestion, you may try to
> connect using TCP, adding, at the agent's ossec.conf:
>
> 
>
>   1.2.3.4
>   *tcp*
>
>
> And, on the manager's ossec.conf:
>
> 
>   
> secure
> *tcp*
>   
>
> I'm going to give this a try.

One thing I've noticed is that the ossec-control script isn't starting up
remoted.  If I start remoted by hand it starts, but then I see 3 remoted
processes.  I've never come across this issue before.  Do you know what
could be causing it?



Is ossec-remoted listed in the DAEMONS variable in the script?
What is your remote condiguration in your ossec.conf?


> Please test it and write back to us if this doesn't solve the problem. All
> feedback is welcome.
>
> Hope it helps.
> Best regards.
>
>
> On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote:
>>
>>
>>
>> On Dec 8, 2016 4:41 PM, "Chris Decker"  wrote:
>>
>> All,
>>
>> I have an OSSEC instance (running the latest/greatest Wuzuh code cloned
>> from GitHub) that has about 1k active hosts.  I've noticed recently that
>> hosts are flipping back and forth between *Active* and *Disconnected*.
>>
>>
>> Perhaps the manager is too busy? I can't remember the host limit offhand,
>> but I believe ossec limits the number of agents to a number smaller than
>> 1000.
>>
>>
>> I've also noticed that not all of the log messages from "*Active" *hosts
>> are being received by the Manager.  For example, I have an agent that
>> generates the same log message every second.  I have debug enabled on the
>> Agent and I can see logcollector reading each message, but only *some*
>> of the messages are received on the Manager (I monitored it for awhile and
>> it's not that the messages show up later due to network congestion--I don't
>> see the messages ever being received).  I tried disabling the agent ID
>> checks on both the Manager and Agent but that didn't have any impact.
>>
>>
>> Ossec will discard some repeated messages. I forget the timeframe offhand
>> though.
>>
>>
>>
>> I suspect there is a misconfiguration or limit I am running into on my
>> Manager running RHEL 7, but I haven't been able to track it down.  I did a
>> simple netcat test between the same two hosts and there was no lag in
>> transmissions.
>>
>> Any suggestions/thoughts from the community?
>>
>>
>>
>>
>> Thanks,
>> Chris
>>
>> --
>>
>> ---
>> 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.

Re: [ossec-list] remoted Dropping Events

[dan (ddp)]

On Dec 8, 2016 4:41 PM, "Chris Decker"  wrote:

All,

I have an OSSEC instance (running the latest/greatest Wuzuh code cloned
from GitHub) that has about 1k active hosts.  I've noticed recently that
hosts are flipping back and forth between *Active* and *Disconnected*.


Perhaps the manager is too busy? I can't remember the host limit offhand,
but I believe ossec limits the number of agents to a number smaller than
1000.


I've also noticed that not all of the log messages from "*Active" *hosts
are being received by the Manager.  For example, I have an agent that
generates the same log message every second.  I have debug enabled on the
Agent and I can see logcollector reading each message, but only *some* of
the messages are received on the Manager (I monitored it for awhile and
it's not that the messages show up later due to network congestion--I don't
see the messages ever being received).  I tried disabling the agent ID
checks on both the Manager and Agent but that didn't have any impact.


Ossec will discard some repeated messages. I forget the timeframe offhand
though.



I suspect there is a misconfiguration or limit I am running into on my
Manager running RHEL 7, but I haven't been able to track it down.  I did a
simple netcat test between the same two hosts and there was no lag in
transmissions.

Any suggestions/thoughts from the community?




Thanks,
Chris

-- 

---
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: important questions on CDB lists

[dan (ddp)]

On Wed, Dec 7, 2016 at 12:39 PM, Omar M  wrote:
> Did anyone find a solution to this problem?
>
> I've compiled the CDB and created the rules but cannot seem to get the
> lookup to work
>

I'd really need more information than this to help 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/d/optout.

Re: [ossec-list] Firewall appliance : netasq/stormshield

[dan (ddp)]

On Wed, Dec 7, 2016 at 5:26 AM, 1kn0  wrote:
> Greetings,
>
> I'm new to OSSEC and I didn't find an answer to my problem on the list.
> I've appliance firewalls (netasq and stormshield) on a network. These
> firewalls exports their log to the computer where OSSEC is installed.
>
> For tests :
>
> I connect on the administration pages of the firewall, with a an invalid
> user/password.
>>
>> Dec  2 15:42:29 192.168.10.1 id=firewall time="2016-12-02 15:42:28"
>> fw="FW1" tz=+ startime="2016-12-02 15:42:28" user="admin"
>> src=192.168.10.2 ruleid=0 method="PLAIN" error=4 msg="Authentication request
>> invalid" logtype="auth"#015
>
>
> I connect to the firewall with SSH
>>
>> Dec  2 14:37:42 192.168.10.1 id=firewall time="2016-12-02 14:37:41"
>> fw="FW1" tz=+ startime="2016-12-02 14:37:40" pri=5 confid=01 slotlevel=2
>> ruleid=1 srcif="Ethernet2" srcifname="port2" ipproto=tcp proto=ssh
>> src=192.168.10.2 srcport=33659 srcportname=ephemeral_fw_tcp srcname=Routeur
>> dst=192.168.10.1 dstport=22 dstportname=ssh dstname=FW action=pass
>> logtype="filter"#015
>
>
>
> Is there decoder and rules for firewall?
> How to configure decode/rules to analyze all events reported by the
> firewalls?
>

I don't believe there are decoders or rules for this firewall (never
heard of it actually).
Running the samples provided through ossec-logtest, I get the following output:
**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 15:42:29 192.168.10.1 id=firewall
time="2016-12-02 15:42:28" fw="FW1" tz=+ startime="2016-12-02
15:42:28" user="admin" src=192.168.10.2 ruleid=0 method="PLAIN"
error=4 msg="Authentication request invalid" logtype="auth"#015'
   hostname: '192.168.10.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 15:42:28" fw="FW1" tz=+
startime="2016-12-02 15:42:28" user="admin" src=192.168.10.2 ruleid=0
method="PLAIN" error=4 msg="Authentication request invalid"
logtype="auth"#015'

**Phase 2: Completed decoding.
   No decoder matched.

**Phase 3: Completed filtering (rules).
   Rule id: '1002'
   Level: '2'
   Description: 'Unknown problem somewhere in the system.'
**Alert to be generated.


**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 14:37:42 192.168.10.1 id=firewall
time="2016-12-02 14:37:41" fw="FW1" tz=+ startime="2016-12-02
14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 srcif="Ethernet2"
srcifname="port2" ipproto=tcp proto=ssh src=192.168.10.2 srcport=33659
srcportname=ephemeral_fw_tcp srcname=Routeur dst=192.168.10.1
dstport=22 dstportname=ssh dstname=FW action=pass
logtype="filter"#015'
   hostname: '192.168.10.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 14:37:41" fw="FW1" tz=+
startime="2016-12-02 14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1
srcif="Ethernet2" srcifname="port2" ipproto=tcp proto=ssh
src=192.168.10.2 srcport=33659 srcportname=ephemeral_fw_tcp
srcname=Routeur dst=192.168.10.1 dstport=22 dstportname=ssh dstname=FW
action=pass logtype="filter"#015'

**Phase 2: Completed decoding.
   No decoder matched.


Adding the following deocder to local_decoder.xml gives us "decoder:
'netasq'" (although this is untested against other logs to make sure
there are no conflicts):

  ^id=



These decoders flesh it out a bit:

  netasq
  logtype="auth"
  ^id=(\S+) time=\.+ fw="(\w+)" \.+ user="(\S+)" src=(\S+) \.+
logtype="auth"
  id, extra_data, user, srcip



  netasq
   logtype="filter"
  ^id=(\S+) time=\.+ fw="(\w+)" \.+ ipproto=(\S+) proto=(\S+)
src=(\S+) srcport=(\d+) \.+ dst=(\S+) dstport=(\d+) \.+ action=(\S+)

  id, extra_data, protocol, protocol, srcip, srcport, dstip,
dstport, action


**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 15:42:29 192.168.10.1 id=firewall
time="2016-12-02 15:42:28" fw="FW1" tz=+ startime="2016-12-02
15:42:28" user="admin" src=192.168.10.2 ruleid=0 method="PLAIN"
error=4 msg="Authentication request invalid" logtype="auth"#015'
   hostname: '192.168.10.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 15:42:28" fw="FW1" tz=+
startime="2016-12-02 15:42:28" user="admin" src=192.168.10.2 ruleid=0
method="PLAIN" error=4 msg="Authentication request invalid"
logtype="auth"#015'

**Phase 2: Completed decoding.
   decoder: 'netasq'
   id: 'firewall'
   extra_data: 'FW1'
   dstuser: 'admin'
   srcip: '192.168.10.2'


**Phase 1: Completed pre-decoding.
   full event: 'Dec  2 14:37:42 192.168.10.1 id=firewall
time="2016-12-02 14:37:41" fw="FW1" tz=+ startime="2016-12-02
14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 srcif="Ethernet2"
srcifname="port2" ipproto=tcp proto=ssh src=192.168.10.2 srcport=33659
srcportname=ephemeral_fw_tcp srcname=Routeur dst=192.168.10.1
dstport=22 dstportname=ssh dstname=FW action=pass
logtype="filter"#015'
   hostname: '192.168.10.1'
   program_name: '(null)'
   log: 'id=firewall time="2016-12-02 14:37:41" fw="FW1" 

Re: [ossec-list] Still having problems with OSSEC 2.8 on FreeBSD 10.3

[dan (ddp)]

On Dec 3, 2016 4:54 PM, "Eponymous -"  wrote:

Hi all,

I've had many problems getting the OSSEC agent to start up correctly on
FreeBSD 10.3 (see: https://groups.google.com/forum/#!topic/ossec-list/
VDT4cTObDPQ - "Chroot directory change option.) I figured it would best to
start a separate discussion.

I've done a completely fresh install of *ossec-hids-client-2.8.2* from
pkg.freebsd.org and then simply changed the IP address to the correct
server address in ossec.conf and then added the key using manage-agents.

Every time I start I get issues with permissions.

/usr/local/ossec-hids/bin/ossec-control start
Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
ossec-execd already running...
2016/12/03 21:42:08 ossec-agentd: INFO: Using notify time: 600 and max time
to reconnect: 1800
Started ossec-agentd...
Started ossec-logcollector...
2016/12/03 21:42:11 ossec-syscheckd(1210): ERROR: Queue
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
refused'.
2016/12/03 21:42:11 ossec-rootcheck(1210): ERROR: Queue
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
refused'.
2016/12/03 21:42:19 ossec-syscheckd(1210): ERROR: Queue
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
refused'.
2016/12/03 21:42:19 ossec-rootcheck(1210): ERROR: Queue
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
refused'.
2016/12/03 21:42:32 ossec-syscheckd(1210): ERROR: Queue
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
refused'.
2016/12/03 21:42:32 ossec-rootcheck(1211): ERROR: Unable to access queue:
'/usr/local/ossec-hids/queue/ossec/queue'. Giving up..
ossec-syscheckd did not start

This page: http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html
talks about checking that "ossec-analysisd" is running, but I can't see
that file anywhere in the install location so my guess is it was removed
and possibly merged into another binary.


That advice is for the server install or local install only.


Using tree, I checked all the permissions:

# tree -ugap /usr/local/ossec-hids/
/usr/local/ossec-hids/
|-- [drwx-- ossecossec   ]  .ssh
|-- [drwxr-xr-x root ossec   ]  active-response
|   `-- [drwxr-xr-x root ossec   ]  bin
|   |-- [-rwxr-xr-x root wheel   ]  disable-account.sh
|   |-- [-rwxr-xr-x root wheel   ]  firewall-drop.sh
|   |-- [-rwxr-xr-x root wheel   ]  host-deny.sh
|   |-- [-rwxr-xr-x root wheel   ]  ip-customblock.sh
|   |-- [-rwxr-xr-x root wheel   ]  ipfw.sh
|   |-- [-rwxr-xr-x root wheel   ]  ipfw_mac.sh
|   |-- [-rwxr-xr-x root wheel   ]  ossec-tweeter.sh
|   |-- [-rwxr-xr-x root wheel   ]  pf.sh
|   |-- [-rwxr-xr-x root wheel   ]  restart-ossec.sh
|   `-- [-rwxr-xr-x root wheel   ]  route-null.sh
|-- [drwxr-xr-x root ossec   ]  agentless
|   |-- [-rwxr-x--- root ossec   ]  main.exp
|   |-- [-rwxr-x--- root ossec   ]  register_host.sh
|   |-- [-rwxr-x--- root ossec   ]  ssh.exp
|   |-- [-rwxr-x--- root ossec   ]  ssh_asa-fwsmconfig_diff
|   |-- [-rwxr-x--- root ossec   ]  ssh_foundry_diff
|   |-- [-rwxr-x--- root ossec   ]  ssh_generic_diff
|   |-- [-rwxr-x--- root ossec   ]  ssh_integrity_check_bsd
|   |-- [-rwxr-x--- root ossec   ]  ssh_integrity_check_linux
|   |-- [-rwxr-x--- root ossec   ]  ssh_nopass.exp
|   |-- [-rwxr-x--- root ossec   ]  ssh_pixconfig_diff
|   |-- [-rwxr-x--- root ossec   ]  sshlogin.exp
|   `-- [-rwxr-x--- root ossec   ]  su.exp
|-- [drwxr-xr-x root ossec   ]  bin
|   |-- [-rwxr-x--- root wheel   ]  agent-auth
|   |-- [-rwxr-x--- root wheel   ]  manage_agents
|   |-- [-rwxr-x--- root wheel   ]  ossec-agentd
|   |-- [-rwxr-x--- root wheel   ]  ossec-control
|   |-- [-rwxr-x--- root wheel   ]  ossec-execd
|   |-- [-rwxr-x--- root wheel   ]  ossec-logcollector
|   |-- [-rwxr-x--- root wheel   ]  ossec-lua
|   |-- [-rwxr-x--- root wheel   ]  ossec-luac
|   |-- [-rwxr-x--- root wheel   ]  ossec-syscheckd
|   `-- [-rwxr-x--- root wheel   ]  util.sh
|-- [drwxr-xr-x root ossec   ]  etc
|   |-- [-r--r- root ossec   ]  client.keys
|   |-- [-r--r- root ossec   ]  internal_options.conf
|   |-- [-rwxr-xr-x root ossec   ]  ossec.conf
|   |-- [-rwxr-xr-x root ossec   ]  ossec.conf.sample
|   `-- [drwxr-xr-x root ossec   ]  shared
|   |-- [-rwxrwx--- root ossec   ]  cis_debian_linux_rcl.txt
|   |-- [-rwxrwx--- root ossec   ]  cis_rhel5_linux_rcl.txt
|   |-- [-rwxrwx--- root ossec   ]  cis_rhel_linux_rcl.txt
|   |-- [-rwxrwx--- root ossec   ]  rootkit_files.txt
|   |-- [-rwxrwx--- root ossec   ]  rootkit_trojans.txt
|   |-- [-rwxrwx--- root ossec   ]  system_audit_rcl.txt
|   |-- [-rwxrwx--- root ossec   ]  win_applications_rcl.txt
|   |-- [-rwxrwx--- root ossec   ]  win_audit_rcl.txt
|   `-- 

Re: [ossec-list] Use file with keywords on rules

[dan (ddp)]

On Mon, Nov 28, 2016 at 7:47 AM, Julio Cesar  wrote:
> Hello. I have a file with more than 1000 IP's blacklisted.
> Have any way to include a syntax like this on custom ossec rule?
>
>>  
>>  /etc/blacklist/list.txt
>>  Black-listed IP address
>>  
>

This is an easy use case for a cdb list:
https://ossec.github.io/docs/manual/rules-decoders/rule-lists.html?highlight=cdb

>
>
> 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/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] Problem with rule 18257

[dan (ddp)]

On Mon, Nov 21, 2016 at 8:09 AM, dan (ddp) <ddp...@gmail.com> wrote:
> On Fri, Nov 18, 2016 at 11:35 AM, Kevin Branch
> <ke...@branchnetconsulting.com> wrote:
>> Rule 18257 appears to be prone to misfire.  I see it tripping for things
>> like this:
>>
>> 2016 Nov 18 10:37:26 WinEvtLog: Application: INFORMATION(302): ESENT: (no
>> user): no domain: BNC-O9020: Music.UI (25428)
>> {87E550B7-AD4D-40F7-BE5E-263C3D44C124}: The database engine has successfully
>> completed recovery steps.
>>
>>
>> See:
>>
>> https://github.com/ossec/ossec-hids/blob/master/etc/rules/msauth_rules.xml
>>
>>   
>> 18101
>> ^200$|^300$|^302$
>> Windows: TS Gateway login success.
>> authentication_success,pci_dss_10.2.5,
>>
>> https://technet.microsoft.com/en-us/library/cc775181(v=ws.10).aspx
>>   
>>
>> This would appear to fire on every single Windows informational event except
>> for event IDs 200, 300, and 302.  I presume some other piece of matching
>> criteria is missing.
>>
>
> It should fire on 200, 300, and 302. This event looks like the id
> should be 302. So this rule should fire, right?
>
> Unfortunately that log message doesn't decode correctly for me, so
> it'll be a pain to figure out what's going on
>

OT: Found that bug and submitted a PR
(https://github.com/ossec/ossec-hids/pull/992)

-- 

--- 
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] Problem with rule 18257

[dan (ddp)]

On Fri, Nov 18, 2016 at 11:35 AM, Kevin Branch
 wrote:
> Rule 18257 appears to be prone to misfire.  I see it tripping for things
> like this:
>
> 2016 Nov 18 10:37:26 WinEvtLog: Application: INFORMATION(302): ESENT: (no
> user): no domain: BNC-O9020: Music.UI (25428)
> {87E550B7-AD4D-40F7-BE5E-263C3D44C124}: The database engine has successfully
> completed recovery steps.
>
>
> See:
>
> https://github.com/ossec/ossec-hids/blob/master/etc/rules/msauth_rules.xml
>
>   
> 18101
> ^200$|^300$|^302$
> Windows: TS Gateway login success.
> authentication_success,pci_dss_10.2.5,
>
> https://technet.microsoft.com/en-us/library/cc775181(v=ws.10).aspx
>   
>
> This would appear to fire on every single Windows informational event except
> for event IDs 200, 300, and 302.  I presume some other piece of matching
> criteria is missing.
>

It should fire on 200, 300, and 302. This event looks like the id
should be 302. So this rule should fire, right?

Unfortunately that log message doesn't decode correctly for me, so
it'll be a pain to figure out what's going on

# /var/ossec/bin/ossec-logtest -q
2016/11/21 08:05:48 ossec-testrule: INFO: Reading the lists file:
'rules/lists/ossec.block'
2016 Nov 18 10:37:26 WinEvtLog: Application: INFORMATION(302): ESENT:
(no user): no domain: BNC-O9020: Music.UI (25428)
{87E550B7-AD4D-40F7-BE5E-263C3D44C124}: The database engine has
successfully completed recovery steps.2016/11/21 08:05:49
ossec-testrule: INFO: Started (pid: 87163).
ossec-testrule: Type one log per line.

**Phase 1: Completed pre-decoding.
   full event: '2016 Nov 18 10:37:26 WinEvtLog: Application:
INFORMATION(302): ESENT: (no user): no domain: BNC-O9020: Music.UI
(25428) {87E550B7-AD4D-40F7-BE5E-263C3D44C124}: The database engine
has successfully completed recovery steps.'
   hostname: 'ix'
   program_name: 'WinEvtLog'
   log: 'Application: INFORMATION(302): ESENT: (no user): no
domain: BNC-O9020: Music.UI (25428)
{87E550B7-AD4D-40F7-BE5E-263C3D44C124}: The database engine has
successfully completed recovery steps.'

**Phase 2: Completed decoding.
   decoder: 'windows'
   status: 'INFORMATION'
   id: 'ESENT'
   extra_data: '(no user)'
   dstuser: 'BNC-O9020'

**Phase 3: Completed filtering (rules).
   Rule id: '18101'
   Level: '0'
   Description: 'Windows informational event.'



> Kevin
>
> --
>
> ---
> 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] A few comments on default active-response settings

[dan (ddp)]

On Fri, Nov 18, 2016 at 6:00 PM, Christina Plummer <cplum...@gmail.com> wrote:
> My 2 cents:
>
> 1) I got tripped up by the fact that the default alert level to trigger an
> active response is 6, while the default alert level to trigger an email is
> 7. There were a number of times when communication between 2 internal hosts
> on my network suddenly stopped working, then mysteriously started working
> again - and it wasn't at all obvious that OSSEC was the culprit.  I dealt
> with this by monitoring active-responses.log on both agents and server, and
> then creating local rules that alert_by_email whenever rules 601-606 hit.
>

That makes sense.
https://github.com/ossec/ossec-hids/pull/991

> 2) There are a lot of SSH rules at level 6 that make it really easy to
> trigger an active response.  E.g. with the default configuration, rule 5706
> will trigger a block if a single invalid connection to port 22 is made (such
> as a telnet or port map). While you could certainly argue that this is
> impolite, there are in fact a lot of monitoring and other tools that do
> something similar in order to see if the port is listening without actually
> trying to make an SSH connection - so blocking after one attempt is way too
> aggressive for us.  I dealt with this by reducing the alert level on a bunch
> of these rules, and adding a frequency/timeframe requirement which triggers
> an email but no active-response (since the level is still < 6):
>
>
>   
> 5706,5713,5731,5747,5748
> Malformed SSH connection attempt
>   
>
>   
> 100012
> alert_by_email
> Potential SSH scan, possible attack
>   
>
> So, I've worked around it - but the default behavior did seem non-intuitive
> and overly aggressive to me.  FWIW, I'm in a corporate environment; I
> imagine if you had SSH exposed to the internet and you were getting scanned
> all the time, the current defaults (block with extreme prejudice and don't
> bother to tell me about it) would make more sense.
>
> Christina
>
> On Fri, Nov 18, 2016 at 10:06 AM, Whit Blauvelt <w...@transpect.com> wrote:
>>
>> Hi Dan,
>>
>> Since I skipped answering this:
>>
>> On Mon, Nov 14, 2016 at 11:09:52AM -0500, dan (ddp) wrote:
>>
>> > > Except in a context of anon FTP servers (does anyone run those any
>> > > more?)
>> > > blocking IPs because they connect using valid logins "too often" is a
>> > > dangerous default. "First, do no harm."
>> >
>> > Creating perfect defaults for every environment is nearly impossible.
>> > Niche and odd-ball usage patterns can cause issues.
>> >
>> > Which rule was triggering the alerts? Maybe it's time for a tweak.
>>
>> 11301 in pure-ftpd_rules (not to be confused with 11302 for multiple
>> failed
>> logins).
>>
>> Whit
>>
>> --
>>
>> ---
>> 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] A few comments on default active-response settings

[dan (ddp)]

On Fri, Nov 18, 2016 at 10:06 AM, Whit Blauvelt <w...@transpect.com> wrote:
> Hi Dan,
>
> Since I skipped answering this:
>
> On Mon, Nov 14, 2016 at 11:09:52AM -0500, dan (ddp) wrote:
>
>> > Except in a context of anon FTP servers (does anyone run those any more?)
>> > blocking IPs because they connect using valid logins "too often" is a
>> > dangerous default. "First, do no harm."
>>
>> Creating perfect defaults for every environment is nearly impossible.
>> Niche and odd-ball usage patterns can cause issues.
>>
>> Which rule was triggering the alerts? Maybe it's time for a tweak.
>
> 11301 in pure-ftpd_rules (not to be confused with 11302 for multiple failed
> logins).
>

I'm not sure why this would trigger anything by default. The level is
only 3, and the default for triggering AR is 6.

> Whit
>
> --
>
> ---
> 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] Agent Syscheck Frequency Issue

[dan (ddp)]

On Mon, Nov 21, 2016 at 7:34 AM, Yousif Johny  wrote:
> Hi all,
>
> I've been having this weird issue with OSSEC. I setup an agent in one
> server, and things seem okay at first.
>
> When I modify a file that is being monitored (/etc/passwd) I'd have to wait
> a significant time for it to trigger an alert (unless I manually run the
> syscheckd). So I went to /var/ossec/etc/ossec.conf (on the Server being
> monitored side) and modified  it as follows:
>
>  
> 
> 30
>
> 
> /etc,/usr/bin,/usr/sbin
> /bin,/sbin
>
>
> So the frequency is 30 (which I believe is in seconds).
>
> Correct me if I'm wrong, but I thought this would mean the syscheck would
> run every 30 seconds? meaning if I modify a file, it'll take a max of 30
> seconds for it to trigger an alert, right?
>
> If so, then why is it not triggering? I've been waiting for minutes and
> minutes and nothing happens. This has been puzzling me.
>

30 seconds is too small. Depending on the system, about 300 seems to
be the minimum.
The more files you're monitoring, the longer it will take, so the
higher the frequency that should be set.

>
> 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/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] Installation error

[dan (ddp)]

On Nov 19, 2016 3:40 PM, "Zach Ogden"  wrote:
>
> Hello,
>
> I am running the Windows Linux Subsystem on Windows 10. I installed ossec
on the debian bash system. I ran the ./install.sh file my normal user with
sudo in front of the script. Installation was successful.  I cannot start
the services correctly. I receive the following error:
>
> /var/ossec/bin/ossec-logtest -v
>
> 2016/11/19 15:08:25 ossec-testrule(1132): ERROR: Unable to chroot to
directory '/var/ossec' due to [(38)-(Function not implemented)].
>

Seems pretty self explanatory.  Chroot doesn't appear to be supported.
As far as I know this is a totally unsupported and untested configuration.
We require a unix like system for the server or local installs,
recommending linux or a bsd.

> /var/ossec/bin/ossec-analysisd -V
>
> OSSEC HIDS v2.9.0 - Trend Micro Inc.
>
> /etc/ossec-init.conf
>
> root@PC:/ossec-hids/src#
> root@PC:/ossec-hids/src#
> root@PC:/ossec-hids/src#
> root@PC:/ossec-hids/src#
> root@PC:/ossec-hids/src# cat /etc/ossec-init.conf
> DIRECTORY="/var/ossec"
> VERSION="v2.9.0"
> DATE="Sat Nov 19 14:57:02 STD 2016"
> TYPE="server"
>
> /var/ossec/etc/ossec.conf
>
> 
>   
> yes
> zogde...@gmail.com
> alt3.gmail-smtp-in.l.google.com.
> ossecm@ZWO-PC
>   
>
>
>   
> 
> 79200
>
> 
> /etc,/usr/bin,/usr/sbin
> /bin,/sbin,/boot
>
> 
> /etc/mtab
> /etc/mnttab
> /etc/hosts.deny
> /etc/mail/statistics
> /etc/random-seed
> /etc/adjtime
> /etc/httpd/logs
> /etc/utmpx
> /etc/wtmpx
> /etc/cups/certs
> /etc/dumpdates
> /etc/svc/volatile
>
> 
> C:\WINDOWS/System32/LogFiles
> C:\WINDOWS/Debug
> C:\WINDOWS/WindowsUpdate.log
> C:\WINDOWS/iis6.log
> C:\WINDOWS/system32/wbem/Logs
> C:\WINDOWS/system32/wbem/Repository
> C:\WINDOWS/Prefetch
> C:\WINDOWS/PCHEALTH/HELPCTR/DataColl
> C:\WINDOWS/SoftwareDistribution
> C:\WINDOWS/Temp
> C:\WINDOWS/system32/config
> C:\WINDOWS/system32/spool
> C:\WINDOWS/system32/CatRoot
>   
>
>   
> /var/ossec/etc/shared/rootkit_files.txt
>
/var/ossec/etc/shared/rootkit_trojans.txt
>
/var/ossec/etc/shared/system_audit_rcl.txt
>
/var/ossec/etc/shared/cis_debian_linux_rcl.txt
>
/var/ossec/etc/shared/cis_rhel_linux_rcl.txt
>
/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt
>   
>
>   
> 127.0.0.1
> ::1
> ^localhost.localdomain$
> 192.168.1.1
> 192.168.1.1
> fec0:0:0:::1
>   
>
>   
> syslog
>   
>
>   
> secure
>   
>
>   
> 1
> 7
>   
>
>   
> host-deny
> host-deny.sh
> srcip
> yes
>   
>
>   
> firewall-drop
> firewall-drop.sh
> srcip
> yes
>   
>
>   
> disable-account
> disable-account.sh
> user
> yes
>   
>
>   
> restart-ossec
> restart-ossec.sh
> 
>   
>
>
>   
> route-null
> route-null.sh
> srcip
> yes
>   
>
>
>   
>   
> 
> host-deny
> local
> 6
> 600
>   
>
>   
> 
> firewall-drop
> local
> 6
> 600
>   
>
>   
>
>   
> syslog
> /var/log/dpkg.log
>   
>
>   
> command
> df -P
>   
>
>   
> full_command
> netstat -tan |grep LISTEN |egrep -v '(127.0.0.1| ::1)' |
sort
>   
>
>   
> full_command
> last -n 5
>   
> 
>
>   
>   
> rules_config.xml
> pam_rules.xml
> sshd_rules.xml
> telnetd_rules.xml
> syslog_rules.xml
> arpwatch_rules.xml
> symantec-av_rules.xml
> symantec-ws_rules.xml
> pix_rules.xml
> named_rules.xml
> smbd_rules.xml
> vsftpd_rules.xml
> pure-ftpd_rules.xml
> proftpd_rules.xml
> ms_ftpd_rules.xml
> ftpd_rules.xml
> hordeimp_rules.xml
> roundcube_rules.xml
> wordpress_rules.xml
> cimserver_rules.xml
> vpopmail_rules.xml
> vmpop3d_rules.xml
> courier_rules.xml
> web_rules.xml
> web_appsec_rules.xml
> apache_rules.xml
> nginx_rules.xml
> php_rules.xml
> mysql_rules.xml
> postgresql_rules.xml
> ids_rules.xml
> squid_rules.xml
> firewall_rules.xml
> apparmor_rules.xml
> cisco-ios_rules.xml
> netscreenfw_rules.xml
> sonicwall_rules.xml
> postfix_rules.xml
> sendmail_rules.xml
> imapd_rules.xml
> mailscanner_rules.xml
> dovecot_rules.xml
> ms-exchange_rules.xml
> racoon_rules.xml
> vpn_concentrator_rules.xml
> spamd_rules.xml
> msauth_rules.xml
> mcafee_av_rules.xml
> trend-osce_rules.xml
> ms-se_rules.xml
> 
> zeus_rules.xml
> solaris_bsm_rules.xml
> vmware_rules.xml
> ms_dhcp_rules.xml
> asterisk_rules.xml
> ossec_rules.xml
> attack_rules.xml
> openbsd_rules.xml
> clam_av_rules.xml
> dropbear_rules.xml
> sysmon_rules.xml
> opensmtpd_rules.xml
> local_rules.xml
> 
>   
>
> Content of /var/ossec/logs/ossec.log
>
> 2016/11/19 14:57:03 ossec-testrule(1132): ERROR: Unable to chroot to
directory '/var/ossec' due to 

Re: [ossec-list] agentless monitoring and cisco ios switches

[dan (ddp)]

On Fri, Nov 18, 2016 at 5:23 AM, Kevin COUSIN  wrote:
>
>
> Le jeudi 17 novembre 2016 18:15:57 UTC+1, dan (ddpbsd) a écrit :
>>
>> On Thu, Nov 17, 2016 at 11:39 AM, Kevin COUSIN 
>> wrote:
>> > Hi list,
>> >
>> > I try to use agentless on cisco ios switches. I add in ossec.conf
>> >
>> >  
>> > ssh_pixconfig_diff
>> > 300
>> > user@switch
>> > periodic_diff
>> >   
>> >
>> > I have ossec-agentlessd: INFO: Test passed for 'ssh_pixconfig_diff'. in
>> > log
>> > file but I don't know if it connect to my switch.
>> >
>>
>> Check your switch's logs?
>> Run the script manually to see if it works?
>
>
> Thanks. I thought I have some logs when ossec connect to the switch, even if
> there is no diff.
>

If you turn on the log all option, you might get something in archives.log.

> Regards,
>
>>
>>
>> > How can I test ?
>> >
>> > Regards
>> >
>> > Kevin
>> >
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] agentless monitoring and cisco ios switches

[dan (ddp)]

On Thu, Nov 17, 2016 at 11:39 AM, Kevin COUSIN  wrote:
> Hi list,
>
> I try to use agentless on cisco ios switches. I add in ossec.conf
>
>  
> ssh_pixconfig_diff
> 300
> user@switch
> periodic_diff
>   
>
> I have ossec-agentlessd: INFO: Test passed for 'ssh_pixconfig_diff'. in log
> file but I don't know if it connect to my switch.
>

Check your switch's logs?
Run the script manually to see if it works?

> How can I test ?
>
> Regards
>
> Kevin
>
>
> --
>
> ---
> 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: Don't see the intrusion logs

[dan (ddp)]

Did you restart the ossec processes after adding the new localfile entry?
Try running the logs through ossec-logtest.


On Thu, Nov 17, 2016 at 5:39 AM, Arthur Hidalgo
 wrote:
> In the file "/var/log/secure" :
>
> Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.22.130.26  user=SVCWABADMINSUP
> Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]: pam_sss(sshd:auth):
> authentication success; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.22.130.26 user=SVCWABADMINSUP

For these I get:
Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.22.130.26  user=SVCWABADMINSUP

**Phase 1: Completed pre-decoding.
   full event: 'Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]:
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=10.22.130.26  user=SVCWABADMINSUP'
   hostname: 'PCYINTPSEVU001'
   program_name: 'sshd'
   log: 'pam_unix(sshd:auth): authentication failure; logname=
uid=0 euid=0 tty=ssh ruser= rhost=10.22.130.26  user=SVCWABADMINSUP'

**Phase 2: Completed decoding.
   decoder: 'pam'
   srcip: '10.22.130.26'
   dstuser: 'SVCWABADMINSUP'

**Phase 3: Completed filtering (rules).
   Rule id: '5503'
   Level: '5'
   Description: 'User login failed.'
**Alert to be generated.



> Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]: Accepted password for
> SVCWABADMINSUP from 10.22.130.26 port 53878 ssh2
>

And for this one:
Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]: Accepted password for
SVCWABADMINSUP from 10.22.130.26 port 53878 ssh2

**Phase 1: Completed pre-decoding.
   full event: 'Nov 17 11:05:03 PCYINTPSEVU001 sshd[35427]:
Accepted password for SVCWABADMINSUP from 10.22.130.26 port 53878
ssh2'
   hostname: 'PCYINTPSEVU001'
   program_name: 'sshd'
   log: 'Accepted password for SVCWABADMINSUP from 10.22.130.26
port 53878 ssh2'

**Phase 2: Completed decoding.
   decoder: 'sshd'
   dstuser: 'SVCWABADMINSUP'
   srcip: '10.22.130.26'

**Phase 3: Completed filtering (rules).
   Rule id: '5715'
   Level: '3'
   Description: 'SSHD authentication success.'
**Alert to be generated.


> So in OSSEC, we must have an alert for the IP 10.22.130.26
>

Check /var/ossec/logs/alerts/alerts.log to see if there is anything in
there for those logs.

> Le jeudi 17 novembre 2016 08:05:15 UTC+1, Arthur Hidalgo a écrit :
>>
>> Hi!
>>
>> I have installed OSSEC agents on RedHat VM.But I have not see the
>> intrusion alerts on the Web. On RedHat VM, the intrusion logs are in the
>> file :"../var/log/secure"".
>> This is the config on "ossec.conf":
>> /etc,/usr/bin,/usr/sbin
>> /bin,/sbin
>> .
>> .
>> .
>>   
>> syslog
>> /var/log/secure
>>   
>>
>> Regards,
>>
>> Arthur.
>>
> --
>
> ---
> 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] A few comments on default active-response settings

[dan (ddp)]

On Mon, Nov 14, 2016 at 10:51 AM, Whit Blauvelt <w...@transpect.com> wrote:
> On Fri, Nov 11, 2016 at 07:10:51PM -0500, dan (ddp) wrote:
>> On Nov 11, 2016 4:11 PM, "Whit Blauvelt" <w...@transpect.com> wrote:
>> >
>> > With a default agent installation of 2.9rc3 with active response included, 
>> > I
>> > was surprised by a few things:
>> >
>> > 1. Too frequent connections, even successful ones with valid logins, to an
>> >ftp or sftp server are considered an attack and blocked for a time. This
>> >was unfortunate, since we use both heavily in contexts where frequent
>> >connections are how the systems exchange files.
>>
>> I think you're expected to tweak ossec to your usage.
>
> Certainly. But it's also a decent target to have the default installation
> not be something that will be dangerously broken unless carefully tweaked
> first -- especially without prominent warnings about the dangers involved.
> Except in a context of anon FTP servers (does anyone run those any more?)
> blocking IPs because they connect using valid logins "too often" is a
> dangerous default. "First, do no harm."
>

Creating perfect defaults for every environment is nearly impossible.
Niche and odd-ball usage patterns can cause issues.

Which rule was triggering the alerts? Maybe it's time for a tweak.


>> > 2. With iptables, OSSEC adds DROPs without having the LOGged. Yes, OSSEC
>> >records adding its rule to its own log. But on systems where there are
>> >already complex firewall rules, it's natural to see precisely what's
>> >being dropped in the standard logs. It's fairly standard practice with
>> >Netfilter to log what you drop.
>>
>> Please submit a pull request.
>
> Okay, once I work up the fix.
>

Much appreciated. :)

>> > 3. OSSEC emails notices about the alerts, but not about its active
>> >responses. That seems an omission.
>>
>> Configure ossec to watch the ar log file, then make sure there ia a rule to
>> alert you to it doing things. Or create a rule. I can't remember if there is
>> one by default or not.
>
> Thanks, I'll have to do that.
>
> For consistency, since ossec emails about everything else, wouldn't it be
> best if this was default behavior for ar too?
>

I've always thought AR needed better logging, just haven't looked into
changing it.

> Is this a project where constructive criticism is not desired? For some
> projects putting out a "release candidate" is an invitation to critique, so
> it can be better perfected.
>

Criticism is welcomed, constructive even more so. But I don't always
agree with it, and may need more convincing.
I guard my hobby time fiercely.

> Best,
> Whit
>
> --
>
> ---
> 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: email not going out - "getaddrinfo: Name or service not known"

[dan (ddp)]

On Mon, Nov 14, 2016 at 10:40 AM, Whit Blauvelt  wrote:
> On Sat, Nov 12, 2016 at 11:17:19AM -0800, Dave Stoddard wrote:
>> If OSSEC is chrooting to /var/ossec, copy your /etc/services and 
>> /etc/hosts
>> files to the /var/ossec/etc directory.  Do not use a symlink or a 
>> hardlink
>> -- copy them physically into the directory. It will find them without any
>> issue and your problem should go away. Best,
>
> Thanks Dave. Only question is: why doesn't the installation routine either
> just do this, or ask for permission to do so?
>

IIRC the setting used to require an IP address,so this wasn't
necessary. Since then either no one's cared, no one's noticed, or no
one wants to change the default behavior (expecting admins to
understand chroot).

> Best,
> Whit
>
> --
>
> ---
> 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] email not going out - "getaddrinfo: Name or service not known"

[dan (ddp)]

On Nov 11, 2016 3:52 PM, "Whit Blauvelt" <w...@transpect.com> wrote:
>
> On Tue, Nov 08, 2016 at 04:37:04AM -0500, dan (ddp) wrote:
>
> > Have you tried 127.0.0.1?
>
> 127.0.0.1 does work.
>
> So this has something to do with chrooting in the current version? I do
have
> localhost defined in /etc/hosts. Not sure how OSSEC is handling the
> chrooting. Where will I find documentation on that?
>

What kind of documentation do you need? Ossec chroots to the install dir
(/var/ossec by default)

> Whit
>
> --
>
> ---
> 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: email not going out - "getaddrinfo: Name or service not known"

[dan (ddp)]

On Nov 11, 2016 3:54 PM, "Whit Blauvelt"  wrote:
>
> On Wed, Nov 09, 2016 at 10:19:21AM -0800, Dave Stoddard wrote:
> > If you are getting that message with getaddrinfo, it is likely you do
not have
> > an /etc/services file on your system, or smtp is not defined in the
/etc/
> > services file. Alternatively, it could be referring to localhost - in
that
> > case, make sure you have an entry in the /etc/hosts file for localhost.
>
> Thanks. I do have an /etc/services file with smtp defined in it, and a
> localhost entry in /etc/hosts. So must be the chroot-y thing added lately.
>

Lately being relative, I guess. Maild has been chrooting for as long as I
remember.

> Whit
>
> --
>
> ---
> 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] A few comments on default active-response settings

[dan (ddp)]

On Nov 11, 2016 4:11 PM, "Whit Blauvelt"  wrote:
>
> With a default agent installation of 2.9rc3 with active response
included, I
> was surprised by a few things:
>
> 1. Too frequent connections, even successful ones with valid logins, to an
>ftp or sftp server are considered an attack and blocked for a time.
This
>was unfortunate, since we use both heavily in contexts where frequent
>connections are how the systems exchange files.
>

I think you're expected to tweak ossec to your usage.

> 2. With iptables, OSSEC adds DROPs without having the LOGged. Yes, OSSEC
>records adding its rule to its own log. But on systems where there are
>already complex firewall rules, it's natural to see precisely what's
>being dropped in the standard logs. It's fairly standard practice with
>Netfilter to log what you drop.
>

Please submit a pull request.

> 3. OSSEC emails notices about the alerts, but not about its active
>responses. That seems an omission.
>

Configure ossec to watch the ar log file, then make sure there ia a rule to
alert you to it doing things. Or create a rule. I can't remember if there
is one by default or not.

> It will be simple to fix the script to fix (2). Haven't quite sussed out
> where the rules creating the problem for (1) are enabled -- any pointers
on
> finding those will be appreciated. As for (3), is that something
> configurable within a stock installation, or will it require programming?
>
> Generally on (1), if someone has a valid login, it's just not going to be
an
> attack. For an ftp server accepting anonymous logins tracking frequence is
> vital to defense, on the other hand. Having the default rule be to block
> valid users for making "too much" use may not be ideal.
>
> On the whole, though, I've been highly impressed with the rest of the
> default behaviors.
>
> Best,
> Whit
>
> --
>
> ---
> 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] invalid option for 2.8.3 ossec-authd -k -v -x but documentation says they are there. Attached screenshot. Am I doing something wrong?

[dan (ddp)]

On Fri, Nov 11, 2016 at 1:16 PM, 'James Vernon' via ossec-list
<ossec-list@googlegroups.com> wrote:
>
>
> On Friday, 11 November 2016 17:39:18 UTC, dan (ddpbsd) wrote:
>>
>> On Fri, Nov 11, 2016 at 12:37 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> > On Fri, Nov 11, 2016 at 12:31 PM, 'James Vernon' via ossec-list
>> > <ossec...@googlegroups.com> wrote:
>> >>
>> >> http://imgur.com/a/efxLo
>> >>
>> >> If you follow that screenshot, you can see what I mean. These options
>> >> were added in 2.8.1, and I have 2.8.3 yet they are invalid. Am I missing
>> >> something really simple here?
>> >>
>> >
>> > When in doubt, trust the binary:
>> >
>> > [ddp@ix] :; pwd
>> > /home/ddp/tmp/ossec-hids-2.8.3/src/os_auth
>> > [ddp@ix] :; grep getopt *
>> > main-client.c:while((c = getopt(argc, argv, "Vdhu:g:D:c:m:p:A:")) !=
>> > -1)
>> > main-server.c:while((c = getopt(argc, argv, "Vdhiu:g:D:c:m:p:")) !=
>> > -1)
>> > ssl-test.c:while((c = getopt(argc, argv, "h:p:")) != -1)
>> >
>>
>> Or, I guess the documentation too:
>>
>> https://ossec.github.io/docs/programs/ossec-authd.html#cmdoption-ossec-authd-v
>>
>> Where in the documentation did you find a reference to 2.8.1? I'd like
>> to correct it.
>>
>> >
>> >
>> >>
>> >> --
>> >>
>> >> ---
>> >> 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.
>
>
> Turns out I was missing something simple. I wasn't looking at the OFFICIAL
> documentation.
>
> https://ossec-docs.readthedocs.io/en/latest/programs/ossec-authd.html
>
> I really messed that one up. Sorry for wasting your time.
>

Not your fault. I'm sure there are many many references to the old
documentation out there still.

> --
>
> ---
> 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] invalid option for 2.8.3 ossec-authd -k -v -x but documentation says they are there. Attached screenshot. Am I doing something wrong?

[dan (ddp)]

On Fri, Nov 11, 2016 at 12:31 PM, 'James Vernon' via ossec-list
 wrote:
>
> http://imgur.com/a/efxLo
>
> If you follow that screenshot, you can see what I mean. These options were 
> added in 2.8.1, and I have 2.8.3 yet they are invalid. Am I missing something 
> really simple here?
>

When in doubt, trust the binary:

[ddp@ix] :; pwd
/home/ddp/tmp/ossec-hids-2.8.3/src/os_auth
[ddp@ix] :; grep getopt *
main-client.c:while((c = getopt(argc, argv, "Vdhu:g:D:c:m:p:A:")) != -1)
main-server.c:while((c = getopt(argc, argv, "Vdhiu:g:D:c:m:p:")) != -1)
ssl-test.c:while((c = getopt(argc, argv, "h:p:")) != -1)



>
> --
>
> ---
> 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] invalid option for 2.8.3 ossec-authd -k -v -x but documentation says they are there. Attached screenshot. Am I doing something wrong?

[dan (ddp)]

On Fri, Nov 11, 2016 at 12:37 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Fri, Nov 11, 2016 at 12:31 PM, 'James Vernon' via ossec-list
> <ossec-list@googlegroups.com> wrote:
>>
>> http://imgur.com/a/efxLo
>>
>> If you follow that screenshot, you can see what I mean. These options were 
>> added in 2.8.1, and I have 2.8.3 yet they are invalid. Am I missing 
>> something really simple here?
>>
>
> When in doubt, trust the binary:
>
> [ddp@ix] :; pwd
> /home/ddp/tmp/ossec-hids-2.8.3/src/os_auth
> [ddp@ix] :; grep getopt *
> main-client.c:while((c = getopt(argc, argv, "Vdhu:g:D:c:m:p:A:")) != -1)
> main-server.c:while((c = getopt(argc, argv, "Vdhiu:g:D:c:m:p:")) != -1)
> ssl-test.c:while((c = getopt(argc, argv, "h:p:")) != -1)
>

Or, I guess the documentation too:
https://ossec.github.io/docs/programs/ossec-authd.html#cmdoption-ossec-authd-v

Where in the documentation did you find a reference to 2.8.1? I'd like
to correct it.

>
>
>>
>> --
>>
>> ---
>> 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] Integrity Checking Issue on Windows Server 2012 R2 with OSSEC 2.8.3

[dan (ddp)]

On Fri, Nov 11, 2016 at 10:41 AM, Keith  wrote:
> I have a new OSSEC install on a 2012r2 box and have set up on directory I
> need to monitor in realtime for any changes or modifications to this one
> specific folder. It does not  appear to be working so any suggestions on
> this would be appreciated. Here is the config from the client side 2012r2
> server:
>
>  report_changes="yes">C:\LIS_Global_Import
>
> Once I added this, I restarted the agent then forced the updated on the
> server side:
>
> # ./agent_control -r -u 019
>
> I added to files into the directory being monitored and nothing, no alert,
> no email, nada..
>
> # ./syscheck_control -i 019
>
> Integrity changes for agent 'xx (019) - x.x.x.x':
>
> Changes for 2016 Nov 11:
> 2016 Nov 11 09:55:39,0 - ossec.conf
> 2016 Nov 11 10:08:58,0 - ossec.conf
> 2016 Nov 11 10:15:46,2 - ossec.conf
>

Are the files in question in the syscheck db
(/var/ossec/queue/syscheck/something identifying the agent) on the
OSSEC server?
Were there baseline hashes in the database for those files before you
modified them?
Had realtime initialized before you made the changes? Look in
ossec.log on the agent

> --
>
> ---
> 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: email not going out - "getaddrinfo: Name or service not known"

[dan (ddp)]

On Wed, Nov 9, 2016 at 1:19 PM, Dave Stoddard  wrote:
> If you are getting that message with getaddrinfo, it is likely you do not
> have an /etc/services file on your system, or smtp is not defined in the
> /etc/services file. Alternatively, it could be referring to localhost - in
> that case, make sure you have an entry in the /etc/hosts file for localhost.
>

Remember that maild is probably chrooted, so change the directory appropriately.

> On Tuesday, November 8, 2016 at 4:35:44 AM UTC-5, Whit Blauvelt wrote:
>>
>> Hi,
>>
>> There have been multiple past discussions of email problems. Yet none seem
>> to cover this exactly. Here's what's logging, repeatedly:
>>
>>   2016/11/04 18:33:53 getaddrinfo: Name or service not known
>>   2016/11/04 18:33:53 ossec-maild(1223): ERROR: Error Sending email to
>> localhost (smtp server)
>>
>> It would be helpful to have better error messaging. What "name or service"
>> does it wish to know? What specifically was the "error sending email"?
>>
>> This system is:
>>
>>   ossec-hids-2.9rc3 (via install.sh)
>>   Ubuntu 16.04.1 LTS
>>   Postfix 3.1.0-3 (from Ubuntu apt)
>> - which works fine when test email composed in mutt and sent
>> - nothing in mail.log at time of ossec's "error sending email" events
>>
>> ossec.conf's only modification was to put in localhost rather than our MX,
>> as we don't want this dependent on an external mail system that way:
>>
>>   
>> yes
>> blah...@obfuscated.com
>> localhost
>> oss...@ossec.obfuscated.com
>>   
>>
>> Postfix is there listening:
>>
>>   root@rpc-ossec:/var/ossec/etc# telnet localhost 25
>>   Trying 127.0.0.1...
>>   Connected to localhost.
>>   Escape character is '^]'.
>>   220 ossec.obfuscated.com ESMTP Postfix (Ubuntu)
>>
>> What's the secret sauce to get ossec-maild to be happy with Postfix?
>>
>> Thanks,
>> Whit
>
> --
>
> ---
> 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] rebuilt endpoint

[dan (ddp)]

On Nov 8, 2016 9:53 AM, "Derek Day"  wrote:
>
> If i have a system that has an ossec agent running, and the system needs
to be rebuilt or replaced, using same name and addresses space etc, just a
pc refresh. do i need to generate a new ID and client.keys on the server
side or can i use the same id/client.keys that was previously created for
the now out of production computer?
>

You can use the same keys, IF you backup and restore the rids on the agent
or reset that agent's rids on the ossec server.

> --
>
> ---
> 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 Agent to server communication issue

[dan (ddp)]

On Tue, Nov 8, 2016 at 9:13 AM, Kumar G  wrote:
> Don't know if this falls under same issue. We are getting same error messages 
> on one of the ossec server A, no new agents addition via manage_agents or 
> ossec_authd were changing the status from "Never connected" to Active after 
> adding them. Both manual and ossec auth worked out, these were the first 
> agents which I tried to connect and they did not.
>
> Hence have to repoint them to another ossec server B where it worked. So is 
> it safe to delete the client.keys file from first ossec server and add a 
> server via manage-agents? Please let us know if its safe to delete the 
> client.keys? There are no agents currently reporting to the ossec server A.
>

Stop the OSSEC processes on that server, then delete the file.

>
> Thanks
> Kumar
>
> --
>
> ---
> 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] email not going out - "getaddrinfo: Name or service not known"

[dan (ddp)]

On Nov 8, 2016 4:35 AM, "Whit Blauvelt"  wrote:
>
> Hi,
>
> There have been multiple past discussions of email problems. Yet none seem
> to cover this exactly. Here's what's logging, repeatedly:
>
>   2016/11/04 18:33:53 getaddrinfo: Name or service not known
>   2016/11/04 18:33:53 ossec-maild(1223): ERROR: Error Sending email to
localhost (smtp server)
>
> It would be helpful to have better error messaging. What "name or service"
> does it wish to know? What specifically was the "error sending email"?
>
> This system is:
>
>   ossec-hids-2.9rc3 (via install.sh)
>   Ubuntu 16.04.1 LTS
>   Postfix 3.1.0-3 (from Ubuntu apt)
> - which works fine when test email composed in mutt and sent
> - nothing in mail.log at time of ossec's "error sending email" events
>
> ossec.conf's only modification was to put in localhost rather than our MX,
> as we don't want this dependent on an external mail system that way:
>
>   
> yes
> blahb...@obfuscated.com
> localhost
>

Have you tried 127.0.0.1?
oss...@ossec.obfuscated.com
>   
>
> Postfix is there listening:
>
>   root@rpc-ossec:/var/ossec/etc# telnet localhost 25
>   Trying 127.0.0.1...
>   Connected to localhost.
>   Escape character is '^]'.
>   220 ossec.obfuscated.com ESMTP Postfix (Ubuntu)
>
> What's the secret sauce to get ossec-maild to be happy with Postfix?
>
> Thanks,
> Whit
>
> --
>
> ---
> 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] getting error: ossec-remoted(1213): WARN: Message from 10.8.6.20 not allowed.

[dan (ddp)]

On Fri, Nov 4, 2016 at 10:09 AM, Stephen LuShing <smlush...@gmail.com> wrote:
> So  Dan I assume that i will need to reinstall the agent with the any or the
> 10.8.6.0/24 entry.I guess it will be for another server also with the same
> issue on the same subnet.
>

You shouldn't have to. You might need to generate new keys, but I'm
not positive about that (you might be able to modify client.keys and
restart the OSSEC processes on the OSSEC server).
Or, if you use routing, nothing should have to change beyond that.

> On Fri, Nov 4, 2016 at 9:06 AM, dan (ddp) <ddp...@gmail.com> wrote:
>>
>> On Fri, Nov 4, 2016 at 8:43 AM, Stephen LuShing <smlush...@gmail.com>
>> wrote:
>> > I was able to install an osec agent to a solaris 10 server and
>> > everything
>> > seems to be working. The only issue is I am getting this error and I
>> > think
>> > is because the network interface has a primary and a 2 virtual network
>> > interface. Here is the network settings:
>> >
>> > sovcbanat1# ifconfig -a
>> > lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
>> > 8232
>> > index 1
>> > inet 127.0.0.1 netmask ff00
>> > bge0:
>> > flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
>> > mtu
>> > 1500 index 2
>> > inet 10.8.6.21 netmask ff00 broadcast 10.8.6.255
>> > groupname NetworkMNICB
>> > ether 0:b:5d:e5:dd:66
>> > bge0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
>> > index 2
>> > inet 10.8.6.20 netmask ff00 broadcast 10.8.6.255
>> > bge2:
>> > flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
>> > mtu
>> > 1500 index 3
>> > inet 10.8.6.22 netmask ff00 broadcast 10.8.6.255
>> > groupname NetworkMNICB
>> > ether 0:b:5d:e5:dd:68
>> > bge2:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
>> > index 3
>> > inet 10.8.6.28 netmask ff00 broadcast 10.8.6.255
>> > sppp0:
>> > flags=10010008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4,FIXEDMTU>
>> > mtu
>> > 1500 index 4
>> > inet 10.1.1.2 --> 10.1.1.1 netmask ff00
>> > ether 0:0:0:0:0:0
>> >
>> >
>> > I had setup the agent as sovcbanat1-bge0 --> 10.8.6.21. When we login to
>> > server we login to 10.8.6.20 (sovcbanat1). The issue I think is that the
>> > remoted may not understand which is the primary interface since the
>> > other
>> > virtual interface are active also. I looked and google for a solution
>> > and
>> > one idea was to setup a allow_ip on the server.
>> >
>> >   
>> > secure
>> > 10.8.6.0/24
>>
>> I belive allowed-ips is only for syslog connection types.
>>
>> >   
>> >
>> > This does not seem to work as I am still getting the message.
>> >
>> > So does anyone have any idea on how to either fix this or somehow bypass
>> > this problem.
>> >
>>
>> If remoted is expecting the ossec packets to come from 10.8.6.21, you
>> need to make sure the packets come from that IP address.
>> Your OS should have routing options to make this happen.
>> Or you could add the agent with an IP of 10.8.6.0/24 or even "any."
>> Then it wouldn't matter as much which IP the packets come from.
>>
>> >
>> > Thanks in advance
>> >
>> > Stephen LuShing
>> > System administrator
>> > Hofstra University
>> >
>> > --
>> >
>> > ---
>> > 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 Signature Update Frequency

[dan (ddp)]

On Fri, Nov 4, 2016 at 6:25 AM, Jesus Linares  wrote:
> Hi Matthew,
>
> Of course, you can do the "same" procedure from OSSEC-HIDS but Wazuh is
> doing a great effort to centralize, test and maintain decoders and rules
> submitted by Open Source contributors and create new ones.
>

Wow, just wow.

-- 

--- 
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] getting error: ossec-remoted(1213): WARN: Message from 10.8.6.20 not allowed.

[dan (ddp)]

On Fri, Nov 4, 2016 at 8:43 AM, Stephen LuShing  wrote:
> I was able to install an osec agent to a solaris 10 server and everything
> seems to be working. The only issue is I am getting this error and I think
> is because the network interface has a primary and a 2 virtual network
> interface. Here is the network settings:
>
> sovcbanat1# ifconfig -a
> lo0: flags=2001000849 mtu 8232
> index 1
> inet 127.0.0.1 netmask ff00
> bge0:
> flags=9040843 mtu
> 1500 index 2
> inet 10.8.6.21 netmask ff00 broadcast 10.8.6.255
> groupname NetworkMNICB
> ether 0:b:5d:e5:dd:66
> bge0:2: flags=1000843 mtu 1500 index 2
> inet 10.8.6.20 netmask ff00 broadcast 10.8.6.255
> bge2:
> flags=9040843 mtu
> 1500 index 3
> inet 10.8.6.22 netmask ff00 broadcast 10.8.6.255
> groupname NetworkMNICB
> ether 0:b:5d:e5:dd:68
> bge2:2: flags=1000843 mtu 1500 index 3
> inet 10.8.6.28 netmask ff00 broadcast 10.8.6.255
> sppp0:
> flags=10010008d1 mtu
> 1500 index 4
> inet 10.1.1.2 --> 10.1.1.1 netmask ff00
> ether 0:0:0:0:0:0
>
>
> I had setup the agent as sovcbanat1-bge0 --> 10.8.6.21. When we login to
> server we login to 10.8.6.20 (sovcbanat1). The issue I think is that the
> remoted may not understand which is the primary interface since the other
> virtual interface are active also. I looked and google for a solution and
> one idea was to setup a allow_ip on the server.
>
>   
> secure
> 10.8.6.0/24

I belive allowed-ips is only for syslog connection types.

>   
>
> This does not seem to work as I am still getting the message.
>
> So does anyone have any idea on how to either fix this or somehow bypass
> this problem.
>

If remoted is expecting the ossec packets to come from 10.8.6.21, you
need to make sure the packets come from that IP address.
Your OS should have routing options to make this happen.
Or you could add the agent with an IP of 10.8.6.0/24 or even "any."
Then it wouldn't matter as much which IP the packets come from.

>
> Thanks in advance
>
> Stephen LuShing
> System administrator
> Hofstra University
>
> --
>
> ---
> 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] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:50 PM, Jit Tank <jitt...@gmail.com> wrote:
> Dan - thanks for your time ... which version of ESXi are you testing
> against?
>

5.5

> On Thu, Nov 3, 2016 at 4:44 PM, dan (ddp) <ddp...@gmail.com> wrote:
>>
>> On Thu, Nov 3, 2016 at 12:31 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> > On Thu, Nov 3, 2016 at 12:24 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> >> On Thu, Nov 3, 2016 at 12:07 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> >>> On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank <jitt...@gmail.com> wrote:
>> >>>> Can anyone confirm the ssh_integrity_check_linux agentless script
>> >>>> works on
>> >>>> the ESXi 4.x, 5.x and 6.x platforms?
>> >>>>
>> >>>
>> >>> If you have an ESXi box, you can.
>> >>>
>> >>
>> >> After some quick testing, you have to modify ssh.exp adding:
>> >> "Password:" {
>> >> send "$pass\r"
>> >> source $sshloginsrc
>> >> }
>> >>
>> >>
>> >> I haven't figured out sshlogin.exp yet, but something there has to be
>> >> modified as well.
>> >>
>> >
>> > It get farther when I add this, but I haven't verified if it's actually
>> > working:
>> > "*" {
>> > send_user "\nINFO: Started.\n"
>> > }
>> >
>> > I expect my lack of expect knowledge is to blame for my inability to
>> > match the command prompt.
>>
>>
>> And trying it from the correct host this time...
>> The actual business line in ssh_integrity_check_linux.exp has to be
>> modified.
>> send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do
>> tail \$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` &&
>> sha1=`sha1sum \$i | cut -d \" \" -f 1` && echo FWD: `stat -c
>> \"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
>>
>> I haven't figured out what it needs to be yet, but I'm quickly eating
>> up my free time :-)
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ossec-list" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/ossec-list/OT0WKGWdQD4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:44 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 12:31 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> On Thu, Nov 3, 2016 at 12:24 PM, dan (ddp) <ddp...@gmail.com> wrote:
>>> On Thu, Nov 3, 2016 at 12:07 PM, dan (ddp) <ddp...@gmail.com> wrote:
>>>> On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank <jitt...@gmail.com> wrote:
>>>>> Can anyone confirm the ssh_integrity_check_linux agentless script works on
>>>>> the ESXi 4.x, 5.x and 6.x platforms?
>>>>>
>>>>
>>>> If you have an ESXi box, you can.
>>>>
>>>
>>> After some quick testing, you have to modify ssh.exp adding:
>>> "Password:" {
>>> send "$pass\r"
>>> source $sshloginsrc
>>> }
>>>
>>>
>>> I haven't figured out sshlogin.exp yet, but something there has to be
>>> modified as well.
>>>
>>
>> It get farther when I add this, but I haven't verified if it's actually 
>> working:
>> "*" {
>> send_user "\nINFO: Started.\n"
>> }
>>
>> I expect my lack of expect knowledge is to blame for my inability to
>> match the command prompt.
>
>
> And trying it from the correct host this time...
> The actual business line in ssh_integrity_check_linux.exp has to be modified.
> send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do
> tail \$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` &&
> sha1=`sha1sum \$i | cut -d \" \" -f 1` && echo FWD: `stat -c
> \"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
>

I think the "--printf" in stat might be the only necessary change:

send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do
tail \$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` &&
sha1=`sha1sum \$i | cut -d \" \" -f 1` && echo FWD: `stat -c
\"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"

> I haven't figured out what it needs to be yet, but I'm quickly eating
> up my free time :-)

-- 

--- 
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] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:31 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 12:24 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> On Thu, Nov 3, 2016 at 12:07 PM, dan (ddp) <ddp...@gmail.com> wrote:
>>> On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank <jitt...@gmail.com> wrote:
>>>> Can anyone confirm the ssh_integrity_check_linux agentless script works on
>>>> the ESXi 4.x, 5.x and 6.x platforms?
>>>>
>>>
>>> If you have an ESXi box, you can.
>>>
>>
>> After some quick testing, you have to modify ssh.exp adding:
>> "Password:" {
>> send "$pass\r"
>> source $sshloginsrc
>> }
>>
>>
>> I haven't figured out sshlogin.exp yet, but something there has to be
>> modified as well.
>>
>
> It get farther when I add this, but I haven't verified if it's actually 
> working:
> "*" {
> send_user "\nINFO: Started.\n"
> }
>
> I expect my lack of expect knowledge is to blame for my inability to
> match the command prompt.


And trying it from the correct host this time...
The actual business line in ssh_integrity_check_linux.exp has to be modified.
send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do
tail \$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` &&
sha1=`sha1sum \$i | cut -d \" \" -f 1` && echo FWD: `stat -c
\"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"

I haven't figured out what it needs to be yet, but I'm quickly eating
up my free time :-)

-- 

--- 
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-authd TLS1.2 only

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:18 PM, john homer alvero  wrote:
> Hello,
>
> Is there a way for ossec-authd to establish TLS1.2 only? The reason im
> asking is that our vulnerability scanner is flagging the ossec-authd port
> 1515 as insecure because of support for RC4 and other non-tls1.2 protocols.
>

You'll have to modify the source.

> --
>
> ---
> 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] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:24 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 12:07 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank <jitt...@gmail.com> wrote:
>>> Can anyone confirm the ssh_integrity_check_linux agentless script works on
>>> the ESXi 4.x, 5.x and 6.x platforms?
>>>
>>
>> If you have an ESXi box, you can.
>>
>
> After some quick testing, you have to modify ssh.exp adding:
> "Password:" {
> send "$pass\r"
> source $sshloginsrc
> }
>
>
> I haven't figured out sshlogin.exp yet, but something there has to be
> modified as well.
>

It get farther when I add this, but I haven't verified if it's actually working:
"*" {
send_user "\nINFO: Started.\n"
}

I expect my lack of expect knowledge is to blame for my inability to
match the command prompt.

-- 

--- 
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] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 12:07 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank <jitt...@gmail.com> wrote:
>> Can anyone confirm the ssh_integrity_check_linux agentless script works on
>> the ESXi 4.x, 5.x and 6.x platforms?
>>
>
> If you have an ESXi box, you can.
>

After some quick testing, you have to modify ssh.exp adding:
"Password:" {
send "$pass\r"
source $sshloginsrc
}


I haven't figured out sshlogin.exp yet, but something there has to be
modified as well.


>>
>>
>> On Thursday, November 3, 2016 at 12:45:45 PM UTC, dan (ddpbsd) wrote:
>>>
>>> On Thu, Nov 3, 2016 at 5:50 AM, Jit Tank <jit...@gmail.com> wrote:
>>> > I note that OSSEC agent only supports VMWare ESX 3.0,3.5.
>>> >
>>> > Is it possible to perform file integrity checks on VMware vSphere ESXi
>>> > 4.x,
>>> > 5.x and 6.x?
>>> >
>>> > If possible, how is this completed? By agentless monitoring or by
>>> > compiling
>>> > new agent binaries that can reside on the ESXi 4.x, 5.x and 6.x
>>> > platforms?
>>> >
>>>
>>> It looks like the ssh_integrity_check_linux agentless script should
>>> work (but I haven't tried it).
>>>
>>> >
>>> > --
>>> >
>>> > ---
>>> > 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.

Re: [ossec-list] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 11:58 AM, Jit Tank  wrote:
> Can anyone confirm the ssh_integrity_check_linux agentless script works on
> the ESXi 4.x, 5.x and 6.x platforms?
>

If you have an ESXi box, you can.

>
>
> On Thursday, November 3, 2016 at 12:45:45 PM UTC, dan (ddpbsd) wrote:
>>
>> On Thu, Nov 3, 2016 at 5:50 AM, Jit Tank  wrote:
>> > I note that OSSEC agent only supports VMWare ESX 3.0,3.5.
>> >
>> > Is it possible to perform file integrity checks on VMware vSphere ESXi
>> > 4.x,
>> > 5.x and 6.x?
>> >
>> > If possible, how is this completed? By agentless monitoring or by
>> > compiling
>> > new agent binaries that can reside on the ESXi 4.x, 5.x and 6.x
>> > platforms?
>> >
>>
>> It looks like the ssh_integrity_check_linux agentless script should
>> work (but I haven't tried it).
>>
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] File Integrity Monitoring for ESXi 4.x, 5.x and 6.x

[dan (ddp)]

On Thu, Nov 3, 2016 at 5:50 AM, Jit Tank  wrote:
> I note that OSSEC agent only supports VMWare ESX 3.0,3.5.
>
> Is it possible to perform file integrity checks on VMware vSphere ESXi 4.x,
> 5.x and 6.x?
>
> If possible, how is this completed? By agentless monitoring or by compiling
> new agent binaries that can reside on the ESXi 4.x, 5.x and 6.x platforms?
>

It looks like the ssh_integrity_check_linux agentless script should
work (but I haven't tried it).

>
> --
>
> ---
> 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] Chroot directory change option

[dan (ddp)]

root -g 0 ossec-dbd ${PREFIX}/bin
install -m 0550 -o root -g 0 ossec-makelists ${PREFIX}/bin
install -m 0550 -o root -g 0 verify-agent-conf ${PREFIX}/bin/
install -m 0550 -o root -g 0 clear_stats ${PREFIX}/bin/
install -m 0550 -o root -g 0 list_agents ${PREFIX}/bin/
install -m 0550 -o root -g 0 ossec-regex ${PREFIX}/bin/
install -m 0550 -o root -g 0 syscheck_update ${PREFIX}/bin/
install -m 0550 -o root -g 0 agent_control ${PREFIX}/bin/
install -m 0550 -o root -g 0 syscheck_control ${PREFIX}/bin/
install -m 0550 -o root -g 0 rootcheck_control ${PREFIX}/bin/

install -d -m 0750 -o ${OSSEC_USER} -g ${OSSEC_GROUP} ${PREFIX}/stats
install -d -m 0550 -o root -g ${OSSEC_GROUP} ${PREFIX}/rules
ifneq (,$(wildcard ${PREFIX}/rules/local_rules.xml))
cp ${PREFIX}/rules/local_rules.xml
${PREFIX}/rules/local_rules.xml.installbackup
install -m 0640 -o root -g ${OSSEC_GROUP} -b
../etc/rules/*.xml ${PREFIX}/rules
install -m 0640 -o root -g ${OSSEC_GROUP}
${PREFIX}/rules/local_rules.xml.installbackup
${PREFIX}/rules/local_rules.xml
rm ${PREFIX}/rules/local_rules.xml.installbackup
else
install -m 0640 -o root -g ${OSSEC_GROUP} -b
../etc/rules/*.xml ${PREFIX}/rules
endif

install -d -m 0750 -o ${OSSEC_USER} -g ${OSSEC_GROUP}
${PREFIX}/queue/fts

install -d -m 0750 -o ${OSSEC_USER} -g ${OSSEC_GROUP}
${PREFIX}/queue/rootcheck

install -d -m 0750 -o ${OSSEC_USER_REM} -g ${OSSEC_GROUP}
${PREFIX}/queue/agent-info
install -d -m 0750 -o ${OSSEC_USER} -g ${OSSEC_GROUP}
${PREFIX}/queue/agentless

install -d -m 0750 -o ${OSSEC_USER_REM} -g ${OSSEC_GROUP}
${PREFIX}/queue/rids

install -m 0640 -o root -g ${OSSEC_GROUP} ../etc/decoder.xml
${PREFIX}/etc/


> On Tuesday, November 1, 2016 at 8:27:43 PM UTC, dan (ddpbsd) wrote:
>>
>> On Nov 1, 2016 2:12 PM, "Eponymous -" <the@gmail.com> wrote:
>> >
>> > Just after I posted that message I had an idea to check the permissions
>> > again and it looks like they were wrong.
>> >
>> > The permissions on the FreeBSD install are all messed up completely.
>> > I've had to change so many manually and this was another I'd missed.
>> >
>> > So far I have the processes running as default like this (user -
>> > command):
>> >
>> > root/usr/local/ossec-hids/bin/ossec-execd
>> > ossec /usr/local/ossec-hids/bin/ossec-agentd
>> > root/usr/local/ossec-hids/bin/ossec-logcollector
>> > root/usr/local/ossec-hids/bin/ossec-syscheckd
>> >
>> > All the directories are set to root:ossec (root owner) and rwxr-wr-x.
>> >
>> > This is why agentd complained as it only had r-x access to
>> > /usr/local/ossec-hids/var/run.
>> >
>> > I also had to change /usr/local/ossec-hids/etc/shared,
>> > /usr/local/ossec-hids/queue/ossec and /usr/local/ossec-hids/queue/rids to 
>> > be
>> > owned by the ossec user.
>> >
>> > I've no idea how this installer managed to mess this up.
>> >
>> > Just for reference, what should the permissions for the processes and
>> > chroot directory look like?
>> >
>>
>> The users for the processes look correct, but I don't know the permissions
>> off hand. I'll try to look them up later.
>>
>> > Thanks!
>> >
>> >
>> > On Tuesday, November 1, 2016 at 6:03:31 PM UTC, dan (ddpbsd) wrote:
>> >>
>> >> On Tue, Nov 1, 2016 at 1:53 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> >> > On Tue, Nov 1, 2016 at 1:49 PM, Eponymous - <the@gmail.com>
>> >> > wrote:
>> >> >>>> To a process chrooted to /usr/local/ossec-hids, /var/run and
>> >> >>>> /usr/local/ossec-hids/var/run are the same thing. The process'
>> >> >>>> root
>> >> >>>> directory (/) is now /usr/local/ossec-hids. So
>> >> >>>> /usr/local/ossec-hids/var/run
>> >> >>>> looks like /var/run to that process.
>> >> >>
>> >> >> That is very true.
>> >> >>
>> >> >> Hmm, so why is it I get the error: ossec-agentd(1103): ERROR: Unable
>> >> >> to open
>> >> >> file '/var/run/.syscheck_run'
>> >> >> when I run without any command line options but then the error
>> >> >> disappears
>> >> >> when I specify "-D /usr/local/ossec-hids"? The two instances should
>> >> >> result
>> >> >> in the same behavi

Re: [ossec-list] OSSEC Signature Update Frequency

[dan (ddp)]

On Wed, Nov 2, 2016 at 12:00 PM, Matthew Casperson
 wrote:
> I've been trying to track down where it details how often signatures are
> updated for OSSEC.  Are new signatures part of each version?  E.g. if I am
> on 2.8.2 and want to have the most up to date signatures would I have to
> upgrade to the current version of OSSEC or are signatures updated
> independent of new version releases?  Help greatly appreciated.
>

The rules are currently updated with releases.

> Matt
>
> --
>
> ---
> 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] Chroot directory change option

[dan (ddp)]

On Nov 1, 2016 2:12 PM, "Eponymous -" <the.e...@gmail.com> wrote:
>
> Just after I posted that message I had an idea to check the permissions
again and it looks like they were wrong.
>
> The permissions on the FreeBSD install are all messed up completely. I've
had to change so many manually and this was another I'd missed.
>
> So far I have the processes running as default like this (user - command):
>
> root/usr/local/ossec-hids/bin/ossec-execd
> ossec /usr/local/ossec-hids/bin/ossec-agentd
> root/usr/local/ossec-hids/bin/ossec-logcollector
> root/usr/local/ossec-hids/bin/ossec-syscheckd
>
> All the directories are set to root:ossec (root owner) and rwxr-wr-x.
>
> This is why agentd complained as it only had r-x access to
/usr/local/ossec-hids/var/run.
>
> I also had to change /usr/local/ossec-hids/etc/shared,
/usr/local/ossec-hids/queue/ossec and /usr/local/ossec-hids/queue/rids to
be owned by the ossec user.
>
> I've no idea how this installer managed to mess this up.
>
> Just for reference, what should the permissions for the processes and
chroot directory look like?
>

The users for the processes look correct, but I don't know the permissions
off hand. I'll try to look them up later.

> Thanks!
>
>
> On Tuesday, November 1, 2016 at 6:03:31 PM UTC, dan (ddpbsd) wrote:
>>
>> On Tue, Nov 1, 2016 at 1:53 PM, dan (ddp) <ddp...@gmail.com> wrote:
>> > On Tue, Nov 1, 2016 at 1:49 PM, Eponymous - <the@gmail.com> wrote:
>> >>>> To a process chrooted to /usr/local/ossec-hids, /var/run and
>> >>>> /usr/local/ossec-hids/var/run are the same thing. The process' root
>> >>>> directory (/) is now /usr/local/ossec-hids. So
/usr/local/ossec-hids/var/run
>> >>>> looks like /var/run to that process.
>> >>
>> >> That is very true.
>> >>
>> >> Hmm, so why is it I get the error: ossec-agentd(1103): ERROR: Unable
to open
>> >> file '/var/run/.syscheck_run'
>> >> when I run without any command line options but then the error
disappears
>> >> when I specify "-D /usr/local/ossec-hids"? The two instances should
result
>> >> in the same behaviour?
>> >>
>> >
>> > No idea, I haven't looked at FreeBSD's port. Perhaps they have it
>> > configured to chroot to a directory that doesn't contain var/run?
>>
>> It's possible that this line
>> (
https://svnweb.freebsd.org/ports/head/security/ossec-hids-server/Makefile?revision=413754=markup#l87)

>> @${ECHO} "DIR=\"${STAGEDIR}${PREFIX}/${PORTNAME}\"" >
${WRKSRC}/src/LOCATION
>> in the port Makefile configures the chroot directory incorrectly.
>>
>> You can try `strings /var/ossec/bin/ossec-agentd | grep ossec` to see
>> if it gives you any clues as to what directory is expected.
>
> --
>
> ---
> 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] Chroot directory change option

[dan (ddp)]

On Tue, Nov 1, 2016 at 1:53 PM, dan (ddp) <ddp...@gmail.com> wrote:
> On Tue, Nov 1, 2016 at 1:49 PM, Eponymous - <the.e...@gmail.com> wrote:
>>>> To a process chrooted to /usr/local/ossec-hids, /var/run and
>>>> /usr/local/ossec-hids/var/run are the same thing. The process' root
>>>> directory (/) is now /usr/local/ossec-hids. So 
>>>> /usr/local/ossec-hids/var/run
>>>> looks like /var/run to that process.
>>
>> That is very true.
>>
>> Hmm, so why is it I get the error: ossec-agentd(1103): ERROR: Unable to open
>> file '/var/run/.syscheck_run'
>> when I run without any command line options but then the error disappears
>> when I specify "-D /usr/local/ossec-hids"? The two instances should result
>> in the same behaviour?
>>
>
> No idea, I haven't looked at FreeBSD's port. Perhaps they have it
> configured to chroot to a directory that doesn't contain var/run?

It's possible that this line
(https://svnweb.freebsd.org/ports/head/security/ossec-hids-server/Makefile?revision=413754=markup#l87)
@${ECHO} "DIR=\"${STAGEDIR}${PREFIX}/${PORTNAME}\"" > ${WRKSRC}/src/LOCATION
in the port Makefile configures the chroot directory incorrectly.

You can try `strings /var/ossec/bin/ossec-agentd | grep ossec` to see
if it gives you any clues as to what directory is expected.

-- 

--- 
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] Chroot directory change option

[dan (ddp)]

On Tue, Nov 1, 2016 at 1:49 PM, Eponymous -  wrote:
>>> To a process chrooted to /usr/local/ossec-hids, /var/run and
>>> /usr/local/ossec-hids/var/run are the same thing. The process' root
>>> directory (/) is now /usr/local/ossec-hids. So /usr/local/ossec-hids/var/run
>>> looks like /var/run to that process.
>
> That is very true.
>
> Hmm, so why is it I get the error: ossec-agentd(1103): ERROR: Unable to open
> file '/var/run/.syscheck_run'
> when I run without any command line options but then the error disappears
> when I specify "-D /usr/local/ossec-hids"? The two instances should result
> in the same behaviour?
>

No idea, I haven't looked at FreeBSD's port. Perhaps they have it
configured to chroot to a directory that doesn't contain var/run?

-- 

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