Re: [ossec-list] OSSEC Upgrade to 3.0.0
I found today, that running ossec-control (any option) displays the version number at the top. I have also been on to Wazuh about getting their public repo updated with version 3.0.0 to eliminate this issue. On Thursday, 30 August 2018 12:14:34 UTC+1, dan (ddpbsd) wrote: > > On Wed, Aug 29, 2018 at 6:06 AM Chris > wrote: > > > > Hi, > > > > I have upgraded OSSEC from 2.8.3 to 3.0.0 on my Ubuntu server, using the > install.sh from the expanded tar.gz. From what I can see this was > successful in running the upgrade, but as this was not an upgrade using the > repo, as version 3.0.0 isn't available on it. I cannot see how to get the > current version number as I will need this for evidence. > > > > dpkg -l shows the old version > > manage_agents -V shows 2.9.0?? > > > > Running one of the binaries with `-V` should give a version. > Unfortunately that doesn't always get bumped properly... > > > 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.
[ossec-list] OSSEC Upgrade to 3.0.0
Hi, I have upgraded OSSEC from 2.8.3 to 3.0.0 on my Ubuntu server, using the install.sh from the expanded tar.gz. From what I can see this was successful in running the upgrade, but as this was not an upgrade using the repo, as version 3.0.0 isn't available on it. I cannot see how to get the current version number as I will need this for evidence. dpkg -l shows the old version manage_agents -V shows 2.9.0?? 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.
[ossec-list] ossec Windows Agent incorrect
Hello,
It seems the Ossec Windows Agent logs incorrect process id: 0 for WinEvtLog:
Security: AUDIT_SUCCESS(4656)
The actual process id is in process name: 0x1abc
Can this be resolved ?
See log below
2018/03/12 10:04:30 ossec-agent: DEBUG: Sending message to server: '2018
Mar 12 10:04:29 WinEvtLog: Security: AUDIT_SUCCESS(4690):
Microsoft-Windows-Security-Auditing: (no user): no domain:
dc01_ADMIN.dc01_ds.local: An attempt was made to duplicate a handle to an
object. Subject: Security ID:
S-1-5-21-3302202820-3722458155-244911019-500 Account Name: administrator
Account Domain: dc01_DS Logon ID: 0x1061b5 Source Handle Information:
Source Handle ID: 0x1f18 Source Process ID: 0x1abc New Handle
Information: Target Handle ID: 0x928 Target Process ID: 0x4'
2018/03/12 10:04:30 ossec-agent: DEBUG: Attempting to send message to
server.
2018/03/12 10:04:30 ossec-agent: DEBUG: Sending message to server: '2018
Mar 12 10:04:29 WinEvtLog: Security: AUDIT_SUCCESS(4658):
Microsoft-Windows-Security-Auditing: (no user): no domain:
dc01_ADMIN.dc01_ds.local: The handle to an object was closed. Subject :
Security ID: S-1-5-21-3302202820-3722458155-244911019-500 Account Name:
administrator Account Domain: dc01_DS Logon ID: 0x1061b5 Object:
Object Server: Security Handle ID: 0x928 Process Information: Process
ID: 0x1abc Process Name: C:\Windows\explorer.exe'
2018/03/12 10:04:30 ossec-agent: DEBUG: Attempting to send message to
server.
*2018/03/12 10:04:30 ossec-agent: DEBUG: Sending message to server: '2018
Mar 12 10:04:29 WinEvtLog: Security: AUDIT_SUCCESS(4656):
Microsoft-Windows-Security-Auditing: (no user): no domain:
dc01_ADMIN.dc01_ds.local: A handle to an object was requested. Subject:
Security ID: S-1-5-21-3302202820-3722458155-244911019-500 Account Name:
administrator Account Domain: dc01_DS Logon ID: 0x1061b5 Object:
Object Server: Security Object Type: File Object Name:
C:\Windows\WinSxS\FileMaps\$$_system32_21f9a9c4a2f8b514.cdf-ms Handle ID:
0x1f18 Process Information: Process ID: 0 Process Name: 0x1abc Access
Request Information: Transaction ID:
{----} Accesses: %%1538 %%1541
%%4416 %%4419 %%4423Access Mask: %%1538:
%%1801 D:(A;;0x1200a9;;;BA) %%1541: %%1801 D:(A;;0x1200a9;;;BA)
%%4416: %%1801 D:(A;;0x1200a9;;;BA) %%4419:
%%1801 D:(A;;0x1200a9;;;BA) %%4423: %%1801 D:(A;;0x1200a9;;;BA)
Privileges Used for Access Check: 0x120089 Restricted SID Count: -'*
2018/03/12 10:04:30 ossec-agent: DEBUG: Attempting to send message to
server.
2018/03/12 10:04:30 ossec-agent: DEBUG: Sending message to server: '2018
Mar 12 10:04:29 WinEvtLog: Security: AUDIT_SUCCESS(4663):
Microsoft-Windows-Security-Auditing: (no user): no domain:
dc01_ADMIN.dc01_ds.local: An attempt was made to access an object.
Subject: Security ID: S-1-5-21-3302202820-3722458155-244911019-500
Account Name: administrator Account Domain: dc01_DS Logon ID:
0x1061b5 Object: Object Server: Security Object Type: File Object Name:
C:\Windows\WinSxS\FileMaps\$$_system32_21f9a9c4a2f8b514.cdf-ms Handle ID:
0x1f18 Process Information: Process ID: 0x1abc Process Name:
C:\Windows\explorer.exe Access Request Information: Accesses:
%%1541Access Mask: 0x10'
2018/03/12 10:04:30 ossec-agent: DEBUG: Attempting to send message to
server.
2018/03/12 10:04:30 ossec-agent: DEBUG: Sending message to server: '2018
Mar 12 10:04:29 WinEvtLog: Security: AUDIT_SUCCESS(4658):
Microsoft-Windows-Security-Auditing: (no user): no domain:
dc01_ADMIN.dc01_ds.local: The handle to an object was closed. Subject :
Security ID: S-1-5-21-3302202820-3722458155-244911019-500 Account Name:
administrator Account Domain: dc01_DS Logon ID: 0x1061b5 Object:
Object Server: Security Handle ID: 0x1f18 Process Information: Process
ID: 0x1abc Process Name: C:\Windows\explorer.exe'
--
---
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
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. 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 <dago...@gmail.com > > 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.
[ossec-list] Inconsistencies with syscheck realtime + report_changes
All, I have hundreds of machines that are (supposed to be) all configured exactly the same way via kickstarts and periodic Puppet runs. I've noticed that sometimes a Puppet push will modify a file across all of our machines, and the resulting syscheck notifications are a mixed bag - some have the report_change included (the *diff*), and others generate an alert but lack the report_change details. I'm scratching my head trying to figure out why it's working on some and not others. Below are some details on a machine where report_change is failing: *OSSEC Agent Version:* ossec-hids-agent-2.9.0-48.el6.art.x86_64 ossec-hids-2.9.0-48.el6.art.x86_64 *inotify-tools Version:* rpm -qa | grep -i inotify inotify-tools-3.14-1.el6.x86_64 *E-mail Notification:* Received From: (removed) 1.2.3.4->syscheck Rule: 102907 fired (level 7) -> "File integrity changed, likely security relevant" Portion of the log(s): Integrity checksum changed for: '/etc/security/limits.conf' Size changed from '1885' to '1927' Old md5sum was: 'a639c5c0ea72bcb59c6a1379f6baa797' New md5sum is : '301d246e310c78c2c76ef69cdefe00d1' Old sha1sum was: '579006cf4e04899e05ff7812dc6a6c17500753fb' New sha1sum is : '714e5ffa5da1b684d0d591b5a822460b8c8ba4c3' *OSSEC Manager syscheck_control Output:* /var/ossec/bin/syscheck_control -i 2337 -f /etc/security/limits.conf Integrity changes for agent 'removed (2337) - 1.2.3.4': Detailed information for entries matching: '/etc/security/limits.conf' 2017 Jan 31 12:55:42,0 - /etc/security/limits.conf File added to the database. Integrity checking values: Size: 1885 Perm: rw-r--r-- Uid: 0 Gid: 0 Md5: a639c5c0ea72bcb59c6a1379f6baa797 Sha1: 579006cf4e04899e05ff7812dc6a6c17500753fb 2017 Feb 09 15:51:49,0 - /etc/security/limits.conf File changed. - 1st time modified. Integrity checking values: Size: >1927 Perm: rw-r--r-- Uid: 0 Gid: 0 Md5: >301d246e310c78c2c76ef69cdefe00d1 Sha1: >714e5ffa5da1b684d0d591b5a822460b8c8ba4c3 *The logs on the Agent do show that real-time monitoring was started prior to this change…* 2017/02/07 20:56:23 ossec-syscheckd: INFO: Initializing real time file monitoring (not started). … 2017/02/07 21:30:07 ossec-syscheckd: INFO: Real time file monitoring started. *Strangely enough, the diff file does exist on the filesystem for this machine:* cat /var/ossec/queue/diff/local/etc/security/limits.conf/diff.1486673498 52a53,54 > * soft stack 10240 > * hard stack unlimited # 1486673498 converts to Thursday February 09, 2017 15:51:38 (pm) *As far as I can tell my agent.conf is correct (and remember I use this agent.conf across hundreds of nodes):* no 79200 /etc … *Permissions of /var/ossec/tmp:* ls -ld /var/ossec/tmp/ dr-xr-x--- 2 root ossec 4096 Feb 9 16:27 /var/ossec/tmp/ Any thoughts on what could be causing this? -- --- 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
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. 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 <dago...@gmail.com > > 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. >
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
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. 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' **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' **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: '' **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 <dago...@gmail.com > > 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:
[ossec-list] ossec server 2.9.0 WinEvt problems
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.
Re: [ossec-list] OSSEC agent limit modification after server install
- Original Message - > Is there a command that can be run to change the max agents per manager? > > The OSSEC server has already been installed so I cannot find a way to run > the following: > > *Can an OSSEC manager have more than 256 agents?* > *By default OSSEC limits the number of agents to 256 per manager. This > limitation is set in the code, but* > *can be modified at compile time. Depending on the event load, a manager > running on modern hardware* > *can handle many more agents. Some users have more than 1000 agents on a > single manager. To change* > *the maximum number of agents, cd into the src directory and run the > following command:* > *make setmaxagents* > > Any help with this much appreciated! After 'make setmaxagents' you can simply run install.sh again to update the binaries. Choose 'y' when you see: You already have OSSEC installed. Do you want to update it? (y/n) -- --- 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
Victor, Thanks. What I was doing was *rm*ing everything in /var/ossec except for queue and logs. Then I was installing the newly-compiled code. When the installer asked if I wanted to update, I answered "yes", which apparently defaults the installation to a local installation (I'm not sure that it even discloses that on the screen). I discovered this after you pointed me towards the fact that it was a local installation, so the last time I installed I actually answered "no" to the update question and then I was able to go through the normal steps and choose "server" as the type. I have the server up and running now. Let's hope my clients become more stable. I'll let you know. Thanks for your continued help! Thanks, Chris On Monday, December 12, 2016 at 3:47:06 PM UTC-5, Victor Fernandez wrote: > > Hi Chris, > > since you compiled the project with "TARGET=server", maybe you chose > "local" when installed it. A local installation is a profile like a server > but without Remoted, that's why that daemon doesn't start with "ossec-control > start". > > The line at ossec-init.conf has only informational purposes, changing it > will be useless. The local profile compiles OSSEC with option " > TARGET=local", copies the script at "src/init/ossec-local.sh" as " > /var/ossec/bin/ossec-control" and applies a local setting template > (without configuration, for example). > > The best option would be to uninstall OSSEC, clean the compilation (make > clean) and re-install it. If you can't uninstall it, these steps may help > you: > >1. Change to the "Wazuh" directory. >2. Clean the project: make -C src clean >3. Compile and install again: make -C src TARGET=server install >4. Create a default remote setting on /var/ossec/etc/ossec.conf: > > > > > ** >*secure* >* * > > > > >5. Restart OSSEC: /var/ossec/bin/ossec-control restart > > This may fix your problem. > > Best regards. > > > > On Monday, December 12, 2016 at 7:11:07 PM UTC+1, Chris Decker wrote: >> >> Victor, >> >> ossec-init.conf is showing the the installation is a *local* >> installation. >> >> However, I know that I performed a server installation per my notes and >> bash history… >> >> make clean >> >> make TARGET=server >> >> >> >> Obviously I could change this value back to 'server', but will this fix >> the issue? >> >> >> >> Thanks, >> Chris >> >> >> On Saturday, December 10, 2016 at 6:04:45 AM UTC-5, Victor Fernandez >> wrote: >>> >>> Hi Chris, >>> >>> as you guessed, there is one *remoted* process for each >>> configuration. Although it's strange that "ossec-control stop" does >>> stop the *remoted *processes but "ossec-control start" doesn't run them. >>> >>> How did you install Wazuh? Please make sure that the file " >>> /var/ossec/etc/ossec-init.conf" has the line: >>> >>> TYPE="server" >>> >>> >>> Regards. >>> >>> >>> On Friday, December 9, 2016 at 5:24:38 PM UTC+1, Chris Decker wrote: >>>> >>>> Dan, >>>> >>>> Thanks for your help. >>>> >>>> Is ossec-remoted listed in the DAEMONS variable in the script? >>>>> >>>> It was *not*, but I added it after noticing it wasn't in there. If I >>>> tell ossec-control to stop, remoted stops as expected: >>>> >>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop >>>> Killing ossec-monitord .. >>>> Killing ossec-logcollector .. >>>> Killing ossec-syscheckd .. >>>> Killing ossec-analysisd .. >>>> Killing ossec-maild .. >>>> Killing ossec-remoted .. >>>> Killing ossec-execd .. >>>> Wazuh v1.2 Stopped >>>> >>>> >>>> However, if I tell ossec-control to start, it starts everything but I >>>> don't see remoted referenced: >>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control start >>>> >>>> Starting Wazuh v1.2 (maintained by Wazuh Inc.)... >>>> Started wazuh-moduled... >>>> Started ossec-maild... >>>> Started ossec-execd... >>>> Started ossec-analysisd... >>>> Started ossec-logcollector... >>>> 2016/12/09 11:22:51 rootcheck: Rootchec
Re: [ossec-list] remoted Dropping Events
Victor, ossec-init.conf is showing the the installation is a *local* installation. However, I know that I performed a server installation per my notes and bash history… make clean make TARGET=server Obviously I could change this value back to 'server', but will this fix the issue? Thanks, Chris On Saturday, December 10, 2016 at 6:04:45 AM UTC-5, Victor Fernandez wrote: > > Hi Chris, > > as you guessed, there is one *remoted* process for each > configuration. Although it's strange that "ossec-control stop" does stop > the *remoted *processes but "ossec-control start" doesn't run them. > > How did you install Wazuh? Please make sure that the file " > /var/ossec/etc/ossec-init.conf" has the line: > > TYPE="server" > > > Regards. > > > On Friday, December 9, 2016 at 5:24:38 PM UTC+1, Chris Decker wrote: >> >> Dan, >> >> Thanks for your help. >> >> Is ossec-remoted listed in the DAEMONS variable in the script? >>> >> It was *not*, but I added it after noticing it wasn't in there. If I >> tell ossec-control to stop, remoted stops as expected: >> >> [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop >> Killing ossec-monitord .. >> Killing ossec-logcollector .. >> Killing ossec-syscheckd .. >> Killing ossec-analysisd .. >> Killing ossec-maild .. >> Killing ossec-remoted .. >> Killing ossec-execd .. >> Wazuh v1.2 Stopped >> >> >> However, if I tell ossec-control to start, it starts everything but I >> don't see remoted referenced: >> [root@logger01 limits.d]# /var/ossec/bin/ossec-control start >> >> Starting Wazuh v1.2 (maintained by Wazuh Inc.)... >> Started wazuh-moduled... >> Started ossec-maild... >> Started ossec-execd... >> Started ossec-analysisd... >> Started ossec-logcollector... >> 2016/12/09 11:22:51 rootcheck: Rootcheck disabled. Exiting. >> 2016/12/09 11:22:51 ossec-syscheckd: WARN: Rootcheck module disabled. >> Started ossec-syscheckd... >> Started ossec-monitord... >> Completed. >> >> >> The only thing I *removed* from that list of modules was the ossec-wuzuh >> module because I do not currently use it. >> >> >>> What is your remote condiguration in your ossec.conf? >> >> >> >> secure >> >> >> >> >> syslog >> tcp >> 514 >> 10.0.0.0/8 >> >> >> syslog >> udp >> 514 >> 10.0.0.0/8 >> >> >> Dave's comment jogged my memory about why remoted is running 3 separate >> processes - 1514/udp, 514/udp and 514/tcp. >> >> >> >> On Friday, December 9, 2016 at 10:33:50 AM UTC-5, dan (ddpbsd) wrote: >>> >>> >>> >>> On Dec 9, 2016 9:17 AM, "Chris Decker" <ch...@chris-decker.com> 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 tha
Re: [ossec-list] remoted Dropping Events
Dan, Thanks for your help. Is ossec-remoted listed in the DAEMONS variable in the script? > It was *not*, but I added it after noticing it wasn't in there. If I tell ossec-control to stop, remoted stops as expected: [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop Killing ossec-monitord .. Killing ossec-logcollector .. Killing ossec-syscheckd .. Killing ossec-analysisd .. Killing ossec-maild .. Killing ossec-remoted .. Killing ossec-execd .. Wazuh v1.2 Stopped However, if I tell ossec-control to start, it starts everything but I don't see remoted referenced: [root@logger01 limits.d]# /var/ossec/bin/ossec-control start Starting Wazuh v1.2 (maintained by Wazuh Inc.)... Started wazuh-moduled... Started ossec-maild... Started ossec-execd... Started ossec-analysisd... Started ossec-logcollector... 2016/12/09 11:22:51 rootcheck: Rootcheck disabled. Exiting. 2016/12/09 11:22:51 ossec-syscheckd: WARN: Rootcheck module disabled. Started ossec-syscheckd... Started ossec-monitord... Completed. The only thing I *removed* from that list of modules was the ossec-wuzuh module because I do not currently use it. > What is your remote condiguration in your ossec.conf? secure syslog tcp 514 10.0.0.0/8 syslog udp 514 10.0.0.0/8 Dave's comment jogged my memory about why remoted is running 3 separate processes - 1514/udp, 514/udp and 514/tcp. On Friday, December 9, 2016 at 10:33:50 AM UTC-5, dan (ddpbsd) wrote: > > > > On Dec 9, 2016 9:17 AM, "Chris Decker" <ch...@chris-decker.com > > 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" <ch...@chris-decker.com> 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
[ossec-list] Re: remoted Dropping Events
Dave, Thanks for your suggestions. If I start remoted manually it doesn't complain that the port is already in use. I am also starting it in debug mode and its starts cleanly AND works when I start it manually. I *do* have remoted configured to accept both tcp and udp logs on port 514, but I've used this just fine in the past; the chrooting must account for the use of privileged ports. If you can think of anything else please shout! Thanks, Chris On Friday, December 9, 2016 at 10:15:41 AM UTC-5, Dave Stoddard wrote: > > If remoted is failing, it is likely you have another program running on > that port that remoted is trying to bind to. For example, syslog is a > common application on UNIX/BSD/Linux systems, and uses port 514. If you > also attempt to use port 514 for remoted, you will get a conflict and > remoted will exit. OSSEC uses 1514 for its default event data, so if you > want to collect syslog data for analysis, port 1515 would be a good logical > choice. > > Another issue exists with remoted when you attempt to bind to port numbers > less than 1024 -- anything less than 1024 is privileged (root only). > Because OSSEC runs as user ossec, you cannot bind to ports lower than 1024 > on most *NIX systems unless the attachment occurs prior to the change to > user ossec. This privileged port restriction is by design (for example, it > prevents a non-root user from running a rogue SSH server to collect userids > and passwords on port 22, or a user from running their own email server on > port 25). Unless you write a lot of UNIX socket code or you have extensive > UNIX admin experience, most people are unaware of the privileged port > restriction issue. It would probably be useful to note this information in > the documentation to alleviate confusion. Best, > > Dave Stoddard > Network Alarm Corporation > https://networkalarmcorp.com > 301-850-0668 x101 > > -- --- 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
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. > > 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? > > 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" <ch...@chris-decker.com> 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.
[ossec-list] remoted Dropping Events
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*. 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. 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.
Re: [ossec-list] Where does agentless data go? No alerts on hash changes.
I've worked round it by not running with use_sudo but by adding a extra send command to the integrity script. send sudo sh this then runs the rest as root. I will be adding a check to confirm the sudo sh worked, but this at least works without having to open root up. cheers On Mon, 11 Jul 2016 at 15:53 Chris Young <chris.young...@gmail.com> wrote: > hi there, > > Jeff - I see that you can get > > '2015/02/23 15:50:18 ossec-agentlessd: INFO: ssh_integrity_check_linux: > admin@agentless-test-rh6: use_sudo specified and 'sudo sh;' worked.' > > out in the log. > > when I try use_sudo I get no reference what so ever. > > have you managed to progress this any further? I really want to be able to > run with out opening root up. > > I've tried 2.9RC2 as well - no joy. > > > > On Tuesday, 24 February 2015 22:22:47 UTC, Jeff Blaine wrote: >> >> I use agents for systems that can run them, so I don't know. Try >>> turning on the logall option to see if the output ends up in >>> archives.log. >>> >> >> Nothing there with yes. Bummer. >> > -- > > --- > 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/sBC4vIpHM3E/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.
Re: [ossec-list] Where does agentless data go? No alerts on hash changes.
hi there, Jeff - I see that you can get '2015/02/23 15:50:18 ossec-agentlessd: INFO: ssh_integrity_check_linux: admin@agentless-test-rh6: use_sudo specified and 'sudo sh;' worked.' out in the log. when I try use_sudo I get no reference what so ever. have you managed to progress this any further? I really want to be able to run with out opening root up. I've tried 2.9RC2 as well - no joy. On Tuesday, 24 February 2015 22:22:47 UTC, Jeff Blaine wrote: > > I use agents for systems that can run them, so I don't know. Try >> turning on the logall option to see if the output ends up in >> archives.log. >> > > Nothing there with yes. Bummer. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: agentless via remote sudo instead root-only ssh?
Hi, did using sudo ever get implemented? we ban sshing as root thanks, Chris On Thursday, 17 September 2015 21:37:18 UTC+1, Ben wrote: > > Hi, > > I am running into the same issue. Did you get this to work? Can you shed > some light? Thanks. > > On Friday, February 20, 2015 at 12:43:24 PM UTC-5, Jeff Blaine wrote: >> >> Is it possible to configure agentless OSSEC to use sudo on the remote >> node? The documentation doesn't show that it is possible, so I assume it is >> not, but thought I'd ask. >> > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] how to keep up to date with rootkit_files and trojans .txt
thanks for taking the time to point out how I can help myself going forwards and the answer. regards, Chris On Wed, 22 Jun 2016 at 16:38 dan (ddp) <ddp...@gmail.com> wrote: > On Wed, Jun 22, 2016 at 11:20 AM, Chris Young <chris.young...@gmail.com> > wrote: > > ok thanks, do you happen to have an idea as to how often this happens? > > > > Not often. > > https://github.com/ossec/ossec-hids/commits/master/src/rootcheck/db/rootkit_files.txt > > https://github.com/ossec/ossec-hids/commits/master/src/rootcheck/db/rootkit_trojans.txt > > > > > > > On Wednesday, 22 June 2016 13:36:57 UTC+1, dan (ddpbsd) wrote: > >> > >> On Wed, Jun 22, 2016 at 8:32 AM, Chris Young <chris.y...@gmail.com> > wrote: > >> > Hi, > >> > > >> > we are just considering implementing OSSEC and one of the requirements > >> > is > >> > for up to date rootkit checking. > >> > > >> > I can't seem to work out where to get the latest, if it is maintained > >> > files > >> > from, ie rootkit_files.txt and rootkit_trojans.txt > >> > > >> > One of the starting points to look at OSSEC was to have a centralised > >> > version of rkhunter, which every time it runs looks for updates. > >> > > >> > any guidance please? > >> > > >> > >> If someone updates the files and submits their changes, you can find > >> them in the github repository: https://github.com/ossec/ossec-hids > >> > >> > many 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 a topic in the > Google Groups "ossec-list" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ossec-list/u1KzVuVOsIw/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.
Re: [ossec-list] how to keep up to date with rootkit_files and trojans .txt
ok thanks, do you happen to have an idea as to how often this happens? On Wednesday, 22 June 2016 13:36:57 UTC+1, dan (ddpbsd) wrote: > > On Wed, Jun 22, 2016 at 8:32 AM, Chris Young <chris.y...@gmail.com > > wrote: > > Hi, > > > > we are just considering implementing OSSEC and one of the requirements > is > > for up to date rootkit checking. > > > > I can't seem to work out where to get the latest, if it is maintained > files > > from, ie rootkit_files.txt and rootkit_trojans.txt > > > > One of the starting points to look at OSSEC was to have a centralised > > version of rkhunter, which every time it runs looks for updates. > > > > any guidance please? > > > > If someone updates the files and submits their changes, you can find > them in the github repository: https://github.com/ossec/ossec-hids > > > many 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.
[ossec-list] how to keep up to date with rootkit_files and trojans .txt
Hi, we are just considering implementing OSSEC and one of the requirements is for up to date rootkit checking. I can't seem to work out where to get the latest, if it is maintained files from, ie rootkit_files.txt and rootkit_trojans.txt One of the starting points to look at OSSEC was to have a centralised version of rkhunter, which every time it runs looks for updates. any guidance please? many 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.
Re: [ossec-list] How/where does one get a version of the OSSEC agent-auth application that will run on Windows?
Thanks for letting me know. I'll keep an eye on the project to see if future releases add support for the agent-auth application for Windows. The use case is a hybrid environment hosted by Amazon Web Services (AWS) where auto-scaling groups cause instances (servers) to come and go. Automation technology, such as AWS CloudFormation, allow fully automated configuration of the entire server without any manual interaction. The Linux version of agent-auth allows this to work well for Linux agents. Not having the Windows version prevents OSSEC from being viable in a large-scale cloud environment where automation is required. Use of third-party tools such as Chef, Puppet, Ansible, etc. can overcome this limitation, but add additional considerations. Thanks, Chris On Tuesday, December 22, 2015 at 7:04:55 AM UTC-6, dan (ddpbsd) wrote: > > On Mon, Dec 21, 2015 at 4:34 PM, Chris <cbro...@3dsi.com > > wrote: > > I have successfully configured an OSSEC server running on Ubuntu in AWS. > > > > > > I have also successfully automated Ubuntu AWS instances automatically > > installing the OSSEC agent and connecting to the OSSEC server via this > > command /var/ossec/bin/agent-auth -m ossec.myprivatedomain.local -p 1515 > > > > > > I am working on automating the installation of the OSSEC agent for > Windows > > instances including automating the Windows instances connecting to the > OSSEC > > server. I understand that the OSSEC agent for Windows can be downloaded > from > > the OSSEC site's "Downloads" page and that it can be silently installed > > using this command line: ossec-agent-win32-2.8.3.exe /S > > > > > > Despite much research, I cannot find out how to get a version of the > OSSEC > > agent-auth executable that will run on Windows to allow me to automate > the > > Windows instances connecting to the OSSEC server. > > > > > > The closest thing I can find to any mention of the agent-auth > application > > being available for Windows is from this blog: > > https://github.com/ossec/ossec-hids/issues/166#issuecomment-41461642 > ... > > where a comment states ... > > > > The Windows version of agent-auth was compiled on Linux (Fedora 20) and > > tested on Windows 7 Home Premium 64-bit. > > > > None of the tutorials that talk about compiling the OSSEC agent for > Windows > > on Linux address how to compile the agent-auth application for Windows. > > > > > > How/where does one get a version of the OSSEC agent-auth application > that > > will run on Windows? > > > > I have a currently untested branch for this at > https://github.com/ddpbsd/ossec-hids/tree/winauthd > > It's using the current development master as its base. I haven't had > the time or motivation to actually test it yet. > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "ossec-list" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to ossec-list+...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] How/where does one get a version of the OSSEC agent-auth application that will run on Windows?
I have successfully configured an OSSEC server running on Ubuntu in AWS. I have also successfully automated Ubuntu AWS instances automatically installing the OSSEC agent and connecting to the OSSEC server via this command /var/ossec/bin/agent-auth -m ossec.myprivatedomain.local -p 1515 I am working on automating the installation of the OSSEC agent for Windows instances including automating the Windows instances connecting to the OSSEC server. I understand that the OSSEC agent for Windows can be downloaded from the OSSEC site's "Downloads" page and that it can be silently installed using this command line: ossec-agent-win32-2.8.3.exe /S Despite much research, I cannot find out how to get a version of the OSSEC agent-auth executable that will run on Windows to allow me to automate the Windows instances connecting to the OSSEC server. The closest thing I can find to any mention of the agent-auth application being available for Windows is from this blog: https://github.com/ossec/ossec-hids/issues/166#issuecomment-41461642 ... where a comment states ... The Windows version of agent-auth was compiled on Linux (Fedora 20) and tested on Windows 7 Home Premium 64-bit. None of the tutorials that talk about compiling the OSSEC agent for Windows on Linux address how to compile the agent-auth application for Windows. How/where does one get a version of the OSSEC agent-auth application that will run on Windows? -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Outlook Web Access (2003) logs
Hi. I'm trying, unsuccessfully, to create a decoder for Outlook Web Access (OWA) 2003 access logs. These are a slightly different format to regular IIS access logs, so aren't getting matched: 2015-12-09 14:03:44 W3SVC1 10.10.10.10 GET /index.php - 80 - 79.141.160.57 Mozilla/5.0+[en]+(X11,+U;+OpenVAS+7.0.5) 403 4 5 I've added a local decoder as below, but it's not getting matched: windows-date-format web-log true ^W3SVC\d+ \S+ (\S+) (\S+ \S+) \d+ \S+ (\d+.\d+.\d+.\d+) \S+ (\d+) action, url, srcip, id Any ideas? I've based this on the tweaks for IIS7 logs, which seem to work. Testing my regex elsewhere, e.g. regex101.com, it seems to work and I don't get any errors. Testing in ossec-logtest, I get the following: **Phase 1: Completed pre-decoding. full event: '2015-12-09 14:03:44 W3SVC1 10.10.10.10 GET /index.php - 80 - 79.141.160.57 Mozilla/5.0+[en]+(X11,+U;+OpenVAS+7.0.5) 403 4 5' hostname: 'ossec' program_name: '(null)' log: '2015-12-09 14:03:44 W3SVC1 10.10.10.10 GET /index.php - 80 - 79.141.160.57 Mozilla/5.0+[en]+(X11,+U;+OpenVAS+7.0.5) 403 4 5' **Phase 2: Completed decoding. decoder: 'windows-date-format' **Phase 3: Completed filtering (rules). Rule id: '31100' Level: '0' Description: 'Access log messages grouped.' I'm trying to detect scans via multiple 400 errors, but they're not getting picked up because the decoder is failing. 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.
[ossec-list] Windows Server 2012 and automated ossec install
Does anyone know if ossec will allow for an unattended install under Windows Server 2012. It seems like I saw some issues in the past and was wondering if there was a newer version that supported it? 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.
[ossec-list] Overwriting Trend AV Rule
HI. We use Trend Micro AV, but the current rules don't match properly. I'm not sure what they're looking at, but our version of Trend writes alerts to the Windows Event Log. Here's a sample. 2015 Apr 29 17:57:52 WinEvtLog: Application: WARNING(500): Trend Micro OfficeScan Server: SYSTEM: NT AUTHORITY: AV01.domain.co.uk: Virus/Malware: Eicar_test_1 Computer: LAPTOP1 Domain: domain.co.uk File: C:\Users\username\AppData\Roaming\Notepad++\backup\new 3@2015-04-29_174606 Date/Time: 29/04/2015 17:57:48 Result: Virus successfully detected, cannot perform the Clean action (Quarantine) I'm trying to overwrite the current rules 7610 and 7611, relating to virus detection, using the Windows decoder: trend-osce_rules.xml: group name=trend_micro,ocse rule id=7610 level=5 if_sid7600/if_sid id^0|$|^1$|^2$|^33|^10$|^11$|^12$/id groupvirus/group descriptionVirus detected and cleaned/quarantined/remved/description /rule /group local_rules.xml: group name=trend_micro,ocse, rule id=7610 level=5 overwrite=yes if_sid18102/if_sid id^500/id groupvirus/group descriptionVirus detected and cleaned/quarantined/removed/description /rule /group However, when I run ossec-logtest it's picking up as 18102, not 7610. If I remove the overwrite and change the rule ID to something unique, like 97610, the rule fires. How can I overwrite the existing Trend rule, but keep the same ID's so that other monitoring systems (specifically OSSIM) work. 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.
[ossec-list] RIDS Issues
All, I have a few Windows hosts that will periodically 'Disconnect' from the OSSEC server. In some cases they randomly will reconnect later on, while in others we have to go through and clear out the RIDS before the agent will re-connect successfully. What's the best way to troubleshoot this issue? From everything I've read, I should enable debug on the agent and manager, but I've added -d to all of the processes, and also bumped the levels in internal_options.conf to 2's, and I still don't get any useful debug in ossec.log. I stopped one of my Linux agents and purposely wiped out the rids files. When I started up in debug mode I didn't get any helpful errors on either end of the interface (I expected to see log messages related to RIDS from error_messages.h). What am I missing? 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.
Re: [ossec-list] Re: Official Support for server 2012
I feel like im kicking a dead horse here by asking again. The company I work for would like to move to server 2012 but they refuse to until ossec support officially lists 2012. Any chance of an eta on this? On Tuesday, January 13, 2015 at 9:22:22 AM UTC-6, dan (ddpbsd) wrote: On Tue, Jan 13, 2015 at 10:11 AM, SoulAuctioneer awidde...@hotmail.com javascript: wrote: It can probably be added. There are a few issues with the proper reporting of 2012 and 2012R2 but they are pretty minimal. Everything else should work though. I've created a pull request to update the documentation on the site: https://github.com/ossec/ossec-docs/pull/74 -- --- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Windows Agent Not Shipping Log File
All, I wanted to add that we had this issue occur again yesterday, and the SysAdmin was able to confirm that OSSEC is *not* reading the file when this 'outage' occurs. When OSSEC does begin reading the file again, it doesn't resume where it left off, so we lose a few hours worth of data from this particular server/log. Anyone have any suggestions or experience with a similar issue? Thanks, Chris On Tue, Feb 17, 2015 at 8:44 PM, Chris Decker ch...@chris-decker.com wrote: All, Many of my Windows machines write logs to c:\Logs\%COMPUTERNAME%.txt, and I have OSSEC monitoring that directory, e.g. localfile location%SYSTEMDRIVE%\Logs\%COMPUTERNAME%.txt/location log_formatsyslog/log_format /localfile We've noticed a few times now that on our busiest machine [1] OSSEC will occasionally stop sending the logs from that file; all other logs generated on the system are sent to the Manager. I haven't noticed any patterns, and the ossec.log on the agent doesn't provide any helpful information. FWIW, I asked the IT support person to verify OSSEC was reading the log file (using Microsoft/SysInternals's Process Explorer application), but he misunderstood my request and verified the log generating process had the file open, so at this time I'm unable to confirm/deny that OSSEC actually had the file open. Has anyone ever seen this before, and if so, is there anything that can be done to prevent this problem from re-occuring? Thanks, Chris [1] Microsoft Windows Server 2008 R2 -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Windows Agent Not Shipping Log File
All, Many of my Windows machines write logs to c:\Logs\%COMPUTERNAME%.txt, and I have OSSEC monitoring that directory, e.g. localfile location%SYSTEMDRIVE%\Logs\%COMPUTERNAME%.txt/location log_formatsyslog/log_format /localfile We've noticed a few times now that on our busiest machine [1] OSSEC will occasionally stop sending the logs from that file; all other logs generated on the system are sent to the Manager. I haven't noticed any patterns, and the ossec.log on the agent doesn't provide any helpful information. FWIW, I asked the IT support person to verify OSSEC was reading the log file (using Microsoft/SysInternals's Process Explorer application), but he misunderstood my request and verified the log generating process had the file open, so at this time I'm unable to confirm/deny that OSSEC actually had the file open. Has anyone ever seen this before, and if so, is there anything that can be done to prevent this problem from re-occuring? Thanks, Chris [1] Microsoft Windows Server 2008 R2 -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Windows Event Channels of Interest
All, I'm a long-time OSSEC user, but I rarely use OSSEC with Windows machines. Recently I had the opportunity to monitor a significant number of Windows machines, and I've been learning where security-relevant logs are stored on the system. In addition to the standard Application/Security/System logs I'm monitoring the following Event Channels, but wanted to see if others had suggestions on additions: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational Microsoft-TaskScheduler/Operational Does anyone have any recommendations that I should add to my configuration? Of course the function of the machine will drive which channels are valuable. I'm currently considering the following: - WinRM - WinNAT - Exchange - SMBServer - PrintService - NTLM - IIS_Logging What do you use in your configuration? 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.
Re: [ossec-list] Logging access to ossec log files
Thank you for the reply. I know all of this. This is not a PCI audit, but it could impact the business too much to fight. I used auditd to watch the folders. Excluding the OSSEC group and auid=-1. Also added a few more monitoring settings to auditd, like watching sudo and su usage. OSSEC looks at the auditd log as if it is a syslog. It reports each line (complete line in alert) as a separate event, but that is good enough. Thanks all for the help! On Monday, January 12, 2015 at 6:24:54 PM UTC-6, David Lang wrote: On Mon, 12 Jan 2015, Christopher Dangerfield wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? I've dealt with clueless auditors making requirements like this before (what I call checkbox secureity because they don't understand what's going on, they are just tryingto check off all the boxes in their checklist) What I've done is a combination of a few things. 1st, the logs in question are on a dedicated box that doesn't get accessed much. As such, the logs could only be tampered with during the time that someone is logged in to the box. 2nd, document the different risks from reading the logs vs changing them. In the vast majority of cases you don't care about reading the logs, only changes to them. 3rd, accept that you aren't going to be able to log every write to the log, due to the recursion that you are running into (yes, you could log elsewhere, but then how is that log protected?). Instead you accept that there is a small window that the logs could be tampered with and have a periodic job generate a checksum of the log to that point (what you record needs to have both the checksum and the number of lines that checksum covers). Then you need to get this checksum off the machine to somewhere more protected (a write-once medium like a printer with continuous feed paper that can print one line at a time is perfect for this) Other things you can do is to get the logs out of ossec to something like rsyslog that includes a couple different mechanisms that you can use for a critical log: a chain of hashes that tie all the lines of the logs together so that it's not possible to tamper with the log without re-writng the entire log file support for using a thrid party service to record and sign checksums that prove that the log wasn't tampered with If you do actually have to show that you have a log of any access to the file, then you have a couple choices 1. consider that anytime someone was logged into the box with the appropriate privileges to read the file that it was read at that time. 2. audit all reads of the file but not writes (so that writes don't trigger recursive writes. And the most important thing to remember is that the Auditor is not able to lay down rules about what you must to on their own. They are supposed to be working to make sure that you are implementing the stated policy. The vast majority of the time, the policy they are checking that you are following is a policy written by your organization, so make sure that your policies don't say that you do the impossible. Evn in cases like PCI audits this applies. PCI says that you must do some things, but it doesn't say how in any technical details, instead they are saying what your company policies must cover. It's then up to your company policies to say how you are achieving the goal set by the PCI policies. The PCI auditors then do checks in two stages, they first check that your policies comply with the PCI policies, then they check that you are following your policies. A log of auditors like to forget this and think they know a lot more than they actually do, so when you run into an unreasonable auditor like you have here (and after you have made sure that your policies don't say that you do the impossible), your management should go to the auditors company and say that they are being unreasonable. David Lang -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Official Support for server 2012
Is there any timeframe for official support of Server 2012? -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com javascript: wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Official Support for server 2012
Nothing, really. We are getting ready to move away from 2008 to 2012 and it isn't listed on http://www.ossec.net/?page_id=36 I know the agent currently works on 2012, its just not on the officially supported list. On Monday, January 12, 2015 at 9:55:30 AM UTC-6, Chris Bertsch wrote: Is there any timeframe for official support of Server 2012? -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
-w /var/ossec/logs/ -F euid!=XXX -p wa -k auditlog So something like that ^^^? On Monday, January 12, 2015 at 1:13:04 PM UTC-6, Chris Decker wrote: You'd want to add a filter to the end of the rule. For example: -F euid!=505 (or whatever the appropriate UID is for your OSSEC account) On Mon, Jan 12, 2015 at 1:48 PM, ch...@rhris.com javascript: wrote: I am looking into auditd and that seems to be the route I want to go. What would the rule be for the folder /var/ossec/logs/ that excludes the OSSEC user? On Monday, January 12, 2015 at 12:43:55 PM UTC-6, Chris Decker wrote: Yes - I currently monitor a few log files for 'writes' using auditd and I have OSSEC configured to generate alerts. Be aware, though, that the auditd logs are multiline logs with a variable number of lines, thus OSSEC cannot stitch 'events' together using the common ID (though from the placeholders in the OSSEC documentation it looks like this feature may be coming in OSSEC 2.9) and give you information like the user ID that wrote to the file. On Mon, Jan 12, 2015 at 12:00 PM, ch...@rhris.com wrote: Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
Also there are three ossec users 'ossec', 'ossecm', and 'ossecr'. Which one is the writing done under? On Monday, January 12, 2015 at 1:13:04 PM UTC-6, Chris Decker wrote: You'd want to add a filter to the end of the rule. For example: -F euid!=505 (or whatever the appropriate UID is for your OSSEC account) On Mon, Jan 12, 2015 at 1:48 PM, ch...@rhris.com javascript: wrote: I am looking into auditd and that seems to be the route I want to go. What would the rule be for the folder /var/ossec/logs/ that excludes the OSSEC user? On Monday, January 12, 2015 at 12:43:55 PM UTC-6, Chris Decker wrote: Yes - I currently monitor a few log files for 'writes' using auditd and I have OSSEC configured to generate alerts. Be aware, though, that the auditd logs are multiline logs with a variable number of lines, thus OSSEC cannot stitch 'events' together using the common ID (though from the placeholders in the OSSEC documentation it looks like this feature may be coming in OSSEC 2.9) and give you information like the user ID that wrote to the file. On Mon, Jan 12, 2015 at 12:00 PM, ch...@rhris.com wrote: Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
You'd want to add a filter to the end of the rule. For example: -F euid!=505 (or whatever the appropriate UID is for your OSSEC account) On Mon, Jan 12, 2015 at 1:48 PM, ch...@rhris.com wrote: I am looking into auditd and that seems to be the route I want to go. What would the rule be for the folder /var/ossec/logs/ that excludes the OSSEC user? On Monday, January 12, 2015 at 12:43:55 PM UTC-6, Chris Decker wrote: Yes - I currently monitor a few log files for 'writes' using auditd and I have OSSEC configured to generate alerts. Be aware, though, that the auditd logs are multiline logs with a variable number of lines, thus OSSEC cannot stitch 'events' together using the common ID (though from the placeholders in the OSSEC documentation it looks like this feature may be coming in OSSEC 2.9) and give you information like the user ID that wrote to the file. On Mon, Jan 12, 2015 at 12:00 PM, ch...@rhris.com wrote: Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@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] Logging access to ossec log files
Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com javascript: wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com javascript: wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
The OS that OSSEC is running on is Gentoo Linux On Monday, January 12, 2015 at 10:27:52 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com javascript: wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] Logging access to ossec log files
Yes - I currently monitor a few log files for 'writes' using auditd and I have OSSEC configured to generate alerts. Be aware, though, that the auditd logs are multiline logs with a variable number of lines, thus OSSEC cannot stitch 'events' together using the common ID (though from the placeholders in the OSSEC documentation it looks like this feature may be coming in OSSEC 2.9) and give you information like the user ID that wrote to the file. On Mon, Jan 12, 2015 at 12:00 PM, ch...@rhris.com wrote: Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google 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] Logging access to ossec log files
I am looking into auditd and that seems to be the route I want to go. What would the rule be for the folder /var/ossec/logs/ that excludes the OSSEC user? On Monday, January 12, 2015 at 12:43:55 PM UTC-6, Chris Decker wrote: Yes - I currently monitor a few log files for 'writes' using auditd and I have OSSEC configured to generate alerts. Be aware, though, that the auditd logs are multiline logs with a variable number of lines, thus OSSEC cannot stitch 'events' together using the common ID (though from the placeholders in the OSSEC documentation it looks like this feature may be coming in OSSEC 2.9) and give you information like the user ID that wrote to the file. On Mon, Jan 12, 2015 at 12:00 PM, ch...@rhris.com javascript: wrote: Would auditd also send its logs to the OSSEC alert system? On Monday, January 12, 2015 at 10:52:25 AM UTC-6, Chris Decker wrote: You could configure *auditd* to monitor for reads/writes to /var/ossec/logs and included a filter to exclude the OSSEC UID. On Mon, Jan 12, 2015 at 11:27 AM, dan (ddp) ddp...@gmail.com wrote: On Mon, Jan 12, 2015 at 11:23 AM, ch...@rhris.com wrote: All other log files aggregate into OSSEC. The auditor wants these logs on the OSSEC server to be logged as well. I just cannot find anyone else that could do this. So no other logs have this requirement? That's kinda silly. Have you tried contacting your mystery OS's vendor? Perhaps they know of a solution. On Monday, January 12, 2015 at 10:22:05 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 11:17 AM, ch...@rhris.com wrote: Sadly no they did not. They just want notices if the files change. But to log access to said files causes a infinite loop of alerts. How is this handled for other log files? On Monday, January 12, 2015 at 9:55:48 AM UTC-6, dan (ddpbsd) wrote: On Mon, Jan 12, 2015 at 10:36 AM, Christopher Dangerfield ch...@rhris.com wrote: After going through a security audit with my current employer something came up that I cannot figure out how to solve. No one online seems to have ran into this. The auditor wants us to log and alert access to the /var/ossec/logs folder. I can do this, but every alert creates a log change thus creates another alert and log change, etc, etc, etc. Has anyone ever had to do this and cold help me? Did the auditors have any suggestions? -- 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+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. 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 forwarding doesn't work with custom_alert_output
It's the default OSSEC install in OSSIM, rather than one I installed myself. It's 2.8 though. Thanks On Monday, January 5, 2015 3:17:09 PM UTC, dan (ddpbsd) wrote: On Mon, Jan 5, 2015 at 10:14 AM, Chris H chris@gmail.com javascript: wrote: Hi. The OSSEC deployment within OSSIM uses custom_alert_output, rather than the default log format. I'm was trying to get these alerts sent to another server, and enabled syslog_output, as I have done on other OSSEC deployments. On the OSSIM deployment, the logs do not get forwarded. I removed the custom_alert_output setting in ossec.conf and the logs get forwarded as expected. Is this a known issue? If not, I can raise a bug on github. Which version of OSSEC did you install? 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Syslog forwarding doesn't work with custom_alert_output
Hi. The OSSEC deployment within OSSIM uses custom_alert_output, rather than the default log format. I'm was trying to get these alerts sent to another server, and enabled syslog_output, as I have done on other OSSEC deployments. On the OSSIM deployment, the logs do not get forwarded. I removed the custom_alert_output setting in ossec.conf and the logs get forwarded as expected. Is this a known issue? If not, I can raise a bug on github. 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.
[ossec-list] ossec-remoted Process Pegged at 100%
Good morning all, I have about 2,000 (heavily active) OSSEC agents sending logs to a Manager. On the Manager side I've noticed that *ossec-remoted* is hovering around 98% to 100% of a CPU. I was under the impression that *ossec-remoted* is multi-threaded, but I only ever see one process running (and no childs). Am I doing something incorrectly? I was speaking with some folks on IRC and they said that not only is the process multi-threaded, but that a modern server could easily handle 70,000 EPS. Right now I have a machine with 16 Intel Xeon cores running at 3.3 GHz, and I estimate I'm seeing about 30,000 EPS. Any performance/tuning tips are appreciated!!! 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.
[ossec-list] exceptions and continuing to scan
Hi, dipping my toe into creating my own rules for the first time. I’ve got a web portal from a third party on one of my hosts that triggers rile 31106 via 31104 and I want to create an exception for this as I deem it to be safe – but I want to ensure I don’t create a big security hole. The alert in question gets generated because the url logged contains http://myurl.com/myhtml.php?home=..\..\someothertext I created a rule in local_rules.xml rule id=100050 level=0 if_sid31106/if_sid match?home=../..//match descriptionIgnore home./description /rule When I test this it works great – but I’m concerned when I hit this, processing stops – I tested this by editing the log to read: http://myurl.com/myhtml.php?home=..\..\someother..\..\text when I use ossec-logtest it shows the rule as my exception rule still, doesn’t flag the new issue I created. However if I make my url in the log read http://myurl.com/myhtml.php?test=..\..\home=..\..\someothertext it goes back to giving me a 31106 alert and all the protection that goes with it. So my question is, can I get OSSEC to be ok with certain whitelisted elements, but still check the rest of the url? Thanks Chris This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Vodat International is a limited company registered in England and Wales. Registered number: 04380546. Registered office:Unit A9 Pearmill Estate,Stockport Road West,Bredbury,Stockport,SK6 2BP -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] RE: exceptions and continuing to scan
Sorry, I just noticed an error in my example, the url would actually be something like this in each case.. http://myurl.com/dir1/dir2/dir3/myhtml.php?home=..\..\someothertexthttp://myurl.com/myhtml.php?home=..\..\someothertext From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Billson Sent: 27 November 2014 14:50 To: ossec-list@googlegroups.com Subject: [ossec-list] exceptions and continuing to scan Hi, dipping my toe into creating my own rules for the first time. I’ve got a web portal from a third party on one of my hosts that triggers rile 31106 via 31104 and I want to create an exception for this as I deem it to be safe – but I want to ensure I don’t create a big security hole. The alert in question gets generated because the url logged contains http://myurl.com/myhtml.php?home=..\..\someothertext I created a rule in local_rules.xml rule id=100050 level=0 if_sid31106/if_sid match?home=../..//match descriptionIgnore home./description /rule When I test this it works great – but I’m concerned when I hit this, processing stops – I tested this by editing the log to read: http://myurl.com/myhtml.php?home=..\..\someother..\..\text when I use ossec-logtest it shows the rule as my exception rule still, doesn’t flag the new issue I created. However if I make my url in the log read http://myurl.com/myhtml.php?test=..\..\home=..\..\someothertext it goes back to giving me a 31106 alert and all the protection that goes with it. So my question is, can I get OSSEC to be ok with certain whitelisted elements, but still check the rest of the url? Thanks Chris This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Vodat International is a limited company registered in England and Wales. Registered number: 04380546. Registered office:Unit A9 Pearmill Estate,Stockport Road West,Bredbury,Stockport,SK6 2BP -- --- 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.commailto:ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Vodat International is a limited company registered in England and Wales. Registered number: 04380546. Registered office:Unit A9 Pearmill Estate,Stockport Road West,Bredbury,Stockport,SK6 2BP -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] RE: manage_agent fails again
Hi Colin,
What we’ve done is script it all. We have around 600 OSSEC agents in nearly as
many remote locations. We grep the individual agent keys out of client.keys on
the server. This is then copied to a location visible to the agent machines and
renamed to reflect the name of the individual agent machines. We then have a
script which copies over the OSSEC Windows agent installer, runs it in silent
mode then copies the ossec.conf and the key file over. The script knows which
key file to pick up by referring to the agent machine name and our ossec.conf
is fortunately identical on each of the agent machines. The key file is then
renamed back to client.keys on the agent machine. The script finally does a
stop / start of the ossecsvc service.
Something like the following is used to extract the individual key files (we’re
running OSSEC under Ubuntu server) :-
sudo grep {agent_name} /var/ossec/etc/client.keys ~/keys/agent_name.keys
The above could be scripted I’m sure, but we’ve had all this up and running for
nearly 5 years now so we only have to take care of a few new key files at a
time as new agent machines are rolled out.
Hope that might help a bit?
Chris
--
Chris Tweed
From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
Behalf Of Colin Bruce
Sent: 25 November 2014 17:17
To: ossec-list@googlegroups.com
Subject: [ossec-list] manage_agent fails again
Is there any way on Windows to install the agent’s key without using the GUI
and cutting and pasting the key into it.
Manage_agents –I should do the import but it doesn’t work. It doesn’t read
from the command line, it doesn’t read the shell variable and it doesn’t prompt
for a key. Cutting and pasting is no use when there are hundreds of servers to
install.
Best wishes…
Colin
--
---
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.commailto:ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Please consider the environment before printing this email
CONFIDENTIALITY NOTICE
This E-Mail contains information which is confidential and privileged. If you
have received this E-Mail in error, please telephone us immediately on +44 116
2223000. Where opinions are expressed they are not necessarily those of Shoe
Zone Retail Ltd.
Shoe Zone Retail Ltd
Registered Office : Haramead Business Centre, Humberstone Road, Leicester LE1
2LH
Registered in England Number 148038
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ossec-list] RE: manage_agent fails again
Hi again Colin,
Sounds like I didn’t really get you any further forwards than you’d already
managed for yourself. I’ve never tried playing with the client side
“manage_agents” to be honest. I’ll have to give it a whirl and see how it goes.
But I suppose even if I can get it working then it’s just going to replace a
scripted file copy with a scripted “manage_agents –i” – swings and roundabouts
maybe – but at least it’s another option, another tool in the kit.
It’s always interesting to see how people get OSSEC to work for them in such a
wide range of environments, finding imaginative ways around obstacles.
I’ll let you know how I get on with that “manage_agents –i” when I get a chance
to try ☺
Chris
--
Chris Tweed
From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
Behalf Of Colin Bruce
Sent: 26 November 2014 14:08
To: ossec-list@googlegroups.com
Subject: [ossec-list] RE: manage_agent fails again
Dear Chris,
Thanks for the suggestions.
I have done something similar but had major problems importing the key. I think
the problem with manage_agents is that the –I option should be followed by the
key and not an ID as shown in the help text. However, that is just a guess as I
needed to get something working last night. I did what you suggested and just
grep’d for the servers address in the key files and copied that over to the
client. At the moment my problem is getting windows servers going so I’ve
created a batch file that installs and configures ossec on a windows server. I
can’t use powershell as some of the servers are pretty elderly and are running
Windows 2003R2. They can’t be upgraded or replaced because the application that
is running on them won’t run (in fact it won’t even install) on anything newer☹
Anyway, thanks again for your help.
Best wishes….
Colin
From: ossec-list@googlegroups.commailto:ossec-list@googlegroups.com
[mailto:ossec-list@googlegroups.com] On Behalf Of Chris Tweed
Sent: 26 November 2014 09:29
To: 'ossec-list@googlegroups.com'
Subject: [ossec-list] RE: manage_agent fails again
Hi Colin,
What we’ve done is script it all. We have around 600 OSSEC agents in nearly as
many remote locations. We grep the individual agent keys out of client.keys on
the server. This is then copied to a location visible to the agent machines and
renamed to reflect the name of the individual agent machines. We then have a
script which copies over the OSSEC Windows agent installer, runs it in silent
mode then copies the ossec.conf and the key file over. The script knows which
key file to pick up by referring to the agent machine name and our ossec.conf
is fortunately identical on each of the agent machines. The key file is then
renamed back to client.keys on the agent machine. The script finally does a
stop / start of the ossecsvc service.
Something like the following is used to extract the individual key files (we’re
running OSSEC under Ubuntu server) :-
sudo grep {agent_name} /var/ossec/etc/client.keys ~/keys/agent_name.keys
The above could be scripted I’m sure, but we’ve had all this up and running for
nearly 5 years now so we only have to take care of a few new key files at a
time as new agent machines are rolled out.
Hope that might help a bit?
Chris
--
Chris Tweed
From: ossec-list@googlegroups.commailto:ossec-list@googlegroups.com
[mailto:ossec-list@googlegroups.com] On Behalf Of Colin Bruce
Sent: 25 November 2014 17:17
To: ossec-list@googlegroups.commailto:ossec-list@googlegroups.com
Subject: [ossec-list] manage_agent fails again
Is there any way on Windows to install the agent’s key without using the GUI
and cutting and pasting the key into it.
Manage_agents –I should do the import but it doesn’t work. It doesn’t read
from the command line, it doesn’t read the shell variable and it doesn’t prompt
for a key. Cutting and pasting is no use when there are hundreds of servers to
install.
Best wishes…
Colin
--
---
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.commailto:ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Image removed by sender. BBC Children in
Need]http://www.shoezone.com/Offers/BBC-Children-in-Need
P Please consider the environment before printing this email
CONFIDENTIALITY NOTICE
This E-Mail contains information which is confidential and privileged. If you
have received this E-Mail in error, please telephone us immediately on +44 116
2223000. Where opinions are expressed they are not necessarily those of Shoe
Zone Retail Ltd.
Shoe Zone Retail Ltd
Registered Office : Haramead Business Centre, Humberstone Road, Leicester LE1
2LH Registered in England Number 148038
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from
[ossec-list] how to forward agent.conf through a hybrid-server
When i create the agent.conf in the /var/ossec/etc/shared of the main ossec server the agent.conf forwards after a while to the /var/ossec/ossec-agent/etc/shared folder. the thing i want to succeed is to forward the same agent.conf through the hybrid - server to the agents that are beneath him. Thnx in advance -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ossec-list] OSSEC with OSSIM
This is exactly what I'm trying to get working with my issue where the hybrid agent stops parsing the alerts log file :( On Wednesday, November 12, 2014 2:09:36 PM UTC, dan (ddpbsd) wrote: On Wed, Nov 12, 2014 at 5:47 AM, Teddy Jayasaputra teddy.ja...@gmail.com javascript: wrote: Dear all, Any of you have working with ossec server talking to ossec in OSSIM? I send alert level ossec via syslog to rsyslog ossim but not working because OSSIM use custom log with tag AV in front of each log so alert from ossec server not recognize by OSSIM. I heard about ossec in hybrid mode. Can someone describe it? Or point me the manual to do it? Can hybrid mode solve deployment ossec to ossec in OSSIM ? Hybrid mode allows an OSSEC manager to report alerts to another OSSEC manager. Thanks. Best Regards, -Teddy- -- --- 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 javascript:. 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] Hybrid issues - stops forwarding logs
Hi. It means nothing to me, but here's a section from strace -f as it
fails again.
20128 stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fff0a998c90) =
-1 ENOENT (No such file or directory)
20128 sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 666, 0, NULL, 0) =
666
20128 read(6, , 4096) = 0
20128 read(7, , 4096) = 0
20128 read(8, , 4096) = 0
20128 read(9, 0x7f328630, 4096) = -1 EISDIR (Is a directory)
20128 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
20128 stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fff0a998c90) =
-1 ENOENT (No such file or directory)
20128 sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 378, 0, NULL, 0) =
378
20128 read(6, , 4096) = 0
20128 read(7, , 4096) = 0
20128 read(8, , 4096) = 0
20128 read(9, 0x7f328630, 4096) = -1 EISDIR (Is a directory)
20128 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
20128 read(5, 104-WinEvtLog\nRule: 18149 (leve..., 4096) = 4096
20128 stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fff0a998c90) =
-1 ENOENT (No such file or directory)
20128 sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 381, 0, NULL, 0) =
381
20128 read(6, , 4096) = 0
20128 read(7, , 4096) = 0
20128 read(8, , 4096) = 0
20128 read(9, 0x7f328630, 4096) = -1 EISDIR (Is a directory)
20128 stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fff0a999720) =
-1 ENOENT (No such file or directory)
20128 sendto(4, 1:ossec-keepalive:--MARK--: c$L/..., 111, 0, NULL, 0) =
111
20128 stat(/logs/ossec/logs/alerts/alerts.log, {st_mode=S_IFREG|0640,
st_size=1216888277, ...}) = 0
20128 stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
20128 open(/logs/ossec/ossec-agent/logs/ossec.log,
O_WRONLY|O_CREAT|O_APPEND, 0666) = 10
20128 fstat(10, {st_mode=S_IFREG|0770, st_size=41256, ...}) = 0
20128 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f32862ff000
20128 fstat(10, {st_mode=S_IFREG|0770, st_size=41256, ...}) = 0
20128 lseek(10, 41256, SEEK_SET)= 41256
20128 write(10, 2014/11/13 15:13:11 ossec-logcol..., 123) = 123
20128 close(10) = 0
20128 munmap(0x7f32862ff000, 4096) = 0
20128 close(5) = 0
20128 munmap(0x7f3286304000, 4096) = 0
20128 stat(/var/log/userhistory.log, {st_mode=S_IFREG|0600, st_size=0,
...}) = 0
20128 stat(/var/log/messages, {st_mode=S_IFREG|0600, st_size=1282, ...})
= 0
20128 stat(/var/log/secure, {st_mode=S_IFREG|0600, st_size=3183, ...}) = 0
20128 stat(/var/log/audit, {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
On Thursday, November 13, 2014 1:53:16 PM UTC, Jeremy Rossi wrote:
Can we try to get an strace with threads: strace -f
On Nov 12, 2014, at 12:52 PM, dan (ddp) ddp...@gmail.com javascript:
wrote:
On Wed, Nov 12, 2014 at 11:49 AM, dan (ddp) ddp...@gmail.com
javascript: wrote:
On Mon, Nov 10, 2014 at 4:02 AM, Chris H chris@gmail.com
javascript: wrote:
The only calls in the strace to alerts.log are these:
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) =
673
Are you sure 4 is a log file, and not the connection to the
ossec-remoted on the other end? I don't think there's enough of the
logs to really get an idea of what's going on (maybe the developers
would have more of a clue).
I did setup a hybrid system on Centos 7 and the latest OSSEC sources,
but I'm not seeing the same issues you are.
Spoke too soon, just saw it happen after about an hour of running.
It's definitely reading it though, as it forwards the logs for a bit.
On Friday, November 7, 2014 1:00:31 PM UTC, dan (ddpbsd) wrote:
On Thu, Nov 6, 2014 at 9:40 AM, Chris H chris@gmail.com
wrote:
Hi.
I'm running on CentOS 6.6.
I enabled debug in internal_options.conf - nothing new in the logs.
strace
gives this at the time that it stops reading the file. It means
nothing
to
me, though.
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) =
-1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 641, 0, NULL, 0) =
641
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) =
-1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 639, 0, NULL, 0) =
639
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) =
-1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 634, 0, NULL, 0) =
634
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60c0390) =
-1
ENOENT (No such file or directory)
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) =
673
stat(/logs/ossec/logs/alerts/alerts.log, {st_mode
[ossec-list] RE: list_agents -n shows non-existing clients?
For the sakes of anyone experiencing this issue in future I thought I'd pop back to say that I found the cause a few minutes ago. Somehow when agents had been removed there were files for those agents left behind in the following path :- /var/ossec/queue/agent-info/ I deleted those files and my list_agents -n is now showing what I would expect. I don't have any clue as to how those files were left and I didn't know that list_agents would refer to that folder. So I've learned something :) Just to stress, I *was* running an old version (which I plan to upgrade now that I have got to the bottom of the issue). Regards, Chris -- Chris Tweed Technical Support Shoe Zone T: 0116 2223000 W: www.shoezone.com -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Tweed Sent: 06 November 2014 17:10 To: 'ossec-list@googlegroups.com' Subject: [ossec-list] list_agents -n shows non-existing clients? I regularly perform a list_agents -n to check for any non-connected OSSEC clients in our environment so that I can investigate the reason and resolve. At present if I perform this check I get quite a long list showing clients which no longer exist in the client.keys file on our server. I must confess to periodically cleaning up the client.keys file using a text editor to remove all the #* lines as our estate can be quite fluid. However I have been doing this for some years now and have never encountered this issue before. I can't understand how a client can be showing in list_agents as non-connected when there is no entry for it in client.keys on the server. I don't know of anywhere else OSSEC could be finding references to these clients which are no longer live in our estate (but certainly used to be live and active clients in the past). Whilst I can't see that it this is actually harmful, it does make the job of spotting genuinely disconnected clients somewhat harder. Is there somewhere I should be looking for a file or files which might contain references to these ghost clients? I'll admit to not knowing enough about OSSEC under the hood to know where to start looking. I've had a plough through the file system but haven't spotted anything obvious. I am still running version 2.7 and intend to update to 2.8.1, however I would rather try to get this issue resolved before updating. It could be that updating clears the issue or it might carry the issue forward. Any pointers would be appreciated, even if it's just a slap of my wrist for manually editing client.keys to trim out the rubbish I guess :) Maybe I shouldn't be doing that, even if I've never (before!) suffered any issues from doing so. Might it be better / quicker to simply start over with a fresh and up-to-date installation of OSSEC? We have around 600 clients (all of them Windows) so it's not a trivial job to roll out a fresh install - but if that's what I have to do then so be it. We have a single OSSEC server running under Ubuntu server 12.04.5 LTS 64 bit (as a Hyper-V virtual machine). Thank you, Chris -- Chris Tweed Please consider the environment before printing this email CONFIDENTIALITY NOTICE This E-Mail contains information which is confidential and privileged. If you have received this E-Mail in error, please telephone us immediately on +44 116 2223000. Where opinions are expressed they are not necessarily those of Shoe Zone Retail Ltd. Shoe Zone Retail Ltd Registered Office : Haramead Business Centre, Humberstone Road, Leicester LE1 2LH Registered in England Number 148038 -- --- 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] Hybrid issues - stops forwarding logs
The only calls in the strace to alerts.log are these:
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) = 673
It's definitely reading it though, as it forwards the logs for a bit.
On Friday, November 7, 2014 1:00:31 PM UTC, dan (ddpbsd) wrote:
On Thu, Nov 6, 2014 at 9:40 AM, Chris H chris@gmail.com javascript:
wrote:
Hi.
I'm running on CentOS 6.6.
I enabled debug in internal_options.conf - nothing new in the logs.
strace
gives this at the time that it stops reading the file. It means nothing
to
me, though.
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 641, 0, NULL, 0) = 641
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 639, 0, NULL, 0) = 639
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 634, 0, NULL, 0) = 634
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60c0390) = -1
ENOENT (No such file or directory)
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) = 673
stat(/logs/ossec/logs/alerts/alerts.log, {st_mode=S_IFREG|0640,
st_size=2608807647, ...}) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
open(/logs/ossec/ossec-agent/logs/ossec.log,
O_WRONLY|O_CREAT|O_APPEND,
0666) = 6
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=
0x7f718bba4000
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
lseek(6, 6467, SEEK_SET)= 6467
write(6, 2014/11/06 14:28:30 ossec-logcol..., 123) = 123
close(6)= 0
munmap(0x7f718bba4000, 4096)= 0
close(5)= 0
munmap(0x7f718bba5000, 4096)= 0
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}^C unfinished ...
I don't actually see an open of the alerts.log, or any failures (or
I'm missing them).
It seems to fail after the keepalive every time.
On Thursday, November 6, 2014 12:53:32 PM UTC, dan (ddpbsd) wrote:
On Thu, Nov 6, 2014 at 6:44 AM, Chris H chris@gmail.com wrote:
Has anyone got Hybrid working?
I have agents that work and I have managers that work. So basically
yes.
What distro/version are you using?
Can you try strace to see if that gives you more information on what's
going on?
Looking at the code, I think better information should be logged,
maybe try turning on debug?
according to lsof, nothing else seems to be accessing the files at
the
time
that the agent stops processing them.
I've figured out why it's looking at additional files/directories,
it's
pulled in the shared agent config; I'd forgotten I'd configured that
:)
On Tuesday, November 4, 2014 3:43:43 PM UTC, Chris H wrote:
Hi. I've set selinux to Permissive, no difference. It sends some
logs
out, in the 2 minutes before it stops processing the file.
Thanks.
On Tuesday, November 4, 2014 12:56:49 PM UTC, dan (ddpbsd) wrote:
On Mon, Nov 3, 2014 at 12:39 PM, Chris H chris@gmail.com
wrote:
Hi. I'm trying to get a hybrid server working, and seeing some
odd
behaviour. I'm running 2.8.1.
When the agent component starts, the logs state:
2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197).
2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address:
192.168.1.1
2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to
server
(192.168.1.1:1514).
2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for:
192.168.1.1
.
2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting.
2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module
disabled.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Started (pid: 26205).
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/etc'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/usr/bin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/usr/sbin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/bin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/sbin'.
2014/11/03 17:00:30 ossec-agentd(1210): ERROR: Queue
'/queue/alerts/execq'
not accessible: 'Queue
Re: [ossec-list] Hybrid issues - stops forwarding logs
Has anyone got Hybrid working? according to lsof, nothing else seems to be accessing the files at the time that the agent stops processing them. I've figured out why it's looking at additional files/directories, it's pulled in the shared agent config; I'd forgotten I'd configured that :) On Tuesday, November 4, 2014 3:43:43 PM UTC, Chris H wrote: Hi. I've set selinux to Permissive, no difference. It sends some logs out, in the 2 minutes before it stops processing the file. Thanks. On Tuesday, November 4, 2014 12:56:49 PM UTC, dan (ddpbsd) wrote: On Mon, Nov 3, 2014 at 12:39 PM, Chris H chris@gmail.com wrote: Hi. I'm trying to get a hybrid server working, and seeing some odd behaviour. I'm running 2.8.1. When the agent component starts, the logs state: 2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197). 2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address: 192.168.1.1 2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to server (192.168.1.1:1514). 2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for: 192.168.1.1 . 2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting. 2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module disabled. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Started (pid: 26205). 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/etc'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/sbin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/sbin'. 2014/11/03 17:00:30 ossec-agentd(1210): ERROR: Queue '/queue/alerts/execq' not accessible: 'Queue not found'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/logs/ossec/logs/alerts/alerts.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/userhistory.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/secure'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/audit'. 2014/11/03 17:00:30 ossec-logcollector: INFO: Started (pid: 26201). 2014/11/03 17:00:45 ossec-agentd: INFO: Unable to connect to the active response queue (disabled). 2014/11/03 17:00:46 ossec-agentd(4102): INFO: Connected to the server (192.168.1.1:1514). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck database (pre-scan). I don't know why it's monitoring most of those, as the ossec.conf for the agent only specifies '/logs/ossec/logs/alerts/alerts.log'. A couple of minutes later, it stops parsing the alerts.log, with: 2014/11/03 17:02:40 ossec-logcollector(1904): INFO: File not available, ignoring it: '/logs/ossec/logs/alerts/alerts.log'. Any idea why it's stopping parsing the log file? I do have logstash consuming the logs too, and thought it might be that, but it happens even if I disable logstash. It's happening almost exactly 2 minutes after the process starts. I've tried setting the permissions on the log file to 644, too, but that makes no difference. Is SELinux or something blocking access to 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.
Re: [ossec-list] Hybrid issues - stops forwarding logs
Hi.
I'm running on CentOS 6.6.
I enabled debug in internal_options.conf - nothing new in the logs. strace
gives this at the time that it stops reading the file. It means nothing to
me, though.
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 641, 0, NULL, 0) = 641
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 639, 0, NULL, 0) = 639
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 634, 0, NULL, 0) = 634
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60c0390) = -1
ENOENT (No such file or directory)
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) = 673
stat(/logs/ossec/logs/alerts/alerts.log, {st_mode=S_IFREG|0640,
st_size=2608807647, ...}) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
open(/logs/ossec/ossec-agent/logs/ossec.log, O_WRONLY|O_CREAT|O_APPEND,
0666) = 6
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f718bba4000
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
lseek(6, 6467, SEEK_SET)= 6467
write(6, 2014/11/06 14:28:30 ossec-logcol..., 123) = 123
close(6)= 0
munmap(0x7f718bba4000, 4096)= 0
close(5)= 0
munmap(0x7f718bba5000, 4096)= 0
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}^C unfinished ...
It seems to fail after the keepalive every time.
On Thursday, November 6, 2014 12:53:32 PM UTC, dan (ddpbsd) wrote:
On Thu, Nov 6, 2014 at 6:44 AM, Chris H chris@gmail.com javascript:
wrote:
Has anyone got Hybrid working?
I have agents that work and I have managers that work. So basically yes.
What distro/version are you using?
Can you try strace to see if that gives you more information on what's
going on?
Looking at the code, I think better information should be logged,
maybe try turning on debug?
according to lsof, nothing else seems to be accessing the files at the
time
that the agent stops processing them.
I've figured out why it's looking at additional files/directories, it's
pulled in the shared agent config; I'd forgotten I'd configured that :)
On Tuesday, November 4, 2014 3:43:43 PM UTC, Chris H wrote:
Hi. I've set selinux to Permissive, no difference. It sends some logs
out, in the 2 minutes before it stops processing the file.
Thanks.
On Tuesday, November 4, 2014 12:56:49 PM UTC, dan (ddpbsd) wrote:
On Mon, Nov 3, 2014 at 12:39 PM, Chris H chris@gmail.com wrote:
Hi. I'm trying to get a hybrid server working, and seeing some odd
behaviour. I'm running 2.8.1.
When the agent component starts, the logs state:
2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197).
2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address:
192.168.1.1
2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to server
(192.168.1.1:1514).
2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for: 192.168.1.1
.
2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting.
2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module
disabled.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Started (pid: 26205).
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/etc'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/usr/bin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/usr/sbin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/bin'.
2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory:
'/sbin'.
2014/11/03 17:00:30 ossec-agentd(1210): ERROR: Queue
'/queue/alerts/execq'
not accessible: 'Queue not found'.
2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file:
'/logs/ossec/logs/alerts/alerts.log'.
2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file:
'/var/log/userhistory.log'.
2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file:
'/var/log/messages'.
2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file:
'/var/log/secure'.
2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file:
'/var/log/audit'.
2014/11/03 17:00:30 ossec-logcollector: INFO: Started (pid: 26201).
2014/11/03 17:00:45 ossec-agentd: INFO: Unable
Re: [ossec-list] Hybrid issues - stops forwarding logs
Same thing, unfortunately.
2014/11/06 15:26:33 ossec-logcollector: DEBUG: Starting ...
2014/11/06 15:26:33 ossec-logcollector: DEBUG: Waiting main daemons to
settle.
2014/11/06 15:26:39 ossec-logcollector: INFO: (unix_domain) Maximum send
buffer set to: '229376'.
2014/11/06 15:26:39 ossec-logcollector: DEBUG: Entering LogCollectorStart().
2014/11/06 15:26:39 ossec-logcollector(1950): INFO: Analyzing file:
'/logs/ossec/logs/alerts/alerts.log'.
2014/11/06 15:26:39 ossec-logcollector: INFO: Started (pid: 7004).
2014/11/06 15:28:49 ossec-logcollector(1904): INFO: File not available,
ignoring it: '/logs/ossec/logs/alerts/alerts.log'.
it's failing immediately after the first keepalive:
sendto(4, 1:ossec-keepalive:--MARK--: X;]^..., 485, 0, NULL, 0) = 485
On Thursday, November 6, 2014 3:15:35 PM UTC, dan (ddpbsd) wrote:
On Nov 6, 2014 9:41 AM, Chris H chris@gmail.com javascript:
wrote:
Hi.
I'm running on CentOS 6.6.
I enabled debug in internal_options.conf - nothing new in the logs.
strace gives this at the time that it stops reading the file. It means
nothing to me, though.
Try killing the daemon and restarting it with the -d flag.
`/var/ossec/ossec-agent/bin/ossec-logcollector -d` (typed on my phone, so
tyops are likely)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 641, 0, NULL, 0) = 641
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 639, 0, NULL, 0) = 639
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60bf900) = -1
ENOENT (No such file or directory)
sendto(4, 1:/logs/ossec/logs/alerts/alerts..., 634, 0, NULL, 0) = 634
stat(/logs/ossec/ossec-agent/queue/ossec/.wait, 0x7fffe60c0390) = -1
ENOENT (No such file or directory)
sendto(4, 1:ossec-keepalive:--MARK--: no[;..., 673, 0, NULL, 0) = 673
stat(/logs/ossec/logs/alerts/alerts.log, {st_mode=S_IFREG|0640,
st_size=2608807647, ...}) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
open(/logs/ossec/ossec-agent/logs/ossec.log,
O_WRONLY|O_CREAT|O_APPEND, 0666) = 6
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f718bba4000
fstat(6, {st_mode=S_IFREG|0770, st_size=6467, ...}) = 0
lseek(6, 6467, SEEK_SET)= 6467
write(6, 2014/11/06 14:28:30 ossec-logcol..., 123) = 123
close(6)= 0
munmap(0x7f718bba4000, 4096)= 0
close(5)= 0
munmap(0x7f718bba5000, 4096)= 0
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {2, 0}^C unfinished ...
It seems to fail after the keepalive every time.
On Thursday, November 6, 2014 12:53:32 PM UTC, dan (ddpbsd) wrote:
On Thu, Nov 6, 2014 at 6:44 AM, Chris H chris@gmail.com wrote:
Has anyone got Hybrid working?
I have agents that work and I have managers that work. So basically
yes.
What distro/version are you using?
Can you try strace to see if that gives you more information on what's
going on?
Looking at the code, I think better information should be logged,
maybe try turning on debug?
according to lsof, nothing else seems to be accessing the files at
the time
that the agent stops processing them.
I've figured out why it's looking at additional files/directories,
it's
pulled in the shared agent config; I'd forgotten I'd configured that
:)
On Tuesday, November 4, 2014 3:43:43 PM UTC, Chris H wrote:
Hi. I've set selinux to Permissive, no difference. It sends some
logs
out, in the 2 minutes before it stops processing the file.
Thanks.
On Tuesday, November 4, 2014 12:56:49 PM UTC, dan (ddpbsd) wrote:
On Mon, Nov 3, 2014 at 12:39 PM, Chris H chris@gmail.com
wrote:
Hi. I'm trying to get a hybrid server working, and seeing some
odd
behaviour. I'm running 2.8.1.
When the agent component starts, the logs state:
2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197).
2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address:
192.168.1.1
2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to
server
(192.168.1.1:1514).
2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for:
192.168.1.1 .
2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting.
2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module
disabled.
2014/11/03 17:00:28 ossec-syscheckd: INFO
[ossec-list] list_agents -n shows non-existing clients?
I regularly perform a list_agents -n to check for any non-connected OSSEC clients in our environment so that I can investigate the reason and resolve. At present if I perform this check I get quite a long list showing clients which no longer exist in the client.keys file on our server. I must confess to periodically cleaning up the client.keys file using a text editor to remove all the #* lines as our estate can be quite fluid. However I have been doing this for some years now and have never encountered this issue before. I can't understand how a client can be showing in list_agents as non-connected when there is no entry for it in client.keys on the server. I don't know of anywhere else OSSEC could be finding references to these clients which are no longer live in our estate (but certainly used to be live and active clients in the past). Whilst I can't see that it this is actually harmful, it does make the job of spotting genuinely disconnected clients somewhat harder. Is there somewhere I should be looking for a file or files which might contain references to these ghost clients? I'll admit to not knowing enough about OSSEC under the hood to know where to start looking. I've had a plough through the file system but haven't spotted anything obvious. I am still running version 2.7 and intend to update to 2.8.1, however I would rather try to get this issue resolved before updating. It could be that updating clears the issue or it might carry the issue forward. Any pointers would be appreciated, even if it's just a slap of my wrist for manually editing client.keys to trim out the rubbish I guess :) Maybe I shouldn't be doing that, even if I've never (before!) suffered any issues from doing so. Might it be better / quicker to simply start over with a fresh and up-to-date installation of OSSEC? We have around 600 clients (all of them Windows) so it's not a trivial job to roll out a fresh install - but if that's what I have to do then so be it. We have a single OSSEC server running under Ubuntu server 12.04.5 LTS 64 bit (as a Hyper-V virtual machine). Thank you, Chris -- Chris Tweed Please consider the environment before printing this email CONFIDENTIALITY NOTICE This E-Mail contains information which is confidential and privileged. If you have received this E-Mail in error, please telephone us immediately on +44 116 2223000. Where opinions are expressed they are not necessarily those of Shoe Zone Retail Ltd. Shoe Zone Retail Ltd Registered Office : Haramead Business Centre, Humberstone Road, Leicester LE1 2LH Registered in England Number 148038 -- --- 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] Hybrid issues - stops forwarding logs
Hi. I've set selinux to Permissive, no difference. It sends some logs out, in the 2 minutes before it stops processing the file. Thanks. On Tuesday, November 4, 2014 12:56:49 PM UTC, dan (ddpbsd) wrote: On Mon, Nov 3, 2014 at 12:39 PM, Chris H chris@gmail.com javascript: wrote: Hi. I'm trying to get a hybrid server working, and seeing some odd behaviour. I'm running 2.8.1. When the agent component starts, the logs state: 2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197). 2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address: 192.168.1.1 2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to server (192.168.1.1:1514). 2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for: 192.168.1.1 . 2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting. 2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module disabled. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Started (pid: 26205). 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/etc'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/sbin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/sbin'. 2014/11/03 17:00:30 ossec-agentd(1210): ERROR: Queue '/queue/alerts/execq' not accessible: 'Queue not found'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/logs/ossec/logs/alerts/alerts.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/userhistory.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/secure'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/audit'. 2014/11/03 17:00:30 ossec-logcollector: INFO: Started (pid: 26201). 2014/11/03 17:00:45 ossec-agentd: INFO: Unable to connect to the active response queue (disabled). 2014/11/03 17:00:46 ossec-agentd(4102): INFO: Connected to the server (192.168.1.1:1514). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck database (pre-scan). I don't know why it's monitoring most of those, as the ossec.conf for the agent only specifies '/logs/ossec/logs/alerts/alerts.log'. A couple of minutes later, it stops parsing the alerts.log, with: 2014/11/03 17:02:40 ossec-logcollector(1904): INFO: File not available, ignoring it: '/logs/ossec/logs/alerts/alerts.log'. Any idea why it's stopping parsing the log file? I do have logstash consuming the logs too, and thought it might be that, but it happens even if I disable logstash. It's happening almost exactly 2 minutes after the process starts. I've tried setting the permissions on the log file to 644, too, but that makes no difference. Is SELinux or something blocking access to 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Hybrid issues - stops forwarding logs
Hi. I'm trying to get a hybrid server working, and seeing some odd behaviour. I'm running 2.8.1. When the agent component starts, the logs state: 2014/11/03 17:00:24 ossec-agentd: INFO: Started (pid: 26197). 2014/11/03 17:00:24 ossec-agentd: INFO: Server IP Address: 192.168.1.1 2014/11/03 17:00:24 ossec-agentd: INFO: Trying to connect to server (192.168.1.1:1514). 2014/11/03 17:00:24 ossec-agentd: INFO: Using IPv4 for: 192.168.1.1 . 2014/11/03 17:00:24 ossec-rootcheck: Rootcheck disabled. Exiting. 2014/11/03 17:00:24 ossec-syscheckd: WARN: Rootcheck module disabled. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Started (pid: 26205). 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/etc'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/usr/sbin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/bin'. 2014/11/03 17:00:28 ossec-syscheckd: INFO: Monitoring directory: '/sbin'. 2014/11/03 17:00:30 ossec-agentd(1210): ERROR: Queue '/queue/alerts/execq' not accessible: 'Queue not found'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/logs/ossec/logs/alerts/alerts.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/userhistory.log'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/messages'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/secure'. 2014/11/03 17:00:30 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/audit'. 2014/11/03 17:00:30 ossec-logcollector: INFO: Started (pid: 26201). 2014/11/03 17:00:45 ossec-agentd: INFO: Unable to connect to the active response queue (disabled). 2014/11/03 17:00:46 ossec-agentd(4102): INFO: Connected to the server (192.168.1.1:1514). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck scan (forwarding database). 2014/11/03 17:01:30 ossec-syscheckd: INFO: Starting syscheck database (pre-scan). I don't know why it's monitoring most of those, as the ossec.conf for the agent only specifies '/logs/ossec/logs/alerts/alerts.log'. A couple of minutes later, it stops parsing the alerts.log, with: 2014/11/03 17:02:40 ossec-logcollector(1904): INFO: File not available, ignoring it: '/logs/ossec/logs/alerts/alerts.log'. Any idea why it's stopping parsing the log file? I do have logstash consuming the logs too, and thought it might be that, but it happens even if I disable logstash. It's happening almost exactly 2 minutes after the process starts. I've tried setting the permissions on the log file to 644, too, but that makes no difference. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] ossec-authd unknown option -v
When I try to run ossec-authd with the -v option I get an invalid option error. According to the man page on the website for version 2.8.1 located at https://ossec-docs.readthedocs.org/en/latest/programs/ossec-authd.html the daemon supports a -v option to pass it a ca cert. The command and error are below. The -h option also produces the same error, but -V does work and reports that it is in fact version 2.8.1. Am I missing something here or did this option not get added? Command: /var/ossec/bin/ossec-authd -g ossec -p 1515 -v /var/ossec/etc/cacert.pem Error: /var/ossec/bin/ossec-authd: invalid option -- 'v' -- --- 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 unknown option -v
Yeah, you can actually disregard this, I posted in the dev list accidentally on friday and missed the thread there. It was confirmed that they are in the latest dev build and not 2.8.1. Sorry for the duplicate post but thanks for the help. On Monday, October 27, 2014 9:26:47 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 27, 2014 at 10:11 AM, Chris cmcm...@gravie.com javascript: wrote: When I try to run ossec-authd with the -v option I get an invalid option error. According to the man page on the website for version 2.8.1 located at https://ossec-docs.readthedocs.org/en/latest/programs/ossec-authd.html the daemon supports a -v option to pass it a ca cert. The command and error are below. The -h option also produces the same error, but -V does work and reports that it is in fact version 2.8.1. Am I missing something here or did this option not get added? Command: /var/ossec/bin/ossec-authd -g ossec -p 1515 -v /var/ossec/etc/cacert.pem Error: /var/ossec/bin/ossec-authd: invalid option -- 'v' I think those options were added after 2.8.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+...@googlegroups.com javascript:. 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] centos7 inotify-tools
On centos7, I'm getting a dependency failure for inotify-tools when trying to install ossec 2.8 from the atomic repos, and I don't see inotify-tools rpm being available in epel or base. That was my question. On Wednesday, July 30, 2014 8:00:21 AM UTC-4, dan (ddpbsd) wrote: On Fri, Jul 25, 2014 at 3:54 PM, Chris Clifton juic...@gmail.com javascript: wrote: Is OSSEC 2.8 supported on centos7? I don't see the inotify-tools rpm as being available in base or epel repos. I haven't tried realtime support specifically, but everything else I've tried seems to work so far. I was trying to install the rpms on my centos7 box from the atomic corp repos, and it fails on the inotify-tools dependency. Maybe I need to install the .tar.gz packages instead? 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] centos7 inotify-tools
Is OSSEC 2.8 supported on centos7? I don't see the inotify-tools rpm as being available in base or epel repos. I was trying to install the rpms on my centos7 box from the atomic corp repos, and it fails on the inotify-tools dependency. Maybe I need to install the .tar.gz packages instead? 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.
Re: [ossec-list] level 10 - High amount of POST requests in a small period of time with ngx_pagespeed
Hi, to ignore those notifications but i'm not sure if there is a better way to avoid such notifications. Any help/hints/tips are welcome. Seems reasonable. thanks for your reply. Running this now for some weeks and have not seen any issues with this local rule. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] level 10 - High amount of POST requests in a small period of time with ngx_pagespeed
Hi list, running OSSEC 2.8 on a debian wheezy server together with NginX 1.6 and the ngx_pagespeed 1.8.31.2 module fires the following OSSEC rule: OSSEC HIDS Notification. 2014 Jun 28 14:45:56 Received From: example.com-/var/log/nginx/access.log Rule: 31533 fired (level 10) - High amount of POST requests in a small period of time (likely bot). Portion of the log(s): 1.2.3.4 - - [28/Jun/2014:14:45:55 +0200] POST /ngx_pagespeed_beacon?url=http%3A%2F%2Fwww.example.com Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 It seems that this is a normal behavior when the ngx_pagespeed module is installed as the IPs causing this POST requests are normal users of this system. For now i have created a local_rule: - !--group name=web,appsec,attack rule id=100030 level=0 if_sid31530/if_sid decoded_asweb-accesslog/decoded_as urlngx_pagespeed_beacon/url descriptionIgnore all ngx_pagespeed_beacon requests/description /rule /group-- - to ignore those notifications but i'm not sure if there is a better way to avoid such notifications. Any help/hints/tips are welcome. Thanks in advance for a reply. -- --- 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 decoder
Not sure if this helps but there are more spaces in the alert log, between the word error and the : then in the decoder you posted. Chris Hughes Layer8 Consulting (240)460-7283 On Jun 11, 2014, at 6:09 AM, PlaySeb59 playse...@gmail.com wrote: Thanks for your help. A restart not resolve the problem. I have install on a virtual machine Monit and Ossec in order to test it on an other system but nothing change and I have the same problem. I'll let you know if I find a solution. Le mardi 10 juin 2014 17:27:13 UTC+2, dan (ddpbsd) a écrit : On Tue, Jun 10, 2014 at 11:01 AM, PlaySeb59 play...@gmail.com wrote: My English is bad, sorry. When I trigger an event (for example, when an hacker try to get acces to the WUI of monit), it generate this line in the monit.log file: [CEST Jun 10 16:40:41] error: Warning: Client '80.70.20.10' supplied wrong password for user 'root' accessing monit httpd I can see in alerts.log: ** Alert 1402411242.25253: mail - syslog,errors, 2014 Jun 10 16:40:42 debian -/home/log/monit.log Rule: 1002 (level 2) - 'Unknown problem somewhere in the system.' [CEST Jun 10 16:40:41] error: Warning: Client '80.70.20.10' supplied wrong password for user 'root' accessing monit httpd ossec-analysisd process don't use my decoder ? If it works with ossec-logtest, it should work with analysisd. I don't know what else the issue could be off hand. Make sure the processes are restarted properly? (stop them, make sure they're stopped, start them back up) Le mardi 10 juin 2014 16:33:32 UTC+2, dan (ddpbsd) a écrit : On Tue, Jun 10, 2014 at 9:03 AM, PlaySeb59 play...@gmail.com wrote: Thanks for your help Dan. Yes, I have already restarted Ossec. (I work on a local installation) And yes, I use the same log in the bin/ossec-logtest tool as the log on the screenshot. That's why I don't understand. ossec-logtest does not log the output to the alerts.log, so there are no new alerts from the old log message. If you want to see another alert in the wui, you have to trigger it. Try echoing the log message to a monitored logfile to see if that triggers it. Le mardi 10 juin 2014 14:14:48 UTC+2, dan (ddpbsd) a écrit : On Tue, Jun 10, 2014 at 7:44 AM, PlaySeb59 play...@gmail.com wrote: Hello guys, I have a problem to add a log. To make more secure my monit httpd interface, I want to add new rules in order to block brute-force attacks. I use these logs: [CEST Jun 10 11:54:17] error : Warning: Client '80.70.20.10' supplied unknown user 'monit' accessing monit httpd [CEST Jun 10 11:47:13] error : Warning: Client '80.70.20.10' supplied wrong password for user 'root' accessing monit httpd So, I made this decoder in etc/local_decoder.xml: decoder name=monit prematcherror : Warning: /prematch regex offset=after_prematchClient '(\d+.\d+.\d+.\d+)'/regex ordersrcip/order /decoder And these rules in rules/local_rules.xml: rule id=100010 level=0 decoded_asmonit/decoded_as descriptionMonit messages grouped./description /rule rule id=14 level=5 if_sid100010/if_sid matchsupplied wrong password for user/match descriptionMonit: User authentication failed./description groupauthentication_failed,monit/group /rule rule id=100011 level=5 if_sid100010/if_sid matchsupplied unknown user/match descriptionMonit: Attempt to login using a non-existent user./description groupauthentication_failed,monit/group /rule rule id=15 level=10 frequency=4 timeframe=600 if_matched_groupmonit/if_matched_group same_source_ip / descriptionMonit: 6 alerts from the same IP/description description in the last 10 minutes./description groupauthentication_failures,/group /rule And when I try my rules with bin/ossec-logtest, it's working fine: # bin/ossec-logtest 2014/06/10 13:09:04 ossec-testrule: INFO: Reading local decoder file. 2014/06/10 13:09:04 ossec-testrule: INFO: Started (pid: 12616). ossec-testrule: Type one log per line. [CEST Jun 10 11:54:17] error : Warning: Client '80.70.20.10' supplied unknown user 'monit' accessing monit httpd **Phase 1: Completed pre-decoding. full event: '[CEST Jun 10 11:54:17] error : Warning: Client '80.70.20.10' supplied unknown user 'monit' accessing monit httpd' hostname: 'ns358990' program_name: '(null)' log: '[CEST Jun 10 11:54:17] error : Warning: Client '80.70.20.10' supplied unknown user 'monit' accessing monit httpd' **Phase 2: Completed decoding. decoder: 'monit' srcip: '80.70.20.10
RE: [ossec-list] Monitoring for PCI
Thanks for the response. When you say is add any other critical files to the list of files to monitor under the agent.conf, I do have an existing syslog server that stores files on its local drive. In order to monitor and alert based on severity, can I simply add this to the agent conf I push out to other agent machines: agent_config name=syslog_server localfile log_formatsyslog/log_format locationC:\Program Files\Syslog\Logs/location /localfile /agent_config I guess I might also be able to use the ossec.conf on the syslog server and add: localfile log_formatsyslog/log_format locationC:\Program Files\Syslog\Logs/location /localfile ... or do I need to send the logs to the OSSEC server? -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Nick Stephens Sent: Wednesday, May 28, 2014 11:25 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Monitoring for PCI By default, the agent.conf file already meets a lot of the requirements for FIM (Requirement 11) for PCI DSS V3.0. For example: - Req 11.5.a: Syscheck needs to run at least once a week minimal and the OSSEC default is I believe every 20 hours? - Req 11.5b (Alerts of unauthorized modifications): To satisfy this requirement, make sure you have emailed alerts set to email you or your IT admins. - Req 10.5.5 (Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts): If OSSEC is your centralized logging solution, we need to verify the following configuration item in the ossec.conf: - directories realtime=yes check_all=yes/var/ossec/logs/directories - directories realtime=yes check_all=yes/var/ossec/etc/ossec.conf/directories Under !-- Files/directories to ignore -- - ignore type=sregex.log$|.tmp/ignore One thing you will need to do is add any other critical files to the list of files to monitor under the agent.conf that you think are critical to the system or business. If you are looking to use OSSEC to satisfy your Centralized logging requirements (Requirement 10) then there is another list of things to be done as well. Nick -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Hughes Sent: Wednesday, May 28, 2014 8:31 AM To: ossec-list@googlegroups.com Subject: [ossec-list] Monitoring for PCI Is there a specific set of rules for the agent.conf file that address PCI requirements? I am looking to use OSSEC for the FIMS requirement as a start, and after I am comfortable with it, use it to augment my existing security toolbox. Can anyone point me in the right direction to answer the PCI FIMS requirement with OSSEC? 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. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Decoder for WatchGuard firebox firewall
I searched the list and only got two hits on this. Has anyone developed a decoder for watchguard? -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Monitoring for PCI
Is there a specific set of rules for the agent.conf file that address PCI requirements? I am looking to use OSSEC for the FIMS requirement as a start, and after I am comfortable with it, use it to augment my existing security toolbox. Can anyone point me in the right direction to answer the PCI FIMS requirement with OSSEC? 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.
RE: [ossec-list] Auto-register windows clients
Saw a post saying that if you - mass-generate the keys on the server - parse the resulting record for a client out of the client.keys file on that server - place the parsed-for record into a client.keys file on the client in the proper directory - Start the windows client ...then it would work. Tried this and it does indeed work. So I'm thinking all I need are instructions on the mass generation of the keys and a script to parse it and spit out a client.keys file for multiple users. Doing this one user at a time isn't an option. Chris Hughes (m) (240)460-7283 -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of dan (ddp) Sent: Tuesday, March 25, 2014 8:34 AM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Auto-register windows clients On Tue, Mar 25, 2014 at 8:04 AM, James M. Pulver jmp...@cornell.edu wrote: I think if you search the list you should find some options. I know I posted generic versions of the two scripts I use to do this (one is AutoIT on Windows, the other is on Linux in bash if I recall correctly and it needs a sudo permission)... It's a shame some effort isn't being put into making the agent-auth stuff work on Windows. -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of C Hughes Sent: Monday, March 24, 2014 8:33 PM To: ossec-list@googlegroups.com Subject: [ossec-list] Auto-register windows clients I've been searching for days and can't find how to do this. I tried running /var/ossec/bin/ossec-authd -p 1515 /dev/null 21 and installing the win32 client on XP systems but that doesn't work. Other solutions for mass deployment I've found are above my Linux pay grade. I have the server working on Ubuntu Server and can manually register clients so I'm confident my install is ok. Anyone out there able to lend a hand? 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. -- --- 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] Auto-register windows clients
I looked and found a post where you posted Auto-IT as an attachment but the attachment no longer was there. The environment is almost exclusively Windows so I wont need the bash script. Can you post Auto-IT? My scripting is pretty crusty but I can usually figure them out. Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 8:05 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients I think if you search the list you should find some options. I know I posted generic versions of the two scripts I use to do this (one is AutoIT on Windows, the other is on Linux in bash if I recall correctly and it needs a sudo permission)… -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of C Hughes Sent: Monday, March 24, 2014 8:33 PM To: ossec-list@googlegroups.com Subject: [ossec-list] Auto-register windows clients I've been searching for days and can't find how to do this. I tried running /var/ossec/bin/ossec-authd -p 1515 /dev/null 21 and installing the win32 client on XP systems but that doesn't work. Other solutions for mass deployment I've found are above my Linux pay grade. I have the server working on Ubuntu Server and can manually register clients so I'm confident my install is ok. Anyone out there able to lend a hand? 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. -- --- 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] Auto-register windows clients
The procedure I read for ossec-authd instructed me to run the command-line below, and then start up the client with the server IP inserted in the ossec.conf file and it would auto register. I tried this and variations of it but nothing happens. Chris Hughes (m) (240)460-7283 -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of dan (ddp) Sent: Tuesday, March 25, 2014 8:33 AM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Auto-register windows clients On Mon, Mar 24, 2014 at 8:32 PM, C Hughes chughes...@gmail.com wrote: I've been searching for days and can't find how to do this. I tried running /var/ossec/bin/ossec-authd -p 1515 /dev/null 21 and installing the win32 client on XP systems but that doesn't work. Other solutions for mass What doesn't work exactly? deployment I've found are above my Linux pay grade. I have the server working on Ubuntu Server and can manually register clients so I'm confident my install is ok. Anyone out there able to lend a hand? 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. -- --- 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] Auto-register windows clients
Thanks James. So if I understand correctly, Run the bash script on the OSSEC serve after modifying it to my environment, and then run AutoIT against the .au3 script on the workstation? Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 10:44 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients You will indeed need the bash script as it has to run on the Linux side with my AutoIT script for it to work. This should help out. I don’t mass generate keys though. This generates them on demand. Read the comments in the autoit script for details. -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Hughes Sent: Tuesday, March 25, 2014 9:37 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients I looked and found a post where you posted Auto-IT as an attachment but the attachment no longer was there. The environment is almost exclusively Windows so I wont need the bash script. Can you post Auto-IT? My scripting is pretty crusty but I can usually figure them out. Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 8:05 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients I think if you search the list you should find some options. I know I posted generic versions of the two scripts I use to do this (one is AutoIT on Windows, the other is on Linux in bash if I recall correctly and it needs a sudo permission)… -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of C Hughes Sent: Monday, March 24, 2014 8:33 PM To: ossec-list@googlegroups.com Subject: [ossec-list] Auto-register windows clients I've been searching for days and can't find how to do this. I tried running /var/ossec/bin/ossec-authd -p 1515 /dev/null 21 and installing the win32 client on XP systems but that doesn't work. Other solutions for mass deployment I've found are above my Linux pay grade. I have the server working on Ubuntu Server and can manually register clients so I'm confident my install is ok. Anyone out there able to lend a hand? 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. -- --- 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] Auto-register windows clients
Great. Thanks. I’ll give it a whirl… Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 2:18 PM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients Well, not exactly. The bash script probably shouldn’t need modification except to be put in the correct directory, and enable it via sudo for the proper user account in the autoit script. You need an existing example file so I just put it there – I believe specified in the autoit script. Then the autoit script, along with plink – compiled into the autoit script – will run the bash script when run on a windows computer. This autoit script is what needs to be modified for your environment, specifically user and password to feed into plink for ssh connections to the OSSEC server… Then compile and run .exe on your desired clients… -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Hughes Sent: Tuesday, March 25, 2014 1:56 PM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients Thanks James. So if I understand correctly, Run the bash script on the OSSEC serve after modifying it to my environment, and then run AutoIT against the .au3 script on the workstation? Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 10:44 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients You will indeed need the bash script as it has to run on the Linux side with my AutoIT script for it to work. This should help out. I don’t mass generate keys though. This generates them on demand. Read the comments in the autoit script for details. -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of Chris Hughes Sent: Tuesday, March 25, 2014 9:37 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients I looked and found a post where you posted Auto-IT as an attachment but the attachment no longer was there. The environment is almost exclusively Windows so I wont need the bash script. Can you post Auto-IT? My scripting is pretty crusty but I can usually figure them out. Chris Hughes (m) (240)460-7283 From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of James M. Pulver Sent: Tuesday, March 25, 2014 8:05 AM To: ossec-list@googlegroups.com Subject: RE: [ossec-list] Auto-register windows clients I think if you search the list you should find some options. I know I posted generic versions of the two scripts I use to do this (one is AutoIT on Windows, the other is on Linux in bash if I recall correctly and it needs a sudo permission)… -- James Pulver CLASSE Computer Group Cornell University From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of C Hughes Sent: Monday, March 24, 2014 8:33 PM To: ossec-list@googlegroups.com Subject: [ossec-list] Auto-register windows clients I've been searching for days and can't find how to do this. I tried running /var/ossec/bin/ossec-authd -p 1515 /dev/null 21 and installing the win32 client on XP systems but that doesn't work. Other solutions for mass deployment I've found are above my Linux pay grade. I have the server working on Ubuntu Server and can manually register clients so I'm confident my install is ok. Anyone out there able to lend a hand? 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. -- --- 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
Re: [ossec-list] Re: OSSEC Logstash
Thanks, I'll have a look. For me the default template created each field
as a multi-field, with the regular, analysed field and an additional raw
un-analysed field. I'm extracting quite a lot of fields from the different
log types, which is something I was doing in Splunk before trying
elasticsearch.
Alert_Level : {
type : multi_field,
fields : {
Alert_Level : {
type : string,
omit_norms : true
},
raw : {
type : string,
index : not_analyzed,
omit_norms : true,
index_options : docs,
include_in_all : false,
ignore_above : 256
}
}
},
I created a new default template in elasticsearch:
curl -XPUT 'http://localhost:9200/_template/template_logstash/' -d '{
template: logstash-*,
settings: {
index.store.compress.stored: true
},
mappings: {
_default_: {
_source: { compress: true },
_all : {
enabled : false
}
}
}
}'
This has applied, but the compression doesn't seem to do much. I'm at the
point where I might only be able to store a limited amount of data in
elasticsearch :(
Chris
On Wednesday, March 19, 2014 7:37:41 PM UTC, Joshua Garnett wrote:
Chris,
Yeah digging into the templates was another big win for me. For instance,
if you try to do a topN query on signature with the default template, you
end up with words like the and and as your top hits. Setting signature
to not_analyzed ensures the field isn't tokenized. Below is my template.
--Josh
Logstash settings:
output {
elasticsearch {
host = 10.0.0.1
cluster = mycluster
index = logstash-ossec-%{+.MM.dd}
index_type = ossec
template_name = template-ossec
template = /etc/logstash/elasticsearch_template.json
template_overwrite = true
}
}
elasticsearch_template.json
{
template:logstash-ossec-*,
settings:{
index.analysis.analyzer.default.stopwords:_none_,
index.refresh_interval:5s,
index.analysis.analyzer.default.type:standard
},
mappings:{
ossec:{
properties:{
@fields.hostname:{
type:string,
index:not_analyzed
},
@fields.product:{
type:string,
index:not_analyzed
},
@message:{
type:string,
index:not_analyzed
},
@timestamp:{
type:date
},
@version:{
type:string,
index:not_analyzed
},
acct:{
type:string,
index:not_analyzed
},
ossec_group:{
type:string,
index:not_analyzed
},
ossec_server:{
type:string,
index:not_analyzed
},
raw_message:{
type:string,
index:analyzed
},
reporting_ip:{
type:string,
index:not_analyzed
},
reporting_source:{
type:string,
index:analyzed
},
rule_number:{
type:integer
},
severity:{
type:integer
},
signature:{
type:string,
index:not_analyzed
},
src_ip:{
type:string,
index:not_analyzed
},
geoip:{
type : object,
dynamic: true,
path: full,
properties : {
location : { type : geo_point }
}
}
},
_all:{
enabled:true
}
}
}
}
On Wed, Mar 19, 2014 at 10:54 AM, Chris H chris@gmail.comjavascript:
wrote:
Hi, Joshua.
I'm using a very similar technique. Are you applying a mapping template,
or using the default? I'm using the default automatic templates, because
frankly I don't fully understand templates. What this means though is that
my daily indexes are larger than the uncompressed alerts.log, between 2-4GB
per day, and I'm rapidly running out of disk space. I gather than this can
be optimised by enabling compression and excluding the _source and _all
fields through the mapping template, but I'm not sure exactly how this
works. Just wondered if you've come across the same problem.
Thanks.
On Saturday, March 8, 2014 10:02:35 PM UTC, Joshua Garnett wrote:
All,
I'll probably write a blog post on this, but I wanted to share some work
I've done today. http://vichargrave.com/ossec-log-management-with-
elasticsearch/ shows how to use OSSEC's syslog output to route messages
to Elasticsearch. The problem with this method is it uses UDP. Even when
sending packets to a local process UDP by definition is unreliable.
Garbage collections and other system events can cause packets to be lost.
I've found it tends to cap out at around 1,500 messages per minute
[ossec-list] Re: OSSEC Logstash
Hi, Joshua.
I'm using a very similar technique. Are you applying a mapping template,
or using the default? I'm using the default automatic templates, because
frankly I don't fully understand templates. What this means though is that
my daily indexes are larger than the uncompressed alerts.log, between 2-4GB
per day, and I'm rapidly running out of disk space. I gather than this can
be optimised by enabling compression and excluding the _source and _all
fields through the mapping template, but I'm not sure exactly how this
works. Just wondered if you've come across the same problem.
Thanks.
On Saturday, March 8, 2014 10:02:35 PM UTC, Joshua Garnett wrote:
All,
I'll probably write a blog post on this, but I wanted to share some work
I've done today.
http://vichargrave.com/ossec-log-management-with-elasticsearch/ shows how
to use OSSEC's syslog output to route messages to Elasticsearch. The
problem with this method is it uses UDP. Even when sending packets to a
local process UDP by definition is unreliable. Garbage collections and
other system events can cause packets to be lost. I've found it tends to
cap out at around 1,500 messages per minute.
To address this issue I've put together a logstash config that will read
the alerts from /var/ossec/logs/alerts/alerts.log. On top of solving the
reliability issue, it also fixes issues with multi-lines being lost, and
adds geoip lookups for the src_ip. I tested it against approximately 1GB
of alerts (3M events).
input {
file {
type = ossec
path = /var/ossec/logs/alerts/alerts.log
sincedb_path = /opt/logstash/
codec = multiline {
pattern = ^\*\*
negate = true
what = previous
}
}
}
filter {
if [type] == ossec {
# Parse the header of the alert
grok {
# Matches 2014 Mar 08 00:57:49 (some.server.com) 10.1.2.3-ossec
# (?m) fixes issues with multi-lines see
https://logstash.jira.com/browse/LOGSTASH-509
match = [message, (?m)\*\* Alert
%{DATA:timestamp_seconds}:%{SPACE}%{WORD}?%{SPACE}\-
%{DATA:ossec_group}\n%{YEAR} %{SYSLOGTIMESTAMP:syslog_timestamp}
\(%{DATA:reporting_host}\)
%{IP:reporting_ip}\-\%{DATA:reporting_source}\nRule:
%{NONNEGINT:rule_number} \(level %{NONNEGINT:severity}\) \-\
'%{DATA:signature}'\n%{GREEDYDATA:remaining_message}]
# Matches 2014 Mar 08 00:00:00 ossec-server01-/var/log/auth.log
match = [message, (?m)\*\* Alert
%{DATA:timestamp_seconds}:%{SPACE}%{WORD}?%{SPACE}\-
%{DATA:ossec_group}\n%{YEAR} %{SYSLOGTIMESTAMP:syslog_timestamp}
%{DATA:reporting_host}\-\%{DATA:reporting_source}\nRule:
%{NONNEGINT:rule_number} \(level %{NONNEGINT:severity}\) \-\
'%{DATA:signature}'\n%{GREEDYDATA:remaining_message}]
}
# Attempt to parse additional data from the alert
grok {
match = [remaining_message, (?m)(Src IP:
%{IP:src_ip}%{SPACE})?(Src Port: %{NONNEGINT:src_port}%{SPACE})?(Dst IP:
%{IP:dst_ip}%{SPACE})?(Dst Port: %{NONNEGINT:dst_port}%{SPACE})?(User:
%{USER:acct}%{SPACE})?%{GREEDYDATA:real_message}]
}
geoip {
source = src_ip
}
mutate {
convert = [ severity, integer]
replace = [ @message, %{real_message} ]
replace = [ @fields.hostname, %{reporting_host}]
add_field= [ @fields.product, ossec]
add_field= [ raw_message, %{message}]
add_field= [ ossec_server, %{host}]
remove_field = [ type, syslog_program, syslog_timestamp,
reporting_host, message, timestamp_seconds, real_message,
remaining_message, path, host, tags]
}
}
}
output {
elasticsearch {
host = 10.0.0.1
cluster = mycluster
}
}
Here are a few examples of the output this generates.
{
@timestamp:2014-03-08T20:34:08.847Z,
@version:1,
ossec_group:syslog,sshd,invalid_login,authentication_failed,,
reporting_ip:10.1.2.3,
reporting_source:/var/log/auth.log,
rule_number:5710,
severity:5,
signature:Attempt to login using a non-existent user,
src_ip:112.65.211.164,
geoip:{
ip:112.65.211.164,
country_code2:CN,
country_code3:CHN,
country_name:China,
continent_code:AS,
region_name:23,
city_name:Shanghai,
latitude:31.0456007,
longitude:121.3997,
timezone:Asia/Shanghai,
real_region_name:Shanghai,
location:[
121.3997,
31.0456007
]
},
@message:Mar 8 01:00:59 someserver sshd[22874]: Invalid user oracle
from 112.65.211.164\n,
@fields.hostname:someserver.somedomain.com,
@fields.product:ossec,
raw_message:** Alert 1394240459.2305861: -
syslog,sshd,invalid_login,authentication_failed,\n2014 Mar 08 01:00:59 (
someserver.somedomain.com) 10.1.2.3-/var/log/auth.log\nRule: 5710 (level
5) - 'Attempt to login using a non-existent user'\nSrc IP:
112.65.211.164\nMar 8 01:00:59 someserver
[ossec-list] help with regex for decoder
Hi. I'm having real problems with a regex for a decoder, and hope someone
can help. I'm trying to extract some details from Windows Event Logs from
a file server, for Object Access. Here's a sample of the logs:
WinEvtLog: Security: AUDIT_SUCCESS(560): Security: user.name: MYDOMAIN:
WIN-FS2: Object Open: Object Server: Security Object Type:
File Object Name: D:\Shares\Recruitment\Head Office\Ops Vacancies
Tracker.xlsxHandle ID: 27948Operation ID:
{3,166460974} Process ID: 4 Image File Name:Primary
User Name: WIN-FS2$ Primary Domain: 4UCORE Primary Logon ID:
(0x0,0x3E7) Client User Name: user.name Client Domain:
MYDOMAIN Client Logon ID: (0x3,0x9D2FBB5)Accesses:
%%1539%%4423 Privileges:
- Restricted Sid Count: 0 Access Mask: 0x40080
The fields I'm interested in, and that I want to use with FTS to trigger an
alert, are the user.name and Object Name. I'm good with extracting the
former with the following decoders:
decoder name=windows
typewindows/type
prematch^WinEvtLog: /prematch
/decoder
decoder name=windows-file-access
typewindows/type
parentwindows/parent
prematch offset=after_parent^\.+: (\w+)\((560)\):/prematch
regex offset=after_parent^\.+: (\w+)\((560)\): \S+: (\S+): \S+:
(\S+):/regex
orderstatus, id, user, system_name/order
/decoder
But I can't extract the Object Name. I've tried various permutations of
along the lines of:
decoder name=windows-file-access
typewindows/type
parentwindows/parent
prematch offset=after_parent^\.+: (\w+)\((560)\):/prematch
regex offset=after_parent^\.+: (\w+)\((560)\): \S+: (\S+): \S+:
(\S+):/regex
regex\.*Object Type: File\s+Object Name: (\.*) +Handle/regex
orderstatus, id, user, system_name/order
/decoder
I also have to deal with files with spaces in the name. With a fuller
regex library I'd do something like this, which works nicely because of the
non-greedy matching:
^.+: (\w+)\((560)\): \w+: (\S+): \S+: (\S+): .*Object Type: File\s+Object
Name: (.+?)\s+Handle
But I can't even get OSSEC to match on something as simple as:
regex\.*Name: (\S+)/regex
Any help would be gratefully received.
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] OSSEC and Nagios integration
could you do something with the syslog output? send the alerts you're interested in to syslog on the nagios host and tail the logs from that? Might allow you to be a bit more selective, too. On Wednesday, February 5, 2014 1:53:38 PM UTC, Michiel van Es wrote: To be more precise: this is the most valuable link I found: http://blog.kintoandar.com/2011/01/nagios-nrpe-ossec-check.html I am still interested in other peoples' implementations. Op woensdag 5 februari 2014 14:45:26 UTC+1 schreef Michiel van Es: Yes, First 3 hits about mail scripts (nagios exchange) and 'swatch alike scripts' but not a lot of specific setup information. That is why I ask it here what people use nowadays and how their setup looks like. Michiel Op woensdag 5 februari 2014 14:32:47 UTC+1 schreef Darin Perusich: Have you asked Google? -- Later, Darin On Wed, Feb 5, 2014 at 6:47 AM, Michiel van Es vanesm...@gmail.com wrote: Hello, I was wondering if someone already used the OSSEC and Nagios to generate alerts ? I have the following idea in my head: alert of level 11+ will be seen by a monitor/swatch script tailing the /var/ossec/logs/alerts/alerts.log logfile and generates an alert/trigger and sends it to Nagios. Nagios generates an alert, shows in on a dashboard. Engineer fixes the issue or filters the alert (in case of a false positive) and OK/ACK the alert in Nagios. Or has someone else a better idea how to integrate these 2 together? All tips are more then welcome! Michiel -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] OSSEC and syslog messages
Just as an FYI, after posting this I thought about my setup a bit and I've
now got logstash consuming the alerts.log directly. I'll see if this works
a bit better; at first glance it seems to. I've attached my logstash.conf.
On Wednesday, February 5, 2014 2:14:36 PM UTC, Chris H wrote:
Hi. I'm trying this setup, after seeing the blog post on ossec.netrecently,
and regularly exceeding the 500mb limit on Splunk free. I'm
sending alerts level 3+ to logstash and 5+ to splunk still. I spent a
while tweaking the logstash.conf to work with spunk format syslog output,
as it includes the groups. Was going to share when it was fully working,
but...
Not all the logs are going into logstash (or at least not going in to
elasticsearch.)
For example, we just had a bunch of alerts from our anti-virus server. In
the space of 30 seconds we had 29 events from one workstation:
** Alert 1391605348.1873086525: - trend_micro,osce,virus
2014 Feb 05 13:02:28 (AV01) 172.19.2.2-WinEvtLog
Rule: 110003 (level 5) - 'Virus detected and Quarantined'
WinEvtLog: Application: WARNING(500): Trend Micro OfficeScan Server:
SYSTEM: NT AUTHORITY: AV01.domain.co.uk: Virus/Malware: TROJ_SPNR.14AR14
Computer: D13800 Domain: Client pcs and laptops File: C:\Documents and
Settings\bob.smith\Local Settings\Temp\tmp0de3e9e7.exe Date/Time:
05/02/2014 13:02:21 Result: Quarantine
The only difference was the timestamp and the filename. All 29 events
went into Splunk, but only 1 made it into elasticsearch (not the first
event, either.) Could this be because of the syslog size limit? There are
a lot more events going into logstash because of the lower alert threshold.
How does OSSEC group alerts when sending them by syslog?
Thanks.
On Monday, January 27, 2014 1:36:19 PM UTC, dan (ddpbsd) wrote:
On Mon, Jan 27, 2014 at 8:16 AM, Michiel van Es vanesm...@gmail.com
wrote:
Hi,
Is anyone using OSSEC = syslog = Logstash = Kibana for their setup?
We found out that the netstat -tan diff ran by syscheck gives only the
first
line of the diff:
132Jan 27 11:37:43 local-machine-001 ossec: Alert Level: 7; Rule: 533
-
Listened ports status (netstat)
changed (new port opened or closed).; Location:
local-machine-001-netstat
-tan |grep LISTEN |grep -v 127.0.0.1 | sort; ossec: output:
'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort' and it does not
show
the diff output (the 2 netstat -tan outputs).
Does anyone else has this issue and if so, how did you fix it with
(r)syslog?
OSSEC 2.7.1 on Red Hat 6 64 bit (Atomic repo) and OSSEC and
Logstash/Kibana
run on 2 seperate machines.
I haven't looked into this really, but I think the syslog output is
limited to 1024(?)k (an old syslog limit). diffs wouldn't really
transfer via syslog very well anyways, so I'm not sure they'd be worth
it.
Michiel
--
---
You received this message because you are subscribed to the Google
Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
input {
file {
path = /logs/ossec/logs/alerts/alerts.log
type = ossec_alerts
}
}
filter {
if [type] == ossec_alerts {
multiline {
pattern = ^** Alert
what = previous
negate = true
}
grok {
match = { message = \nRule: (?Rule\d+) \(level
(?Alert_Level\d+)\) \- '(%{DATA:Description})'\n }
}
grok {
match = { message = \n(?event_timestamp%{YEAR} +%{MONTH}
+%{MONTHDAY} %{TIME}) \((?reporting_host.*?)\)
(?reporting_ip\d+\.\d+\.\d+\.\d+)-(?reporting_source.*?)\n }
}
grok {
match = { message = \n(?event_timestamp%{YEAR} +%{MONTH}
+%{MONTHDAY} %{TIME}) (?reporting_host[^\(\)]+)-(?reporting_source.*?)\n }
}
date {
match = [ event_timestamp, MMM dd HH:mm:ss ]
target = @timestamp
}
# groups
grok {
match = { message = ^\*\* Alert .* - +(%{DATA:OSSEC_Groups}),?\n }
}
# details
grok {
match = { message = \n(?Details[^\n]+)\n$ }
}
mutate {
add_field = [ logstash_host, %{host} ]
add_field = [ OSSEC_Group, %{OSSEC_Groups} ]
split = [ OSSEC_Group, , ]
strip = [ OSSEC_Group ]
remove_field = [ syslog_hostname, syslog_message, syslog_pid,
message, @version, type, host ]
add_tag = [ ossec ]
}
}
if ossec in [tags] {
if [Details] =~ /^WinEvtLog/ {
grok {
match = { Details =
(?Event_StatusAUDIT_\w+)\((?Event_ID\d
Re: [ossec-list] OSSEC and syslog messages
On Thursday, February 6, 2014 1:06:35 PM UTC, dan (ddpbsd) wrote: On Wed, Feb 5, 2014 at 9:14 AM, Chris H chris@gmail.com javascript: wrote: Hi. I'm trying this setup, after seeing the blog post on ossec.net recently, and regularly exceeding the 500mb limit on Splunk free. I'm sending alerts level 3+ to logstash and 5+ to splunk still. I spent a while tweaking the logstash.conf to work with spunk format syslog output, as it includes the groups. Was going to share when it was fully working, but... Not all the logs are going into logstash (or at least not going in to elasticsearch.) For example, we just had a bunch of alerts from our anti-virus server. In the space of 30 seconds we had 29 events from one workstation: ** Alert 1391605348.1873086525: - trend_micro,osce,virus 2014 Feb 05 13:02:28 (AV01) 172.19.2.2-WinEvtLog Rule: 110003 (level 5) - 'Virus detected and Quarantined' WinEvtLog: Application: WARNING(500): Trend Micro OfficeScan Server: SYSTEM: NT AUTHORITY: AV01.domain.co.uk: Virus/Malware: TROJ_SPNR.14AR14 Computer: D13800 Domain: Client pcs and laptops File: C:\Documents and Settings\bob.smith\Local Settings\Temp\tmp0de3e9e7.exe Date/Time: 05/02/2014 13:02:21 Result: Quarantine The only difference was the timestamp and the filename. All 29 events went into Splunk, but only 1 made it into elasticsearch (not the first event, either.) Could this be because of the syslog size limit? There are a lot more events going into logstash because of the lower alert threshold. How does OSSEC group alerts when sending them by syslog? When you come across an instance like this, do all (or at least 1) of the alerts get sent to logstash by ossec-csyslogd? Hi Dan. I don't whether they're being dropped by logstash, or not being posted. There's nothing in the logstash logs to indicate them being dropped. Is there a log file to indicate when a message is posted by ossec-csyslogd? My alerts.log is 2.2gb so far today, there's too much going through to be able to readily compare what's going through to what's being received. Thanks Thanks. On Monday, January 27, 2014 1:36:19 PM UTC, dan (ddpbsd) wrote: On Mon, Jan 27, 2014 at 8:16 AM, Michiel van Es vanesm...@gmail.com wrote: Hi, Is anyone using OSSEC = syslog = Logstash = Kibana for their setup? We found out that the netstat -tan diff ran by syscheck gives only the first line of the diff: 132Jan 27 11:37:43 local-machine-001 ossec: Alert Level: 7; Rule: 533 - Listened ports status (netstat) changed (new port opened or closed).; Location: local-machine-001-netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort; ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort' and it does not show the diff output (the 2 netstat -tan outputs). Does anyone else has this issue and if so, how did you fix it with (r)syslog? OSSEC 2.7.1 on Red Hat 6 64 bit (Atomic repo) and OSSEC and Logstash/Kibana run on 2 seperate machines. I haven't looked into this really, but I think the syslog output is limited to 1024(?)k (an old syslog limit). diffs wouldn't really transfer via syslog very well anyways, so I'm not sure they'd be worth it. Michiel -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] OSSEC and syslog messages
Hi. I'm trying this setup, after seeing the blog post on ossec.net recently, and regularly exceeding the 500mb limit on Splunk free. I'm sending alerts level 3+ to logstash and 5+ to splunk still. I spent a while tweaking the logstash.conf to work with spunk format syslog output, as it includes the groups. Was going to share when it was fully working, but... Not all the logs are going into logstash (or at least not going in to elasticsearch.) For example, we just had a bunch of alerts from our anti-virus server. In the space of 30 seconds we had 29 events from one workstation: ** Alert 1391605348.1873086525: - trend_micro,osce,virus 2014 Feb 05 13:02:28 (AV01) 172.19.2.2-WinEvtLog Rule: 110003 (level 5) - 'Virus detected and Quarantined' WinEvtLog: Application: WARNING(500): Trend Micro OfficeScan Server: SYSTEM: NT AUTHORITY: AV01.domain.co.uk: Virus/Malware: TROJ_SPNR.14AR14 Computer: D13800 Domain: Client pcs and laptops File: C:\Documents and Settings\bob.smith\Local Settings\Temp\tmp0de3e9e7.exe Date/Time: 05/02/2014 13:02:21 Result: Quarantine The only difference was the timestamp and the filename. All 29 events went into Splunk, but only 1 made it into elasticsearch (not the first event, either.) Could this be because of the syslog size limit? There are a lot more events going into logstash because of the lower alert threshold. How does OSSEC group alerts when sending them by syslog? Thanks. On Monday, January 27, 2014 1:36:19 PM UTC, dan (ddpbsd) wrote: On Mon, Jan 27, 2014 at 8:16 AM, Michiel van Es vanesm...@gmail.comjavascript: wrote: Hi, Is anyone using OSSEC = syslog = Logstash = Kibana for their setup? We found out that the netstat -tan diff ran by syscheck gives only the first line of the diff: 132Jan 27 11:37:43 local-machine-001 ossec: Alert Level: 7; Rule: 533 - Listened ports status (netstat) changed (new port opened or closed).; Location: local-machine-001-netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort; ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort' and it does not show the diff output (the 2 netstat -tan outputs). Does anyone else has this issue and if so, how did you fix it with (r)syslog? OSSEC 2.7.1 on Red Hat 6 64 bit (Atomic repo) and OSSEC and Logstash/Kibana run on 2 seperate machines. I haven't looked into this really, but I think the syslog output is limited to 1024(?)k (an old syslog limit). diffs wouldn't really transfer via syslog very well anyways, so I'm not sure they'd be worth it. Michiel -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Active Response Requires Agent Restarts?
All, I just recently started using Active Response. My main use case right now is to perform a firewall-drop on my ‘login’ nodes using locationdefined-agent/location. This appears to be working fine (after I realized that I couldn’t define more than 1 agent within an active-response stanza). I run into issues when I restart the OSSEC Manager. When I do that, it appears that agents are never instructed to trigger their AR until I manually restart the agents. I’ve been working around this by using agent_control -R [uid] for each login node, but that doesn’t seem very elegant. Is there a more elegant way to solve this problem? I know that it is possible to restart just select processes of the OSSEC arch without impacting things - is that the case with AR? 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/groups/opt_out.
Re: [ossec-list] Alerting on mass phishing attacks
Hi, Michael. Exchange 2003. I've got the Message Tracking logs. Thanks On Tuesday, December 17, 2013 5:32:53 PM UTC, Michael Starks wrote: On 2013-12-17 10:24, Chris H wrote: Hi. We recently experienced a mass phishing attack, and I wondered if this was something that could be detected using OSSEC. I know that I can trigger an alert based off a number of events occurring within an allotted time period, but can this be grouped somehow? For example, 100 emails with the same subject and sender received in 30 minutes. Is this possible in the rules? Thanks. What MTA are you using? -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Alerting on mass phishing attacks
Thank you. I wasn't aware of that site. I've raised an enhancement, https://bitbucket.org/jbcheng/ossec-hids/issue/64/ Hopefully there's enough information in there. On Wednesday, December 18, 2013 3:53:57 PM UTC, dan (ddpbsd) wrote: On Wed, Dec 18, 2013 at 10:29 AM, Michael Starks ossec...@michaelstarks.com javascript: wrote: On 2013-12-18 9:21, Chris H wrote: Thanks, that's kind of what I was expecting. Even same_user, or any of the other standard decoder fields might help, as they could be misused somewhat. Thanks for clarifying I think this would be pretty useful. I'll keep it in mind as we work on v3. You should create an enhancement ticket: https://bitbucket.org/jbcheng/ossec-hids/issues?status=newstatus=open I think this is a really good idea, and would love to see it in 3.0. -- --- 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Alerting on mass phishing attacks
Hi. We recently experienced a mass phishing attack, and I wondered if this was something that could be detected using OSSEC. I know that I can trigger an alert based off a number of events occurring within an allotted time period, but can this be grouped somehow? For example, 100 emails with the same subject and sender received in 30 minutes. Is this possible in the rules? Thanks. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] How to backup and restore ossec manager
I have need to backup the OSSEC manager on one Ubuntu Linux server and restore it onto a new Ubuntu Linux server. I have hundreds of agents deployed and would prefer to not have to reinstall or reconfigure every agent to talk to the new server. Is there a process to back up the OSSEC manager, all logs, essentially everything pertaining to OSSEC (version 2.6) on one server and restore it onto a new server. On the new server I have already installed OSSEC 2.6 and I plan to change the IP of the new server to that of the old so all of my agents can once again connect after the restore. Is there any documentation anyone can point me to for achieving this? 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/groups/opt_out.
Re: [ossec-list] Re: BIG PROBLEM - runaway syscheckd process
Hi guys, I'm encountering this problem on an Ubuntu 10.04 server running OSSEC 2.7.0. It even occurred after I disabled rootcheck. I do have wildcards in my syscheck directories config, but I was under the impression from the thread that that bug was fixed already, and I don't see any No such file or directory problems. Was there ever a formal bug opened for this syscheckd problem, or a patch that was added to specifically address this issue? Here's the log of cpu soft lockup error; the only error in the ossec log is a mail error that is expected since don't allow this server to mail out. Any ideas? [132944.273425] BUG: soft lockup - CPU#11 stuck for 61s! [ossec-syscheckd:1604] [132944.274714] Modules linked in: fbcon tileblit font bitblit softcursor vga16fb vgastate bonding radeon ttm psmouse drm_kms_helper drm serio_raw edac_core i2c_algo_bit edac_mce_amd i2c_piix4 joydev hpilo bnx2 power_meter lp parport usbhid hid ahci pata_atiixp cciss [132944.274714] CPU 11: [132944.274714] Modules linked in: fbcon tileblit font bitblit softcursor vga16fb vgastate bonding radeon ttm psmouse drm_kms_helper drm serio_raw edac_core i2c_algo_bit edac_mce_amd i2c_piix4 joydev hpilo bnx2 power_meter lp parport usbhid hid ahci pata_atiixp cciss [132944.274714] Pid: 1604, comm: ossec-syscheckd Not tainted 2.6.32-53-server #115-Ubuntu ProLiant DL385 G7 [132944.274714] RIP: 0010:[812c1f9d] [812c1f9d] copy_user_generic_string+0x2d/0x40 [132944.274714] RSP: 0018:880c2ccafe40 EFLAGS: 00010246 [132944.274714] RAX: 880c2ccae000 RBX: 880c2ccafe98 RCX: 0100 [132944.274714] RDX: RSI: 88002000 RDI: 7fff62731620 [132944.274714] RBP: 81013c6e R08: 880001002000 R09: 7f73a85e8700 [132944.274714] R10: 82ba700022726568 R11: 0246 R12: 88002000 [132944.274714] R13: 0800 R14: 0800 R15: [132944.274714] FS: 7f73a85e8700() GS:88084e48() knlGS: [132944.274714] CS: 0010 DS: ES: CR0: 8005003b [132944.274714] CR2: 88002000 CR3: 000c2cd75000 CR4: 06e0 [132944.274714] DR0: DR1: DR2: [132944.274714] DR3: DR6: 0ff0 DR7: 0400 [132944.274714] Call Trace: [132944.274714] [811aa150] ? read_kcore+0x250/0x360 [132944.274714] [81053ce0] ? __dequeue_entity+0x30/0x50 [132944.274714] [8101178c] ? __switch_to+0x1ac/0x320 [132944.274714] [811a9f00] ? read_kcore+0x0/0x360 [132944.274714] [8119f271] ? proc_reg_read+0x81/0xc0 [132944.274714] [81147e85] ? vfs_read+0xb5/0x1a0 [132944.274714] [81148041] ? sys_read+0x51/0x80 [132944.274714] [81013172] ? system_call_fastpath+0x16/0x1b -Chris On Monday, March 30, 2009 7:49:51 PM UTC, John A. Sullivan III wrote: Thank you, Daniel. This gives us a usable work around as we can find other options for rootkit detection. I wonder why the process checking was causing it such grief and so locked the systems that only a power cycle was able to stop the runaway process. The wildcards are great news. I see one uses sregex for ignore directives and posix wild cards for localfiles. Shall I assume these remain the same and we have added posix wild cards for directories directives? - John On Mon, 2009-03-30 at 16:35 -0300, Daniel Cid wrote: Hi John, So, for the first issue (using wildcards), you can do if you update to the latest snapshot: http://www.ossec.net/files/snapshots/ossec-hids-090330.tar.gz For the second issue, by looking at the strace output you sent and the logs, it is being caused by rootcheck (that does the rootkit detection) and not by syscheck. However, rootcheck is called from inside syscheck and that's why you are seeing the process ossec-syscheckd going crazy. If you want to disable rootcheck, just set disabled to yes under the rootcheck configuration and this problem should go away. Also, by looking at the strace, the CPU was going very high during the period of process checking, where it tries to loop through all available pids and compare the output of getpid, getpgid, getsid, proc and ps, looking for anomalies... So, it was not dead of hang . Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Mon, Mar 30, 2009 at 12:01 PM, John A. Sullivan III jsul...@opensourcedevel.com javascript: wrote: On Mon, 2009-03-30 at 08:05 -0400, John A. Sullivan III wrote: On Mon, 2009-03-30 at 07:10 -0400, John A. Sullivan III wrote: On Mon, 2009-03-30 at 07:04 -0400, John A. Sullivan III wrote: On Mon, 2009-03-30 at 06:58 -0400, John A. Sullivan III wrote: On Tue, 2009-03-24 at 11:49 -0400, John A. Sullivan III wrote: Here it is. There is another problem. My apologies for wondering why
[ossec-list] Re: release 2.7.1, Windows agents and profiles, and Server 2012
Hi. I'll have a go setting up a build environment following that guide, and see what I can come up with. I've installed the agent on Windows 2012, it works but doesn't detect OS, never mind the profile. I had a poke through the code and it looked like the OS detection routine was just missing the reference to 2012. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] release 2.7.1, Windows agents and profiles, and Server 2012
Hi, I was wondering whether the 2.7.1 release is scheduled to include a fix to support centralised agent profiles on Windows servers, or support to recognise Windows 2012? I spent a bit of time a short while ago trying to get to the bottom of it, but I couldn't get it to compile. If anyone has instructions on getting the build environment working under Win 7 (or Fedora) I'll have another go. Thanks -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ossec-list] Re: OSSEC manager redundancy
Hi Michiel. Do you have any current load-balancers that you could set up a Virtual IP on, and point the agents to the VIP? Or use something like heartbeat http://linux-ha.org/wiki/Heartbeat? I'm not sure how you'd sync the config, maybe store them on a mount from a SAN or even something like rsync to keep the secondary server up to date? Chris On Thursday, October 31, 2013 2:19:40 PM UTC, Michiel van Es wrote: Hello, I am planning to setup OSSEC 2.7 for my company for about 500+ servers and some appliances. It will be running on Red Hat 5 + 6 agents mainly. There is a company policy that one server is the same a no server at all (redundancy is a must in my company). Is it possible to create a redundant setup of 2 OSSEC managers, having the port 1514 UDP load balanced and both servers store their entries and databases/keys on a NAS or single (redundant) storage platform? Has aynone else created such a setup? I want to use rsync/bash scripting as less as possible to make the setup easy to maintain :) Michiel -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Cannot get agent profile working on windows (2nd try)
On Friday, September 27, 2013 3:39:38 PM UTC+1, Chris H wrote: On Thursday, September 26, 2013 5:25:10 PM UTC+1, Chris H wrote: On Thursday, September 26, 2013 3:49:39 PM UTC+1, dan (ddpbsd) wrote: On Thu, Sep 26, 2013 at 10:29 AM, Chris H chris@gmail.com wrote: On Thursday, September 26, 2013 2:59:08 PM UTC+1, dan (ddpbsd) wrote: On Wed, Sep 25, 2013 at 8:18 AM, Chris H chris@gmail.com wrote: An update to this. It appears that on Windows Server 2012 it agent.conf doesn't work with OS either. I get this in the log files, and it's not monitoring anything: 2013/09/25 13:16:49 ossec-agent(1702): INFO: No directory provided for syscheck to monitor. 2013/09/25 13:16:49 ossec-agent: WARN: Syscheck disabled. Thanks Look to see how OSSEC gets the OS information, and find out what 2012 gives. With that info we might be able to get it working. Thanks Dan. I presume I'm looking for something in the logs? I've enabled debug, but not seeing anything: You'd have to look in the code. Took a while to find the code :) OK, I've not done much C dev, and not for a long time, but I think it uses GetVersionEx. It identifies first based on major version; Vista an onwards are v6. Then it checks for minor version but only 0 or 1. 2012, and presumably Win8, return minor version 2; mine shows a Version of 6.2.9200, and a Name of Microsoft Windows Server 2012 Standard. Also, the code to read the agent profile seems to be in there, but I'm not sure why it's failing and showing the profile as NULL. I'll try and add some more debug code. OK, not sure whether it's me, or I've got a funny version of the code, but I can't get it to compile either under Fedora or on Windows with mingw :( Thanks 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading agent configuration. 2013/09/26 15:24:07 ossec-agent Using notify time: 600 and max time to reconnect: 1800 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading logcollector configuration. 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [sftp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dc] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dhcp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dns] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-execd: INFO: Started (pid: 4100). Thanks. On Wednesday, September 25, 2013 12:41:31 PM UTC+1, Chris H wrote: Sorry to resurrect an old thread, but is there any update to this? I'm just moving towards a centralised config, and experiencing this issue. referencing by OS or name, works, but by config-profile doesn't on Windows. I've also tried the 2.7.1 beta agent, and seeing the same issue. I don't know if it's relevant, but I'm seeing entries like this in the agent logs if I enable debug logging: 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dhcp] did not match agent config profile name [(null)] 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dns] did not match agent config profile name [(null)] Thanks On Tuesday, March 5, 2013 11:19:31 PM UTC, dan (ddpbsd) wrote: On Tue, Mar 5, 2013 at 12:49 AM, Андрей Шевченко dioer...@gmail.com wrote: Is it possible to add this functionality in a future version of ossec-agent for win? Definitely. среда, 27 февраля 2013 г., 10:11:21 UTC+6 пользователь Андрей Шевченко написал: It looks like this feature was not included in the ossec-hids/src/win32/ I have not found any changes in the win32 sources. среда, 27 февраля 2013 г., 2
Re: [ossec-list] Client.keys
Koby, If you can contact me directly I will send you what I used. On Tuesday, October 15, 2013 4:25:48 AM UTC-5, koby yakov wrote: Hi Chris, i'm facing with the same issue that you were having here, my current status is: i'm abling to install the agents on the windows machine, copy the conf file and create the agents on the server side. i need your assistence with extracting the keys from the server side and insert each key to each agent. i would appriciate if you could share your codes (scripts and other staff). thanks a lot koby. On Friday, September 27, 2013 9:25:42 PM UTC+3, Chris Lauritzen wrote: As a follow up: Only to find out there is a 1500 record limit in each instance OSSEC. On Friday, September 27, 2013 10:11:33 AM UTC-5, Chris Lauritzen wrote: In a nut shell: Auto populate the keys on the server. Copy the key files to a windows Pc and using a excel batch file it extracted each key to a txt file name with the PC name. I then used a batch to copy the file from the share based on the the computer name and and then renamed the file to client.keys. Then using LANDesk to push out the agent and run the batch installer. Using this method I installed the agent on 3486 pc in 10 minutes. On Thursday, September 26, 2013 5:12:00 PM UTC-5, Michael Starks wrote: On 26.09.2013 16:40, Chris Lauritzen wrote: Thank you everyone for your help. I have resolved my issue and have pushed out the agent to 3500 PC's today in just over an hour. Inquiring minds want to know! :) -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Cannot get agent profile working on windows (2nd try)
On Thursday, September 26, 2013 5:25:10 PM UTC+1, Chris H wrote: On Thursday, September 26, 2013 3:49:39 PM UTC+1, dan (ddpbsd) wrote: On Thu, Sep 26, 2013 at 10:29 AM, Chris H chris@gmail.com wrote: On Thursday, September 26, 2013 2:59:08 PM UTC+1, dan (ddpbsd) wrote: On Wed, Sep 25, 2013 at 8:18 AM, Chris H chris@gmail.com wrote: An update to this. It appears that on Windows Server 2012 it agent.conf doesn't work with OS either. I get this in the log files, and it's not monitoring anything: 2013/09/25 13:16:49 ossec-agent(1702): INFO: No directory provided for syscheck to monitor. 2013/09/25 13:16:49 ossec-agent: WARN: Syscheck disabled. Thanks Look to see how OSSEC gets the OS information, and find out what 2012 gives. With that info we might be able to get it working. Thanks Dan. I presume I'm looking for something in the logs? I've enabled debug, but not seeing anything: You'd have to look in the code. Took a while to find the code :) OK, I've not done much C dev, and not for a long time, but I think it uses GetVersionEx. It identifies first based on major version; Vista an onwards are v6. Then it checks for minor version but only 0 or 1. 2012, and presumably Win8, return minor version 2; mine shows a Version of 6.2.9200, and a Name of Microsoft Windows Server 2012 Standard. Also, the code to read the agent profile seems to be in there, but I'm not sure why it's failing and showing the profile as NULL. I'll try and add some more debug code. OK, not sure whether it's me, or I've got a funny version of the code, but I can't get it to compile either under Fedora or on Windows with mingw :( Thanks 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading agent configuration. 2013/09/26 15:24:07 ossec-agent Using notify time: 600 and max time to reconnect: 1800 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading logcollector configuration. 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [sftp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dc] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dhcp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dns] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-execd: INFO: Started (pid: 4100). Thanks. On Wednesday, September 25, 2013 12:41:31 PM UTC+1, Chris H wrote: Sorry to resurrect an old thread, but is there any update to this? I'm just moving towards a centralised config, and experiencing this issue. referencing by OS or name, works, but by config-profile doesn't on Windows. I've also tried the 2.7.1 beta agent, and seeing the same issue. I don't know if it's relevant, but I'm seeing entries like this in the agent logs if I enable debug logging: 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dhcp] did not match agent config profile name [(null)] 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dns] did not match agent config profile name [(null)] Thanks On Tuesday, March 5, 2013 11:19:31 PM UTC, dan (ddpbsd) wrote: On Tue, Mar 5, 2013 at 12:49 AM, Андрей Шевченко dioer...@gmail.com wrote: Is it possible to add this functionality in a future version of ossec-agent for win? Definitely. среда, 27 февраля 2013 г., 10:11:21 UTC+6 пользователь Андрей Шевченко написал: It looks like this feature was not included in the ossec-hids/src/win32/ I have not found any changes in the win32 sources. среда, 27 февраля 2013 г., 2:01:56 UTC+6 пользователь dan (ddpbsd) написал: On Thu
Re: [ossec-list] Client.keys
In a nut shell: Auto populate the keys on the server. Copy the key files to a windows Pc and using a excel batch file it extracted each key to a txt file name with the PC name. I then used a batch to copy the file from the share based on the the computer name and and then renamed the file to client.keys. Then using LANDesk to push out the agent and run the batch installer. Using this method I installed the agent on 3486 pc in 10 minutes. On Thursday, September 26, 2013 5:12:00 PM UTC-5, Michael Starks wrote: On 26.09.2013 16:40, Chris Lauritzen wrote: Thank you everyone for your help. I have resolved my issue and have pushed out the agent to 3500 PC's today in just over an hour. Inquiring minds want to know! :) -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Client.keys
As a follow up: Only to find out there is a 1500 record limit in each instance OSSEC. On Friday, September 27, 2013 10:11:33 AM UTC-5, Chris Lauritzen wrote: In a nut shell: Auto populate the keys on the server. Copy the key files to a windows Pc and using a excel batch file it extracted each key to a txt file name with the PC name. I then used a batch to copy the file from the share based on the the computer name and and then renamed the file to client.keys. Then using LANDesk to push out the agent and run the batch installer. Using this method I installed the agent on 3486 pc in 10 minutes. On Thursday, September 26, 2013 5:12:00 PM UTC-5, Michael Starks wrote: On 26.09.2013 16:40, Chris Lauritzen wrote: Thank you everyone for your help. I have resolved my issue and have pushed out the agent to 3500 PC's today in just over an hour. Inquiring minds want to know! :) -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ossec-list] Cannot get agent profile working on windows (2nd try)
On Thursday, September 26, 2013 2:59:08 PM UTC+1, dan (ddpbsd) wrote: On Wed, Sep 25, 2013 at 8:18 AM, Chris H chris@gmail.comjavascript: wrote: An update to this. It appears that on Windows Server 2012 it agent.conf doesn't work with OS either. I get this in the log files, and it's not monitoring anything: 2013/09/25 13:16:49 ossec-agent(1702): INFO: No directory provided for syscheck to monitor. 2013/09/25 13:16:49 ossec-agent: WARN: Syscheck disabled. Thanks Look to see how OSSEC gets the OS information, and find out what 2012 gives. With that info we might be able to get it working. Thanks Dan. I presume I'm looking for something in the logs? I've enabled debug, but not seeing anything: 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading agent configuration. 2013/09/26 15:24:07 ossec-agent Using notify time: 600 and max time to reconnect: 1800 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading logcollector configuration. 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [sftp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dc] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dhcp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dns] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-execd: INFO: Started (pid: 4100). Thanks. On Wednesday, September 25, 2013 12:41:31 PM UTC+1, Chris H wrote: Sorry to resurrect an old thread, but is there any update to this? I'm just moving towards a centralised config, and experiencing this issue. referencing by OS or name, works, but by config-profile doesn't on Windows. I've also tried the 2.7.1 beta agent, and seeing the same issue. I don't know if it's relevant, but I'm seeing entries like this in the agent logs if I enable debug logging: 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dhcp] did not match agent config profile name [(null)] 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dns] did not match agent config profile name [(null)] Thanks On Tuesday, March 5, 2013 11:19:31 PM UTC, dan (ddpbsd) wrote: On Tue, Mar 5, 2013 at 12:49 AM, Андрей Шевченко dioer...@gmail.com wrote: Is it possible to add this functionality in a future version of ossec-agent for win? Definitely. среда, 27 февраля 2013 г., 10:11:21 UTC+6 пользователь Андрей Шевченко написал: It looks like this feature was not included in the ossec-hids/src/win32/ I have not found any changes in the win32 sources. среда, 27 февраля 2013 г., 2:01:56 UTC+6 пользователь dan (ddpbsd) написал: On Thu, Feb 21, 2013 at 6:38 AM, Андрей Шевченко dioer...@gmail.com wrote: I tried to add a bad option and i see that it is not being picked up... Like in my example, i don't see anything related to options in specific agent profile. You could check the code repository to see if the commits enabling this functionality for unixy systems also enabled it for Windows. вторник, 19 февраля 2013 г., 23:15:44 UTC+6 пользователь dan (ddpbsd) написал: On Mon, Feb 18, 2013 at 6:23 AM, Андрей Шевченко dioer...@gmail.com wrote: osssec.conf(agent test_PC): ossec_config client config-profiletest1/config-profile server-ip1.1.1.1/server-ip /client active-response disabledno/disabled /active-response /ossec_config agent.conf(server): agent_config name=test_PC syscheck directories check_all=yesD://directories /syscheck /agent_config agent_config profile=test1
Re: [ossec-list] Cannot get agent profile working on windows (2nd try)
On Thursday, September 26, 2013 3:49:39 PM UTC+1, dan (ddpbsd) wrote: On Thu, Sep 26, 2013 at 10:29 AM, Chris H chris@gmail.comjavascript: wrote: On Thursday, September 26, 2013 2:59:08 PM UTC+1, dan (ddpbsd) wrote: On Wed, Sep 25, 2013 at 8:18 AM, Chris H chris@gmail.com wrote: An update to this. It appears that on Windows Server 2012 it agent.conf doesn't work with OS either. I get this in the log files, and it's not monitoring anything: 2013/09/25 13:16:49 ossec-agent(1702): INFO: No directory provided for syscheck to monitor. 2013/09/25 13:16:49 ossec-agent: WARN: Syscheck disabled. Thanks Look to see how OSSEC gets the OS information, and find out what 2012 gives. With that info we might be able to get it working. Thanks Dan. I presume I'm looking for something in the logs? I've enabled debug, but not seeing anything: You'd have to look in the code. Took a while to find the code :) OK, I've not done much C dev, and not for a long time, but I think it uses GetVersionEx. It identifies first based on major version; Vista an onwards are v6. Then it checks for minor version but only 0 or 1. 2012, and presumably Win8, return minor version 2; mine shows a Version of 6.2.9200, and a Name of Microsoft Windows Server 2012 Standard. Also, the code to read the agent profile seems to be in there, but I'm not sure why it's failing and showing the profile as NULL. I'll try and add some more debug code. Thanks 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading agent configuration. 2013/09/26 15:24:07 ossec-agent Using notify time: 600 and max time to reconnect: 1800 2013/09/26 15:24:07 ossec-agent: DEBUG: Reading logcollector configuration. 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [sftp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dc] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dhcp] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_profile(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_profile() = [(null)] 2013/09/26 15:24:07 Read agent config profile name [(null)] 2013/09/26 15:24:07 [dns] did not match agent config profile name [(null)] 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-agent: calling os_read_agent_name(). 2013/09/26 15:24:07 ossec-agent: os_read_agent_name returned (W-DC-01 ). 2013/09/26 15:24:07 ossec-execd: INFO: Started (pid: 4100). Thanks. On Wednesday, September 25, 2013 12:41:31 PM UTC+1, Chris H wrote: Sorry to resurrect an old thread, but is there any update to this? I'm just moving towards a centralised config, and experiencing this issue. referencing by OS or name, works, but by config-profile doesn't on Windows. I've also tried the 2.7.1 beta agent, and seeing the same issue. I don't know if it's relevant, but I'm seeing entries like this in the agent logs if I enable debug logging: 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dhcp] did not match agent config profile name [(null)] 2013/09/25 12:40:07 Read agent config profile name [(null)] 2013/09/25 12:40:07 [dns] did not match agent config profile name [(null)] Thanks On Tuesday, March 5, 2013 11:19:31 PM UTC, dan (ddpbsd) wrote: On Tue, Mar 5, 2013 at 12:49 AM, Андрей Шевченко dioer...@gmail.com wrote: Is it possible to add this functionality in a future version of ossec-agent for win? Definitely. среда, 27 февраля 2013 г., 10:11:21 UTC+6 пользователь Андрей Шевченко написал: It looks like this feature was not included in the ossec-hids/src/win32/ I have not found any changes in the win32 sources. среда, 27 февраля 2013 г., 2:01:56 UTC+6 пользователь dan (ddpbsd) написал: On Thu, Feb 21, 2013 at 6:38 AM, Андрей Шевченко dioer...@gmail.com wrote: I tried to add a bad option and i see that it is not being picked up... Like in my example, i don't see anything
Re: [ossec-list] Client.keys
Thank you everyone for your help. I have resolved my issue and have pushed out the agent to 3500 PC's today in just over an hour. -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
