Re: [ossec-list] mariadb monitoring?

[John Gelnaw]

Link to the MariaDB audit plugin format: 
 
https://mariadb.com/kb/en/mariadb/about-the-mariadb-audit-plugin/#audit-log-format
 

syslog format: 
 
[timestamp][syslog_host][syslog_ident]:[syslog_info][serverhost],[username],[host],
[connectionid],[queryid],[operation],[database],[object],[retcode]

We're using syslog, since it allows us to easily forward the logs to our 
central logging server for archiving.

And here's a small sample of log files:

May 23 14:40:00 mysql09a mysql-server_auditing: 
 mysql09a.local,root,MYSQLADM.local,725989,179577437,QUERY,,'DROP DATABASE 
`ese_adherence_s`',0
May 24 10:22:21 mysql09a mysql-server_auditing: 
 
mysql09a.local,ahc_shwb01_t,10.15.190.182,840046,210662172,QUERY,`ahc_shwb01_t`,'CREATE
 
TABLE `zipcodes` (   `zip` varchar(16) NOT NULL DEFAULT \'0\' COMMENT 
\'Postal / ZIP code.\',   `city` varchar(30) NOT NULL DEFAULT \'\' COMMENT 
\'City.\',   `state` varchar(30) NOT NULL DEFAULT \'\' COMMENT \'Province / 
State.\',   `latitude`',0
May 24 10:22:21 mysql09a mysql-server_auditing: 
 
mysql09a.local,ahc_shwb01_t,10.15.190.182,840046,210662174,QUERY,`ahc_shwb01_t`,'/*!4
 
ALTER TABLE `zipcodes` DISABLE KEYS */',0
May 24 11:51:30 mysql09a mysql-server_auditing: 
 mysql09a.local,ahc_shwb01_t,ahc-web29d.local,849705,0,CONNECT,ahc_shwb01_t,,0 
  
May 24 11:51:30 mysql09a mysql-server_auditing: 
 
mysql09a.local,ahc_shwb01_t,ahc-web29d.local,849705,0,DISCONNECT,ahc_shwb01_t,,0
 
   
May 24 12:01:12 mysql09a mysql-server_auditing: 
 mysql09a.local,,AHC-GSMPX11.local,850526,0,FAILED_CONNECT,,,1158

The 'mysql-server_auditing' is a user-configurable option (I took the 
default).

I can provide a larger sample of logs if anyone wants.

-- 

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

[Pedro Sanchez]

Hi,

If you want to disable syscheck component for specific folders, you could
push an  setting for syscheck block using agent.conf centralized
configuration.
For example, you could ignore something like:

*/etc/*


Reference here

.

Same way you could totally disable syscheck using  setting.

When the OS update be done, modify again agent.conf to restore back the
configuration.

To prevent alerts for "new file" you could:


> */var/ossec/bin/syscheck_control -u AGENT_ID*
> *Remove .cpt files in /var/ossec/queue/syscheck**Restart Manager.*



I hope someone could add more ideas for this use case.

Best,
Pedro.




On Tue, May 23, 2017 at 9:33 PM,  wrote:

> I am going to update my Linux servers and I tried to disable the
> ossec-agent for this time.
> I was the following workarounds:
> 1. stop agent on a host
> 2. run   /var/ossec/bin/syscheck_control -u AGENT_ID
> 3. update
> 4. up agent
> But after start agent I got lots of trigger "new files in the server"
> alarms.  (alert_new_file  - yes)
>
> How to properly disable the ossec-agent on a host during the Linux update
> or for modifying 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.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and 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 
.
 
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 
>> ,
>>  
>> 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 events. 
>>
>> Do you have any ideas what I could try next? 
>>
>> Many thanks for your help so far!
>>
>>
>> On Tuesday, May 23, 2017 at 1:35:58 AM UTC+12, Jesus Linares wrote:
>>>
>>> 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.

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

[Fredrik Hilmersson]

Thanks everyone for the feedback and support. It all made sense and your 
comment did guide me to resolve it, wasn't any harder then updating the 
 section and add agent ID, e.g.:



   ossec-slack

   server,AGENT.ID 

   7

   

Den tisdag 23 maj 2017 kl. 16:18:29 UTC+2 skrev 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. 
> 
>
> 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

[Fredrik Hilmersson]

Thanks everyone for the feedback and support. It all made sense and your 
comment did guide me to resolve it, wasn't any harder then updating the 
 section and add agent ID, e.g.:



   ossec-slack

   local,AGENT.ID

   7

   

Have a nice day and,
Kind regards

Fredrik
Den tisdag 23 maj 2017 kl. 16:18:29 UTC+2 skrev 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. 
> 
>
> 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.