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

[Gert Verhoog]

Aha, thanks for the insights, that makes sense. I've changed the \.* into 
\S* and restarted everything. It seems to work! Thanks for your help!

Cheers,
Gert

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

-- 

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

[Topper Bowers]

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  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/lgFD
>> OlR6zNg 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+unsubscr...@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] OSSEC slack alerts for agents v2.9.0

[Fredrik Hilmersson]

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.

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

[ossec-list] problems registering agents

[Topper Bowers]

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.