Re: [ossec-list] Linux processes monitoring through ossec

[Jesus Linares]

Hi,

you can find information about auditd and OSSEC 
here: 
https://documentation.wazuh.com/current/user-manual/capabilities/system-calls-monitoring/index.html

Regards.

On Monday, July 24, 2017 at 1:50:10 PM UTC+2, thefergus wrote:
>
>
> On Fri, 21 Jul 2017 at 08:06,  wrote:
>
> I am new to ossec. I would like to monitor process through ossec. My plan 
>> is need to get the notification if some one start any new process or 
>> stop/kill any process.
>> Can some one help me
>>
>
> auditd logging execve. You can also have it log file access and metadata 
> updates.
>
> kmw
>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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] Linux processes monitoring through ossec

[Jesus Linares]

Hi,

check out this 
post: 
http://santi-bassett.blogspot.com.es/2015/08/how-to-monitor-running-processes-with-ossec.html

I hope it helps.


On Saturday, July 22, 2017 at 3:03:25 AM UTC+2, CEH wrote:
>
> Check Nagios for process monitoring
>
> On 22-Jul-2017 02:54, "dan (ddp)"  wrote:
>
> On Fri, Jul 21, 2017 at 5:27 AM,   
> wrote:
> > Hi all,
> >
> > I am new to ossec. I would like to monitor process through ossec. My 
> plan is
> > need to get the notification if some one start any new process or 
> stop/kill
> > any process.
> > Can some one help me
> >
>
> If there is a way to log all processes that are started, you could
> configure OSSEC to read that log. Then create alerts or whatnot for
> the entries.
> Or, you could do a full_command with some `ps` wizardry.
>
> > 
> > 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 .
> > 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.

Re: [ossec-list] Re: Email alerts are sent hourly

[Jesus Linares]

Finally, you got it!.

I think your conclusion makes sense.

Regards.


On Wednesday, July 12, 2017 at 7:49:36 PM UTC+2, Alexis Lessard wrote:
>
> The issue was indeed the email_maxperhour setting. My guess is, because we 
> basically told OSSEC to send every event to noreply@localhost. The default 
> threshold was reached pretty quickly, so all events until the threshold was 
> reach until the end of the hour were sent back to us in a big email. We 
> changed that setting to its maximum value, , and now we receive all 
> alerte we specified we wanted (altough now we might have some tweaking to 
> do in our local_rules to adjust it to our needs), but at least, it works!
>
> tl;dr: Ensure that the email_maxperhour setting in the global config is 
> set to an appropriate value. Default is 12.
>
> 2017-07-12 7:26 GMT-04:00 Jesus Linares <je...@wazuh.com >:
>
>> Hi Alexis,
>>
>> So, you are receiving alert with level 3 in ourservice@domain, right?. 
>> That doesn't make sense (I understand that email1, email2 or email3 is not 
>> ourservice@domain).
>>
>> Try to use: do_not_delay and do_not_group. Also, the email_maxperhour 
>> <https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/global.html?highlight=email_maxperhour#email-maxperhour>is
>>  
>> 12 by default, maybe you should change it.
>>
>> In order to simplify the debug process, use only 1 custom email alert.
>>
>> Also, you can use the report settings 
>> <https://documentation.wazuh.com/current/user-manual/manager/output-options/manual-email-report/index.html>
>>  
>> instead of the email settings.
>>
>> OSSEC emails options aren't that good...
>>
>>
>>
>> On Tuesday, July 11, 2017 at 10:27:41 PM UTC+2, Alexis Lessard wrote:
>>>
>>> Thanks for the tip! We tested it, but it doesn't seem to be working. 
>>> Here's what the configuration looks like now:
>>>   
>>> yes
>>> noreply@localhost
>>> smtpserver
>>> ossec@domain
>>>   
>>>
>>>   
>>> email1
>>> email2
>>> email3
>>> several, agents, name
>>>   
>>>
>>>   
>>> ourservice@domain
>>> 9
>>> 
>>> 
>>>   
>>>
>>>
>>> *email_alert_level *was also set to 1. We received one level 10 alert 
>>> email by itself. However, there were several others level 10 alerts that we 
>>> didn't receive any notifications from, even tough they appear in the alert 
>>> log. We then received an email report in ourservice@domain mailbox of about 
>>> 10 minutes worth of  events, with several level 10 alerts in it, but mostly 
>>> a lot of alerts we have no need for, like
>>> Rule: 31101 fired (level 5) -> "Web server 400 error code." 
>>>
>>> I don't think that there's anything in my config that would justify 
>>> alerts of level 3 and 5 being sent. Do you know what could be wrong? We 
>>> will probably go back to having an email_alert_level of 7 with no custom 
>>> alerts and work from there. We receive a lot of events to this server; I'd 
>>> say about one every two or three seconds. Could that be a problem?
>>>
>>> Thanks you for the reply, I'll be sure to keep you updated to document 
>>> the issue if anyone else has that problem,
>>>
>>> -- 
>>
>> --- 
>> 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/7gS_5wxiI8M/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] Re: Email alerts are sent hourly

[Jesus Linares]

Hi Alexis,

So, you are receiving alert with level 3 in ourservice@domain, right?. That 
doesn't make sense (I understand that email1, email2 or email3 is not 
ourservice@domain).

Try to use: do_not_delay and do_not_group. Also, the email_maxperhour 
is
 
12 by default, maybe you should change it.

In order to simplify the debug process, use only 1 custom email alert.

Also, you can use the report settings 

 
instead of the email settings.

OSSEC emails options aren't that good...



On Tuesday, July 11, 2017 at 10:27:41 PM UTC+2, Alexis Lessard wrote:
>
> Thanks for the tip! We tested it, but it doesn't seem to be working. 
> Here's what the configuration looks like now:
>   
> yes
> noreply@localhost
> smtpserver
> ossec@domain
>   
>
>   
> email1
> email2
> email3
> several, agents, name
>   
>
>   
> ourservice@domain
> 9
> 
> 
>   
>
>
> *email_alert_level *was also set to 1. We received one level 10 alert 
> email by itself. However, there were several others level 10 alerts that we 
> didn't receive any notifications from, even tough they appear in the alert 
> log. We then received an email report in ourservice@domain mailbox of about 
> 10 minutes worth of  events, with several level 10 alerts in it, but mostly 
> a lot of alerts we have no need for, like
> Rule: 31101 fired (level 5) -> "Web server 400 error code." 
>
> I don't think that there's anything in my config that would justify alerts 
> of level 3 and 5 being sent. Do you know what could be wrong? We will 
> probably go back to having an email_alert_level of 7 with no custom alerts 
> and work from there. We receive a lot of events to this server; I'd say 
> about one every two or three seconds. Could that be a problem?
>
> Thanks you for the reply, I'll be sure to keep you updated to document the 
> issue if anyone else has that problem,
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: ossec blocked all ips? everywhere?

[Jesus Linares]

In case that you want to block all connections, you can create an active 
response script to add a specific rule in iptables.

On Wednesday, July 12, 2017 at 1:03:01 PM UTC+2, Jesus Linares wrote:
>
> I think, by default, OSSEC has the active-response for blocking an IP if 
> an alert higher than 6 is fired. I recommend to disable this setting.
>
> Regards.
>
>
>
> On Tuesday, July 11, 2017 at 8:37:21 PM UTC+2, Cristian Lorenzetto wrote:
>>
>> is there a condition where ossec blocks all incoming connections?
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: ossec blocked all ips? everywhere?

[Jesus Linares]

I think, by default, OSSEC has the active-response for blocking an IP if an 
alert higher than 6 is fired. I recommend to disable this setting.

Regards.



On Tuesday, July 11, 2017 at 8:37:21 PM UTC+2, Cristian Lorenzetto wrote:
>
> is there a condition where ossec blocks all incoming connections?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Email alerts are sent hourly

[Jesus Linares]

Hi Alexis,

I'm not sure about what it is happening. Do a simple test. Set 
*email_alert_level 
*to 1, and configure only one custom alert:


yes
noreply@localhost
smtpserver
*email1*
  


  
*email2*
10


  

Generate an alert with level 10, you will receive:

   - all alerts in email1 (including alerts with level 10)
   - alerts with level 10 in email2
   

That is the theory.
I hope it helps.

Regards.

On Monday, July 10, 2017 at 8:35:26 PM UTC+2, Alexis Lessard wrote:
>
> Hi!
> We are trying to configure more effective notifications for OSSEC for our 
> needs. However, something weird is happening. An hourly report of ALL 
> alerts is being sent to one adress in our config. Here's the email 
> configuration of our ossec.conf file:
>
>  
> yes
> noreply@localhost
> smtpserver
> os...@domain.com 
>   
>
>   
> email1
> email2
> email3
> several, agents, name
>   
>
>   
> our...@domain.com 
> 9
>   
>
>   
> email4
> 10
> 
> 
>   
>
>   
> our...@domain.com 
> 6
> attack
>   
>
>   
> 10100
> our...@domain.com 
>   
>
>
> Basically, here's what I'd like OSSEC to do:
>
>- Send an email for every level 9 or higher alert
>- Send an email for every matchd rule from the attack group of level 6 
>or higher
>- Send an email for the rule 10100 wich shows when a user is logged 
>for the first time.
>- The other rules are for user specific needs. 
>
> I modified the email for this example, but in the file, they are your 
> usual name@domain format. We send every alert to noreply@localhost because 
> we want to control everything with custom alerts. The email_alert_level is 
> set to 0, so every alert is supposed to be sent to this adress. But no 
> alert of a level 3 should be sent to our email box, right? Yet we receive 
> every alerts at the same time (in the same email) every hour, It is being 
> sent at the our...@domain.com  as well as email4 . Am I 
> doing something wrong here? Can OSSEC behave the way I want it to do?
>
> Thanks for the 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.

[ossec-list] Re: OSSEC log analysis settings for apache access/error.log

[Jesus Linares]

Hi Kazim,


   - Review the ossec.log of your agent: is it monitoring the file? are 
   there errors?.
   - The log file must exist before OSSEC is started.
   - Try with the format "syslog".
   - Copy some logs to /var/ossec/bin/ossec-logtest and check if an alert 
   would be generated.

Just some ideas.

I hope it helps.
Regards.

On Friday, July 7, 2017 at 10:15:02 AM UTC+2, Kazim Koybasi wrote:
>
> Yes OSSEC mentioning about log files and says analyzing log file. I tried 
> with apache log format and without logformat settings and results is 
> same.What could be a workaround for that?
>
> On Thursday, 6 July 2017 23:37:55 UTC+3, Kazim Koybasi wrote:
>>
>> I added config below to etc/shared/agent.conf in ossec-server home 
>> directory but there is no alerts in server.What could I need with this 
>> configuration?
>>
>>
>> 
>> 
>> apache
>> /var/log/httpd/site/site_log
>> 
>> 
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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] What is the best method to augment an existing decoder?

[Jesus Linares]

Hi Ian,

change the decoders could be a harmful process. Keep in mind that if you 
change something in /var/ossec/rules, it will be overwritten during an 
update.

Wazuh has created the *decoder_exclude* to simulate the *overwrite *option 
existing in rules but not in decoders. Take a look at the 
documentation: 
https://documentation.wazuh.com/current/user-manual/ruleset/custom.html. 
There are 3 scenarios:

   - Adding new decoders and rules
   - Changing an existing rule
   - Changing an existing decoder

I hope it helps.
Regards.

On Friday, July 7, 2017 at 3:55:18 AM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, Jul 6, 2017 at 9:52 PM, Ian Brown  
> wrote: 
> > Dan, 
> > 
> > Apparently it isn't compatible: 
> > 
> > ../bin/ossec-logtest -v 
> > 2017/07/07 01:50:33 ossec-analysisd: Invalid element 'accumulate' for 
> > decoder 'decoder' 
> > 2017/07/07 01:50:33 ossec-testrule(1202): ERROR: Configuration error at 
> > '/etc/decoder.xml'. Exiting. 
> > 
>
> Good to know. 
> You could try taking the windows decoders out of the newer decoder.xml 
> file, but that might be a lot of work for little benefit. 
>
> > 
> > 
> > On 7/6/2017 6:48 PM, dan (ddp) wrote: 
> >> 
> >> On Thu, Jul 6, 2017 at 9:08 PM, Ian Brown  > wrote: 
> >>> 
> >>> Dan, 
> >>> 
> >>> It's what comes in SecurityOnion's latest iso 
> >>> (securityonion-14.04.5.2.iso). 
> >>> 
> >>> ./ossec-logtest -V 
> >>> 
> >>> OSSEC HIDS v2.8 - Trend Micro Inc. 
> >>> 
> >>> This program is free software; you can redistribute it and/or modify 
> >>> it under the terms of the GNU General Public License (version 2) as 
> >>> published by the Free Software Foundation. For more details, go to 
> >>> http://www.ossec.net/main/license/ 
> >>> 
> >>> I tried "apt-file search /var/ossec/bin/ossec-logtest" to see if a 
> >>> package 
> >>> owns it, but that program returned no results, so I'm going to assume 
> it 
> >>> has 
> >>> been compiled from source. 
> >>> 
> >> 2.8 is good enough info. I don't have anything that old to test 
> >> unfortunately. 
> >> You could backup your decoder.xml and local_decoder.xml files and 
> >> download the latest decoders. 
> >> I think they should be compatible, and you can test them quickly with 
> >> ossec-logtest without restarting OSSEC. 
> >> 
> >>> 
> >>> On 7/6/2017 5:47 PM, dan (ddp) wrote: 
>  
>  On Wed, Jul 5, 2017 at 10:26 PM, Ian Brown  > wrote: 
> > 
> > Dan, that matches for the source and destination IP addresses, but 
> if I 
> > understand logtest's "Phase 2" output correctly, using those 
> additional 
> > decoders drops all the other things that the original windows 
> decoder 
> > found: 
> > 
> > --- 
> > 
> > # ./ossec-logtest -v 
> > 2017/07/06 02:19:12 ossec-testrule: INFO: Reading local decoder 
> file. 
> > 2017/07/06 02:19:12 ossec-testrule: INFO: Started (pid: 4227). 
> > ossec-testrule: Type one log per line. 
> > 
> > 2017 Jul 03 11:17:37 WinEvtLog: Security: AUDIT_FAILURE(5152): 
> > Microsoft-Windows-Security-Auditing: (no user): no domain: 
> workstation: 
> > The 
> > Windows Filtering Platform blocked a packet. Application 
> Information: 
> > Process ID: 0 Application Name: - Network Information: Direction: 
> > %%14592 
> > Source Address: 1.2.3.4 Source Port: 143 Destination Address: 
> 5.6.7.8 
> > Destination Port: 2619 Protocol: 6 Filter Information: Filter 
> Run-Time 
> > ID: 
> > 93069 Layer Name: %%14597 Layer Run-Time ID: 13 
> > 
> > 
> > **Phase 1: Completed pre-decoding. 
> >  full event: '2017 Jul 03 11:17:37 WinEvtLog: Security: 
> > AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): 
> no 
> > domain: workstation: The Windows Filtering Platform blocked a 
> packet. 
> > Application Information: Process ID: 0 Application Name: - Network 
> > Information: Direction: %%14592 Source Address: 1.2.3.4 Source Port: 
> > 143 
> > Destination Address: 5.6.7.8 Destination Port: 2619 Protocol: 6 
> Filter 
> > Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer 
> > Run-Time 
> > ID: 13' 
> >  hostname: 'securityonion' 
> >  program_name: '(null)' 
> >  log: '2017 Jul 03 11:17:37 WinEvtLog: Security: 
> > AUDIT_FAILURE(5152): 
> > Microsoft-Windows-Security-Auditing: (no user): no domain: 
> workstation: 
> > The 
> > Windows Filtering Platform blocked a packet. Application 
> Information: 
> > Process ID: 0 Application Name: - Network Information: Direction: 
> > %%14592 
> > Source Address: 1.2.3.4 Source Port: 143 Destination Address: 
> 5.6.7.8 
> > Destination Port: 2619 Protocol: 6 Filter Information: Filter 
> Run-Time 
> > ID: 
> > 93069 Layer Name: %%14597 Layer Run-Time ID: 13' 
> > 
> > **Phase 2: Completed decoding. 
> 

Re: [ossec-list] Re: I'm unclear why my rule is not matching...

[Jesus Linares]

Hi Ian,

Here you have the syntax of the OSSEC 
regexs: 
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html

 Another difference I've discovered is that Perl's regex is greedy -- 
> it'll match all it can. It looks like this regex will only match the 
> least number of characters it can


I think OSSEC regexs are greedy too, at least sometimes.

Our regex is weird. 

Totally agree.

Regards. 


On Friday, July 7, 2017 at 2:49:39 AM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Jul 5, 2017 at 10:41 PM, Ian Brown  > wrote: 
> > Dan, 
> > 
> > All my regex experience comes from Perl.  It's clear this regex does 
> things 
> > a bit differently than how I expected.  In Perl \.+ means only match 1 
> or 
> > more periods. 
> > 
> > Another difference I've discovered is that Perl's regex is greedy -- 
> it'll 
> > match all it can. It looks like this regex will only match the least 
> number 
> > of characters it can. If I understand the difference correctly, \.+ in 
> this 
> > regex would be .+? in Perl. 
> > 
> > In Perl, [0-9A-Fx]+ means match one or more from the following set: 0 
> > through 9, A through F and x.  I guess that's done differently here.  :) 
> > 
> > Thanks for helping me understand this better. 
> > 
>
> Our regex is weird. 
>
> > 
> > On 7/5/2017 6:45 PM, dan (ddp) wrote: 
> >> 
> >> On Mon, Jul 3, 2017 at 11:28 AM, Ian Brown  > wrote: 
> >>> 
> >>> I believe I've figured it out -- I think the decoder isn't matching 
> the 
> >>> full 
> >>> log string and is thus stripping the ip address information.  Also 
> after 
> >>> looking at the regex in the decoder, I've discovered that it doesn't 
> even 
> >>> match against the first three example strings provided: 
> >>> 
> >>> Here's an example from the comments (After prematch): 
> >>> Security: AUDIT_FAILURE(0x02A9): Security: SYSTEM: NT AUTHORITY: 
> The 
> >>> logon to account: xyz by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from 
> >>> workstation: la failed. The error code was: 3221225572 
> >>> 
> >>> yet, the regex is: 
> >>> ^\.+: (\w+)\((\d+)\): (\.+): 
> >>> 
> >>> The second (\d+) will only match against numbers, so (0x02A9) will 
> >>> never 
> >>> match.  It should be ([0-9A-Fx]+) 
> >> 
> >> I don't think this does what you want it to. But dealing with the hex 
> >> might be an issue we'll have to look into. 
> >> 
> >>> Also, why is it escaping the period at the beginning and at the end? 
> >>> shouldn't the regex be: 
> >>> ^.+: (\w+)\((\d+)\): (.+): 
> >>> 
> >> Not if you want to match any character, that should only match '.'. 
> >> 
> >>> -- 
> >>> 
> >>> --- 
> >>> You received this message because you are subscribed 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.

Re: [ossec-list] OSSEC rule match time and timeframe

[Jesus Linares]

I never used 
it: 
http://ossec-docs.readthedocs.io/en/latest/syntax/head_rules.html#element-time

I think is the time when the event comes to the manager (not the original 
time).

On Thursday, July 6, 2017 at 3:46:49 AM UTC+2, dan (ddpbsd) wrote:
>
> On Mon, Jul 3, 2017 at 6:10 AM, Fredrik Hilmersson 
>  wrote: 
> > Hello, 
> > 
> > Lets say I have a script which runs once every half an hour. With a 
> latency 
> > difference in about 10-20 seconds. 
> > Would it be possible to match the following: 
> > 
> > 1. Time 
> > 2. Hostname 
> > 3. Username 
> > 
> > The reason I prefer more than a single match, i.e only time is to not by 
> > mistake miss an actual event. 
> > 
> >  
> > 
> >  5501 
> >  **:30 
> > 
> >  agent-hostname 
> >  ssh-user 
> > 
> >  no_email_alert 
> > 
> >  Ignore rule 5501 for host  
> > 
> >  
> > 
>
> Where do you plan on getting the time from? The timestamp in the logs 
> are stripped off and not evaluated. 
>
> > 
> > Kind regards, 
> > Fredrik 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] Re: I'm unclear why my rule is not matching...

[Jesus Linares]

Hi Ian,

try this rule:


  

  
18105
192.168.1.120
ignore 192.168.1.120.
  



ossec-logtest:
2017 Jul 02 22:38:47 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-
Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows 
Filtering Platform blocked a packet. Application Information: Process ID: 0 
Application Name: - Network Information: Direction: %%14592 Source Address: 
192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 
Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 
93069 Layer Name: %%14597 Layer Run-Time ID: 13




**Phase 1: Completed pre-decoding.
   full event: '2017 Jul 02 22:38:47 WinEvtLog: Security: 
AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no 
domain: leaf-1: The Windows Filtering Platform blocked a packet. 
Application Information: Process ID: 0 Application Name: - Network 
Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 
39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 
17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer 
Run-Time ID: 13'
   hostname: 'ip-10-0-0-10'
   program_name: 'WinEvtLog'
   log: 'Security: AUDIT_FAILURE(5152): 
Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The 
Windows Filtering Platform blocked a packet. Application Information: 
Process ID: 0 Application Name: - Network Information: Direction: %%14592 
Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 
192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: 
Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13'


**Phase 2: Completed decoding.
   decoder: 'windows'
   status: 'AUDIT_FAILURE'
   id: '5152'
   extra_data: 'Microsoft-Windows-Security-Auditing'
   dstuser: '(no user)'
   system_name: 'leaf-1'


**Phase 3: Completed filtering (rules).
   Rule id: '11'
   Level: '0'
   Description: 'ignore 192.168.1.120.'


I hope it helps.


On Monday, July 3, 2017 at 5:28:04 PM UTC+2, Ian Brown wrote:
>
> I believe I've figured it out -- I think the decoder isn't matching the 
> full log string and is thus stripping the ip address information.  Also 
> after looking at the regex in the decoder, I've discovered that it doesn't 
> even match against the first three example strings provided:
>
> Here's an example from the comments (After prematch):
> Security: AUDIT_FAILURE(0x02A9): Security: SYSTEM: NT AUTHORITY: The 
> logon to account: xyz by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from 
> workstation: la failed. The error code was: 3221225572
>
> yet, the regex is:
> ^\.+: (\w+)\((\d+)\): (\.+): 
>
> The second (\d+) will only match against numbers, so (0x02A9) will 
> never match.  It should be ([0-9A-Fx]+)
>
> Also, why is it escaping the period at the beginning and at the end? 
>  shouldn't the regex be:
> ^.+: (\w+)\((\d+)\): (.+):
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: OSSEC rule match time and timeframe

[Jesus Linares]

Hi Fredrik,

do you want to ignore the rule 5501 if it is fired by your script?. is it 
not enough with the hostname and the user?.

Regards.

On Monday, July 3, 2017 at 12:10:18 PM UTC+2, Fredrik Hilmersson wrote:
>
> Hello,
>
> Lets say I have a script which runs once every half an hour. With a 
> latency difference in about 10-20 seconds.
> Would it be possible to match the following:
>
> 1. Time
> 2. Hostname
> 3. Username
>
> The reason I prefer more than a single match, i.e only time is to not by 
> mistake miss an actual event.
>
> 
>
>  5501
>  **:30
>
>  agent-hostname
>  ssh-user
>
>  no_email_alert
>
>  Ignore rule 5501 for host 
>
> 
>
> Kind regards,
> Fredrik
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 doesn't synchronize agent.conf

[Jesus Linares]

Hi

ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf': 
> XMLERR: File 'shared/agent.conf' not found. (line 147).


what is in the line 147?.

More information about the agent.conf and the process to synchronize it: 
https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html
 

I hope it helps.
Regards.

On Sunday, July 2, 2017 at 3:30:07 AM UTC+2, Ricardo Galossi wrote:
>
> Hi guys,
>
> I'd like to ask for some help here..
>
> My windows agents are not synchronizing shared/agent.conf, 
> within C:\Program Files (x86)\ossec-agent\shared direrectory there is no 
> agent.conf even after restarting windows agent. Follow my agent.cong below:
>
> 
> 
>  check_all="yes">C:\labtest
> 
> 
>
> In the agent log file I receive the following message:
>
> ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf': 
> XMLERR: File 'shared/agent.conf' not found. (line 147).
>
> If I create the file agent.conf manually the configuration works (what 
> proof that the configuration is ok), but also doesn't synchronize if i try 
> to change it.
>
> Am I making some mistake? Please, help me!!
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Block ssh user ip after failed login attempt in OSSEC

[Jesus Linares]

Remember that you need to restart OSSEC after changing the rules.

Also, you can use *ossec-logest* to test your rules.
Regards.

On Thursday, June 29, 2017 at 11:25:17 AM UTC+2, Rahul Tiwari wrote:
>
> I tired this but its not working any other rule or something which i need 
> to add.
> As i m new in OSSEC Please help me out
>
> On Wednesday, June 28, 2017 at 10:40:20 PM UTC+5:30, Jesus Linares wrote:
>>
>> Hi,
>>
>> the *frequency *attribute specifies the number of times (+2) the rule 
>> must have matched before firing. In this case, the rule 5720 will be fired 
>> if the rule 5716 is fired 8 times (6+2).
>>
>> You must use *frequency="1"* to fire the rule after 3 attempts. Also, it 
>> is a good idea to add the *timeframe *attribute.
>>
>> I hope it helps.
>> Regards.
>>
>> On Wednesday, June 28, 2017 at 10:09:56 AM UTC+2, Rahul Tiwari wrote:
>>>
>>> I need to block the user ip after 3 times login failed attempt in ossec 
>>> I tried below in sshd_rules file
>>>
>>> 
>>> 5716
>>> 
>>> Multiple SSHD authentication failures.
>>> authentication_failures,
>>>   
>>>
>>> But its blocking the user ip after 10 attempt please help me out
>>>
>>

-- 

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

[ossec-list] Re: Passing entire log line to Active Response script - how?

[Jesus Linares]

Hi,

you are totally right. Active response configuration should allow any 
field: srcip, user, port, dynamic fields 
,
 
etc. It is in Wazuh roadmap.

It doesnt work, a real shame... It will only work if you dont have spaces 
> in your log line.

Could you share your log and your decoders?.

Thanks.
Regards.


On Wednesday, June 28, 2017 at 6:21:57 PM UTC+2, Guy Or wrote:
>
> It doesnt work, a real shame... It will only work if you dont have spaces 
>> in your log line. 
>>
>   This is really really really annoying lol... all that is needed is to 
> wrap with ' ' the argument (log line with spaces and all sort of 
> characters) when you pass it to the active response script (works when I 
> manually run it)  but I as a user cannot do that its ossec's code also 
> why limit the argumets to srcip and user? what are the other parameters for 
> (extra_data etc) just logging it seems and some rule filtering which 
> kills the level of logic you can have in the active response script. 
>
>
> Maybe in ossec 3...
>
>>  
>>
>  
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Block ssh user ip after failed login attempt in OSSEC

[Jesus Linares]

Hi,

the *frequency *attribute specifies the number of times (+2) the rule must 
have matched before firing. In this case, the rule 5720 will be fired if 
the rule 5716 is fired 8 times (6+2).

You must use *frequency="1"* to fire the rule after 3 attempts. Also, it is 
a good idea to add the *timeframe *attribute.

I hope it helps.
Regards.

On Wednesday, June 28, 2017 at 10:09:56 AM UTC+2, Rahul Tiwari wrote:
>
> I need to block the user ip after 3 times login failed attempt in ossec I 
> tried below in sshd_rules file
>
> 
> 5716
> 
> Multiple SSHD authentication failures.
> authentication_failures,
>   
>
> But its blocking the user ip after 10 attempt please help me out
>

-- 

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

[ossec-list] Re: Treat Multiple Files as One

[Jesus Linares]

Hi Eric,

Right now, I believe OSSEC is only able to correlate multiple failed logins 
> if they all happen to show up on only 1 of the log files


That is not correct. The rules are based on the content of a log, not in 
the source.

Pay attention to the following rules:

  
sshd
SSHD messages grouped.
  

   
5700
*illegal user|invalid user*
sshd: Attempt to login using a non-existent user


invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,

  

It is looking for the strings: "illegal user" or "invalid user" in a ssh 
log. When is a ssh log? If it is decoded as ssh: 


  ^sshd


...


Usually, there are no checks for the source of an event.

I hope it helps.
Regards.

On Tuesday, June 27, 2017 at 5:47:05 PM UTC+2, Eric wrote:
>
> I'm using OSSEC in a slightly untraditional way as a sudo SIEM. I have it 
> running on 1 server and it's parsing through logs that are coming from 
> multiple sources and then alerting me on what is going on. Overall this has 
> worked fine but now I'm needing to spread out the load and the logs are 
> being written to multiple files. Is there a way to tell OSSEC to treat 5 
> separate log files as the same source? 
>
> The use case I have is file1.log, file2.log, file3.log, file4.log, and 
> file5.log are all load balanced across a F5 VIP. So if you have fave 
> multiple failed logins from user1 on server1, those failed logins could 
> show up in any 5 of the log files. Right now, I believe OSSEC is only able 
> to correlate multiple failed logins if they all happen to show up on only 1 
> of the log files.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 block vulnerability scanners head user_agent

[Jesus Linares]

Good job.

Also, you can block the IP using active response 
<https://blog.wazuh.com/blocking-attacks-active-response/>.

Regards.

On Monday, June 26, 2017 at 11:12:02 AM UTC+2, Fredrik Hilmersson wrote:
>
> Hello Jesus,
>
> So, I think I've got the rule to work.
>
> 1. Rule:
>
> 
>   31101
>   web-accesslog
>Jorgee$
>   Jorgee vulnerability scanner
> 
>
> 2. Logtest output:
>
> SRCIP - - [26/Jun/2017:08:38:43 +0200] "HEAD http://HOSTIP:80/phpmyadmin4/ 
> HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee
>
> **Phase 1: Completed pre-decoding.
> full event: 'SRCIP - - [26/Jun/2017:08:38:43 +0200] "HEAD 
> http://HOSTIP:80/phpmyadmin4/ 
> HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee'
>
>   hostname: 'agent-id'
>  program_name: '(null)'
>  log: 'SRCIP - - [26/Jun/2017:08:38:43 +0200] "HEAD 
> http://HOSTIP:80/phpmyadmin4/ HTTP/1.1" 404 0 "-" "Mozilla/5.0 Jorgee'
>
> **Phase 2: Completed decoding.
>
>   decoder: 'web-accesslog'
>   srcip: 'SRCIP'
>   url: 'http://HOSTIP:80/phpmyadmin4/'
>   id: '404'
>
> **Phase 3: Completed filtering (rules).
>
>   Rule id: '100205'
>   Level: '0'
>   Description: 'Jorgee vulnerability scanner'
>
> Kind regards,
> Fredrik
>
> Den måndag 26 juni 2017 kl. 10:48:16 UTC+2 skrev Jesus Linares:
>>
>> What is the output of ossec-logtest?.
>>
>> Once you have a rule for that event, you can create an active response.
>>
>> Regards.
>>
>> On Sunday, June 25, 2017 at 12:06:23 AM UTC+2, Fredrik Hilmersson wrote:
>>>
>>> I spoke to early, Still getting spammed ...
>>>
>>> Den lördag 24 juni 2017 kl. 22:20:13 UTC+2 skrev Fredrik Hilmersson:
>>>>
>>>> Thank you!
>>>>
>>>> Den lördag 24 juni 2017 kl. 21:21:48 UTC+2 skrev dan (ddpbsd):
>>>>>
>>>>> On Sat, Jun 24, 2017 at 2:08 PM, Fredrik Hilmersson 
>>>>> <f.hilm...@worldclearing.org> wrote: 
>>>>> > Hello, 
>>>>> > 
>>>>> > so recently I got spammed by this vulnerability scanner. 
>>>>> > The HEAD is always the same, in regards to the $user_agent, Jorgee 
>>>>> > 
>>>>> > ** Alert 1498324205.1278330: - web,accesslog, 
>>>>> > 2017 Jun 24 17:10:05 (OSSEC AGENT) SRCIP->/var/log/nginx/access.log 
>>>>> > Rule: 31101 (level 5) -> 'Web server 400 error code.' 
>>>>> > 213.119.18.4 - - [24/Jun/2017:19:10:05 +0200] HEAD 
>>>>> > http://SRCIP:80/sql/phpmyadmin2/ HTTP/1.1 404 0 - Mozilla/5.0 
>>>>> Jorgee 
>>>>> > 
>>>>> > So i'm wondering if anyone has a good idea or rule how to block/ban 
>>>>> these 
>>>>> > attempts? 
>>>>> > 
>>>>> > Kind regards, 
>>>>> > Fredrik 
>>>>> > 
>>>>>
>>>>> Possibly something like: 
>>>>>  
>>>>>   nginx-errorlog 
>>>>>Jorgee$ 
>>>>>   Jorgee is loud 
>>>>>  
>>>>>
>>>>>
>>>>> > -- 
>>>>> > 
>>>>> > --- 
>>>>> > You received this message because you are subscribed 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] ossec on cent os 7

[Jesus Linares]

Hi,

keep in mind that the previous link 
 
is for OSSEC 2.8.2 and the latest release is v2.9.1 
. I recommend you to install 
OSSEC from packages, here you can find the 
packages for OSSEC 2.8.3 (we are working on the new packages for OSSEC 
2.9.1).

On the other hand, I encourage you to take a look at Wazuh 
, here 
you
 
can find a guide for RPM based distributions.

I hope it helps.
Regards.

On Sunday, June 25, 2017 at 8:37:58 PM UTC+2, PG@Wazuh wrote:
>
> Detailed instructions on vultr.com:
>
> https://www.vultr.com/docs/how-to-install-ossec-hids-on-a-centos-7-server
>
> Regards.
> —PG
> IT Security Engineer
> Wazuh Inc.
> Unix, BASIC, C, PASCAL, APL, ADA, and PROFANITY spoken here.
>
>
> On Jun 24, 2017, at 7:23 PM, satvi...@gmail.com  wrote:
>
> how to install ossec on centos 7?
>
> -- 
>
> --- 
> You received this message because you are subscribed 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] Passing entire log line to Active Response script - how?

[Jesus Linares]

Hi,

active response only accepts *user *and *srcip *as arguments. So, you need 
to create a decoder to extract the log as user or srcip. I'm not sure if 
this regex will work: "^(\.+)$".

I hope it helps.

On Sunday, June 25, 2017 at 7:06:31 PM UTC+2, dan (ddpbsd) wrote:
>
>
>
> On Jun 25, 2017 1:05 PM, "Guy Or"  wrote:
>
> Hello,
>
> I am writing decoders, rules and scripts that monitor my uwsgi application.
>
> Say that I write a decoder for a certain event that appears in the log, 
> and that triggers a rule I wrote for it (using 'decoded_as').
>
> How do I pass the entrie log line to my custom active response script, so 
> that I can use the information in the logic of the script?
>
> FYI : I am using ossec and zabbix in conjunction, right now I detect and 
> parse events with ossec real time log monitoring and send the information 
> to zabbix trappers. Works wonderfully
>
>
> Decode the entire log message as ?
>
>
> -- 
>
> --- 
> You received this message because you are subscribed 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] OSSEC block vulnerability scanners head user_agent

[Jesus Linares]

What is the output of ossec-logtest?.

Once you have a rule for that event, you can create an active response.

Regards.

On Sunday, June 25, 2017 at 12:06:23 AM UTC+2, Fredrik Hilmersson wrote:
>
> I spoke to early, Still getting spammed ...
>
> Den lördag 24 juni 2017 kl. 22:20:13 UTC+2 skrev Fredrik Hilmersson:
>>
>> Thank you!
>>
>> Den lördag 24 juni 2017 kl. 21:21:48 UTC+2 skrev dan (ddpbsd):
>>>
>>> On Sat, Jun 24, 2017 at 2:08 PM, Fredrik Hilmersson 
>>>  wrote: 
>>> > Hello, 
>>> > 
>>> > so recently I got spammed by this vulnerability scanner. 
>>> > The HEAD is always the same, in regards to the $user_agent, Jorgee 
>>> > 
>>> > ** Alert 1498324205.1278330: - web,accesslog, 
>>> > 2017 Jun 24 17:10:05 (OSSEC AGENT) SRCIP->/var/log/nginx/access.log 
>>> > Rule: 31101 (level 5) -> 'Web server 400 error code.' 
>>> > 213.119.18.4 - - [24/Jun/2017:19:10:05 +0200] HEAD 
>>> > http://SRCIP:80/sql/phpmyadmin2/ HTTP/1.1 404 0 - Mozilla/5.0 Jorgee 
>>> > 
>>> > So i'm wondering if anyone has a good idea or rule how to block/ban 
>>> these 
>>> > attempts? 
>>> > 
>>> > Kind regards, 
>>> > Fredrik 
>>> > 
>>>
>>> Possibly something like: 
>>>  
>>>   nginx-errorlog 
>>>Jorgee$ 
>>>   Jorgee is loud 
>>>  
>>>
>>>
>>> > -- 
>>> > 
>>> > --- 
>>> > You received this message because you are subscribed 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] Re: ERROR: Incorrectly formated message from 'Agent IP'

[Jesus Linares]

Hi,

2017/06/20 10:17:55 ossec-remoted(1403): ERROR: Incorrectly formated 
> message from 'Agent IP'.


that error is due to the manager is receiving a message from an agent with 
an invalid key. I would generate a new key for your agent.

Also, check if the client.keys has duplicated IPs:

IP1 KEY1
IP2 KEY2
IP1 KEY3

I think it would be possible that your agent (*IP1*) has the *KEY3*, but 
OSSEC is using the *KEY1 *to decipher the message.

I hope it helps.




On Tuesday, June 20, 2017 at 7:30:27 PM UTC+2, Anthony Egbujor wrote:
>
> Hello,
>
> I am having an issue with my communication between the server and agent.
>
> Partial Log:
>
> 2017/06/20 10:17:46 ossec-syscheckd: INFO: Starting syscheck database 
> (pre-scan).
> 2017/06/20 10:17:46 ossec-syscheckd: INFO: Initializing real time file 
> monitoring (not started).
> 2017/06/20 10:17:55 ossec-remoted(1403): ERROR: Incorrectly formated 
> message from 'Agent IP'.
> 2017/06/20 10:18:01 ossec-remoted(1403): ERROR: Incorrectly formated 
> message from 'Agent IP'.
> 2017/06/20 10:18:05 ossec-remoted(1403): ERROR: Incorrectly formated 
> message from 'Agent IP'.
>
> I have already tried to remove and readd the agent.
> I have tried to restart the agent.
> I have deleted the processes running.
> I have deleted the extras in client.keys
> I have even gone so far to uninstall both the server and agent ossec and 
> reinstall them.
>
> Nothing is working and I still get the same error.
>
> Any help would be greatly appreciated.
>
> Thanks!
>
>
>

-- 

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

[ossec-list] Re: OSSEC ignore ip issue

[Jesus Linares]

What hostname?.

If you share your rules, you may help other user with the same issue.

Regards.

On Tuesday, June 20, 2017 at 2:31:57 PM UTC+2, Fredrik Hilmersson wrote:
>
> Thanks alot Jesus,
>
> did solve it by creating two local rules one for rule 5715 matching the 
> srcip,
> and one rule to match the hostname to ignore the 5501.
>
> Kind regards,
> Fredrik
>
> Den tisdag 20 juni 2017 kl. 14:09:39 UTC+2 skrev Jesus Linares:
>>
>> Hi Fredrik,
>>
>> when you create a new ssh connection, the following alerts are generated:
>>
>> ** Alert 1497960059.10786: - 
>> syslog,sshd,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
>> ip-10-0-0-10->/var/log/auth.log
>> Rule: *5715 *(level 3) -> 'sshd: authentication success.'*Src IP: 
>> 10.10.10.10*
>> User: root
>> Jun 20 12:00:58 ip-10-0-0-10 sshd[2266]: Accepted publickey for root from 
>> 10.10.10.10 port 54950 ssh2: RSA 
>> 2d:b0:79:60:11:11:1c:b3:09:a4:1d:87:28:f2:64:11
>> ** Alert 1497960059.11162: - 
>> pam,syslog,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
>> ip-10-0-0-10->/var/log/auth.log
>> Rule: *5501 *(level 3) -> 'PAM: Login session opened.'
>> User: root
>> Jun 20 12:00:58 ip-10-0-0-10 sshd[2266]: pam_unix(sshd:session): session 
>> opened for user root by (uid=0)
>> uid: 0
>> ** Alert 1497960059.11471: - 
>> syslog,sshd,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
>> ip-10-0-0-10->/var/log/auth.log
>> Rule: 5715 (level 3) -> 'sshd: authentication success.'*Src IP: 10.10.10.10*
>> User: root
>> Jun 20 12:00:58 ip-10-0-0-10 sshd[2268]: Accepted publickey for root from 
>> 10.10.10.10 port 54953 ssh2: RSA 
>> 2d:b0:79:60:11:11:1c:b3:09:a4:1d:87:28:f2:64:11
>> ** Alert 1497960059.11847: - 
>> pam,syslog,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
>> ip-10-0-0-10->/var/log/auth.log
>> Rule: *5501 *(level 3) -> 'PAM: Login session opened.'
>> User: root
>> Jun 20 12:00:58 ip-10-0-0-10 sshd[2268]: pam_unix(sshd:session): session 
>> opened for user root by (uid=0)
>> uid: 0
>>
>>
>>
>> As you can see, the alerts 5501 don't have *srcip*. For that reason your 
>> rule is not working. You can use *if_group* *sshd *in order to ignore: 
>> all ssh alerts with your IP (*if the IP is extracted as srcip*).
>>
>> I hope it helps.
>>
>>
>> On Tuesday, June 20, 2017 at 1:53:41 PM UTC+2, Fredrik Hilmersson wrote:
>>>
>>> Hey Jesus,
>>>
>>> I'm only overwriting rule 5501 to increase its alert level to 7 (as I 
>>> test to use only send alert if 7 or < ).
>>>
>>> I did test the following:
>>>
>>> 
>>>
>>>  5501
>>>
>>>  Remote IP
>>>
>>>  Ignoring host remote IP
>>>
>>> 
>>>
>>> also:
>>>
>>> 
>>>
>>>  5501
>>>
>>>  Remote IP
>>>  no_email_alert
>>>
>>>  Ignoring host remote IP
>>>
>>> 
>>>
>>> However, I still get alerts sent to me when connecting to any ossec 
>>> agent through that remote host.
>>>
>>> Den måndag 19 juni 2017 kl. 16:27:47 UTC+2 skrev Jesus Linares:
>>>>
>>>> Your second rule is ignoring only alerts with level 2 and with your IP. 
>>>> I think you could use *if_sid*.
>>>>
>>>> Why are you overwriting the rule 5501?.
>>>>
>>>> Regards.
>>>>
>>>>
>>>>
>>>> On Monday, June 19, 2017 at 12:00:29 PM UTC+2, Fredrik Hilmersson wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> So I got the following custom rule on the ossec server:
>>>>>
>>>>>  
>>>>>
>>>>>5500
>>>>>
>>>>>session opened for user 
>>>>>
>>>>>Login session opened.
>>>>>
>>>>>authentication_success,
>>>>>
>>>>>  
>>>>>
>>>>> Then afterwards I use the local rule on the ossec server to avoid 
>>>>> alert spam from a specific IP:
>>>>>
>>>>>  
>>>>>
>>>>>2
>>>>>
>>>>>MYIP
>>>>>
>>>>>Ignoring ip MYIP
>>>>>
>>>>>  
>>>>>
>>>>> I tried with  instead of srcip but without success, the 
>>>>> ossec agents still generate alerts to my ossec server when connecting 
>>>>> from 
>>>>> MYIP.
>>>>>
>>>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Grouping syscheck email alerts per agent.

[Jesus Linares]

Hi,

I think is not possible, but you can use *reports:*
 
https://documentation.wazuh.com/current/user-manual/manager/output-options/manual-email-report/index.html#multiples-options-and-multiples-email

I hope it helps.

On Tuesday, June 20, 2017 at 12:09:02 PM UTC+2, Kazim Koybasi wrote:
>
> Is it possible to group syscheck email alert per agent?
>

-- 

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

[ossec-list] Re: OSSEC ignore ip issue

[Jesus Linares]

Hi Fredrik,

when you create a new ssh connection, the following alerts are generated:

** Alert 1497960059.10786: - 
syslog,sshd,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
ip-10-0-0-10->/var/log/auth.log
Rule: *5715 *(level 3) -> 'sshd: authentication success.'*Src IP: 10.10.10.10*
User: root
Jun 20 12:00:58 ip-10-0-0-10 sshd[2266]: Accepted publickey for root from 
10.10.10.10 port 54950 ssh2: RSA 2d:b0:79:60:11:11:1c:b3:09:a4:1d:87:28:f2:64:11
** Alert 1497960059.11162: - 
pam,syslog,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
ip-10-0-0-10->/var/log/auth.log
Rule: *5501 *(level 3) -> 'PAM: Login session opened.'
User: root
Jun 20 12:00:58 ip-10-0-0-10 sshd[2266]: pam_unix(sshd:session): session opened 
for user root by (uid=0)
uid: 0
** Alert 1497960059.11471: - 
syslog,sshd,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
ip-10-0-0-10->/var/log/auth.log
Rule: 5715 (level 3) -> 'sshd: authentication success.'*Src IP: 10.10.10.10*
User: root
Jun 20 12:00:58 ip-10-0-0-10 sshd[2268]: Accepted publickey for root from 
10.10.10.10 port 54953 ssh2: RSA 2d:b0:79:60:11:11:1c:b3:09:a4:1d:87:28:f2:64:11
** Alert 1497960059.11847: - 
pam,syslog,authentication_success,pci_dss_10.2.5,2017 Jun 20 12:00:59 
ip-10-0-0-10->/var/log/auth.log
Rule: *5501 *(level 3) -> 'PAM: Login session opened.'
User: root
Jun 20 12:00:58 ip-10-0-0-10 sshd[2268]: pam_unix(sshd:session): session opened 
for user root by (uid=0)
uid: 0



As you can see, the alerts 5501 don't have *srcip*. For that reason your 
rule is not working. You can use *if_group* *sshd *in order to ignore: all 
ssh alerts with your IP (*if the IP is extracted as srcip*).

I hope it helps.


On Tuesday, June 20, 2017 at 1:53:41 PM UTC+2, Fredrik Hilmersson wrote:
>
> Hey Jesus,
>
> I'm only overwriting rule 5501 to increase its alert level to 7 (as I test 
> to use only send alert if 7 or < ).
>
> I did test the following:
>
> 
>
>  5501
>
>  Remote IP
>
>  Ignoring host remote IP
>
> 
>
> also:
>
> 
>
>  5501
>
>  Remote IP
>  no_email_alert
>
>  Ignoring host remote IP
>
> 
>
> However, I still get alerts sent to me when connecting to any ossec agent 
> through that remote host.
>
> Den måndag 19 juni 2017 kl. 16:27:47 UTC+2 skrev Jesus Linares:
>>
>> Your second rule is ignoring only alerts with level 2 and with your IP. I 
>> think you could use *if_sid*.
>>
>> Why are you overwriting the rule 5501?.
>>
>> Regards.
>>
>>
>>
>> On Monday, June 19, 2017 at 12:00:29 PM UTC+2, Fredrik Hilmersson wrote:
>>>
>>> Hello,
>>>
>>> So I got the following custom rule on the ossec server:
>>>
>>>  
>>>
>>>5500
>>>
>>>session opened for user 
>>>
>>>Login session opened.
>>>
>>>authentication_success,
>>>
>>>  
>>>
>>> Then afterwards I use the local rule on the ossec server to avoid alert 
>>> spam from a specific IP:
>>>
>>>  
>>>
>>>2
>>>
>>>MYIP
>>>
>>>Ignoring ip MYIP
>>>
>>>  
>>>
>>> I tried with  instead of srcip but without success, the 
>>> ossec agents still generate alerts to my ossec server when connecting from 
>>> MYIP.
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: How to start syscheck at same time in a weekdays?

[Jesus Linares]

Hi,

you can find information about the precedence of* agent.conf *and 
*ossec.conf* 
here: 
https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html#precedence

The *alert_new_files *setting is only valid for manager.

keep in mind that the first time that syscheck is executed (Monday - 
08.00), it will create the database, so you will see alerts about changes 
the next time that syscheck runs (Tuesday - 08.00).

I hope it helps.

On Saturday, June 17, 2017 at 4:44:31 PM UTC+2, Kazim Koybasi wrote:
>
> I want to manually trigger Wazuh OSSEC syscheck like AIDE. I configure it 
> to check manually every day at 08:00 with below shared/agent.conf but even 
> whan I start syscheck with agent_control -r -a .It does not report changes 
> to alets.log. Do manager ossec.conf affect agents or every agent configured 
> with own ossec.conf and shared/agent.conf? My shared/agent.conf and manager 
> ossec.conf is like below and same config also applies in manager 
> ossec.conf. Thanks for reading.
>
> 
> 
> yes
> 
> 
> 
> Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday
> 08:00
> no
> yes
> 604800
>  
> 
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: OSSEC Agent Logs Showing Error

[Jesus Linares]

Hi,

it looks like you have other instance of *authd *running:

2017/06/16 06:06:33 ossec-authd: Unable to bind to port 1515


Kill the authd and run it again. Then register your agent and restart it.

I hope it helps.

On Friday, June 16, 2017 at 2:50:01 PM UTC+2, Arvind Lavania wrote:
>
> Hi,
>
> I have installed OSSEC SERVER on Centos 6.9. everything is working as 
> expected.
>
> One error i am noticing in my logs from client server. client server is 
> running on Centos 6.9
>
> Details From OSSEC-Server/Manager
>
> [root@al ~]# /var/ossec/bin/ossec-authd -v /var/ossec/etc/sslmanager.cert 
> -d
>
> 2017/06/16 06:06:33 ossec-authd: DEBUG: Starting ...
>
> 2017/06/16 06:06:33 ossec-authd: INFO: Started (pid: 6097).
>
> 2017/06/16 06:06:33 ossec-authd: DEBUG: Peer verification requested.
>
> 2017/06/16 06:06:33 ossec-authd: DEBUG: Returning CTX for server.
>
> 2017/06/16 06:06:33 ossec-authd: Unable to bind to port 1515
>
>
> [root@al ~]# tcpdump -i eth0 port 1515 -vv
>
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 
> 65535 bytes
>
> 06:16:59.804739 IP (tos 0x10, ttl 64, id 31414, offset 0, flags [DF], 
> proto TCP (6), length 60)
>
> 10.24.211.130.56622 > x.x.x.37.ifor-protocol: Flags [S], cksum 0xfcd2 
> (correct), seq 3432935783, win 17922, options [mss 8961,sackOK,TS val 
> 1444817 ecr 0,nop,wscale 6], length 0
>
> 06:16:59.804780 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP 
> (6), length 60)
>
> 10.24.211.37.ifor-protocol > 10.24.211.130.56622: Flags [S.], cksum 
> 0x27c1 (correct), seq 1407314966, ack 3432935784, win 17898, options [mss 
> 8961,sackOK,TS val 1348875 ecr 1444817,nop,wscale 7], length 0
>
> 06:16:59.805215 IP (tos 0x10, ttl 64, id 31415, offset 0, flags [DF], 
> proto TCP (6), length 52)
>
> 10.24.211.130.56622 > x.x.x.37.ifor-protocol: Flags [.], cksum 0xb8aa 
> (correct), seq 1, ack 1, win 281, options [nop,nop,TS val 1444818 ecr 
> 1348875], length 0
>
> 06:17:02.704313 IP (tos 0x10, ttl 64, id 31416, offset 0, flags [DF], 
> proto TCP (6), length 57)
>
> 10.24.211.130.56622 > x.x.x.37.ifor-protocol: Flags [P.], cksum 
> 0xa757 (correct), seq 1:6, ack 1, win 281, options [nop,nop,TS val 1447717 
> ecr 1348875], length 5
>
> 06:17:02.704397 IP (tos 0x0, ttl 64, id 31004, offset 0, flags [DF], proto 
> TCP (6), length 52)
>
> 10.24.211.37.ifor-protocol > x.x.x.130.56622: Flags [.], cksum 0xa28c 
> (correct), seq 1, ack 6, win 140, options [nop,nop,TS val 1351774 ecr 
> 1447717], length 0
>
> 2017/06/16 06:17:02 ossec-authd: ERROR: SSL Error (-1)
>
> 140489331664744:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version 
> number:s3_pkt.c:350:
>
> 06:17:02.713275 IP (tos 0x0, ttl 64, id 31005, offset 0, flags [DF], proto 
> TCP (6), length 52)
>
>
>
> [root@al ~]# netstat -tunlp
>
> Active Internet connections (only servers)
>
> Proto Recv-Q Send-Q Local Address   Foreign Address   
>   State   PID/Program name   
>
> tcp0  0 0.0.0.0:96540.0.0.0:* 
>   LISTEN  5939/python 
>
> tcp0  0 0.0.0.0:22  0.0.0.0:* 
>   LISTEN  1089/sshd   
>
> tcp0  0 127.0.0.1:250.0.0.0:* 
>   LISTEN  1187/master 
>
> tcp0  0 :::1515 :::*  
>   LISTEN  6360/ossec-authd
>
> tcp0  0 :::22   :::*  
>   LISTEN  1089/sshd   
>
> tcp0  0 ::1:25  :::*  
>   LISTEN  1187/master 
>
> udp0  0 0.0.0.0:68  0.0.0.0:* 
>   829/dhclient
>
> udp0  0 :::1514 :::*  
>   6485/ossec-remoted  
>
>
> [root@al ~]# lsof -P -c ossec-remoted
>
> COMMANDPID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
>
> ossec-rem 6485 ossecr  cwdDIR  202,1 4096 401636 
> /var/ossec
>
> ossec-rem 6485 ossecr  rtdDIR  202,1 4096 401636 
> /var/ossec
>
> ossec-rem 6485 ossecr  txtREG  202,1   231568   6005 
> /var/ossec/bin/ossec-remoted
>
> ossec-rem 6485 ossecr  memREG  202,166432 264229 
> /lib64/libnss_files-2.12.so
>
> ossec-rem 6485 ossecr  memREG  202,1   122056 264206 
> /lib64/libselinux.so.1
>
> ossec-rem 6485 ossecr  memREG  202,1   111440 264239 
> /lib64/libresolv-2.12.so
>
> ossec-rem 6485 ossecr  memREG  202,110192 267113 
> /lib64/libkeyutils.so.1.3
>
> ossec-rem 6485 ossecr  memREG  202,143728 267126 
> /lib64/libkrb5support.so.0.1
>
> ossec-rem 6485 ossecr  memREG  202,1   174840 267122 
> /lib64/libk5crypto.so.3.1
>
> ossec-rem 6485 ossecr  memREG  202,114664 264654 
> 

Re: [ossec-list] No Decoder Match Problem

[Jesus Linares]

Hi Akash,

the OSSEC engine has 3 phases: pre-decoding, decoding, rule matching.

The pre-decoding is done automatically by OSSEC (at c level):

**Phase 1: Completed pre-decoding.
   full event: 'myapplication: This is a test'
   hostname: 'ip-10-0-0-10'
   *program_name**: '(null)'*
   log: 'myapplication: This is a test'

You have to create your decoders based on the information extracted on the 
phase 1:

   - If pre-decoding extracts *program_name*, use *program_name *in your 
   parent decoder.
   - Otherwise, use *prematch*

So, you must to use *prematch*, because your *program_name *is null.


myapplication: 




test
this
(\S+)
extra_data



myapplication: This is a test

**Phase 1: Completed pre-decoding.
   full event: 'myapplication: This is a test'
   hostname: 'ip-10-0-0-10'
   program_name: '(null)'
   log: 'myapplication: This is a test'

**Phase 2: Completed decoding.
   decoder: 'test'
   extra_data: 'This'

I hope it helps.
Regards.


On Sunday, June 11, 2017 at 2:16:58 AM UTC+2, dan (ddpbsd) wrote:
>
> On Fri, Jun 9, 2017 at 11:21 AM, Akash Munjal  > wrote: 
> > 
> > Hi, 
> > 
> > I create custom decoder,   /var/ossec/etc/local_decoder.xml as: 
> > 
> >  
> >   myapplication 
> >   ^myapplication:  
> >  
> > 
> > 
> > Entry of decoder in manager ossec.conf file as: 
> > 
> >  
> >  local_rules.xml 
> > etc/decoder.xml 
> > etc/local_decoder.xml 
> > rules/plugins 
> >  
> > 
> > 
> > when i run logtest command it show this: 
> > 
> > 
> > 
> >  /var/ossec/bin/ossec-logtest 
> > 2017/06/09 20:08:54 ossec-testrule: INFO: Reading decoder file 
> > etc/decoder.xml. 
> > 2017/06/09 20:08:54 ossec-testrule: INFO: Reading decoder file 
> > etc/local_decoder.xml. 
> > 2017/06/09 20:08:54 ossec-testrule: INFO: Started (pid: 21573). 
> > ossec-testrule: Type one log per line. 
> > 
> > myapplication: This is a test 
> > 
> > 
> > **Phase 1: Completed pre-decoding. 
> >full event: 'myapplication: This is a test' 
> >hostname: 'ip-x.x.x.x' 
> >program_name: '(null)' 
>
> In your decoder you had program_name equal to myapplication. This is 
> not how the event was decoded. 
>
> >log: 'myapplication: This is a test' 
> > 
> > **Phase 2: Completed decoding. 
> >No decoder matched. 
> > 
> >  I follow this link as below: 
> > 
> > 
> https://www.alienvault.com/documentation/usm-appliance/ids-configuration/process-reading-log-file-with-hids-agent-windows.htm
>  
> > 
> > 
> > Anyone can help me out in this. 
> > 
> > Thanks... 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@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] Updates rules and signatures

[Jesus Linares]

The script is only valid for Wazuh.


On Thursday, June 8, 2017 at 2:31:24 PM UTC+2, Alexis Lessard wrote:
>
> I did see that script. Seemed really interesting. Due to a lack of a test 
> environment, I didn't try it, but reading it, I was under the impression 
> that it only worked with a wazzuh installation and not with ossec vanilla. 
> Would it actually work without installing wazzuh?
>
> Le jeudi 8 juin 2017 05:14:07 UTC-4, Jesus Linares a écrit :
>>
>> Hi Alexis,
>>
>> Dan's method is the faster way to do it and it should work properly.
>>
>> Saying that, Wazuh does a great effort to centralice decoders, rules, 
>> rootchecks and OpenSCAP content in wazuh-ruleset 
>> <https://github.com/wazuh/wazuh-ruleset> repository. Also, a script 
>> <https://documentation.wazuh.com/current/user-manual/ruleset/update.html>to 
>> update the ruleset is provided. Unfortunately, the ruleset (and the script) 
>> only works with Wazuh manager 2.0 due to compatibility issues (we included 
>> dynamic 
>> fields 
>> <https://documentation.wazuh.com/current/user-manual/ruleset/dynamic-fields.html>)
>>  
>> but OSSEC agents are fully compatible with Wazuh manager.
>>
>> I hope it helps.
>> Regards.
>>
>> On Thursday, June 8, 2017 at 3:48:05 AM UTC+2, dan (ddpbsd) wrote:
>>>
>>> On Wed, Jun 7, 2017 at 4:24 PM, Alexis Lessard 
>>> <alexisl...@gmail.com> wrote: 
>>> > Hi! 
>>> > 
>>> > What is the cleanest and easiest way to updates rules and signatures 
>>> of 
>>> > attacks and threats in ossec? I'm looking maybe for a command I could 
>>> use to 
>>> > automate it. When I execute  bin/manage_agents -V (to obtain version), 
>>> I get 
>>> > this: 
>>> > OSSEC HIDS v2.8.3 - Trend Micro Inc. 
>>> > 
>>> > According to the documentation for 2.8.1 right here, in order to 
>>> update 
>>> > those rules, we have to download the installation package and 
>>> reinstall it. 
>>> > The installation script should ask us to update. That seems pretty 
>>> > complicated and unorthodox. Is there a simpler way? 
>>> > 
>>>
>>> Clone the github repo, copy the decoder.xml and rules files to the 
>>> proper directory, restart ossec. 
>>>
>>> > Also, I think I should ask that question: Does anyone know how often 
>>> does 
>>> > ossec update their signatures and rules, or if they update them at 
>>> all? 
>>> > 
>>>
>>> When we do. A lot of it depends on how often people submit new rules, 
>>> decoders or even log samples. 
>>>
>>> > 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. 
>>> > 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: OSSEC rule to avoid alerts for apt-daily

[Jesus Linares]

Hi Fredrik,

you want to do something like: "if Starting daily apt activities -> disable 
syscheck for that agent". I think there is no way to do it. The rule engine 
doesn't allow rules like "if event A (starting apt) and event B (syscheck) 
-> rule to ignore event".

You can create a rule to ignore syscheck events between a range of time. Do 
you know when the update will be executed?.

Regards.

On Thursday, June 8, 2017 at 10:05:12 AM UTC+2, Fredrik Hilmersson wrote:
>
> Hello,
>
> So i'm getting more and more comfortable with the configuration and server 
> - agent architecture. However, now i'd like to step it up and start create 
> my own custom rules and would appreciate some guidance and pointers.
>
> The rule i'd like to create is to avoid alerts during the apt-daily update 
> which triggers the integrity check and renders in plenty notifications. The 
> syslog outputs "Starting daily apt activites..." before the 
> apt-daily.service run its updates, so I thought one way would be to timeout 
> the integrity check rule for x seconds once the apt-daily appear in the 
> syslog. I don't know there might be an even more 'reliable' solution?
>
> Any pointers or ideas would be greatly appreciated!
>
> Kind regards,
> Fredrik
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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] Updates rules and signatures

[Jesus Linares]

Hi Alexis,

Dan's method is the faster way to do it and it should work properly.

Saying that, Wazuh does a great effort to centralice decoders, rules, 
rootchecks and OpenSCAP content in wazuh-ruleset 
 repository. Also, a script 
to 
update the ruleset is provided. Unfortunately, the ruleset (and the script) 
only works with Wazuh manager 2.0 due to compatibility issues (we included 
dynamic 
fields 
)
 
but OSSEC agents are fully compatible with Wazuh manager.

I hope it helps.
Regards.

On Thursday, June 8, 2017 at 3:48:05 AM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Jun 7, 2017 at 4:24 PM, Alexis Lessard 
>  wrote: 
> > Hi! 
> > 
> > What is the cleanest and easiest way to updates rules and signatures of 
> > attacks and threats in ossec? I'm looking maybe for a command I could 
> use to 
> > automate it. When I execute  bin/manage_agents -V (to obtain version), I 
> get 
> > this: 
> > OSSEC HIDS v2.8.3 - Trend Micro Inc. 
> > 
> > According to the documentation for 2.8.1 right here, in order to update 
> > those rules, we have to download the installation package and reinstall 
> it. 
> > The installation script should ask us to update. That seems pretty 
> > complicated and unorthodox. Is there a simpler way? 
> > 
>
> Clone the github repo, copy the decoder.xml and rules files to the 
> proper directory, restart ossec. 
>
> > Also, I think I should ask that question: Does anyone know how often 
> does 
> > ossec update their signatures and rules, or if they update them at all? 
> > 
>
> When we do. A lot of it depends on how often people submit new rules, 
> decoders or even log samples. 
>
> > 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 . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

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

Re: [ossec-list] Re: How to know when syscheck agent finishes a scan?

[Jesus Linares]

>
> Thanks that helped a lot and definitely speed it up.  We went from several 
> hours to 4 minutes now.  This includes our entire webapp

If syscheck sends too much events in a short period of time, it is possible 
that they are lost due to UDP. So, don't use too low values.

Is there a way to speed up rootcheck?  That is the longest part of the scan 
> that takes 15 minutes now, so the whole process takes approx 20 minutes now.

Rootcheck does a lot of things (documentation 
<https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/rootcheck.html>).
 
You can enable only what you want:

   - check_dev
   - check_files
   - check_if
   - check_pids
   - check_policy
   - check_ports
   - check_sys
   - check_trojans
   - check_unixaudit
   - check_winapps
   - check_winapps
   - check_winmalware
   
The main reason is anytime we deploy I want to follow what is in the doc, 
> stop ossec on manager, then clear database and run a new baseline, but 
> trying to speed up the process.  If there is a way to disable rootcheck 
> when I do that command?  I need to do that becuase otherwise I will get 
> tons of emails every time we do a deploy.

If you want to disable rootcheck remotely in an agent, you can use the 
agent.conf 
<https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html>
.

Regards.


On Wednesday, June 7, 2017 at 8:13:24 PM UTC+2, John Kondur wrote:
>
> Thanks that helped a lot and definitely speed it up.  We went from several 
> hours to 4 minutes now.  This includes our entire webapp
>
>
> Is there a way to speed up rootcheck?  That is the longest part of the 
> scan that takes 15 minutes now, so the whole process takes approx 20 
> minutes now.
>
> But I would like to either disable root check when you send for example 
> the following command:
>
>  /var/ossec/bin/agent_control -r -u 1027
>
>
> The main reason is anytime we deploy I want to follow what is in the doc, 
> stop ossec on manager, then clear database and run a new baseline, but 
> trying to speed up the process.  If there is a way to disable rootcheck 
> when I do that command?  I need to do that becuase otherwise I will get 
> tons of emails every time we do a deploy.
>
> Thanks
>
>
> On Wednesday, June 7, 2017 at 11:36:13 AM UTC-4, Jesus Linares wrote:
>>
>> Hi John,
>>
>> there is a way to speed up syscheck. By default *syscheck sleeps 2 
>> seconds each 15 files*. This avoid packet loss due to UDP. You can 
>> overwrite this configuration in *local_internal_options.conf*:
>>
>> $ nano /var/ossec/etc/local_internal_options.conf
>>
>> syscheck.sleep=1
>> syscheck.sleep_after=150
>>
>>
>> This is 20 times faster than the default configuration. I would not 
>> increase these values more than 1 - 150.
>>
>> How many files are you scanning?. Remember that syscheck is only for 
>> important files.
>>
>> In *ossec.log *you should see something like:
>>
>> 2017/06/07 14:21:51 ossec-syscheckd: INFO: Starting syscheck scan
>> ...
>> 2017/06/07 14:27:19 ossec-syscheckd: INFO: Ending syscheck scan
>>
>>
>> I hope it helps.
>> Regards.
>>
>>
>> On Wednesday, June 7, 2017 at 4:54:07 PM UTC+2, jose wrote:
>>>
>>> Hi John
>>>
>>> You cannot speed the syscheck, but you can always add the option 
>>> *realtime* for your more important folders, with this option you will 
>>> have the alerts in “real time” :)
>>>
>>>
>>> https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/syscheck.html?highlight=realtime
>>>
>>>
>>> Regards
>>> ---
>>> Jose Luis Ruiz
>>> Wazuh Inc.
>>> jo...@wazuh.com
>>>
>>> On June 7, 2017 at 10:15:19 AM, John Kondur (kongf...@gmail.com) wrote:
>>>
>>> Thanks I did find it that did help, 
>>>
>>> I had two more questions not sure if I should start another thread:
>>>
>>> I had frequency set on the agents to:
>>>
>>> 7200
>>>
>>> I looked in the ossec.log and it never kicked off, and it has been 15 
>>> hours since the last scan finished.  I restarted the agent and it kicked 
>>> off but any idea what might not start it?  
>>>
>>>
>>>
>>> Second question:
>>>
>>> The scans seem to take a very long time, I ran it and it takes 4 hours 
>>> on one of my web servers.  Is it the size of the files or the number of 
>>> files that determines the scan and is there anyway to speed it up?  
>>>
>>>
>

Re: [ossec-list] Re: How to know when syscheck agent finishes a scan?

[Jesus Linares]

Hi John,

there is a way to speed up syscheck. By default *syscheck sleeps 2 seconds 
each 15 files*. This avoid packet loss due to UDP. You can overwrite this 
configuration in *local_internal_options.conf*:

$ nano /var/ossec/etc/local_internal_options.conf

syscheck.sleep=1
syscheck.sleep_after=150


This is 20 times faster than the default configuration. I would not 
increase these values more than 1 - 150.

How many files are you scanning?. Remember that syscheck is only for 
important files.

In *ossec.log *you should see something like:

2017/06/07 14:21:51 ossec-syscheckd: INFO: Starting syscheck scan
...
2017/06/07 14:27:19 ossec-syscheckd: INFO: Ending syscheck scan


I hope it helps.
Regards.


On Wednesday, June 7, 2017 at 4:54:07 PM UTC+2, jose wrote:
>
> Hi John
>
> You cannot speed the syscheck, but you can always add the option 
> *realtime* for your more important folders, with this option you will 
> have the alerts in “real time” :)
>
>
> https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/syscheck.html?highlight=realtime
>
>
> Regards
> ---
> Jose Luis Ruiz
> Wazuh Inc.
> jo...@wazuh.com 
>
> On June 7, 2017 at 10:15:19 AM, John Kondur (kongf...@gmail.com 
> ) wrote:
>
> Thanks I did find it that did help, 
>
> I had two more questions not sure if I should start another thread:
>
> I had frequency set on the agents to:
>
> 7200
>
> I looked in the ossec.log and it never kicked off, and it has been 15 
> hours since the last scan finished.  I restarted the agent and it kicked 
> off but any idea what might not start it?  
>
>
>
> Second question:
>
> The scans seem to take a very long time, I ran it and it takes 4 hours on 
> one of my web servers.  Is it the size of the files or the number of files 
> that determines the scan and is there anyway to speed it up?  
>
>
> Thanks
>
>
>
> On Wednesday, June 7, 2017 at 5:21:01 AM UTC-4, Jesus Linares wrote: 
>>
>> Review the ossec.conf of the agent 1027. You should see a log for 
>> starting/ending rootcheck and syscheck. 
>>
>> I hope it helps.
>>
>> On Tuesday, June 6, 2017 at 9:17:11 PM UTC+2, John Kondur wrote: 
>>>
>>> Thanks but unfortunately all it shows is the following: 
>>>
>>>
>>> OSSEC HIDS agent_control. Agent information:
>>>Agent ID:   1027
>>>Agent Name: server1
>>>IP address: any/any
>>>Status: Active
>>>
>>>Operating system:Linux 4.4.
>>>Client version:  OSSEC HIDS v2.8.3 / 
>>> 6322ee12ea9a05951f97923a8341a01a
>>>    Last keep alive: Tue Jun  6 19:10:59 2017
>>>
>>>Syscheck last started  at: Tue Jun  6 18:19:23 2017
>>>Rootcheck last started at: Tue Jun  6 18:41:54 2017
>>>
>>>  
>>> It just shows last started, but never shows when it completes.
>>>
>>>
>>> On Tuesday, June 6, 2017 at 4:42:52 AM UTC-4, Jesus Linares wrote: 
>>>>
>>>> Hi John, 
>>>>
>>>> I think it should appear in */var/ossec/bin/agent_control -i 1027.* 
>>>> Also, you can review the ossec.conf of your agent.
>>>>
>>>> Regards.
>>>>
>>>> On Monday, June 5, 2017 at 6:24:14 PM UTC+2, John Kondur wrote: 
>>>>>
>>>>> I just started to use ossec, and was doing some testing by making some 
>>>>> changes in a file in a directory, and then I run from the server: 
>>>>>
>>>>>
>>>>> /var/ossec/bin/agent_control -r -a
>>>>>
>>>>>
>>>>> if I do a query on the agent:
>>>>>
>>>>>
>>>>>
>>>>> /var/ossec/bin/agent_control -i 1027
>>>>>
>>>>>
>>>>>
>>>>> It will show last time it started but never shows when it completes?  
>>>>> Is there a process or way to check to see if it completed or am I not 
>>>>> waiting long enough?  So far I am not seeing ossec pick up that the file 
>>>>> changes.
>>>>>
>>>>> 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 .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 

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

Re: [ossec-list] Problem with dovecot decoder

[Jesus Linares]

Hi,

what fields do you need?.

Dec 19 17:20:08 ny dovecot: pop3-login: Aborted login (auth failed, 2 
attempts in 18 secs): *user*=, method=PLAIN, *rip*=1.2.3.4, *lip*=1.2.
3.4, session=

**Phase 1: Completed pre-decoding.
   full event: 'Dec 19 17:20:08 ny dovecot: pop3-login: Aborted login 
(auth failed, 2 attempts in 18 secs): user=, method=PLAIN, 
rip=1.2.3.4, lip=1.2.3.4, session='
   hostname: 'ny'
   program_name: 'dovecot'
   log: 'pop3-login: Aborted login (auth failed, 2 attempts in 18 
secs): user=, method=PLAIN, rip=1.2.3.4, lip=1.2.3.4, 
session='

**Phase 2: Completed decoding.
   decoder: 'dovecot'
   dstuser: 'test'
   srcip: '1.2.3.4'
   dstip: '1.2.3.4'
   proto: 'session='

**Phase 3: Completed filtering (rules).
   Rule id: '9705'
   Level: '5'
   Description: 'Dovecot Invalid User Login Attempt.'
**Alert to be generated.

You can change the decoder 
to
 
extract the *method *field, but it seems the rest of fields are decoded.

I hope it helps.
Regards.

On Tuesday, June 6, 2017 at 7:58:55 PM UTC+2, dan (ddpbsd) wrote:
>
>
>
> On Jun 6, 2017 1:56 PM,  wrote:
>
> Hi all,
>
> have problem with dovecot decoder 
>
> Example log:
> Dec 19 17:20:08 ny dovecot: pop3-login: Aborted login (auth failed, 2 
> attempts in 18 secs): user=, method=PLAIN, rip=1.2.3.4, lip=1.2.3.4, 
> session=
>
> Default dovecot decoder 
>
> 
>   dovecot
>   ^\w\w\w\w-login: Aborted login
>   : user=\p(\S+)\p, method=\S+, 
> rip=:::(\d+.\d+.\d+.\d+), lip=:::(\d+.\d+.\d+.\d+)$
>
>
> Try changing the rip and lip to "(\S+)"
> What's there now seems very wrong.
>
>   user, srcip, dstip
>  
>
> Is it possible to create additional decoder that extracts same fields as 
> in the above decoder if regex tag not matches but prematch was matched?
>
>
> -- 
>
> --- 
> You received this message because you are subscribed 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] Re: How to know when syscheck agent finishes a scan?

[Jesus Linares]

Hi John,

I think it should appear in */var/ossec/bin/agent_control -i 1027. *Also, 
you can review the ossec.conf of your agent.

Regards.

On Monday, June 5, 2017 at 6:24:14 PM UTC+2, John Kondur wrote:
>
> I just started to use ossec, and was doing some testing by making some 
> changes in a file in a directory, and then I run from the server:
>
>
> /var/ossec/bin/agent_control -r -a
>
>
> if I do a query on the agent:
>
>
>
> /var/ossec/bin/agent_control -i 1027
>
>
>
> It will show last time it started but never shows when it completes?  Is 
> there a process or way to check to see if it completed or am I not waiting 
> long enough?  So far I am not seeing ossec pick up that the file changes.
>
> 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] Re: Email Notification using msmtp..

[Jesus Linares]

Hi Rakesh,

In case that your SMTP server has authentication (like Gmail), it is 
necessary to configure a server relay 

 
because OSSEC does not support it by default. However, if you are using 
Gmail, I think it is possible to use directly the Google SMTP relay 
service: https://support.google.com/a/answer/176600?hl=en

Anyway, your OSSEC configuration looks right (if msmtp is working 
properly). Did you check the* ossec.log*?. It may has useful information. 
Also, review the msmtp logs.

I hope it helps.
Regards.


On Friday, June 2, 2017 at 11:58:07 PM UTC+2, Rakesh Goyal wrote:
>
> I  have configured msmtp 
>
> # Set defaults.
>> defaults
>> # Enable or disable TLS/SSL encryption.
>> tls on
>> tls_starttls on
>> tls_trust_file /etc/ssl/certs/ca-certificates.crt
>> # Setup WP account's settings.
>> account el-notification
>> domain localhost
>> host smtp.mandrillapp.com
>> port 587
>> auth login
>> user admin@*
>> password *
>> from admin@
>> logfile /var/log/msmtp/msmtp.log
>> account default : el-notification
>
>
> I am able to send mail using msmtp.
>
> How can I use msmtp with ossec without installing sendmail or postfix ? 
>
> 
>> yes
>> rakesh.goyal@**
>>
>>
>> root@localhost
>> localhost
>> 
>
>
> I tried different options but not able to send mail using msmtp.  Mails 
> are going with aspmx.l.google.com but I want to send mail through 
> smtp.mandrillapp.com. Any way of doing this in ossec 2.8.3 version ?
>  
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: OSSEC - windows event

[Jesus Linares]

Hi Irshad,

sorry, I thought was the same problem than Akash.

I would like to be able to retrieve logs from windows machine to my OSSIM


Do you meand OSSEC, right?.

Review the ossec.log of your agent. Maybe the location is wrong or there 
are no events.

I hope it helps.
Regards.


On Thursday, June 1, 2017 at 6:51:14 AM UTC+2, Irshad Rahimbux wrote:
>
> ANy one can provide some help? @Jesus Linares... the link you provided is 
> not helping much. It's for another issue.
>
> On Wednesday, May 31, 2017 at 1:07:19 PM UTC+4, Jesus Linares wrote:
>>
>> https://groups.google.com/forum/#!topic/ossec-list/wcIE_EcDVxo
>>
>> On Tuesday, May 30, 2017 at 4:34:46 PM UTC+2, Akash Munjal wrote:
>>>
>>>
>>> Hi All,
>>>
>>> I am also facing the same problem.I am not getting alert of 
>>> creation/deletion of file  from windows agent 
>>> to my manager(linux). Agent show connected and active, I only get alert 
>>> from agent(win) is agent start/restart/change in ossec.conf(agent).
>>> To monitor D:\ drive, I have done the following changes in ossec.conf on 
>>> manager:
>>>
>>>  >> check_all="yes">C:.,D:.
>>>
>>> But i don't get any alerts on my manager.
>>>
>>> Can you please help me out.
>>>
>>> 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] Re: OSSEC - windows event

[Jesus Linares]

https://groups.google.com/forum/#!topic/ossec-list/wcIE_EcDVxo

On Tuesday, May 30, 2017 at 4:34:46 PM UTC+2, Akash Munjal wrote:
>
>
> Hi All,
>
> I am also facing the same problem.I am not getting alert of 
> creation/deletion of file  from windows agent 
> to my manager(linux). Agent show connected and active, I only get alert 
> from agent(win) is agent start/restart/change in ossec.conf(agent).
> To monitor D:\ drive, I have done the following changes in ossec.conf on 
> manager:
>
>   check_all="yes">C:.,D:.
>
> But i don't get any alerts on my manager.
>
> Can you please help me out.
>
> 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] Re: Don't Getting Alerts From Window Agent to Linux Manager

[Jesus Linares]

Hi,

check out the 
documentation: 
http://ossec-docs.readthedocs.io/en/latest/faq/syscheck.html#why-aren-t-new-files-creating-an-alert

Also, it is not a good idea to monitor all the partition:

   - *report_changes *creates a snapshot in the agent for each change.
   - *realtime *on Windows allows until 256 directories.

Syscheck should be for critical files.

Regards.

On Wednesday, May 31, 2017 at 10:04:38 AM UTC+2, Akash Munjal wrote:
>
>
> Hi All,
>
> I am also facing the same problem.I am not getting alert of 
> creation/deletion of file  from windows agent 
> to my manager(linux). Agent show connected and active, I only get alert 
> from agent(win) is agent start/restart/change in ossec.conf(agent).
> To monitor D:\ drive, I have done the following changes in ossec.conf on 
> manager:
>
>  C:.,D:. directories>
>
> But i don't get any alerts on my manager.
>
> Can you please help me out.
>
> 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] Re: Help with decoder

[Jesus Linares]

Hi,

your prematch is wrong:

   - log: [...] vd=root logdesc [...]
   - prematch: [...] vd=*"*\.+*"* [...]


Try this one:



fortigate-firewall-v5
type=event subtype=vpn level=
logdesc="\.+" msg="(\.+)" action=(\.*) remip=(\S+) locip=(\S+) 
\.*vpntunnel="(\.*)"
extra_data,action,dstip,srcip,status



**Phase 2: Completed decoding.
   decoder: 'fortigate-firewall-v5'
   extra_data: 'IPsec phase 2 status change'
   action: 'phase2-down'
   dstip: '1.1.1.1'
   srcip: '2.2.2.2'
   status: 'VPN_XPTO'


**Phase 3: Completed filtering (rules).
   Rule id: '81603'
   Level: '0'
   Description: 'Fortigate messages grouped.'


I hope it helps.
Regards.




On Sunday, May 28, 2017 at 4:41:24 PM UTC+2, RWagner wrote:
>
> Ooops!
>
> Correcting the decoder parent and my decoder:
>
> Decoder parent:
> 
> date=\S+ time=\.+ devname=\S+ devid=FG\w+ logid=\d+ 
> 
> syslog
> 
>
>
> My decoder:
> 
> fortigate-firewall-v5
> type=event subtype=vpn level=\S+ 
> vd="\.+" logdesc="\.+" msg=
> logdesc="\.+" msg="(\.+)" action=(\.*) remip=(\S+) locip=(\S+) 
> \.*vpntunnel="(\.*)"
> extra_data,action,dstip,srcip,status
> 
>
> Em domingo, 28 de maio de 2017 11:38:16 UTC-3, RWagner escreveu:
>>
>>
>> 
>> Hi Guys!
>>
>> I'm making a decoder for problems with vpn phase_2 for the fortigate.
>>
>> Sample log:
>> date=2017-05-20 time=07:31:20 devname=Fw1-sa-dc2d-g56 
>> devid=FGT60D00 logid=01016745858 type=event subtype=vpn 
>> level=notice vd=root logdesc="IPsec phase 2 status changed" msg="IPsec 
>> phase 2 status change" action=phase2-down remip=1.1.1.1 locip=2.2.2.2 
>> remport=500 locport=500 outintf="wan2" 
>> cookies="dfaf555664477957/b55566998873c6f9" user="N/A" group="N/A" 
>> xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="VPN_XPTO" 
>> phase2_name=VPN_XPTO
>>
>>
>> Decoder parent:
>> 
>>  date = \ S + time = \. + Devname = \ S + devid = FG \ w + 
>> logid = \ d +
>>  syslog 
>> 
>>
>>
>> My decoder:
>> 
>>  fortigate-firewall-v5 
>>  >  logdesc = "\. +" Msg = "(\. +)" Action = (\. *) Remip = (\ S 
>> +) locip = 
>>  extra_data, action, dstip, srcip, status 
>> 
>>
>> In the image with the test done with the logtest, does not show data 
>> extra_data, action, dstip, srcip, status.
>>
>> I wonder what's wrong with my decoder.
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

I don't know what is happening. Both, *regex* and *match *look in the *full_log 
*field. So it should work with regex (escaping reserved characters) and 
match. It looks like the full_log doesn't contain that information, only 
the filename. 

Anyway, if you are using Wazuh 2.0, the "title" and the "file" are 
extracted as dynamic fields 
<https://documentation.wazuh.com/current/user-manual/ruleset/dynamic-fields.html>.
 
Example:

*local_rules.xml*  (change the level to 0)


510
*File is owned by root and has written permissions 
to anyone*
Ignore this rule
rootcheck,


*alerts.log*
*Rule: 100510 (level 15) -> 'Ignore this rule'*
File '/var/lib/test' is owned by root and has written permissions to anyone.
title: File is owned by root and has written permissions to anyone.
file: /var/lib/test

You can use both fields to ignore only some files:
File is owned by root and has written permissions to 
anyone
good_file.txt

The  tag is a regex, so you can use wildcards (\.+ \.*), or (|), 
expressions (\w, \S), etc.

I hope it helps.



On Wednesday, May 24, 2017 at 5:32:48 AM UTC+2, Gert Verhoog wrote:
>
> I think I'm just really confused as to what "regex" and "match" are 
> actually matching against. Given the following log event:
>
> 2017 May 24 12:38:16 (ci-runner__development_12.34.56.78) any->rootcheck 
> File 
> '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt'
>  
> is owned by root and has written permissions to anyone.
>
> This rule successfully ignores it:
>
>   
> 510
> /var/lib/docker/volumes/\S+/_data
> Ignore this rule
> rootcheck,
>   
>
>
> But this one doesn't:
>
>   
> 510
> is owned by root and has written permissions to anyone
> Ignore this rule
> rootcheck,
>   
>
>
> What string does regex match against? The docs say "Any regex to match 
> against the log event"; that should include more than just the file path, 
> right?
>
> Cheers,
> Gert
>
>
>
> On Wednesday, May 24, 2017 at 1:02:24 PM UTC+12, Gert Verhoog wrote:
>>
>> Unfortunately, it's still not working, and I'm not sure what else I can 
>> try... This is what I'm doing:
>>
>> The log entries that I want to ignore all look like this (from 
>> archives.log):
>>
>> 2017 May 24 12:38:16 (ci-runner__development_12.34.56.78) any->rootcheck 
>> File 
>> '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt'
>>  
>> is owned by root and has written permissions to anyone.
>>
>> Inspired by rule 511 from the wazuh ruleset 
>> <https://github.com/wazuh/wazuh-ruleset/blob/f1e1e46e51faefbe75c79052d63437cc3c1a02b4/rules/0015-ossec_rules.xml#L63>,
>>  
>> I have the following rule in /var/ossec/etc/rules/local_rules.xml:
>>
>>   
>> 510 
>> is owned by root and has written permissions to anyone 
>> Ignore this rule 
>> rootcheck, 
>>   
>>
>> After editing the local rules file, I execute a 
>> "/var/ossec/bin/ossec-control restart" on the server, and after that also 
>> on the client. I wait for rootcheck to execute, which generates many 
>> entries such as the one above in the archives.log. Unfortunately, they 
>> still show up as a level 7 event in the kibana dashboard:
>>
>> rule.id:510 agent.name:ci-runner__development_12.34.56.78 agent.id:009 
>> manager.name:ec2-11-22-33-44.ap-southeast-2.compute.amazonaws.comrule.
>> firedtimes:1,700 rule.level:7 rule.description:Host-based anomaly 
>> detection event (rootcheck). rule.groups:ossec, rootcheck source:decoder.
>> name:rootcheck title:File is owned by root and has written permissions 
>> to anyone. full_log:File 
>> '/var/lib/docker/volumes/d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/path/to/some/file.txt'
>>  
>> is owned by root and has written permissions to anyone. @timestamp:May 
>> 24th 2017, 12:38:16.000 file:/var/lib/docker/volumes/
>> d758587e86d60a53043c93c1f730d6e04acdcb5f7a5a181182cfe0fb754aa293/_data/
>> path/to/some/file.txt host:ec2-11-22-33-44.ap-southeast-2.compute.
>> amazonaws.com location:rootcheck
>>
>>
>> Unfortunately, we can't just change the permissions of these without 
>> breaking our CI. I'm not very concerned about the world-writable files 
>> under /var/lib/docker/volumes, since only root can traverse this path 
>> anyway, so I would love to just ignore them, as they are about 90% of what 
>> shows up in the dashboards, so it drowns out other e

Re: [ossec-list] OSSEC slack alerts for agents v2.9.0

[Jesus Linares]

I see your point.. I thought you were talking about the *integratord*.

I never tried it using AR, but in your active-response configuration I see:

> local


It means that OSSEC is going to execute the script in the agent that 
generated the event. So, you must to configure your slack script in every 
agent. I think for this reason Daniel Cid created the integratord. 
<https://blog.sucuri.net/2016/01/server-security-integrating-ossec-with-slack-and-pagerduty.html>

I hope it helps.

On Tuesday, May 23, 2017 at 12:46:36 PM UTC+2, Fredrik Hilmersson wrote:
>
> Hello again Jesus,
>
> As I did state, so we're not misunderstanding each other, I do not run the 
> wazuh forked version, but the 2.9.0 OSSEC version.
> This is the configuration settings i've got:
>
> ossec-slack.sh
>
> SLACKUSER="ossec"
>
> CHANNEL="#channel"
>
> SITE="https://hooks.slack.com/services/...;
>
> SOURCE="ossec2slack"
>
> ossec.conf
>
> 
>
>ossec-slack
>
>ossec-slack.sh
>
> 
>
>no
>
>
>
>
> 
>
>    ossec-slack
>
>local
>
>7
>
>
>
> Kind regards,
> Fredrik
>
> Den tisdag 23 maj 2017 kl. 11:08:51 UTC+2 skrev Jesus Linares:
>>
>> Hi Fredrik,
>>
>> this is the flow:
>>
>>- The integrator reads the alerts from alerts*.log *filtering by 
>>*rule_id*, *level*, *group *or *event_location*.
>>- It executes the script using the arguments *hook_url *and *api_key*.
>>- The slack script send the alert to slack.
>>
>> Clarification: The host specific alerts are sent to slack but the agent 
>>> alerts are being ignored.
>>
>> Review your integrator configuration, maybe you have a filter to get only 
>> alerts in the current host. Share here the config.
>>
>> Regards.
>>
>>
>> On Tuesday, May 23, 2017 at 10:55:55 AM UTC+2, Fredrik Hilmersson wrote:
>>>
>>> Clarification: The host specific alerts are sent to slack but the agent 
>>> alerts are being ignored.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 slack alerts for agents v2.9.0

[Jesus Linares]

Hi Fredrik,

this is the flow:

   - The integrator reads the alerts from alerts*.log *filtering by 
   *rule_id*, *level*, *group *or *event_location*.
   - It executes the script using the arguments *hook_url *and *api_key*.
   - The slack script send the alert to slack.

Clarification: The host specific alerts are sent to slack but the agent 
> alerts are being ignored.

Review your integrator configuration, maybe you have a filter to get only 
alerts in the current host. Share here the config.

Regards.


On Tuesday, May 23, 2017 at 10:55:55 AM UTC+2, Fredrik Hilmersson wrote:
>
> Clarification: The host specific alerts are sent to slack but the agent 
> alerts are being ignored.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: problems registering agents

[Jesus Linares]

Hi,

it is a known issue in that version (1.1.1). It is related with the 
algorithm that assigns an agent ID. This issue is fixed in Wazuh 2.0.

Also, you can use the API to register agents remotely: 1.1.1 
<https://documentation.wazuh.com/1.1/ossec_api.html> and 2.0 
<https://documentation.wazuh.com/current/user-manual/api/index.html> API 
documentation.

Regards.

On Monday, May 22, 2017 at 6:56:10 PM UTC+2, Topper Bowers wrote:
>
> I deleted some of the lines starting with bang (!) but that didn't clear 
> up the problem. My client.keys is now smaller than 2048, but I still can't 
> add agents. I was able to duplicate this problem on a fresh install in 
> vagrant. Using the bin/manage_agents command I was able to add over 4k 
> clients (and clients.keys grew without problem). However, when I try to add 
> a new agent through authd... I get the same internal error problem.
>
> Results of commands:
>
> $ cat /var/ossec/etc/client.keys | wc -l
>
> 2032
>
> $ cat /var/ossec/etc/client.keys | grep -P "^\d+\s*\!" -v | wc -l
>
> 209
>
> $ cat /var/ossec/etc/client.keys | grep -P "^\d+\s*\!" | wc -l
>
> 1823
>
> On Mon, May 22, 2017 at 6:28 PM, Jesus Linares <je...@wazuh.com 
> > wrote:
>
>> Hi,
>>
>> as you mentioned, it seems that inactive agents are counting for the 
>> limit (2048 agents). Run the following commands in order to know the size 
>> of the *client.keys *file:
>>
>>- Total lines: cat /var/ossec/etc/client.keys | wc -l
>>- Active agents: cat /var/ossec/etc/client.keys | grep -P "^\d+\s*\!" 
>>-v | wc -l
>>- Inactive agents: cat /var/ossec/etc/client.keys | grep -P 
>>"^\d+\s*\!" | wc -l
>>
>> The solution could be clean the client.keys (lines with "!") after 
>> removing the agent.
>>
>> Regards.
>>
>>
>> On Monday, May 22, 2017 at 11:05:38 AM UTC+2, Topper Bowers wrote:
>>>
>>> Hi,
>>>
>>> My client has a highly dynamic environment and we're using OSSEC (wazuh 
>>> 1.1.1 release, OSSEC v2.8). When a server spins up, it registers itself as 
>>> an agent to the servers authd and everything was going ok. However, my 
>>> client.keys file is now 2048 lines long and no new agents can register. 
>>> They get an "(internal error)" that we see in the /var/ossec/logs/ossec.log
>>>
>>> We have a process in place to remove inactive agents using the 
>>> `/var/ossec/bin/manage_agents -r ${ossec_id}` command. And if you use 
>>> /var/ossec/bin/manage_agents -l only about 100 agents show up. 
>>>
>>> I've seen this 
>>> https://groups.google.com/forum/#!topic/ossec-list/lgFDOlR6zNg and it 
>>> looks remarkably similar to what we're seeing. However, we don't actually 
>>> have thousands of active agents. It seems like inactive agents are counting 
>>> against the limit. Since we have a really dynamic environment with servers 
>>> going up and down all the time, increasing the limit seems like it's just 
>>> pushing out the inevitable.
>>>
>>> In summary... dynamic environment, can't add new agents, only 100 or so 
>>> active agents, 2048 lines in client.keys. No other error messages besides 
>>> "internal error"
>>>
>>> Any suggestions?
>>>
>>> Thanks!
>>>
>>> Topper
>>>
>> -- 
>>
>> --- 
>> 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/k_MFr5aAjRU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> *Topper Bowers*
>
> *Engineering*
> *Vitals* | 160 Chubb Ave, Suite 301, Lyndhurst, NJ 07071, USA 
>
> M : 646.515.6630
>
> http://www.vitals.com
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 slack alerts for agents v2.9.0

[Jesus Linares]

Hi Fredrik,

check out the documentation about *integrator*
: 
https://documentation.wazuh.com/current/user-manual/manager/output-options/manual-integration.html

I hope it helps.
Regards.

On Monday, May 22, 2017 at 4:53:56 PM UTC+2, Fredrik Hilmersson wrote:
>
> Hello Miguelangel!
>
> I do not see any new rows regarding the agent-ossec.com (within the host 
> active-response.log, only in the alerts.log).
>
> Here's what you asked for from the ../etc/ossec.conf (server host)
>
> 
>
> ossec-slack
>
> ossec-slack.sh
>
>  
>
> no
>
> 
>
>
> 
>
> ossec-slack
>
> local
>
> 7
>
> 
>
> Kind regards,
> Fredrik
>
> Den måndag 22 maj 2017 kl. 16:47:54 UTC+2 skrev Miguelangel Freitas:
>>
>> Hi Fredrik,
>>
>> Can you see in logs/active-responses.log any new row regarding (
>> agent-ossec.com)?
>>
>> Could you share  and 
>>  from etc/ossec.conf regarding slack 
>> notification?, 
>> thanks.
>>
>> Regards,
>>
>> On Sun, May 21, 2017 at 4:18 PM, Fredrik Hilmersson <
>> f.hilm...@worldclearing.org> wrote:
>>
>>> I set up a OSSEC server along with an remote agent. The alert log file 
>>> is populated with alerts regarding both the host and the agent. However, 
>>> the integrated slack notification script only send reports regarding the 
>>> host. The only difference within the log is how the hostnames are 
>>> displayed, e.g., 2017-05-10, host-ossec.com.. and 2017-05-10, (
>>> agent-ossec.com). Is there anything i'm missing regarding my setup 
>>> which causes the script to dismiss the agent alerts? Any tip or help is 
>>> greatly appreciated.
>>>
>>> Kind regards,
>>> Fredrik
>>>
>>> -- 
>>>
>>> --- 
>>> You received this message because you are subscribed 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] Re: problems registering agents

[Jesus Linares]

Hi,

as you mentioned, it seems that inactive agents are counting for the limit 
(2048 agents). Run the following commands in order to know the size of the 
*client.keys 
*file:

   - Total lines: cat /var/ossec/etc/client.keys | wc -l
   - Active agents: cat /var/ossec/etc/client.keys | grep -P "^\d+\s*\!" -v 
   | wc -l
   - Inactive agents: cat /var/ossec/etc/client.keys | grep -P "^\d+\s*\!" 
   | wc -l
   
The solution could be clean the client.keys (lines with "!") after removing 
the agent.

Regards.


On Monday, May 22, 2017 at 11:05:38 AM UTC+2, Topper Bowers wrote:
>
> Hi,
>
> My client has a highly dynamic environment and we're using OSSEC (wazuh 
> 1.1.1 release, OSSEC v2.8). When a server spins up, it registers itself as 
> an agent to the servers authd and everything was going ok. However, my 
> client.keys file is now 2048 lines long and no new agents can register. 
> They get an "(internal error)" that we see in the /var/ossec/logs/ossec.log
>
> We have a process in place to remove inactive agents using the 
> `/var/ossec/bin/manage_agents -r ${ossec_id}` command. And if you use 
> /var/ossec/bin/manage_agents -l only about 100 agents show up. 
>
> I've seen this 
> https://groups.google.com/forum/#!topic/ossec-list/lgFDOlR6zNg and it 
> looks remarkably similar to what we're seeing. However, we don't actually 
> have thousands of active agents. It seems like inactive agents are counting 
> against the limit. Since we have a really dynamic environment with servers 
> going up and down all the time, increasing the limit seems like it's just 
> pushing out the inevitable.
>
> In summary... dynamic environment, can't add new agents, only 100 or so 
> active agents, 2048 lines in client.keys. No other error messages besides 
> "internal error"
>
> Any suggestions?
>
> Thanks!
>
> Topper
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

You can't use ossec-logtest for rootcheck events. For example, if I get the 
full_log of a real alert: "File 
'/usr/local/nsis/nsis-3.0b2-src/Contrib/Language files/Valencian.nlf' is 
owned by root and has written permissions to anyone." and I paste it in 
logtest:

*Phase 1: Completed pre-decoding.
   full event: 'File '/usr/local/nsis/nsis-3.0b2-src/Contrib/Language 
files/Valencian.nlf' is owned by root and has written permissions to 
anyone.'
   hostname: 'ip-10-0-0-10'
   program_name: '(null)'
   log: 'File '/usr/local/nsis/nsis-3.0b2-src/Contrib/Language files/
Valencian.nlf' is owned by root and has written permissions to anyone.'


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


So, ossec-logtest doesn't show anything, but the alert is properly 
generated. This is due to rootcheck has decoders at c-level.

Your rule looks right, just restart OSSEC and test it manually. Sometimes, 
OSSEC has problems with \.* so if that part doesn't have spaces, it is 
better to use \S*.

Let me know if it works.
Regards.


On Saturday, May 20, 2017 at 3:04:44 AM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, May 18, 2017 at 4:51 PM, Gert Verhoog <ge...@montoux.com 
> > wrote: 
> > Hi Jesus, 
> > 
> > I'm having the same problem, and the triggering of this rule causes so 
> much 
> > noise that it's drowning out other alerts. I have added a rule like you 
> > suggested to my local rules: 
> > 
> >
> > 510 
> > /var/lib/docker/volumes/\.*/_data/\.* is owned by root and 
> has 
> > written permissions to anyone 
> > Ignore rootcheck warning on world-writable docker 
> > volumes 
> >
> > 
> > But it doesn't seem to have an effect. I've played with the regex, 
> > simplifying it and even deleting it altogether, but I still can't seem 
> to 
> > get it working. Logtest shows the following output: 
> > 
> > 
> > File 
> > 
> '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot'
>  
>
> > is owned by root and has written permissions to anyone. 
> > 
>
> Is this the log message you get from the agent? You can turn on the 
> logall option and check archives.log for the exact message from the 
> agent. 
>
> > 
> > **Phase 1: Completed pre-decoding. 
> > 
> > 
> >full event: 'File 
> > 
> '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot'
>  
>
> > is owned by root and has written permissions to anyone.' 
> > 
> > 
> >hostname: 'ec2-12-34-56-78' 
> > 
> > 
> >program_name: '(null)' 
> > 
> > 
> >log: 'File 
> > 
> '/var/lib/docker/volumes/81c96e1d9b6a07710dc0ba90daccf5650efe59e213b20354bbb86f4e65929a0e/_data/path/to/static/fonts/icons/glyphicons-social-regular.eot'
>  
>
> > is owned by root and has written permissions to anyone.' 
> > 
> > 
> > 
> > 
> > **Phase 2: Completed decoding. 
> > 
> > 
> >No decoder matched. 
> > 
> > 
> > 
> > I'm fairly new to OSSEC and Wazuh, so I may be missing something. Is 
> there 
> > anything obvious that I'm doing wrong? 
> > 
> > Cheers! 
> > Gert 
> > 
> > 
> > 
> > On Wednesday, April 19, 2017 at 12:14:28 AM UTC+12, Jesus Linares wrote: 
> >> 
> >> Hi Rob, 
> >> 
> >> you need to add the conditions to trigger that rule only for your 
> specific 
> >> files. Use match or regex: 
> >> 
> >>  
> >> 510 
> >>  
> >> Ignore rule 510 for 600 seconds for some 
> >> files. 
> >>  
> > 
> > 
> > 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] TargetUserName is not mapped to an indexed field

[Jesus Linares]

Hi all,

I think there is a misunderstanding. According to your *full_log*, I can 
see 2 "Account name" fields, the first one is *SubjectUserName*, and the 
second one is *TargetUserName*. We are only extracting the *SubjectUserName* 
as *Account name*. So, if you paste here your log, I can improve the 
decoder to extract both fields.

Anyway, we are thinking how to improve OSSEC to extract all the windows 
fields automatically (using dynamic fields 
<https://documentation.wazuh.com/current/user-manual/ruleset/dynamic-fields.html>)
 
with the proper name.

Regards.


On Wednesday, May 17, 2017 at 10:30:41 AM UTC+2, Pedro Sanchez wrote:
>
> Hi AntonH,
>
> I can see your full_log on Kibana screenshots, it seems like even OSSEC is 
> not getting that field on the raw_log, meaning we are not extracting it 
> from the EventChannel.
> Currently OSSEC is not extracting all the fields detail on the XML, 
> related code: 
> https://github.com/wazuh/wazuh/blob/master/src/logcollector/read_win_event_channel.c#L738
>
> Related issues / mails:
>
> "OSSEC Windows Agent fails to extract data from some eventchannel events"
> https://github.com/wazuh/wazuh/issues/101
>
> "Potential Bug: Windows Security Event ID 5140 incorrectly parsed by 
> OSSEC."
> https://groups.google.com/forum/#!topic/ossec-list/GnA9qGZw9MU
>
> "Bug in Windows ossec-agent: Windows event ID 4664 is misread."
> https://groups.google.com/forum/#!topic/wazuh/OnHqGX8uml0
>
> Mainly OSSEC is subscribing  to a certain channel, extracting some fields 
> manually 
> <https://github.com/wazuh/wazuh/blob/master/src/logcollector/read_win_event_channel.c#L738-L813>
>  
> (name, id, source, uid, computer, level...) and adding to the event the 
> string returned by calling Windows function EvtFormatMessage 
> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa385359(v=vs.85).aspx>
> ().
> I am not sure right now how to get TargetUserName from the event log, but 
> I will study it if I have some time.
>
> As Jesus said, once we got that windows field in "full_log" field you will 
> only need to add new decoders to extract it and populate it to Kibana.
>
>
> Regards,
> Pedro Sanche.
>
>
>
>
>
> On Mon, May 15, 2017 at 10:19 AM, Jesus Linares <je...@wazuh.com 
> > wrote:
>
>> Hi AntonH,
>>
>> you don't see *TargetUserName *in Kibana, because OSSEC decoders are not 
>> extracting that field. We will need to improve them.
>>
>> Could you paste the raw log (*full_log*) here?. Once we update the 
>> decoders and you install them, the new events will come with the 
>> *TargetUserName 
>> *extracted.
>>
>> Regards.
>>
>> On Saturday, May 13, 2017 at 1:52:46 AM UTC+2, dan (ddpbsd) wrote:
>>>
>>> On Fri, May 12, 2017 at 4:40 AM, AntonH <an...@inkcreations.com> wrote: 
>>> > Hello, 
>>> > 
>>> > I'm using Wazuh and I don't know how to map TargetUserName to an 
>>> indexed 
>>> > field. 
>>> > Security events are generated but the associated username is not 
>>> mapped so 
>>> > there is no way to search for or display the culprit. 
>>> > 
>>> > The field marked yellow is not mapped or indexed. 
>>> > 
>>> > 
>>> > Corresponding xml event from eventvwr 
>>> > 
>>> > 
>>> > I'm using the ossec-agent to transport logs to Wazuh v2.0 
>>> > 
>>> > 
>>> > I hope someone can help me. 
>>> > 
>>>
>>> It might be better to ask Wazuh about their project. 
>>>
>>> > 
>>> > -- 
>>> > 
>>> > --- 
>>> > You received this message because you are subscribed 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.

Re: [ossec-list] TargetUserName is not mapped to an indexed field

[Jesus Linares]

Hi AntonH,

you don't see *TargetUserName *in Kibana, because OSSEC decoders are not 
extracting that field. We will need to improve them.

Could you paste the raw log (*full_log*) here?. Once we update the decoders 
and you install them, the new events will come with the *TargetUserName *
extracted.

Regards.

On Saturday, May 13, 2017 at 1:52:46 AM UTC+2, dan (ddpbsd) wrote:
>
> On Fri, May 12, 2017 at 4:40 AM, AntonH  > wrote: 
> > Hello, 
> > 
> > I'm using Wazuh and I don't know how to map TargetUserName to an indexed 
> > field. 
> > Security events are generated but the associated username is not mapped 
> so 
> > there is no way to search for or display the culprit. 
> > 
> > The field marked yellow is not mapped or indexed. 
> > 
> > 
> > Corresponding xml event from eventvwr 
> > 
> > 
> > I'm using the ossec-agent to transport logs to Wazuh v2.0 
> > 
> > 
> > I hope someone can help me. 
> > 
>
> It might be better to ask Wazuh about their project. 
>
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] Active Response not working at all

[Jesus Linares]

Hi,

you are right Tony. The syntax for *ossec.conf* is not user-friendly. You 
must think in the following way:

If it is a setting like yes/no, it will be overwritten if the parser found 
the same setting below. Example:


  yes



  no


The final value will be 'no'.

However, if the setting is like a *list*, it will be append it if the 
parser found the same setting below. Example:

   /var/ossec/etc/shared/system_audit_rcl.txt



   /var/ossec/etc/shared/system_audit_ssh.txt


The final value will be:

   /var/ossec/etc/shared/system_audit_rcl.txt
   /var/ossec/etc/shared/system_audit_ssh.txt


This kind of merge only happens for some sections. For example, it doesn't 
happen for *localfile, agentless, command, remote *and* syslog_output.*

I hope some day we can improve the syntax:


yes
10.10.10.10


...




   
   ...
   



Regards.
 


On Thursday, April 27, 2017 at 11:27:49 PM UTC+2, Tony Bryant wrote:
>
> For anyone curious it was an incredibly simple fix :(. Apparently if any 
> active-responses in your ossec.config file are disabled, it will disable 
> all of the active responses. I had 4 enabled and 1 disabled, but because of 
> that 1, they all were disabled.
>
> On Wednesday, April 19, 2017 at 3:42:46 PM UTC-7, Tony Bryant wrote:
>>
>> Hmm, ok, is this the only active-response config on your agent? I'm not 
>> seeing any so that may be my problem. Is it one active-response config for 
>> all (like the one you posted below should serve all future ARs)? And what I 
>> posted was on the server. I'll give this a try though
>>
>> On Wednesday, April 19, 2017 at 2:54:55 PM UTC-7, dan (ddpbsd) wrote:
>>>
>>> On Wed, Apr 19, 2017 at 5:34 PM, Tony Bryant  
>>> wrote: 
>>> > How would I go about checking if AR is disabled on agents? Checking 
>>> config 
>>> > files and don't see anything about it. Running v2.8.3 for OSSEC. Also, 
>>> this 
>>> > on Ubuntu 
>>> > 
>>>
>>> I think it's enabled by default. This is all I have on one of my agents: 
>>>
>>> no 
>>> 15,60,1440,86400 
>>>
>>>
>>>
>>> > On Wednesday, April 19, 2017 at 2:21:47 PM UTC-7, dan (ddpbsd) wrote: 
>>> >> 
>>> >> On Wed, Apr 19, 2017 at 5:09 PM, Rob Williams  
>>> wrote: 
>>> >> > Still no luck. Just to verify, the scripts should be located in 
>>> >> > /var/ossec/active-response/bin/, correct? Unfortunately the logs 
>>> aren't 
>>> >> > really telling me anything either. 
>>> >> > 
>>> >> 
>>> >> Yep, that's where they go. 
>>> >> AR isn't disabled on the agents is it? 
>>> >> What version of OSSEC? What OS/distro are you using? I don't think 
>>> >> I'll be able to setup anything to try and recreate this. 
>>> >> 
>>> >> 
>>> >> 
>>> >> > On Wednesday, April 19, 2017 at 12:31:41 PM UTC-7, dan (ddpbsd) 
>>> wrote: 
>>> >> >> 
>>> >> >> On Wed, Apr 19, 2017 at 3:23 PM, Tony Bryant  
>>> >> >> wrote: 
>>> >> >> > Yes test.sh is on the agent. Execd is also running and yep the 
>>> alert 
>>> >> >> > is 
>>> >> >> > firing. 
>>> >> >> > 
>>> >> >> 
>>> >> >> Try removing the level option and leave just the rules_id. 
>>> >> >> 
>>> >> >> > On Wednesday, April 19, 2017 at 11:30:37 AM UTC-7, dan (ddpbsd) 
>>> >> >> > wrote: 
>>> >> >> >> 
>>> >> >> >> On Wed, Apr 19, 2017 at 2:26 PM, Tony Bryant <
>>> cspit...@gmail.com> 
>>> >> >> >> wrote: 
>>> >> >> >> > Hello, 
>>> >> >> >> > 
>>> >> >> >> > I'm pretty new to OSSEC and I'm working to get some active 
>>> >> >> >> > responses 
>>> >> >> >> > working. I have tried a number of different active responses 
>>> but 
>>> >> >> >> > cannot 
>>> >> >> >> > seem 
>>> >> >> >> > to get it to work anywhere (not on the server or agents). I'm 
>>> now 
>>> >> >> >> > trying 
>>> >> >> >> > a 
>>> >> >> >> > simple AR to just log to active-responses.log but it still 
>>> does 
>>> >> >> >> > not 
>>> >> >> >> > seem 
>>> >> >> >> > to 
>>> >> >> >> > be triggering. I do receive the email alert, but the AR does 
>>> not 
>>> >> >> >> > trigger. 
>>> >> >> >> > Here is my config for the test active response: 
>>> >> >> >> > 
>>> >> >> >> >  
>>> >> >> >> > 
>>> >> >> >> >test 
>>> >> >> >> > 
>>> >> >> >> >test.sh 
>>> >> >> >> > 
>>> >> >> >> > 
>>> >> >> >> > 
>>> >> >> >> >no 
>>> >> >> >> > 
>>> >> >> >> >  
>>> >> >> >> > 
>>> >> >> >> > (I've tried the location as local, all, and server but no 
>>> luck) 
>>> >> >> >> > 
>>> >> >> >> >  
>>> >> >> >> > 
>>> >> >> >> >no 
>>> >> >> >> > 
>>> >> >> >> >test 
>>> >> >> >> > 
>>> >> >> >> >local 
>>> >> >> >> > 
>>> >> >> >> >70999 
>>> >> >> >> > 
>>> >> >> >> >0 
>>> >> >> >> > 
>>> >> >> >> >  
>>> >> >> >> > 
>>> >> >> >> > 
>>> >> >> >> > 
>>> >> >> >> > #!/bin/sh 
>>> >> >> >> > 
>>> >> >> >> > ACTION=$1 
>>> >> >> >> > USER=$2 
>>> >> >> >> > IP=$3 
>>> >> >> >> > ALERTID=$4 
>>> >> >> >> > RULEID=$5 
>>> >> >> >> > 
>>> >> >> >> > LOCAL=`dirname $0`; 
>>> >> >> >> > cd $LOCAL 
>>> >> >> >> > cd ../ 
>>> >> 

Re: [ossec-list] i dos'd myself but ossec did not record it

[Jesus Linares]

OSSEC will detect the DoS attack only if it is monitoring a log file which 
contains an event related to DoS and probably you will have to create some 
decoders/rules.

Regards.

On Wednesday, April 26, 2017 at 9:35:44 PM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Apr 26, 2017 at 3:27 PM, Sargeras  > wrote: 
> > Greetings, I recently installed ossec (ubuntu VM) and in order to verify 
> its 
> > abilities, i dos'd myself on a kali vm I also installed, but as it seems 
> > ossec did not recorded it.anyone can help me out? 
> > 
>
> What kind of DoS? What logs were produced by this DoS? 
> What alerts were you expecting from OSSEC? 
>
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] Disable all rules for ossec server

[Jesus Linares]

I don't know if it is possible, but why do you want to do it?.

On Wednesday, April 26, 2017 at 11:42:22 AM UTC+2, Huc Manté Miras wrote:
>
> I try to remove all includes but not work :(
>
> El martes, 25 de abril de 2017, 17:41:56 (UTC+2), dan (ddpbsd) escribió:
>>
>>
>>
>> On Apr 25, 2017 11:25 AM, "Huc Manté Miras"  wrote:
>>
>> Hello,
>>
>> I try to disable all rules to ossec server.
>>
>> This is possible?
>>
>>
>> Have you tried removing the rules from the server's ossec.conf?
>>
>>
>>
>> Thanks!!
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@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] Re: Override eventlog with eventchannel via Centralized agent config

[Jesus Linares]

Hi Brett,

here you can find information about the configuration 
preference: 
https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html#precedence

In your case, both configurations are applying. Also, I recommend you to 
filter other noisy events 
.

Regards.

On Thursday, April 20, 2017 at 6:26:18 PM UTC+2, Brett Simpson wrote:
>
> I wasn't sure how to do this or if it's possible but I have a large number 
> of ossec agents where I want to filter out specific Windows Event ID agent 
> side. If I modify the ossec.conf on the agent and replace the log_format of 
> my System from eventlog  to eventchannel it works however if I leave it to 
> eventlog and alter the centralized agent config to include that for Windows 
> OS it doesn't work. I do see it get replicated to the agent under the 
> shared folder but it looks like eventlog is taking priority. Touching each 
> agent is not feasible as I just don't have that kind of control, at least I 
> would have to somehow repackage an ossec install and wrap a new config into 
> it, then have my IT people reinstall it on hundreds of Windows systems. 
> Although I'm testing filtering event ID 7000 on a workstation I have many 
> Windows servers with the windows packet filtering bombarding the event 
> logs. This ends up saturating my network links from the agent to the 
> manager which I want to eliminate.
>
> In ossec.conf
>   
> System
> eventlog
>   
>
> In Shared folder as agent.conf
> 
>
>   
> System
> eventchannel
> Event/System[EventID!=7000]
>   
>
> 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

Hi Rob,

you need to add the conditions to trigger that rule only for your specific 
files. Use match or regex:


510

Ignore rule 510 for 600 seconds for some files.



I think you can't use *same_id *because the decoders are not extracting any 
ID.

Regards.

On Monday, April 17, 2017 at 6:55:19 PM UTC+2, Rob Williams wrote:
>
> Hi Jesus, the first rule is what I am trying. You said I can match the 
> file in  but can I do that when the file changes as is not one file 
> I want to ignore. Can I use regex syntax in rules? I used it in decoders as 
> I thought I wasn't able to. Thanks!
>
> 
> 510
> 
> Ignore rule 510 for 600 seconds if the same ID is 
> matched.
> 
>
> On Monday, April 17, 2017 at 3:16:48 AM UTC-5, Jesus Linares wrote:
>>
>> What rule did you use?. Please, share here the rule and the alerts that 
>> you want to ignore.
>>
>> I'd need the ID from the decoder to do so
>>
>> There are no xml decoders for rootcheck. What you want to extract in the 
>> id field is the file, right?. You can do a *match* in the rule for the 
>> file.
>>
>> Regards.
>>
>> On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>>>
>>> Hi Jesus,
>>>
>>> Thanks for the reply. I have noticed when I activate this rule, it 
>>> blocks all events and does not alert on the first event. Also note, I am 
>>> trying to use the ID field from my decoder to match against. I can't just 
>>> use a static match as the ID continuously changes so I'd need the ID from 
>>> the decoder to do so. Any ideas? Thanks!
>>>
>>> On Wednesday, April 5, 2017 at 12:26:31 PM UTC-7, Rob Williams wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I'm running into an issue where rule 510 is triggering and I'm getting 
>>>> spammed with alerts but I can't seem to tune it correctly. What's weird is 
>>>> that I am still getting alerted for rule 510 for this log, but I can't 
>>>> figure out how to get that to show in logtest. Basically, I am getting 
>>>> spammed with rule 510 and trying to filter it down more and here is what 
>>>> happens when I enter the log in logtest: any ideas on how to fix 
>>>> this?
>>>>
>>>> **Phase 1: Completed pre-decoding.
>>>>
>>>>full event: 'File '/filepath/' is owned by root and has written 
>>>> permissions to anyone.'
>>>>
>>>>hostname: 'hostname'
>>>>
>>>>program_name: '(null)'
>>>>
>>>>log: 'File '/filepath/' is owned by root and has written 
>>>> permissions to anyone.'
>>>>
>>>>
>>>> **Phase 2: Completed decoding.
>>>>
>>>>decoder: 'sample_decoder_setup'
>>>>
>>>>id: '/filepath/'
>>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

What rule did you use?. Please, share here the rule and the alerts that you 
want to ignore.

I'd need the ID from the decoder to do so

There are no xml decoders for rootcheck. What you want to extract in the id 
field is the file, right?. You can do a *match* in the rule for the file.

Regards.

On Friday, April 14, 2017 at 12:13:50 AM UTC+2, Rob Williams wrote:
>
> Hi Jesus,
>
> Thanks for the reply. I have noticed when I activate this rule, it blocks 
> all events and does not alert on the first event. Also note, I am trying to 
> use the ID field from my decoder to match against. I can't just use a 
> static match as the ID continuously changes so I'd need the ID from the 
> decoder to do so. Any ideas? Thanks!
>
> On Wednesday, April 5, 2017 at 12:26:31 PM UTC-7, Rob Williams wrote:
>>
>> Hi all,
>>
>> I'm running into an issue where rule 510 is triggering and I'm getting 
>> spammed with alerts but I can't seem to tune it correctly. What's weird is 
>> that I am still getting alerted for rule 510 for this log, but I can't 
>> figure out how to get that to show in logtest. Basically, I am getting 
>> spammed with rule 510 and trying to filter it down more and here is what 
>> happens when I enter the log in logtest: any ideas on how to fix 
>> this?
>>
>> **Phase 1: Completed pre-decoding.
>>
>>full event: 'File '/filepath/' is owned by root and has written 
>> permissions to anyone.'
>>
>>hostname: 'hostname'
>>
>>program_name: '(null)'
>>
>>log: 'File '/filepath/' is owned by root and has written 
>> permissions to anyone.'
>>
>>
>> **Phase 2: Completed decoding.
>>
>>decoder: 'sample_decoder_setup'
>>
>>id: '/filepath/'
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 soon does an agent disconnect appear

[Jesus Linares]

Check out *notify_time* and *time-reconnect*
: 
http://ossec-docs.readthedocs.io/en/latest/syntax/head_ossec_config.client.html#ossec-conf-client-options

On Friday, April 14, 2017 at 12:08:02 AM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Apr 12, 2017 at 4:01 PM, Nikki S  > wrote: 
> > How long does it take for the agent to appear as 'disconnected'?  I read 
> on 
> > another thread that the 'keep alive' needs to fail three times. I could 
> not 
> > find where we set the frequency of the agent check in. 
> > 
>
> I think it's 10 minutes, and I don't think it's currently configurable 
> in ossec.conf. 
>
> > 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+...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

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

Re: [ossec-list] Is it possible to trigger an active response on a rule with a severity level of 0?

[Jesus Linares]

Hi Rob,

I'm not sure, but you can increase the level to 1 and:

set the attribute noalert 

:



or use the options no_log 

:

no_log

Let me know if it works.

Regards.



On Friday, April 14, 2017 at 12:05:08 AM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Apr 12, 2017 at 1:40 PM, Rob Williams  > wrote: 
> > Essentially, I want to trigger an active response for a rule that I 
> created 
> > that has a severity level of 0. I created this rule because I did not 
> want 
> > to be alerted on the default rule and only wanted to be alerted based on 
> the 
> > output from my active response. My question is if I have the severity 
> level 
> > of 0, will it just be completely ignored without the active response 
> even 
> > triggering? I ask because I'm having trouble setting it up properly and 
> want 
> > to rule out if this is the cause. Thank you for your help in advance. 
> > 
>
> I think it will be ignored, but I've never tried it. You could try 
> bumping the level to 1 to see if that fixes the issue. 
>
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

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

Re: [ossec-list] Re: Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

Hi Rob,

it is not possible to create decoders for rootcheck because they are at C 
level: https://github.com/wazuh/wazuh/blob/master/src/analysisd/analysisd.c#L772

Also, you don't need them, just create a rule like:


510
your conditions (match the file?)
Ignore rule 510 during 300 seconds.



Example for ignore completely a rootcheck 
event: 
https://github.com/wazuh/wazuh-ruleset/blob/f1e1e46e51faefbe75c79052d63437cc3c1a02b4/rules/0015-ossec_rules.xml#L63

Also, you can disable the check in the *ossec.conf*.

I hope it helps.
Regards.

On Thursday, April 6, 2017 at 7:44:57 PM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, Apr 6, 2017 at 1:28 PM, Rob Williams  > wrote: 
> > Hi, 
> > 
> > I tried to do this, but I'm getting: 
> > 
> > ERROR: Parent decoder name invalid: 'rootcheck' 
> > ERROR: Error adding decoder plugin 
> > 
> > I don't see the rootcheck decoder within decoder.xml as well, any ideas? 
> > 
>
> It must be one of the built in decoders, and I guess those can't be 
> used for child decoders. 
> No other ideas at the moment, but I'll keep thinking about it. 
>
> > Thanks again for the help! 
> > 
> > 
> > On Wednesday, April 5, 2017 at 12:26:31 PM UTC-7, Rob Williams wrote: 
> >> 
> >> Hi all, 
> >> 
> >> I'm running into an issue where rule 510 is triggering and I'm getting 
> >> spammed with alerts but I can't seem to tune it correctly. What's weird 
> is 
> >> that I am still getting alerted for rule 510 for this log, but I can't 
> >> figure out how to get that to show in logtest. Basically, I am getting 
> >> spammed with rule 510 and trying to filter it down more and here is 
> what 
> >> happens when I enter the log in logtest: any ideas on how to 
> fix 
> >> this? 
> >> 
> >> **Phase 1: Completed pre-decoding. 
> >> 
> >>full event: 'File '/filepath/' is owned by root and has written 
> >> permissions to anyone.' 
> >> 
> >>hostname: 'hostname' 
> >> 
> >>program_name: '(null)' 
> >> 
> >>log: 'File '/filepath/' is owned by root and has written 
> >> permissions to anyone.' 
> >> 
> >> 
> >> **Phase 2: Completed decoding. 
> >> 
> >>decoder: 'sample_decoder_setup' 
> >> 
> >>id: '/filepath/' 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] Re: OSSEC Rule to alert on the first event, but ignore the rest for a 5 minute period.

[Jesus Linares]

Hi Jakes,

the first instance should trigger the normal rule, then the rule 70908 
should ignore the event during 300 seconds. I didn't test it...

Let me know if it works.
Regards.

On Thursday, April 6, 2017 at 7:14:01 PM UTC+2, Jake B. wrote:
>
> Hi Jesus,
>
> Thanks for the reply. Would this also alert on the first instance of this? 
> I still do want to alert, but I want to avoid the spam that comes with it 
> as it typically happens in large batches with little to no difference in 
> meaning between the different events.
>
> Thanks!
>
> On Thursday, April 6, 2017 at 1:24:05 AM UTC-7, Jesus Linares wrote:
>>
>> Hi Jake,
>>
>> take a look at rule 511 
>> <https://github.com/wazuh/wazuh-ruleset/blob/f1e1e46e51faefbe75c79052d63437cc3c1a02b4/rules/0015-ossec_rules.xml#L63>.
>>  
>> It is the way to ignore a event coming from rule 510. You could do the same 
>> with a composite rule, it would be something like:
>>
>> 
>> 510
>> your_file
>> Ignore rule 510 for 'your_file' during 300 seconds.
>> 
>> 
>>
>> frequency=”0” would mean the rule must be matched 2 times (frequency is 
>> always +2 than the setting).
>> level 0 will not generate an alert (for testing you could increase it).
>>
>> I hope it help.
>> Regards.
>>
>>
>> On Wednesday, April 5, 2017 at 5:11:22 PM UTC+2, Jake B. wrote:
>>>
>>> Hello,
>>>
>>> I have alerts coming in huge batches for rule 510. The batches of alerts 
>>> are essentially all the same event and the file path of the area that's 
>>> causing this is essentially identical in each batch except for the last 
>>> file. I'm trying to setup a rule that would look at the ID I setup in my 
>>> decoder, which is a file path that takes the path except for the last file 
>>> in order to match the batches of events. I want to alert only on the first 
>>> one and ignore the rest with that same ID for 5 minutes. First of all, does 
>>> the rule below look ok for this? Does frequency="0" work as I know the 
>>> frequency essentially adds 2 to it? Also, I'm having another issue with 
>>> this in particular is that ossec-logtest does not test this rule correctly 
>>> at all. Even when I paste the message, it doesn't even show up as something 
>>> that would trigger rule 510, which is what the alerts are coming as. So 
>>> that is also making it hard to troubleshoot this. Any ideas? Thanks!
>>>
>>>  
>>> 510 my_decoder 
>>>  *TEST* - Only alert on the first docker root event 
>>> for the same host and file path in a 60 second range. 
>>> *TEST* - This is meant to reduce noise as docker root events 
>>> typically happen in batches with not much difference in 
>>> meaning. 
>>>
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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] Rule 510 is triggering events but logtest is not showing any rules that should be triggered

[Jesus Linares]

Hi,

check this 
out: https://groups.google.com/forum/#!topic/ossec-list/USAF6jF8yk8

Regards.

On Wednesday, April 5, 2017 at 10:45:52 PM UTC+2, Rob Williams wrote:
>
> I stopped them all (which appeared to work fine) and start again. Here is 
> the rule and decoder I made for this (I want to alert only once if the same 
> ID (filepath) has alerted in the past minute):
>
> 
>
> 510
>
> 
>
> This is meant to reduce noise as these events happen in 
> batches with not much difference in meaning.
>
>   
>
>
> DECODER:
>
>
> 
>
>   ^(\.+) (\p/filepath\.+) 
>
>   (/filepath/\.+/mnt/\.+/)
>
>   id
>
> 
>
>
> Logtest returns the id I am looking for to match and that part works fine. 
> It only gets to the first 2 steps though, and does not match it with a rule 
> in logtest.
> On Wednesday, April 5, 2017 at 12:48:21 PM UTC-7, dan (ddpbsd) wrote:
>>
>> On Wed, Apr 5, 2017 at 3:44 PM, Rob Williams  
>> wrote: 
>> > Yes I have, I've also tried to disable all the relevant changes I've 
>> made, 
>> > restart, and still have the same issue. 
>> > 
>>
>> Try stopping the ossec processes, verify that ossec-analysisd has 
>> stopped (sometimes it doesn't and causes issues), and start it back 
>> up. 
>> Can you also post the changes you made? 
>>
>> > On Wednesday, April 5, 2017 at 12:39:42 PM UTC-7, dan (ddpbsd) wrote: 
>> >> 
>> >> On Wed, Apr 5, 2017 at 3:26 PM, Rob Williams  
>> wrote: 
>> >> > Hi all, 
>> >> > 
>> >> > I'm running into an issue where rule 510 is triggering and I'm 
>> getting 
>> >> > spammed with alerts but I can't seem to tune it correctly. What's 
>> weird 
>> >> > is 
>> >> > that I am still getting alerted for rule 510 for this log, but I 
>> can't 
>> >> > figure out how to get that to show in logtest. Basically, I am 
>> getting 
>> >> > spammed with rule 510 and trying to filter it down more and here is 
>> what 
>> >> > happens when I enter the log in logtest: any ideas on how to 
>> fix 
>> >> > this? 
>> >> > 
>> >> > **Phase 1: Completed pre-decoding. 
>> >> > 
>> >> >full event: 'File '/filepath/' is owned by root and has 
>> written 
>> >> > permissions to anyone.' 
>> >> > 
>> >> >hostname: 'hostname' 
>> >> > 
>> >> >program_name: '(null)' 
>> >> > 
>> >> >log: 'File '/filepath/' is owned by root and has written 
>> >> > permissions 
>> >> > to anyone.' 
>> >> > 
>> >> > 
>> >> > **Phase 2: Completed decoding. 
>> >> > 
>> >> >decoder: 'sample_decoder_setup' 
>> >> > 
>> >> >id: '/filepath/' 
>> >> > 
>> >> 
>> >> Did you restart the OSSEC processes on the server after making your 
>> >> modifications? 
>> >> 
>> >> > -- 
>> >> > 
>> >> > --- 
>> >> > You received this message because you are subscribed 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.

[ossec-list] Re: OSSEC Rule to alert on the first event, but ignore the rest for a 5 minute period.

[Jesus Linares]

Hi Jake,

take a look at rule 511 
.
 
It is the way to ignore a event coming from rule 510. You could do the same 
with a composite rule, it would be something like:


510
your_file
Ignore rule 510 for 'your_file' during 300 seconds.



frequency=”0” would mean the rule must be matched 2 times (frequency is 
always +2 than the setting).
level 0 will not generate an alert (for testing you could increase it).

I hope it help.
Regards.


On Wednesday, April 5, 2017 at 5:11:22 PM UTC+2, Jake B. wrote:
>
> Hello,
>
> I have alerts coming in huge batches for rule 510. The batches of alerts 
> are essentially all the same event and the file path of the area that's 
> causing this is essentially identical in each batch except for the last 
> file. I'm trying to setup a rule that would look at the ID I setup in my 
> decoder, which is a file path that takes the path except for the last file 
> in order to match the batches of events. I want to alert only on the first 
> one and ignore the rest with that same ID for 5 minutes. First of all, does 
> the rule below look ok for this? Does frequency="0" work as I know the 
> frequency essentially adds 2 to it? Also, I'm having another issue with 
> this in particular is that ossec-logtest does not test this rule correctly 
> at all. Even when I paste the message, it doesn't even show up as something 
> that would trigger rule 510, which is what the alerts are coming as. So 
> that is also making it hard to troubleshoot this. Any ideas? Thanks!
>
>  
> 510 my_decoder 
>  *TEST* - Only alert on the first docker root event 
> for the same host and file path in a 60 second range. 
> *TEST* - This is meant to reduce noise as docker root events 
> typically happen in batches with not much difference in 
> meaning. 
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Detecting Powershell

[Jesus Linares]

Hi,

Sysmon has several events (1, 11, 15) that can be used to monitor 
Powershell executions.

Sysmon - Event 1

> 2017 Mar 29 13:36:36 WinEvtLog: Microsoft-Windows-Sysmon/Operational: 
> INFORMATION(1): Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: 
> WIN-P57C9KN929H: Process Create:  UtcTime: 2017-03-29 11:36:36.964 
>  ProcessGuid: {DB577E3B-9C44-58DB--0010B0983A00}  ProcessId: 3784 * 
> Image: 
> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe*  CommandLine: 
> "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-file" 
> "C:\Users\Alberto\Desktop\test.ps1"  CurrentDirectory: 
> C:\Users\Alberto\Desktop\  User: WIN-P57C9KN929H\Alberto  LogonGuid: 
> {DB577E3B-89E5-58DB--0020CB290500}  LogonId: 0x529cb 
>  TerminalSessionId: 1  IntegrityLevel: Medium  Hashes: 
> MD5=92F44E405DB16AC55D97E3BFE3B132FA,SHA256=6C05E11399B7E3C8ED31BAE72014CF249C144A8F4A2C54A758EB2E6FAD47AEC7
>  
>  ParentProcessGuid: {DB577E3B-89E6-58DB--0010FA3B0500} 
>  ParentProcessId: 2308  ParentImage: C:\Windows\explorer.exe 
>  ParentCommandLine: C:\Windows\Explorer.EXE


I'm improving the Sysmon decoders/rules, I will update them 
in: https://github.com/wazuh/wazuh-ruleset. In my lab, the following rule 
is working:


sysmon_event1
powershell.exe|.ps1|.ps2
Sysmon - Event 1: Use of Powershell
sysmon_event1,powershell_execution,


I hope it help.
Regards.

On Monday, April 3, 2017 at 4:48:39 PM UTC+2, namobud...@gmail.com wrote:
>
> I'm looking for a rule to put in local_rules.xml that will detect 
> powershell activity.
>
> Also it would be great to hear about what modifications and special rules 
> folks have created.
>
> 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.

Re: [ossec-list] time based exceptions

[Jesus Linares]

Hi,

there are rules for that 
in 
https://github.com/wazuh/wazuh-ruleset/blob/master/rules/0215-policy_rules.xml. 
They are included by default, but not enabled.

Regards.

On Thursday, March 30, 2017 at 12:20:39 AM UTC+2, jose wrote:
>
> Hi mscrano, yes you can do that, 
>
> example:
>
> 
>   100125
>   6 pm – 8:30 am
>   Login outside business hours.  
>   policy_violation
> 
>
> http://ossec-docs.readthedocs.io/en/latest/syntax/head_rules.html#element-time
>  
>
>
> Regards
> ---
> Jose Luis Ruiz
> Wazuh Inc.
> jo...@wazuh.com 
>
> On March 29, 2017 at 6:17:37 PM, msc...@ieee.org  (
> msc...@ieee.org ) wrote:
>
> Hi Ossec-list, 
> I am wondering if anyone else has run into this issue, I have a cron that 
> runs at the same time every day and it always triggers the promiscuous mode 
> rule (per expected behavior) .  Is it possible to have a time based 
> exclusion for a rule such that it will not trigger between specific times? 
> For example I would like to disable this rule for 2 minutes at midnight.  I 
> have not seen such a configuration option in the documentation. Anyone have 
> any advice?
> Thanks,
> Mark Scrano
> --
>
> ---
> You received this message because you are subscribed 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] Dynamic values in regex inside OSSEC rules?

[Jesus Linares]

Hi,

it is very interesting. Right now, Wazuh is able to extract dynamic fields 
and use them in the rule description. Example for your log:

**Phase 1: Completed pre-decoding.
   full event: '2017 Mar 02 04:04:22 WinEvtLog: Security: 
AUDIT_FAILURE(4656): Microsoft-Windows-Security-Auditing: (no user): no 
domain: Desktop: A handle to an object was requested.Subject:   
Security ID:  S-1-5-21-XX-XX-XX-   Account 
Name:  Subject1  Account Domain:  DESKTOP   Logon ID:  0xXObject:   
Object Server:  Security   Object Type:  File   Object Name: 
 C:\Users\Subject2\Documents\Private.txt   Handle ID:  0xXXX   Resource 
Attributes: -Process Information:   Process ID:  0xXXX   Process Name: 
 C:\Windows\System32\notepad.exeAccess Request Information:   
Transaction ID:  {----}   Accesses: 
 SYNCHRONIZE  ReadData (or ListDirectory) Access Reasons: 
 SYNCHRONIZE: Granted by  D:(A;;0x1200a9;;;BU)  ReadData (or 
ListDirectory): Granted by  D:(A;;0x1200a9;;;BU) Access Mask: 
 0x11   Privileges Used for Access Check: -   Restricted SID Count: 0'
   hostname: 'ip-10-0-0-10'
   program_name: 'WinEvtLog'
   log: 'Security: AUDIT_FAILURE(4656): 
Microsoft-Windows-Security-Auditing: (no user): no domain: Desktop: A 
handle to an object was requested.Subject:   Security ID: 
 S-1-5-21-XX-XX-XX-   Account Name:  Subject1 
 Account Domain:  DESKTOP   Logon ID:  0xXObject:   Object Server: 
 Security   Object Type:  File   Object Name: 
 C:\Users\Subject2\Documents\Private.txt   Handle ID:  0xXXX   Resource 
Attributes: -Process Information:   Process ID:  0xXXX   Process Name: 
 C:\Windows\System32\notepad.exeAccess Request Information:   
Transaction ID:  {----}   Accesses: 
 SYNCHRONIZE  ReadData (or ListDirectory) Access Reasons: 
 SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU)  ReadData (or 
ListDirectory): Granted by   D:(A;;0x1200a9;;;BU) Access Mask: 
 0x11   Privileges Used for Access Check: -   Restricted SID Count: 0'


**Phase 2: Completed decoding.
   decoder: 'windows'
   status: 'AUDIT_FAILURE'
   id: '4656'
   extra_data: 'Microsoft-Windows-Security-Auditing'
   dstuser: '(no user)'
   system_name: 'Desktop'
   account_name: 'Subject1'
   account_domain: 'DESKTOP'
   logon_id: '0xX'
   accesses: ' SYNCHRONIZE  ReadData (or ListDirectory) 
Access Reasons:  SYNCHRONIZE: Granted byD:(A;;0x1200a9;;;BU) 
 ReadData (or ListDirectory): Granted by  D:(A;;0x1200a9;;;BU)'
   target_file: 'C:\Users\Subject2\Documents\Private.txt'


**Phase 3: Completed filtering (rules).
   Rule id: '20'
   Level: '5'
   Description: 'Unauthorized object access by Subject1'
**Alert to be generated.

The rule is:


18105
Unauthorized object access by *$(account_name)*




Then you want to fire a rule *if account_name (Subject1) is a substring of 
target_file (C:\Users\Subject2\Documents\Private.txt)*.

Unfortunately, it is not possible to do it, but it is in our roadmap to 
improve the OSSEC rule engine. It will be something like:


18105
*$(account_name) substr $(target_file)*
Unauthorized object access by $(account_name)



Feel free to send us use cases like this one and we will keep in mind for 
the new rule engine. Also, we want to improve the correlation (if event A 
and event B -> alert!).

Thanks for share it.
Regards.


On Thursday, March 2, 2017 at 9:27:30 AM UTC-8, dan (ddpbsd) wrote:
>
> On Thu, Mar 2, 2017 at 1:01 AM, InfoSec  > wrote: 
> > In the Wazuh fork, dynamic decoders are an outstanding idea. It allows 
> > unprecedented visualization capabilities in the security console 
> *without* 
> > having to resort to further parsing tricks at ingestion time. It is all 
> done 
> > in OSSEC. 
> > 
> > Dynamic decoders enable unprecedented normalization of events. Dynamic 
> > variables + dynamic decoders would tremendously boost OSSEC's host 
> intrusion 
> > detection capabilities, enabling modeling of attack scenarios that were 
> > previously unthinkable in stock OSSEC. 
> > 
> > The above examples are a very basic illustration of the endless threat 
> > scenario modeling possibilities that dynamic variables would add to 
> Wazuh 
> > fork of OSSEC. 
> > 
> > By the way, legitimate user names and domain names in Windows may 
> contain 
> > spaces. System events have "NT Authority" as domain name. The 
> out-of-the-box 
> > dynamic decoders fail and only picks up "NT" in the case of "NT 
> Authority" 
> > domain. Ditto for user names that contain spaces. 
> > 
> > The following work in case user name or domain contain spaces: 
> > 
> > Account Name:\s\s+(\w\.+)\s\s+Account Domain: 
> > 
> > and for domain names: 
> > 
> > 

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[Jesus Linares]

Hi,

could you give us a real example?.

Thanks

On Wednesday, March 1, 2017 at 10:34:18 AM UTC-8, dan (ddpbsd) wrote:
>
> On Mon, Feb 27, 2017 at 2:50 PM, Jahchan, Georges J. 
>  wrote: 
> > That is not what I meant. 
> > 
> > If the source IP is decoded and stored in field srcip, I want to be able 
> to 
> > specify _srcip_ (or whatever convention used to tell regex that this is 
> a 
> > variable), and have _srcip_ replaced by the value saved as srcip in the 
> > event. 
> > 
> > If srcip is 10.0.0.1, specifying in the regex 
> > Some-regex-preceding-_srcip_-some regex tailing _srcip_ 
> in 
> > the regex would be dynamically replaced by its value (10.0.0.1) during 
> regex 
> > evaluation. 
> > 
>
> There's no support for that. 
>
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed 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] Re: Create custom rule for OSSEC 2.8.3, to capture specific phrase in application log

[Jesus Linares]

Hi,

you should create decoders and rules for that event. Check out the 
documentation: http://ossec-docs.readthedocs.io/en/latest/syntax/analysis.html

Also. you can use the binary /var/ossec/bin/ossec-logtest to test your own 
decoders/rules.

On Monday, January 30, 2017 at 7:04:34 AM UTC-8, Eli Tunkel wrote:
>
> 2016-07-24 11:43:22,707 INFO  [main-EventThread  ] 
> [.m.async.facade.Bootstrap] Became Leader!!!  |TAGS|
> 2016-07-24 11:43:22,707 INFO  [main-EventThread  ] 
> [.m.async.facade.Bootstrap] ## Leader election: 
> *Server 
> is leader and starting* ##  |TAGS|
>
>   
>
>   
>
> .I have added the custom path for this log to the ossec.conf .״This is 
> sample log I want to capture, the phrase I want to make a rule for is 
> "*Server 
> is leader and start*
>
> Thanks friend,  
>  
>
>   
>
>  
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Alerts generated despite level '0' rule being hit

[Jesus Linares]

Hi Daniel,

review *archives.log* to be sure the log is how you expected. Also, check 
out *alerts.log* to see the alert. Remember that *ossec-logtest* shows 
alerts with level 0, but OSSEC does not or at least it should not.

Regards.

On Friday, January 27, 2017 at 8:00:19 AM UTC-8, Daniel B. wrote:
>
> Yes, via ./ossec-control -r
>
> On Thursday, January 26, 2017 at 4:41:20 PM UTC-5, Daniel B. wrote:
>>
>>
>> 
>>
>>
>>
>> full_log: 
>> Files hidden inside directory 
>> '/var/lib/docker/aufs/mnt/545d04c068f0f7ce19361a94d1c43b0c6686a0dfdd45e1803ccee569acc1767b/usr/share/locale'.
>>  
>> Link count does not match number of files (54,70).
>>
>> I have a rule setup to ignore this, and it's actually being hit when I 
>> test the above line via ./ossec-logtest -v (see image)
>>
>> When I check the alerts, I see this as a level 7 alert. 
>>
>> The rules are defined on the server. Any idea on why an alert would be 
>> generated despite the level 0 rule being hit? 
>>
>> Decoder: 
>>
>>> 
>>>
>>>   Files hidden inside directory 
>>>
>>>   (\p/var/lib/docker\.+)
>>>
>>>   extra_data
>>>
>>> 
>>>
>>>
>> Rule: 
>>
>>> 
>>
>> ignore_docker_mismatch
>>
>> Level 0 Alert -- Ignoring Docker Files 
>>> Mismatch
>>
>>   
>>
>>  
>>
>>
>>
>>

-- 

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

[ossec-list] Re: local_decoder.xml -- can't override (ignore) parent decoder

[Jesus Linares]

Hi Daniel,

you are right, I forgot to add a regex to the rule. It could be something 
like:



  
  
5104
device veth\S+ entered promiscuous mode
Ignore rule 5104 for weave.
  



Adapt the regex to the logs generated by weave. Also, you can use **.


Let me know if it works ;).
Regards.


On Wednesday, January 18, 2017 at 6:11:38 PM UTC+1, Daniel B. wrote:
>
> Jesus, thanks for the response. I'm aware of ossec-logtest always showing 
> the name of the parent (which confused me until I RTFM). Using 
> `ossec-logtest -v` I was able to verify that the decoder was not being hit 
> as the rule for that was not being caught. 
>
> I did consider inserting an entry into local_rules.xml, but that would 
> ignore *all *alerts with sid 5104 (and not just the ones raised by 
> weave). I suppose it's better than digging through 10 pages of false 
> positives, but I'd like to be able to filter out entries using a regex like 
> "\w+ device veth\w+ entered promiscuous mode$" -- but the rules files can't 
> use the OS_Regex synatx (can only use OS_Match, which is much simpler). 
>
> Any options other than filtering out all entries with rule ID 5104?
>
> I *feel* like I should be able to override the iptables decoder... but 
> maybe that's me being optimistic. 
>
> On Wednesday, January 18, 2017 at 5:00:47 AM UTC-5, Jesus Linares wrote:
>>
>> Hi Daniel,
>>
>> ossec-logtest always shows the name of the parent.
>>
>> If you want to ignore that alert, just create a rule in local_rules.xml:
>>
>> 
>>
>>
>>   
>>   
>> 5104
>> Ignore rule 5104.
>>   
>>
>>
>> 
>>
>> Jan 16 20:46:57 machine_name kernel: [347956.184868] device veth9c8da7ba 
>> entered promiscuous mode
>>
>>
>>
>>
>> **Phase 1: Completed pre-decoding.
>>full event: 'Jan 16 20:46:57 machine_name kernel: [347956.184868] 
>> device veth9c8da7ba entered promiscuous mode'
>>hostname: 'machine_name'
>>program_name: 'kernel'
>>log: '[347956.184868] device veth9c8da7ba entered promiscuous 
>> mode'
>>
>>
>> **Phase 2: Completed decoding.
>>decoder: 'kernel'
>>
>>
>> **Phase 3: Completed filtering (rules).
>>Rule id: '11'
>>Level: '0'
>>Description: 'Ignore rule 5104.'
>>
>> (I changed the name of the decoder from iptables to kernel).
>>
>> I hope it helps.
>>
>> On Tuesday, January 17, 2017 at 8:58:28 PM UTC+1, Daniel B. wrote:
>>>
>>> We use weave which periodically causes a network interface to enter 
>>> promiscuous mode to sniff network traffic. This is expected behavior, and 
>>> as such, I'm looking to ignore it. 
>>>
>>> For reference, the iptables decoder is set at 
>>> https://github.com/ossec/ossec-hids/blob/592d681ea07f9a8bf2bedb039ee9493e6fbe3c26/etc/decoder.xml#L1135
>>>
>>> The log line I'm attempting to ignore looks like: 
>>> Jan 16 20:46:57 machine_name kernel: [347956.184868] device 
>>> veth9c8da7ba entered promiscuous mode
>>>
>>> Now, this is inserted into my local_decoder.xml file (with an 
>>> appropriate local rule):
>>>
>>>
>>> 
>>>   iptables
>>>   device (veth\w+) entered promiscuous 
>>> mode
>>>   kernel
>>>   
>>>   extra_data
>>> 
>>>
>>>
>>> I've tried a lot of different variations on the above, including getting 
>>> rid of the parent and prematch offsets (while temporarily deleting the 
>>> original / parent iptables rule in 
>>> etc/ossec_decoders/kernel-iptables_apparmor_decoders.xml
>>>
>>>
>>> Each time I run the log through ./ossec-logtest, it matches to the 
>>> parent decoder, and as such an alert is fired.
>>>
>>> **Phase 1: Completed pre-decoding.
>>>full event: 'Jan 16 20:46:57 machine_name kernel: [347956.184868] 
>>> device veth9c8da7ba entered promiscuous mode'
>>>hostname: 'machine_name'
>>>program_name: 'kernel'
>>>log: '[347956.184868] device veth9c8da7ba entered promiscuous 
>>> mode'
>>>
>>> **Phase 2: Completed decoding.
>>>decoder: 'iptables'
>>>
>>> **Phase 3: Completed filtering (rules).
>>>Rule id: '5104'
>>>Level: '8'
>>>Description: 'Interface entered in promiscuous(sniffing) mode.'
>>> **Alert to be generated.
>>>  
>>>
>>> Is there a way I can override the iptables decoder for this one specific 
>>> log message? 
>>>
>>> Any help is appreciated, thanks!
>>>
>>

-- 

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

[ossec-list] Re: local_decoder.xml -- can't override (ignore) parent decoder

[Jesus Linares]

Hi Daniel,

ossec-logtest always shows the name of the parent.

If you want to ignore that alert, just create a rule in local_rules.xml:




  
  
5104
Ignore rule 5104.
  




Jan 16 20:46:57 machine_name kernel: [347956.184868] device veth9c8da7ba 
entered promiscuous mode




**Phase 1: Completed pre-decoding.
   full event: 'Jan 16 20:46:57 machine_name kernel: [347956.184868] 
device veth9c8da7ba entered promiscuous mode'
   hostname: 'machine_name'
   program_name: 'kernel'
   log: '[347956.184868] device veth9c8da7ba entered promiscuous mode'


**Phase 2: Completed decoding.
   decoder: 'kernel'


**Phase 3: Completed filtering (rules).
   Rule id: '11'
   Level: '0'
   Description: 'Ignore rule 5104.'

(I changed the name of the decoder from iptables to kernel).

I hope it helps.

On Tuesday, January 17, 2017 at 8:58:28 PM UTC+1, Daniel B. wrote:
>
> We use weave which periodically causes a network interface to enter 
> promiscuous mode to sniff network traffic. This is expected behavior, and 
> as such, I'm looking to ignore it. 
>
> For reference, the iptables decoder is set at 
> https://github.com/ossec/ossec-hids/blob/592d681ea07f9a8bf2bedb039ee9493e6fbe3c26/etc/decoder.xml#L1135
>
> The log line I'm attempting to ignore looks like: 
> Jan 16 20:46:57 machine_name kernel: [347956.184868] device veth9c8da7ba 
> entered promiscuous mode
>
> Now, this is inserted into my local_decoder.xml file (with an appropriate 
> local rule):
>
>
> 
>   iptables
>   device (veth\w+) entered promiscuous 
> mode
>   kernel
>   
>   extra_data
> 
>
>
> I've tried a lot of different variations on the above, including getting 
> rid of the parent and prematch offsets (while temporarily deleting the 
> original / parent iptables rule in 
> etc/ossec_decoders/kernel-iptables_apparmor_decoders.xml
>
>
> Each time I run the log through ./ossec-logtest, it matches to the parent 
> decoder, and as such an alert is fired.
>
> **Phase 1: Completed pre-decoding.
>full event: 'Jan 16 20:46:57 machine_name kernel: [347956.184868] 
> device veth9c8da7ba entered promiscuous mode'
>hostname: 'machine_name'
>program_name: 'kernel'
>log: '[347956.184868] device veth9c8da7ba entered promiscuous mode'
>
> **Phase 2: Completed decoding.
>decoder: 'iptables'
>
> **Phase 3: Completed filtering (rules).
>Rule id: '5104'
>Level: '8'
>Description: 'Interface entered in promiscuous(sniffing) mode.'
> **Alert to be generated.
>  
>
> Is there a way I can override the iptables decoder for this one specific 
> log message? 
>
> Any help is appreciated, thanks!
>

-- 

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

[ossec-list] Re: Wazuh OSSEC Rules

[Jesus Linares]

Hi,

usually all rules in wazuh ruleset  
should work with OSSEC but in some cases it could be a compatibility issue 
due to some new capabilities of Wazuh (like support dynamic fields 

 
in the tag ** of a rule). In other cases, we change the structure or 
names of a decoder/rule for something that we consider more proper.

The USB rules use the *kernel decoder* which does not exist in OSSEC. If 
you change *kernel* for *iptables* it should work. This is due to the old 
decoder was:


 ^kernel
  

And we changed 

 
it to:


 ^kernel


I hope it helps.
Regards.


On Wednesday, December 28, 2016 at 4:36:53 PM UTC+1, namobud...@gmail.com 
wrote:
>
> I don't have the Wazuh OSSEC fork installed, but I pull out individual 
> rules such the USB rule and put in my local_rules.xlm?
>
> 
> 
> kernel
> usb
> USB messages grouped.
> 
> 
> 
> 81100
> New USB device found
> Attached USB Storage
> 
>  
>

-- 

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

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

[Jesus Linares]

Hi,

I have not used databases in OSSEC, but you can choose the type in the 
configuration:



192.168.2.30
ossecuser
ossecpass
ossec
mysql



In order to use databases, you must compile OSSEC with database support:
# cd ossec-hids-*
# cd src; make setdb; cd ..
# ./install.sh
# /var/ossec/bin/ossec-control enable database

Also, you can do it with: 
# make TARGET=server DATABASE=mysql install

Documentation:
http://ossec-docs.readthedocs.io/en/latest/manual/output/database-output.html
http://ossec-docs.readthedocs.io/en/latest/manual/output/mysql-database-output.html
http://ossec-docs.readthedocs.io/en/latest/manual/output/pgsql-database-outout.html

I hope it helps.
Regards.


On Tuesday, December 13, 2016 at 1:35:40 AM UTC+1, ste...@uw.edu wrote:
>
> Hi,
>
> There hasn't been any action on this topic for over a year but it was 
> never answered and I'm running into the same issue.  What libraries is it 
> looking for?  Is there somewhere that I can look at, possibly edit the 
> list?  Why does it look for particular libraries, couldn't I just specify 
> the type of database (MySQL or PostgreSql) that I want to use?  
>
> Natassia
>
> On Tuesday, September 22, 2015 at 7:24:08 PM UTC-7, dan (ddpbsd) wrote:
>
>> On Sat, Sep 19, 2015 at 10:42 AM, Kai Chung Lau  
>> wrote: 
>> > I know Ossec supports PostgreSql and Mysql, but since MariaDb is the 
>> drop-in 
>> > replacement for Mysql, can Ossec also work with Mariadb? 
>> > 
>> > I have tried recompiling Ossec but it doesn't work. 
>> > [root@ju src]# make setdb; 
>> > 
>> > Error: PostgreSQL client libraries not installed. 
>> > 
>> > Error: DB libraries not installed. 
>> > 
>>
>> Perhaps your distro is putting things in places OSSEC doesn't expect? 
>> You're not giving us much to go on. 
>>
>> > -- 
>> > 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "ossec-list" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to ossec-list+...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 

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

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

[Jesus Linares]

Hi,

what OSSEC version are you running?.

Regards.

On Friday, December 9, 2016 at 11:51:09 AM UTC+1, 1kn0 wrote:
>
> Hello Dan, 
>
> Thank you very much for your help. 
>
> I've a problem with the following decoder and sample. Its generates a 
> segfault in ossec-logtest : 
>
>  
>
>  
>   netasq 
>   logtype="filter" 
>   ^id=(\S+) time=\.+ fw="(\w+)" \.+ srcifname="(\w+)" 
> ipproto=(\S+) proto=(\S+) src=(\S+) srcport=(\d+) \.+ dst=(\S+) 
> dstport=(\d+) \.+ action=(\S+) 
>   id, extra_data, extra_data, protocol, protocol, srcip, 
> srcport, dstip, dstport, action 
>  
>
> the segfaut appears before the display of dstport 
> For the 'action' item, I can't display it too. 
>
> Any ideas? 
>
>
>
> 2016-12-07 13:06 GMT+01:00 dan (ddp) : 
> > On Wed, Dec 7, 2016 at 5:26 AM, 1kn0  
> wrote: 
> >> Greetings, 
> >> 
> >> I'm new to OSSEC and I didn't find an answer to my problem on the list. 
> >> I've appliance firewalls (netasq and stormshield) on a network. These 
> >> firewalls exports their log to the computer where OSSEC is installed. 
> >> 
> >> For tests : 
> >> 
> >> I connect on the administration pages of the firewall, with a an 
> invalid 
> >> user/password. 
> >>> 
> >>> Dec  2 15:42:29 192.168.10.1 id=firewall time="2016-12-02 15:42:28" 
> >>> fw="FW1" tz=+ startime="2016-12-02 15:42:28" user="admin" 
> >>> src=192.168.10.2 ruleid=0 method="PLAIN" error=4 msg="Authentication 
> request 
> >>> invalid" logtype="auth"#015 
> >> 
> >> 
> >> I connect to the firewall with SSH 
> >>> 
> >>> Dec  2 14:37:42 192.168.10.1 id=firewall time="2016-12-02 14:37:41" 
> >>> fw="FW1" tz=+ startime="2016-12-02 14:37:40" pri=5 confid=01 
> slotlevel=2 
> >>> ruleid=1 srcif="Ethernet2" srcifname="port2" ipproto=tcp proto=ssh 
> >>> src=192.168.10.2 srcport=33659 srcportname=ephemeral_fw_tcp 
> srcname=Routeur 
> >>> dst=192.168.10.1 dstport=22 dstportname=ssh dstname=FW action=pass 
> >>> logtype="filter"#015 
> >> 
> >> 
> >> 
> >> Is there decoder and rules for firewall? 
> >> How to configure decode/rules to analyze all events reported by the 
> >> firewalls? 
> >> 
> > 
> > I don't believe there are decoders or rules for this firewall (never 
> > heard of it actually). 
> > Running the samples provided through ossec-logtest, I get the following 
> output: 
> > **Phase 1: Completed pre-decoding. 
> >full event: 'Dec  2 15:42:29 192.168.10.1 id=firewall 
> > time="2016-12-02 15:42:28" fw="FW1" tz=+ startime="2016-12-02 
> > 15:42:28" user="admin" src=192.168.10.2 ruleid=0 method="PLAIN" 
> > error=4 msg="Authentication request invalid" logtype="auth"#015' 
> >hostname: '192.168.10.1' 
> >program_name: '(null)' 
> >log: 'id=firewall time="2016-12-02 15:42:28" fw="FW1" tz=+ 
> > startime="2016-12-02 15:42:28" user="admin" src=192.168.10.2 ruleid=0 
> > method="PLAIN" error=4 msg="Authentication request invalid" 
> > logtype="auth"#015' 
> > 
> > **Phase 2: Completed decoding. 
> >No decoder matched. 
> > 
> > **Phase 3: Completed filtering (rules). 
> >Rule id: '1002' 
> >Level: '2' 
> >Description: 'Unknown problem somewhere in the system.' 
> > **Alert to be generated. 
> > 
> > 
> > **Phase 1: Completed pre-decoding. 
> >full event: 'Dec  2 14:37:42 192.168.10.1 id=firewall 
> > time="2016-12-02 14:37:41" fw="FW1" tz=+ startime="2016-12-02 
> > 14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 srcif="Ethernet2" 
> > srcifname="port2" ipproto=tcp proto=ssh src=192.168.10.2 srcport=33659 
> > srcportname=ephemeral_fw_tcp srcname=Routeur dst=192.168.10.1 
> > dstport=22 dstportname=ssh dstname=FW action=pass 
> > logtype="filter"#015' 
> >hostname: '192.168.10.1' 
> >program_name: '(null)' 
> >log: 'id=firewall time="2016-12-02 14:37:41" fw="FW1" tz=+ 
> > startime="2016-12-02 14:37:40" pri=5 confid=01 slotlevel=2 ruleid=1 
> > srcif="Ethernet2" srcifname="port2" ipproto=tcp proto=ssh 
> > src=192.168.10.2 srcport=33659 srcportname=ephemeral_fw_tcp 
> > srcname=Routeur dst=192.168.10.1 dstport=22 dstportname=ssh dstname=FW 
> > action=pass logtype="filter"#015' 
> > 
> > **Phase 2: Completed decoding. 
> >No decoder matched. 
> > 
> > 
> > Adding the following deocder to local_decoder.xml gives us "decoder: 
> > 'netasq'" (although this is untested against other logs to make sure 
> > there are no conflicts): 
> >  
> >   ^id= 
> >  
> > 
> > 
> > These decoders flesh it out a bit: 
> >  
> >   netasq 
> >   logtype="auth" 
> >   ^id=(\S+) time=\.+ fw="(\w+)" \.+ user="(\S+)" src=(\S+) \.+ 
> > logtype="auth" 
> >   id, extra_data, user, srcip 
> >  
> > 
> >  
> >   netasq 
> >logtype="filter" 
> >   ^id=(\S+) time=\.+ fw="(\w+)" \.+ ipproto=(\S+) proto=(\S+) 
> > src=(\S+) srcport=(\d+) \.+ dst=(\S+) dstport=(\d+) \.+ action=(\S+) 
> >  
> >   id, extra_data, protocol, protocol, srcip, srcport, dstip, 
> > dstport, action 
> >  
> > 
> > **Phase 

Re: [ossec-list] Re: important questions on CDB lists

[Jesus Linares]

Hi Omar,

if you don't mind, please share your decoders, rules and CDB list and I can 
test it in my lab.

Thanks.

On Wednesday, December 7, 2016 at 9:01:18 PM UTC+1, Omar M wrote:
>
> Hi Dan,
> Thanks for the quick response.
>
> The objective is to create a rule that will trigger if a restricted 
> package is installed on the system.  This is what I've done so far:
>
>1. Created a custom decoder for Yum.  This works fine.  The logs are 
>decoded properly and the name of the package that is installed is decoded 
>and stored in "id"
>2. Created a cdb file; placed the cdb file in /var/ossec/rules/; and 
>updated ossec.conf to include cdb-list under the rules 
>section. The cdb file compiles as expected
>3. Created a custom rule (see below) 
>4. Run ossec-logtest (the output of logtest is below).
>
> The rule is getting called but the alert never fires, see the output 
> below.  
>
> ==RULES
>  
>   
> yum
> Yum custom group.
>   
>
>   
> 11
> cdb-list -->
> illegal package installed via Yum!!!
>   
> 
> ===
>
> Logtest Output==
> # ./ossec-logtest -vvv
> 2016/12/07 13:14:07 ossec-testrule: INFO: Reading local decoder file.
> 2016/12/07 13:14:07 ossec-testrule: INFO: Reading the lists file: 
> 'cdb-list'
> 2016/12/07 13:14:07 ossec-testrule: INFO: Started (pid: 8075).
> ossec-testrule: Type one log per line.
>
> Dec  7 07:05:06 ax yum: Installed: libX11-devel - 1.0.3-9.el5.i386
>
>
> **Phase 1: Completed pre-decoding.
>full event: 'Dec  7 07:05:06 ax yum: Installed: libX11-devel - 
> 1.0.3-9.el5.i386'
>hostname: 'ax'
>program_name: 'yum'
>log: 'Installed: libX11-devel - 1.0.3-9.el5.i386'
>
> **Phase 2: Completed decoding.
>decoder: 'yum'
>id: 'libX11-devel'
>
> **Rule debugging:
> Trying rule: 1 - Generic template for all syslog rules.
>*Rule 1 matched.
>*Trying child rules.
> Trying rule: 600 - Active Response Messages Grouped
> Trying rule: 11 - Yum custom group.
>*Rule 11 matched.
>*Trying child rules.
> Trying rule: 110001 - illegal package installed via Yum!!!
>
> **Phase 3: Completed filtering (rules).
>Rule id: '11'
>Level: '0'
>Description: 'Yum custom group.'
> ==
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: regex in agent id field

[Jesus Linares]

Hi Sean,

it seems that agent_config name 
 is 
checked by the function OS_Match2 
 which 
only matches strings with *^*, *$* or *|* special characters. So, you can 
not use regex in the name.

I recommend you to use profiles in your agents, define your production 
servers with the profile "production", the development server with "dev" 
and so on.

Example:

*production agent*


  
10.0.0.220
centos, centos7, production
  


*agent.conf*


I hope it helps.
Regards.

On Monday, December 5, 2016 at 11:33:01 PM UTC+1, Sean Roe wrote:
>
> Hi All,
>
> new to this list and I have a question:
>
> will the agent_config name field except regex expressions?
>
> I found a post by Daniel Cid with this reference: 
> 
> 
> /var/log/my.log
> syslog
> 
> 
>
> so I was hoping to build a stanza in agent.conf like this:
>
> 
>  
> blah, blah.
>
> to get the prodAB002, prodCD002, devDD002, qaQQ002 servers
>
> Is that doable?
>
> Sean
>

-- 

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

Re: [ossec-list] Problem with rule 18257

[Jesus Linares]

Hi all,

nice catch Dan!. Unfortunately, the rule 18257 is still triggering. The log 
is related with a "Database update" and the rule 18257 is for logins. So, I 
think we should add a rule to ignore 
 this kind of 
logs.

Regards.

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

-- 

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

Re: [ossec-list] Agent Syscheck Frequency Issue

[Jesus Linares]

Hi Yousif,

as Dan said, the minimum is around 300 seconds. Do not set a lower value.

It is possible to improve the syscheck performance, changing this option in* 
local_internal_options.conf*:
syscheck.sleep=2  // change to 1 or 0
syscheck.sleep_after=15 // change for a greater value

By default, OSSEC sleeps 2 seconds after scanning 15 files.  If you change 
this configuration syscheck will be faster, but also it will use more 
resources, so it can impact in the performance of the agent.

Regards.

On Monday, November 21, 2016 at 2:00:57 PM UTC+1, dan (ddpbsd) wrote:
>
> On Mon, Nov 21, 2016 at 7:34 AM, Yousif Johny  > wrote: 
> > Hi all, 
> > 
> > I've been having this weird issue with OSSEC. I setup an agent in one 
> > server, and things seem okay at first. 
> > 
> > When I modify a file that is being monitored (/etc/passwd) I'd have to 
> wait 
> > a significant time for it to trigger an alert (unless I manually run the 
> > syscheckd). So I went to /var/ossec/etc/ossec.conf (on the Server being 
> > monitored side) and modified  it as follows: 
> > 
> >   
> >  
> > 30 
> > 
> >  
> > /etc,/usr/bin,/usr/sbin 
> > /bin,/sbin 
> > 
> > 
> > So the frequency is 30 (which I believe is in seconds). 
> > 
> > Correct me if I'm wrong, but I thought this would mean the syscheck 
> would 
> > run every 30 seconds? meaning if I modify a file, it'll take a max of 30 
> > seconds for it to trigger an alert, right? 
> > 
> > If so, then why is it not triggering? I've been waiting for minutes and 
> > minutes and nothing happens. This has been puzzling me. 
> > 
>
> 30 seconds is too small. Depending on the system, about 300 seems to 
> be the minimum. 
> The more files you're monitoring, the longer it will take, so the 
> higher the frequency that should be set. 
>
> > 
> > Thank you. 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@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] Filter Windows Event at client

[Jesus Linares]

Hi Fredrik,

create a rule for your "level 2 events". Then, use the rule ID and the tag 
*rule_id 
*of granular email 
options: 
http://ossec-docs.readthedocs.io/en/latest/syntax/head_ossec_config.email_alerts.html

I hope it helps.
Regards.

On Wednesday, November 9, 2016 at 8:29:02 PM UTC+1, Fredrik wrote:
>
> Thanks Jesus!!
>
>
> Operators seems to be working just fine as you suggested!
>
> The "level" query is doing its job - I tested with the command in my post. 
> However, do you know of a way to trigger an email  where all Level 2 events 
> within a certain timeframe (e.g. 24h) are grouped together and included in 
> the email? I realize this might involve multiple parts and configuration, 
> but perhaps you can give a few pointers without spending too much of your 
> time?
>
> Best regards,
> Fredrik 
>
> On Friday, November 4, 2016 at 9:37:37 AM UTC+1, Jesus Linares wrote:
>>
>> Hi Fredrik,
>>
>> according to the documentation you can use the Microsoft event schema 
>> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa385201(v=vs.85).aspx>.
>>  
>> If you want to add multiple event IDs:
>> 
>>   Security
>>   eventchannel 
>>   Event/System[EventID=5140 and EventID=5144]
>> 
>>
>> Also, I think you can use other operators in the query (=, !=, <, >), so 
>> it could be useful for you to define an interval:
>> Event/System[EventID> and EventID<]
>>
>> I've never used the "Level" query. is it not working?.
>>
>> Regards.
>>
>> On Wednesday, November 2, 2016 at 1:34:43 PM UTC+1, Fredrik wrote:
>>>
>>> Hi Santiago and others,
>>>
>>>
>>> Interesting thread (even if dated). I did something similar today and 
>>> got an OSSEC agent to forward Windows Server Events according to below to 
>>> the OSSEC server. I have some experience writing decoders to syslog event 
>>> (but limited as you can see in this forum :)). How would I go about writing 
>>> rules on the OSSEC server to handle the forwarded events? 
>>>
>>> - Say I would like to group all Level 1 events and send them in a daily 
>>> email?
>>> - How would I add mulitiple eventIDs to the below query? OSSEC and 
>>> operand? Could you please provide example?
>>>
>>> ossec.conf
>>>
>>> 
>>>
>>>   
>>>
>>>   
>>> Security
>>> eventchannel
>>> Event/System[EventID=4740]
>>>   
>>>
>>>   
>>> System
>>> eventchannel
>>> Event/System[Level=2]
>>>   
>>>
>>> The query for Level=2 generates alert below on OSSEC server when a test 
>>> event was created using command below.
>>>
>>> eventcreate /t error /id 100 /l system /d "Create event in application 
>>> log" 
>>>
>>> alerts.log
>>> 2016 Nov 02 13:18:55 (win-testdc) 10.1.1.10->WinEvtLog
>>> 2016 Nov 02 13:19:24 WinEvtLog: System: ERROR(100): system: ADMIN: 
>>> contoso: win-testdc.contoso.com: (no message)
>>>
>>>
>>> Best regards,
>>> Fredrik 
>>>
>>> On Tuesday, August 18, 2015 at 9:20:43 PM UTC+2, Santiago Bassett wrote:
>>>>
>>>> I guess you want to remove these sections from the ossec.conf file in 
>>>> the agent. Those are used to get all application, security and system 
>>>> events.
>>>>
>>>>
>>>> Application 
>>>> eventlog 
>>>>
>>>>  
>>>>
>>>> Security 
>>>> eventlog 
>>>>
>>>>  
>>>>
>>>> System 
>>>> eventlog 
>>>>
>>>>
>>>> On Tue, Aug 18, 2015 at 12:13 PM, Ralph Durkee <ossec...@rd1.net> 
>>>> wrote:
>>>>
>>>>> The shared agent is as previously shared, copied below for reference:
>>>>>
>>>>> 
>>>>> 
>>>>>
>>>>> 
>>>>>   Security
>>>>>   eventchannel
>>>>>   Event/System[EventID=4624]
>>>>> 
>>>>>
>>>>> 
>>>>>
>>>>> *The Windows OSSEC after the comments starts with *(middle portion 
>>>>> removed, and has no localfile entries. )
>>>>>
>>>>>  
>>>>>  
>>>>

Re: [ossec-list] OSSEC Signature Update Frequency

[Jesus Linares]

Hi Matthew,

I just remembered that the script only works with the new release of Wazuh. 
Anyway, you can do it manually:

   1. Backup your current installation
   2. Copy ossec-rules/decoders/ to /var/ossec/etc/decoders
   3. Copy ossec-rules/rules/ to /var/ossec/rules.
   4. Copy ossec-rules/rootchecks to /var/ossec/etc/shared
   5. Use this configuration 
   <https://github.com/wazuh/ossec-rules/blob/master/rules/rules.template> 
   in your ossec.conf (if you do not use *local_decoder.xml*, you can 
   remove that line).
   6. Restart OSSEC. You will see some errors (some rules/decoders are not 
   compatible). So, replace the "no compatible rules" with the backup rules. 

Of course, you can do the "same" procedure from OSSEC-HIDS but Wazuh is 
doing a great effort to centralize, test and maintain decoders and rules 
submitted by Open Source contributors and create new ones.

Regards.


On Friday, November 4, 2016 at 9:43:58 AM UTC+1, Jesus Linares wrote:
>
> Hi Matthew,
>
> Wazuh has a repository <https://github.com/wazuh/ossec-rules> for 
> decoders, rules, rootchecks, etc. Almost all decoders/rules should work in 
> every OSSEC version, except some of them that use new features. I recommend 
> you to create a backup of OSSEC, then update the rules using the script 
> <https://github.com/wazuh/ossec-rules/blob/master/ossec_ruleset.py>. Some 
> rules will be failing, so replace them with the proper backup. In this way 
> you will have the most up to date "signatures".
>
> Regards.
>
> On Wednesday, November 2, 2016 at 5:03:51 PM UTC+1, dan (ddpbsd) wrote:
>>
>> On Wed, Nov 2, 2016 at 12:00 PM, Matthew Casperson 
>> <matthews...@gmail.com> wrote: 
>> > I've been trying to track down where it details how often signatures 
>> are 
>> > updated for OSSEC.  Are new signatures part of each version?  E.g. if I 
>> am 
>> > on 2.8.2 and want to have the most up to date signatures would I have 
>> to 
>> > upgrade to the current version of OSSEC or are signatures updated 
>> > independent of new version releases?  Help greatly appreciated. 
>> > 
>>
>> The rules are currently updated with releases. 
>>
>> > Matt 
>> > 
>> > -- 
>> > 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "ossec-list" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to ossec-list+...@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] Re: can ossec 2.8 run on CentOS 7.x ?

[Jesus Linares]

Yes, it works. Just try it.

On Thursday, November 3, 2016 at 10:46:57 PM UTC+1, Rajanikanthrao Bolla 
wrote:
>
> Hi,
> Will ossec 2.8 (server type install)  run on CentOS 7.x?
>
> Has anyone tested it or had experience using it?
>
> Please share.
>
> Thanks,
> Raj.
>

-- 

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

Re: [ossec-list] OSSEC Signature Update Frequency

[Jesus Linares]

Hi Matthew,

Wazuh has a repository  for decoders, 
rules, rootchecks, etc. Almost all decoders/rules should work in every 
OSSEC version, except some of them that use new features. I recommend you 
to create a backup of OSSEC, then update the rules using the script 
. Some 
rules will be failing, so replace them with the proper backup. In this way 
you will have the most up to date "signatures".

Regards.

On Wednesday, November 2, 2016 at 5:03:51 PM UTC+1, dan (ddpbsd) wrote:
>
> On Wed, Nov 2, 2016 at 12:00 PM, Matthew Casperson 
>  wrote: 
> > I've been trying to track down where it details how often signatures are 
> > updated for OSSEC.  Are new signatures part of each version?  E.g. if I 
> am 
> > on 2.8.2 and want to have the most up to date signatures would I have to 
> > upgrade to the current version of OSSEC or are signatures updated 
> > independent of new version releases?  Help greatly appreciated. 
> > 
>
> The rules are currently updated with releases. 
>
> > Matt 
> > 
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@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] Filter Windows Event at client

[Jesus Linares]

Hi Fredrik,

according to the documentation you can use the Microsoft event schema 
.
 
If you want to add multiple event IDs:

  Security
  eventchannel 
  Event/System[EventID=5140 and EventID=5144]


Also, I think you can use other operators in the query (=, !=, <, >), so it 
could be useful for you to define an interval:
Event/System[EventID> and EventID<]

I've never used the "Level" query. is it not working?.

Regards.

On Wednesday, November 2, 2016 at 1:34:43 PM UTC+1, Fredrik wrote:
>
> Hi Santiago and others,
>
>
> Interesting thread (even if dated). I did something similar today and got 
> an OSSEC agent to forward Windows Server Events according to below to the 
> OSSEC server. I have some experience writing decoders to syslog event (but 
> limited as you can see in this forum :)). How would I go about writing 
> rules on the OSSEC server to handle the forwarded events? 
>
> - Say I would like to group all Level 1 events and send them in a daily 
> email?
> - How would I add mulitiple eventIDs to the below query? OSSEC and 
> operand? Could you please provide example?
>
> ossec.conf
>
> 
>
>   
>
>   
> Security
> eventchannel
> Event/System[EventID=4740]
>   
>
>   
> System
> eventchannel
> Event/System[Level=2]
>   
>
> The query for Level=2 generates alert below on OSSEC server when a test 
> event was created using command below.
>
> eventcreate /t error /id 100 /l system /d "Create event in application 
> log" 
>
> alerts.log
> 2016 Nov 02 13:18:55 (win-testdc) 10.1.1.10->WinEvtLog
> 2016 Nov 02 13:19:24 WinEvtLog: System: ERROR(100): system: ADMIN: 
> contoso: win-testdc.contoso.com: (no message)
>
>
> Best regards,
> Fredrik 
>
> On Tuesday, August 18, 2015 at 9:20:43 PM UTC+2, Santiago Bassett wrote:
>>
>> I guess you want to remove these sections from the ossec.conf file in the 
>> agent. Those are used to get all application, security and system events.
>>
>>
>> Application 
>> eventlog 
>>
>>  
>>
>> Security 
>> eventlog 
>>
>>  
>>
>> System 
>> eventlog 
>>
>>
>> On Tue, Aug 18, 2015 at 12:13 PM, Ralph Durkee  wrote:
>>
>>> The shared agent is as previously shared, copied below for reference:
>>>
>>> 
>>> 
>>>
>>> 
>>>   Security
>>>   eventchannel
>>>   Event/System[EventID=4624]
>>> 
>>>
>>> 
>>>
>>> *The Windows OSSEC after the comments starts with *(middle portion 
>>> removed, and has no localfile entries. )
>>>
>>>  
>>>  
>>>  
>>>
>>>
>>> Application 
>>> eventlog 
>>>
>>>  
>>>
>>> Security 
>>> eventlog 
>>>
>>>  
>>>
>>> System 
>>> eventlog 
>>>
>>>  
>>>  
>>>   
>>> . . . SNIP . . .
>>>
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>   
>>> 
>>>   xxx-ossec-srv1 
>>> 
>>>  
>>>
>>> -- Ralph Durkee
>>>
>>> On 08/18/2015 01:24 PM, Santiago Bassett wrote:
>>>
>>> Could you share your ossec.conf settings (from the agent) and also the 
>>> shared/agent.conf ones. Those are probably located in C:\Program 
>>> Files/ossec-agent 
>>>
>>> I am guessing, but I think you probably are reading all Security events 
>>> in some other place of the configuration (look for the different locations).
>>>
>>> Regards
>>>
>>> On Tue, Aug 18, 2015 at 10:17 AM, Ralph Durkee  wrote:
>>>
 Tried stopping and starting the agent service on the windows system. 
 Still getting other security events from that system such as 4672 and 4634 
 in addition to the 4624.  Any other suggestions? 

 -- Ralph Durkee


 On 08/18/2015 01:10 PM, Ralph Durkee wrote:

 I've restarted ossec on the server several times.  Are you refering to 
 the Windows agent? 

 -- Ralph Durkee


 On 08/18/2015 11:46 AM, Santiago Bassett wrote:

 Try restarting it manually and see if that works.

 On Tue, Aug 18, 2015 at 7:23 AM, Ralph Durkee  wrote:

> I'm trying to filter Windows events based on strings such as the login 
> type and workstation name, but as a starting point I tried the 
> configuration below to filter on EventID 4624. The 
> /var/ossec/etc/shared/agent.conf file contains:
>
> 
> 
>
> 
>   Security
>   eventchannel
>   Event/System[EventID=4624]
> 
>
> 
>
> However I continue receiving all security events including Security 
> EventID 4624 and others.
> I restarted the windows system agent via agent_control -R  and also 
> restarted the OSSEC manager.
> I don't have any errors in ossec.log with regard to the 
> shared/agent.conf file. 
>
> Any suggestions on getting this working? 
>
> Thanks,
>
> -- Ralph Durkee
>
> On 08/08/2015 01:32 PM, Santiago Bassett wrote:
>
> Hi, 
>
> 

[ossec-list] Re: Ignore computer account logon and logoff

[Jesus Linares]

Thanks for your recommendation about windows logs.

On Wednesday, October 26, 2016 at 4:52:41 AM UTC+2, InfoSec wrote:
>
> Windows uses a combination of tabs and spaces between fields, and between 
> field names and field content. There is not telling how many of each there 
> are.
>
> Using \t*\s* between field name and field content has proven to be 
> bulletproof for me.
>
> Example: Account Name:\t*\s*\.+\$
>
> If the $ is followed by anything other than  it is misinterpreted 
> as a variable and fails, Account 
> Name:\t*\s*\.+\$|some_other_regex does not behave as expected.
>
>

-- 

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

[ossec-list] Re: Teamviewer logs not consistant

[Jesus Linares]

Hi,

this could be a good starting point:


^\d+\t+\.+\d\d-\d\d-\d\d\d\d 





teamviewer
^\d+\t\t
^\d+\t+\s*(\.+)\t+(\.+)\t+(\.+)\t+RemoteControl\t+{(\.+)}
extra_data,status,srcuser,id





teamviewer
^\d+\t
^\d+\t+(\.+)\t+(\.+)\t+(\.+)\t+(\.+)\t+RemoteControl\t+{(\S+)}

url,extra_data,status,srcuser,id


Output 1:
151856824   01-06-2016 19:30:36 01-06-2016 20:00:44 
userRemoteControl   {38164985-5201-4BFE-BF6E-32F2E770954E}
...
**Phase 2: Completed decoding.
   decoder: 'teamviewer'
   extra_data: '01-06-2016 19:30:36'
   status: '01-06-2016 20:00:44'
   srcuser: 'user'
   id: '38164985-5201-4BFE-BF6E-32F2E770954E}'


Output 2:
891956027   Afterworld  18-08-2016 18:13:27 18-08-2016 18:26:37 
userRemoteControl   {E4555287-A198-4D54-8851-67C2DF8EA5DD}
...
**Phase 2: Completed decoding.
   decoder: 'teamviewer'
   url: 'Afterworld'
   extra_data: '18-08-2016 18:13:27'
   status: '18-08-2016 18:26:37'
   srcuser: 'user'
   id: 'E4555287-A198-4D54-8851-67C2DF8EA5DD}'

If you create more decoders/rules for teamviewer, please share them here.

Regards.

On Wednesday, October 12, 2016 at 1:41:56 AM UTC+2, Jacob Mcgrath wrote:
>
> I am looking at logging on a windows agent Teamviewer logs.  The issue is 
> the irregular output like soo.
>
> 673915615 Support Team20-05-2016 19:37:51 20-05-2016 20:04:29 
> userRemoteControl   {811FB7EC-E1EB-470A-B5EE-01E7290B7FDF}  
> 151856824 01-06-2016 19:30:36 01-06-2016 20:00:44 user
> RemoteControl   {38164985-5201-4BFE-BF6E-32F2E770954E}  
> 151856824 02-06-2016 18:29:32 02-06-2016 18:47:33 user
> RemoteControl   {22D28696-95C0-4AF8-9EBE-440580B85D65}  
> 172856590 PCMust  16-08-2016 15:15:21 16-08-2016 15:22:54 user
> RemoteControl   {934B2BDF-DB82-4113-9C60-9250A6E47A7A}  
> 891956027 Afterworld  18-08-2016 18:13:27 18-08-2016 18:26:37 
> userRemoteControl   {E4555287-A198-4D54-8851-67C2DF8EA5DD}
>
>
> How would one go about regexing this type of output?
>
>
> The stuff in blue would be the required data to pass to rulesets  
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Ignore computer account logon and logoff

[Jesus Linares]

I didn't test it, but it seems OSSEC tries to use "$\S+" as a variable.

You could do something like:
@domain
Account Name: \S+\$

Regards.

On Monday, October 10, 2016 at 10:28:37 PM UTC+2, 
roberto@phoebustecnologia.com.br wrote:
>
> hi!
> I'm using this solution in my ossec. But I have another question.
> I also wanted to ignore the following entry:
> host$*@domain*
>
> Can anyone help?
>
> Already tried:
>
> Account Name: \S+\$@\S+
> Account Name: \S+\$\S+
> Account Name: \S+\$'@'\S+
> Account Name: \S+\$\S+
> Account Name: \S+\$\\S+
> Account Name: \S+\$\\w
>
> Always gives error. For example, when I use the ossec-logtest:
>
> *XMLERR: Unknown variable: '\S+'..*  error for:
> Account Name: \S+\$\S+
>
> * XMLERR: Unknown variable: '@\S+'..*  error for:
> Account Name: \S+\$@\S+
>
>
> Em terça-feira, 17 de abril de 2012 16:08:29 UTC-3, ash kumar escreveu:
>>
>> This should do it
>>
>>User Name: \S+\$|Account Name: \S+\$
>>
>> Ash Kumar
>>
>> On Monday, April 9, 2012 4:04:16 PM UTC-4, (unknown) wrote:
>>>
>>> Can someone help me with this rule to filter out computer logon and 
>>> logoff events?  Since all computer accounts end with the $ I figured I 
>>> could just filter on that, for example 
>>>
>>> WinEvtLog Rule: 18149 (level 3) -> 'Windows User Logoff.' Src IP: (none) 
>>> User: *W-ABC-3ND88P1$* WinEvtLog: Security: AUDIT_SUCCESS(4634)
>>>
>>>
>>> Here is what I have but it is not working.  I have tried several 
>>> variations of the regex but no luck with anything.  Sure it is something 
>>> simple but I am just not hitting the right combination.
>>>
>>>   
>>> 18149
>>> User: w+ \$
>>> Ignore machine logoff
>>>   
>>>
>>> Thanks for the help.
>>> Karl
>>>
>>> The information transmitted is intended only for the person or entity to
>>> which it is addressed and may contain confidential and/or privileged
>>> material. Any review, retransmission, dissemination or other use of, or
>>> taking of any action in reliance upon this information by persons or
>>> entities other than the intended recipient is prohibited. If you received
>>> this in error, please contact the sender and destroy any copies of this
>>> document.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Correct way to overwrite a "chained" rule

[Jesus Linares]

Hi Christina,

1) I think you could create a child rule of 5503 (if_sid) with level 0. 
Then, use regex to match a user with backslash. In this way, you are 
ignoring alert 5503 if the user contains a backslash (or anything you put 
in the regex). You could do the same with alert 5551.
2)  is OS_Match/sregex Syntax 

.
3) There is no "negative match". This is the 
syntax: http://ossec-docs.readthedocs.io/en/latest/syntax/regex.html. Just 
for srcip, dstip you can user "!".
4) A child rule of 5551 with level 0 and with the regex for your user it 
should solve your issue.

Regards.


On Wednesday, October 5, 2016 at 6:53:49 PM UTC+2, linuxfancy wrote:
>
> Hello all,
>
> My problem: 
> Erroneous messages are causing rule 5503 (pam_unix authentication failure) 
> to trigger even when the login was actually successful.  This is not 
> OSSEC's fault - it is due to the pam stack being configured to check both 
> pam_unix and another module which performs AD authentication.  So a 
> successful AD login still causes a spurious pam_unix failure to be written 
> into the logs, e.g.
>
> Oct  5 16:03:22 my-server sudo: pam_unix(sudo:auth): authentication 
> failure; logname=AD\cplummer1 uid=1010101010 euid=0 tty=/dev/pts/1 
> ruser=AD\cplummer1 rhost=  user=AD\cplummer1
>
> or 
>
> Oct  5 16:03:20 my-server sshd[10362]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=/dev/pts/1 ruser= rhost=  
> user=AD\cplummer1
>
> This isn't a major problem on its own, since rule 5503 is only level 5 and 
> I only alert on level 7 and higher.  However, rule 5551 matches on 6 
> instances of 5503 from the same source IP within 180 seconds:
>
>   
> 5503
> 
> Multiple failed logins in a small period of 
> time.
> authentication_failures,
>   
>
> I suppose I could create a local rule using 5551 and set 
> the level to 0 if the user= contains a backslash.  But I think it makes 
> more sense to prevent 5503 from triggering at all in these cases, so the 
> spurious messages don't add to the count.
>
> So, my questions:
> 1) Is there a way to overwrite 5503 (using a single rule) to match as it 
> does today EXCEPT when the user name contains a backslash?  I couldn't tell 
> from the online docs whether it is possible to have multiple conditions 
> ANDed in a single rule.
>
> 2) Is it possible to use regex syntax for the  attribute to match 
> any string containing a backslash? Or would I have to use something like 
> user=\S*\\ instead?
>
> 3) Is it possible to perform a negative match in either regex or match 
> syntax?
>
> 4) What's the best way to do this?  Since I think the answers to 1-3 are 
> "no", it seems like the only way to do what I am looking for would be to 
> create a local rule (e.g. 105503) using 5503, and then 
> overwrite 5551 with 105503 instead.
>
> Thanks,
> Christina
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 SSTP VPN rule.

[Jesus Linares]

I'm not familiar with RRAS or Radius. If you share the logs, we can help 
with decoders and rules for the events that you need.

On Monday, October 3, 2016 at 6:11:37 PM UTC+2, namobud...@gmail.com wrote:
>
> It looks like I want to monitor for windows event log source entries that 
> have keyword “RASClient” in the list. These log entries are generated from 
> the Microsoft VPN RAS application. according to research I did.
>
> Apparently RRAS keeps local logs too.
>
> Ideally it would be great to be able to GEOLocate the VPN connection.
>
> Maybe I need to be monitoring Radius connections too?
>
> On Saturday, October 1, 2016 at 5:03:18 AM UTC-4, Jesus Linares wrote:
>>
>> Hi,
>>
>> if you share the events (logs) that you want to track, we can help to 
>> create the decoders and rules.
>>
>> Regards.
>>
>> On Wednesday, September 28, 2016 at 5:58:03 PM UTC+2, 
>> namobud...@gmail.com wrote:
>>>
>>> I'm wondering if anyone has done an OSSEC Windows SSTP VPN rule?
>>> I want to start tracking and logging them, GEO tracking would be awesome?
>>>
>>> Has anyone already done this, or could they suggest a rule?
>>>
>>> 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] Re: Ossec Naming Conventions

[Jesus Linares]

I don't think so. Check out the ossec.log of the agents that don't connect 
to the Manager. Usually they do not connect due to: firewall, bad key or 
duplicate counters (rids). The hostname should not be a problem.

On Friday, September 30, 2016 at 2:56:28 PM UTC+2, EvilZ wrote:
>
> Hi everyone i would like to know if Ossec use a Netbios naming convention 
> where the name must be less than 14 charaters ? because i noticed a few 
> servers who will not connect and realized it was because they are 15 
> characters however their are other servers who are active and yet have the 
> same number of characters
>
> In this example, these two "servers" have two different name however my 
> fear is that the second one would not be accepted as it would be seen as a 
> duplicate as Ossec cannot read further than the 14 characters name which 
> would then ignore the 1.
>
>
> bob-the-bobiest
> bob-the-bobiest1
>
> Am i correct ?
>
> 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.

[ossec-list] Re: Ossec authd, Cant connect

[Jesus Linares]

Hi, 

it looks like a firewall issue. You could run tcpdump in the Manager to see 
if there are a connection between the manager and the agent.

Regards.

On Monday, October 3, 2016 at 10:02:52 AM UTC+2, Ali Khan wrote:
>
> Hi All,
>
> I am trying to use ossec-authd and agent-authd for auto agent key 
> registration . On OSSEC server i did the following 
>
>
>1. *openssl genrsa -out /var/ossec/etc/sslmanager.key 2048*
>2. *openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out 
>/var/ossec/etc/sslmanager.cert -days 365*
>3. */var/ossec/bin/ossec-authd -p 1515 -i >/dev/null 2>&1 &*
>4. *also added the following rule in etc/ossim/firewall_include : *
>5. *-A INPUT –p tcp –-dport 1515 –j ACCEPT*
>6. *Run the ossim-reconfig and then again run **/var/ossec/bin/ossec-authd 
>-p 1515 -i >/dev/null 2>&1 and the process starts.*
>
>
> *However on agent side when i enter  **./agent-auth -m 192.168.10.246 -p 
> 1515 it gives me the following error .* 
>
> 2016/10/03 12:34:58 ossec-authd: INFO: Started (pid: 9656).
> 2016/10/03 12:34:58 ossec-authd: Unable to connect to 192.168.10.246:1515
>
> Any kind of help would be highly appreciated as I cant think of workaround 
> for this issue . 
>
> Looking forward to your 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.

[ossec-list] Re: Windows SSTP VPN rule.

[Jesus Linares]

Hi,

if you share the events (logs) that you want to track, we can help to 
create the decoders and rules.

Regards.

On Wednesday, September 28, 2016 at 5:58:03 PM UTC+2, namobud...@gmail.com 
wrote:
>
> I'm wondering if anyone has done an OSSEC Windows SSTP VPN rule?
> I want to start tracking and logging them, GEO tracking would be awesome?
>
> Has anyone already done this, or could they suggest a rule?
>
> 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] Re: What is the best way to make ossec ignore alerts caused by new packages (unatended upgrades)?

[Jesus Linares]

Hi James,

review the alerts related with packages, and create a rule to ignore the 
events that you do not need.

Regards.

On Wednesday, September 28, 2016 at 5:40:34 PM UTC+2, James Vernon wrote:
>
> As the title sais, is there a defined best practice for this?
>
> If unattended upgrades runs and upgrades any packages, ossec spams emails 
> about changed files (as expected). Is there a tried and true method to make 
> ossec aware that the packages were updated via unattended upgrades so it 
> doesn't generate alerts or something similar outside of ossec (I 
> acknowledge that this can be abused, but I would like to see if its 
> possible)? I'm quite new to this software so you will have to forgive me.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Active response command not present

[Jesus Linares]

Hi,

if it is a linux agent, the restart-ossec.cmd will not work. You must use 
restart-ossec.sh.

Check out the documentation:

   - http://ossec-docs.readthedocs.io/en/latest/manual/ar/index.html
   - 
   
http://ossec-docs.readthedocs.io/en/latest/syntax/head_ossec_config.active-response.html
   

Regards.

On Friday, September 23, 2016 at 3:53:44 PM UTC+2, F1LT3R wrote:
>
> I also see the above on a Linux box (Ubuntu 14).
>
> On Tuesday, April 21, 2015 at 10:07:28 AM UTC-4, Bob Jolliffe wrote:
>>
>> I am seeing the following in my ossec.log on a linux agent: 
>>
>> ossec-execd: INFO: Active response command not present: 
>> '/var/ossec/active-response/bin/restart-ossec.cmd'. Not using it on 
>> this system 
>>
>> It is true that command is not present.  It looks maybe this is the 
>> command for a windows agent.  What I do have is: 
>>
>> /var/ossec/active-response/bin/restart-ossec.sh 
>>
>> Is there a configuration option I need to set somewhere to tell what 
>> the active response command should be? 
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Querying Kibana for specific event types

[Jesus Linares]

Hi,

Review *alerts.json* in order to know if you have the decoder name and the 
event id extracted in fields. Also, check out your logstash mapping. If the 
fields are not extracted in alerts.json, you can not filter by them in 
kibana.

I did the query in Wazuh and it works, so I recommend you to try it. This 
is the documentation 
<http://wazuh-documentation.readthedocs.io/en/latest/ossec_elk.html>.

Regards.

On Wednesday, September 21, 2016 at 3:55:17 PM UTC+2, namobud...@gmail.com 
wrote:
>
> I tried this and it didn't work, I think because decoder.name doesn't 
> exist in the logstash index. Instead of id, I have _id which is not a 
> number but a character string.
>
> On Tuesday, September 20, 2016 at 3:56:44 AM UTC-4, Jesus Linares wrote:
>>
>> Hi,
>>
>> in order to filter by an event ID of Windows, just use this query in the 
>> search bar of kibana:
>> decoder.name:"windows" AND id:"4625"
>>
>> In this case, you are filtering events with id 4625:
>> 2016 Sep 20 07:50:17 WinEvtLog: Security: AUDIT_FAILURE(*4625*): 
>> Microsoft-Windows-Security-Auditing: (no user): no domain: WIN-: An 
>> account failed to log on...
>>
>> I assume you are sending the file *alerts.json* to elasticsearch.
>>
>> Regards.
>>
>> On Monday, September 19, 2016 at 10:11:37 PM UTC+2, namobud...@gmail.com 
>> wrote:
>>>
>>> Based on this storm center article:
>>>
>>> https://isc.sans.edu/forums/diary/Windows+Events+log+for+IRForensics+Part+1/21493/
>>>
>>> I'm trying to figure out how to query Kibana for specific event ID 
>>> numbers from the dashboard search area the article mentions. Is there a 
>>> definitive guide for searching OSSEC with Kibana.
>>>
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Querying Kibana for specific event types

[Jesus Linares]

Hi,

in order to filter by an event ID of Windows, just use this query in the 
search bar of kibana:
decoder.name:"windows" AND id:"4625"

In this case, you are filtering events with id 4625:
2016 Sep 20 07:50:17 WinEvtLog: Security: AUDIT_FAILURE(*4625*): Microsoft-
Windows-Security-Auditing: (no user): no domain: WIN-: An account 
failed to log on...

I assume you are sending the file *alerts.json* to elasticsearch.

Regards.

On Monday, September 19, 2016 at 10:11:37 PM UTC+2, namobud...@gmail.com 
wrote:
>
> Based on this storm center article:
>
> https://isc.sans.edu/forums/diary/Windows+Events+log+for+IRForensics+Part+1/21493/
>
> I'm trying to figure out how to query Kibana for specific event ID numbers 
> from the dashboard search area the article mentions. Is there a definitive 
> guide for searching OSSEC with Kibana.
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Best way to whitelist installed RPM / packages

[Jesus Linares]

Hi Shawn,

by default OSSEC triggers an alert when a package is 
installed/removed/updated:

*command*
yum install valgrind.x86_64

*archives.log*
2016 Sep 15 09:08:44 ip-10-0-0-10->/var/log/messages Sep 15 09:08:43 ip-10-0
-0-10 yum[5630]: Installed: 1:valgrind-3.10.0-16.el7.x86_64

*alerts.log*
** Alert 1473930524.4047: mail  - syslog,yum,config_changed,pci_dss_10.6.1,
pci_dss_10.2.7,
2016 Sep 15 09:08:44 ip-10-0-0-10->/var/log/messages
Rule: 2932 (level 7) -> 'New Yum package installed.'
Sep 15 09:08:43 ip-10-0-0-10 yum[5630]: Installed: 1:valgrind-3.10.0-
16.el7.x86_64


If you want a whitelist of packages:

   1. Create a decoder for yum in order to extract the package name in a 
   field (*extra_data *for example)
   2. Create a *CDB list* with the white list packages
   3. Create a child rule of 2932 in* local_rules.xml* with level 0 and 
   check if extra_data (the package name) is in the CDB list. In this way, you 
   will see only alerts for packages which are not in the list.

I hope it helps.
Regards.

On Wednesday, September 14, 2016 at 10:27:07 PM UTC+2, Shawn Wiley wrote:
>
> Is there a way with OSSEC to create a white list of packages that should 
> be installed on my Red Hat server and create an ongoing alert that's 
> triggered if an unauthorized package (non-white-list) is installed? My 
> concern is if someone installs an unauthorized package and I miss the alert 
> or the alert is cleared would the package be able to continue to run 
> without any new alerts being generated? Can I use OSSEC in this test case 
> or is there another tool I need to use? Thanks in advance for any advice.
>
> -Shawn
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: Alienvault OSSEC 2.8 a couple of computers are showing disconnected from the webGUI and I don't know how to get them reconnected

[Jesus Linares]

Hi,

probably you need to reset the counters:

Stop manager and the agent: /var/ossec/bin/ossec-control stop

*agent*

   - cd /var/ossec/queue/rids
   - remove all the files

*manager*

   - cd /var/ossec/queue/rids
   - Remove *the file of the agent* (the filename is the agent ID)

Start manager and the agent: /var/ossec/bin/ossec-control start

Let me know if it works.

Regards.

On Tuesday, September 13, 2016 at 12:52:57 AM UTC+2, cher...@usa.g4s.com 
wrote:
>
> I tried to reinstall the agent manually and push it from the web GUI. I 
> made sure the OSSEC agent manager ip was pointing to the right server. 
> I would like to not jailbreak the server if possible.
>
>
> I looked at the logs and this seems like a regular issue.
>
> 2016/09/12 16:59:45 ossec-agent(4101): WARN: Waiting for server reply (not 
> started). Tried: 'ip'.
>
> 2016/09/12 17:01:53 ossec-agent: INFO: Trying to connect to server 
> (ip:1514).
>
> 2016/09/12 17:01:53 ossec-agent: INFO: Using IPv4 for: ip.
>
> 2016/09/12 17:02:14 ossec-agent(4101): WARN: Waiting for server reply (not 
> started). Tried: 'ip'.
>
> 2016/09/12 17:03:11 ossec-agent: Using notify time: 120 and max time to 
> reconnect: 240
>
> 2016/09/12 17:03:11 ossec-execd: INFO: Started (pid: ip).
>
> 2016/09/12 17:03:11 ossec-agent(1410): INFO: Reading authentication keys 
> file.
>
> 2016/09/12 17:03:11 ossec-agent: INFO: No previous counter available for 
> 'Host-ip'.
>
> 2016/09/12 17:03:11 ossec-agent: INFO: Assigning counter for agent 
> Host-ip: '0:0'.
>
> 2016/09/12 17:03:11 ossec-agent: INFO: Assigning sender counter: 0:84
>
> 2016/09/12 17:03:11 ossec-agent: INFO: Trying to connect to server 
> (ip:1514).
>
>
>
>
>
> This company is part of the G4S group of companies. This communication 
> contains information which may be confidential, personal and/or privileged. 
> It is for the exclusive use of the intended recipient(s). If you are not 
> the intended recipient(s), please note that any distribution, forwarding, 
> copying or use of this communication or the information in it is strictly 
> prohibited. Any personal views expressed in this e-mail are those of the 
> individual sender and the Company does not endorse or accept responsibility 
> for them. Prior to taking any action based upon this e-mail message, you 
> should seek appropriate confirmation of its authenticity. This message has 
> been checked for viruses on behalf of the Company.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 on windows laptops that will be out of the network

[Jesus Linares]

Vilius, OSSEC is designed to receive alerts from the present and not old 
logs. If you send to OSSEC old logs, the alert timestamp will be the 
timestamp when the alert was triggered (and not the timestamp when the log 
was generated). I was talking about a related issue here 
<https://groups.google.com/forum/#!topic/wazuh/eSqkmBfSSIk>.

Nick, usually it is not a good idea to make your Manager accessible from 
the public Internet. If your server has a security breach, anyone could 
access to confidential information of your agents. It could even control 
them if they have the active response enabled. If you are sure, follow some 
security hardening guide for your host and configure your firewall 
properly. I would not recommend to make public a OSSEC Manager.

Regards.

On Tuesday, September 13, 2016 at 6:47:14 PM UTC+2, Nick Giannoulis wrote:
>
> Didnt know you can use "ANY" , thats great thanks a lot. If my ossec 
> server is accessible externally any alerts from the agents should still 
> reach my server right ? ( if the agents are connected to the net and 
> nothing blocking )
>
> On Tuesday, 13 September 2016 10:51:37 UTC+1, Jesus Linares wrote:
>>
>> Hi,
>>
>> as Eero said, you can register your agents with ANY instead of the IP.
>>
>> anyway, remember that the agents send the alerts in real time. *Alerts are 
>> not stored to be sent later*. So, you are not going to receive the 
>> alerts generated in your agents when they were not connected to the Manager 
>> network.
>>
>> Regards.
>>
>> On Tuesday, September 13, 2016 at 11:23:56 AM UTC+2, Eero Volotinen wrote:
>>>
>>> You can use ip address any while creating agent keys for roaming devices.
>>>
>>> Eero
>>>
>>> 2016-09-13 10:58 GMT+03:00 Nick Giannoulis <ni...@nea-idea.com>:
>>>
>>>> Hi all
>>>>  I have an OSSEC server running perfectly monitoring all my servers. I 
>>>> want to expand it to start monitoring my 'normal' clients ( win7-10 
>>>> laptops 
>>>> and workstations ) . Some of these laptops will be outside of the network 
>>>> most of the time. Considering that ossec agents shouldnt have the same IP 
>>>> is there any work around for my situation ? i imagine at some point or 
>>>> another a few laptops will have the same IP while they are connected to 
>>>> various other networks. 
>>>>
>>>>
>>>> -- 
>>>>
>>>> --- 
>>>> You received this message because you are subscribed 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] OSSEC agent on windows laptops that will be out of the network

[Jesus Linares]

Hi,

as Eero said, you can register your agents with ANY instead of the IP.

anyway, remember that the agents send the alerts in real time. *Alerts are 
not stored to be sent later*. So, you are not going to receive the alerts 
generated in your agents when they were not connected to the Manager 
network.

Regards.

On Tuesday, September 13, 2016 at 11:23:56 AM UTC+2, Eero Volotinen wrote:
>
> You can use ip address any while creating agent keys for roaming devices.
>
> Eero
>
> 2016-09-13 10:58 GMT+03:00 Nick Giannoulis  >:
>
>> Hi all
>>  I have an OSSEC server running perfectly monitoring all my servers. I 
>> want to expand it to start monitoring my 'normal' clients ( win7-10 laptops 
>> and workstations ) . Some of these laptops will be outside of the network 
>> most of the time. Considering that ossec agents shouldnt have the same IP 
>> is there any work around for my situation ? i imagine at some point or 
>> another a few laptops will have the same IP while they are connected to 
>> various other networks. 
>>
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed 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] Re: ossec-analysisd: Rules in an inconsistent state. Exiting

[Jesus Linares]

Hi,

the  section is missing in your ossec.conf. Did you remove it?.

Regards.

On Tuesday, September 13, 2016 at 10:19:19 AM UTC+2, toddmichael wrote:
>
> When I start ossec-hids via init script, ossec-analysisd dies shortly 
> thereafter with the following error:
>
> 2016/09/13 01:07:43 ossec-analysisd: Rules in an inconsistent state. 
> Exiting.
>
> Interestingly enough, I don't see this issue if I simply start 
> ossec-analysisd by itself using:
>
> /var/ossec/bin/ossec-analysisd -d
>
> In this case, the last message I see is:
>
> 2016/09/13 01:17:28 ossec-analysisd: DEBUG: Startup completed. Waiting for 
> new messages..
>
> Config and system info below.  Appreciate any assistance.  Cheers.
>
> Todd Michael
>
> -
>
> *# version*
> OSSEC HIDS v2.8.3 - Trend Micro Inc.
>
> -
>
> *# /etc/ossec-init.conf*
> DIRECTORY="/var/ossec"
> VERSION="2.8.3"
> DATE="Fri Apr  8 14:30:15 EDT 2016"
> TYPE="server"
>
> -
>
> *# /var/ossec/etc/ossec.conf*
> 
>   
> 21600
> /etc,/usr/bin,/usr/sbin
> /bin,/sbin
> /etc/mtab
> /etc/hosts.deny
> /etc/mail/statistics
> /etc/random-seed
> /etc/adjtime
> /etc/httpd/logs
>   
>   
> no
> /var/ossec/etc/shared/rootkit_files.txt
> 
> /var/ossec/etc/shared/rootkit_trojans.txt
> /var/ossec/etc/shared/system_audit_rcl.txt
>   
>   
> syslog
> /var/log/messages
>   
>   
> yes
> oss...@ossec1.domain.com 
> m...@mydomain.com 
> 127.0.0.1
>   
>   
> 7
> 1
> no
>   
>   
> secure
>   
> 
>
> -
>
> *# uname*
> Linux ossec1-mgmt-usw2 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 
> 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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: logg file from Kaspesky Antivirus for Linux File Server 8.0

[Jesus Linares]

As Dan said:

> logcollectord currently does not support pulling data from a database.


Try to create a script to transform the db to a log file or configure the 
AV to send the logs to syslog (if it is possible).

On Friday, September 9, 2016 at 3:18:49 PM UTC+2, al...@mazm.ru wrote:
>
> So , I did make "dump" from *.db file to text file and added to this 
> message.
>
> Test file named eicar.
>
>
> https://drive.google.com/file/d/0BwoZO7sx1EqaU1JYS0o2dHpJQzg/view?usp=sharing
>
>
>
>
>

-- 

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