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

[Gert Verhoog]

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.
>>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: 
>>> > 
>>> >   >> ignore="600"> 
>>> > 510 
>>> > 

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

[Gert Verhoog]

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.
>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: 
>> > 
>> >   > ignore="600"> 
>> > 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 
>> > 
>> 

[ossec-list] Disable the ossec-agent for OS updates.

[andrii . pravdyvyi]

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.

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. 


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]

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] OSSEC slack alerts for agents v2.9.0

[Fredrik Hilmersson]

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]

Hello and thanks Jesus,

I've read the documentation, however I do not use the forked wazuh version 
of OSSEC so i'm not sure that the integrator applies? What I want to 
clarify regarding my issue, so I do not misunderstand the approach. The 
OSSEC server (host) is the one responsible for sending the slack 
notifications reading from the *alerts.log(?).*

The communication between the host and agent works, as my host alerts.log 
is getting populated with alerts regarding the agent. The issue seem to be 
that the slack script does not catch these, or do I need to specify 
anything at the agent side for the host to send its alerts or vice versa?

Kind regards

Den måndag 22 maj 2017 kl. 18:33:54 UTC+2 skrev 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.

Re: [ossec-list] Re: problems registering agents

[Topper Bowers]

Thank you! This is a huge help. The upgrade to 2.0 locally was painless
*and* fixed my authd issues. Now to production.

On Mon, May 22, 2017 at 7:19 PM, Jesus Linares  wrote:

> 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/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/to
>>> pic/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 <(646)%20515-6630>
>>
>> http://www.vitals.com
>>
> --
>
> ---
> 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.