Re: [ossec-list] ossec 3.6 configration

[Daniel Cid]

What errors are you getting when you try to install?

If you can give more details, maybe we will be able to help more.

Thanks,


On Sat, Jul 30, 2022, 11:16 AM ABHISHEKH LADE 
wrote:

> Dear Member,
> Hello  my name is Abhishekh. I am new here and want to install the OSSEC
> into ubuntu but not able to install please help me out and please tell me
> about OSSEC. 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ossec-list/e2e68b5a-47a2-459f-a515-80e19e4d5217n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/CABEm7%2BCJFwXow9eV1H-imG_2DZGApv8EpOoQfk0PXcOkqKbRag%40mail.gmail.com.

Re: [EXTERNAL MSG:][ossec-list] Re: ACTIVE-RESPONSE NOT WORKING

[Daniel Folch]

Hello John,

Our documentation has a comprehensive guide about the capabilities of 
active response and how to configure it,

https://documentation.wazuh.com/3.13/user-manual/capabilities/active-response/index.html

Also, we periodically release blog posts about different topics, some of 
them may be of your interest, for example in this one we explain how to 
integrate Wazuh with Yara using active response:

https://wazuh.com/blog/how-to-integrate-yara-with-wazuh/

If you have any more questions about active-response or find any problem 
configuring it do not hesitate to contact us.

Regards,
Daniel Folch

On Thursday, September 24, 2020 at 1:35:12 PM UTC+2, John Gomez wrote:
>
> Is there any deep dive on active response or a collection of use cases as 
> to how people are using it?
>
> Just seems to be such a cool capability of OSSEC that is under utilized.
>
>
>
> Sent from my T-Mobile 4G LTE Device
>
>
>
>  Original message 
> From: Daniel Folch > 
> Date: 9/23/20 7:21 AM (GMT-05:00) 
> To: ossec-list > 
> Subject: [EXTERNAL MSG:][ossec-list] Re: ACTIVE-RESPONSE NOT WORKING 
>
> WARNING: This email originated from outside of Sensato. Do not click 
> links or open attachments unless you verify by phone with the sender.
>
> Hello, 
>
> First, let us start with the active response configuration of the manager 
> and agent, the configuration you shared should be used on the manager side, 
> and for the agent you just need to set it like this:
>
>   
> no
> /var/ossec/etc/wpk_root.pem
> yes
>   
>
> As a side note, the rule 5720 is triggered when the rule 5716 activates 8 
> times in a short period of time, so having both of them in the active 
> response is not necessary.
>
> Hydra tests the passwords in the list sequentially and it is really fast 
> so if your list only contains few passwords it may be possible for hydra to 
> test the correct password from the list before active response can shut 
> down the connection form the IP, this should not happen in a real brute 
> force attack as the list of passwords would be long enough for active 
> response to act in time. A possibility to minimize this phenomenom would be 
> to reduce the number of attempts needed before shutting down.
>
> Just to verify could you share the length of the list you are using for 
> this test, and if possible could you try running Hydra like this to verify 
> that active response is working as intended:
>
> hydra -l agent -x 1:5:aA1 [AGENT_IP] ssh
>
> This will try to test all combinations of lowercase characters, uppercase 
> characters, and numbers with a length between 1 and 5, so it should not be 
> able to find your password before active response triggers.
>
> Regards, 
> Daniel Folch
>
> On Tuesday, September 22, 2020 at 1:07:58 PM UTC+2, conm...@gmail.com 
> wrote: 
>>
>> Hi everybody
>> I have seen an article about configuring active-response to block SSH 
>> bruteforce on https://wazuh.com/blog/blocking-attacks-active-response/
>>
>> I have configured the direction and added some ssh related rules hoping 
>> that it will prevent the attack, but it doesn't work.
>> I configured the following in ossec.conf:
>> 
>>  firewall-drop 
>>  firewall-drop.sh 
>>  srcip 
>>  yes 
>> 
>>
>> 
>>  firewall-drop 
>>  local 
>>  5712,5716,5720 
>>  1800 
>> 
>>
>> I still find the password to login after bruteforce, I use the following 
>> command to attack:
>> hydra -l agent -P /home/attacker/Desktop/list.txt 192.168.10.2 -t 4 ssh
>>
>> Is there any way the active-response can prevent this
>> thanks everyone
>>
> -- 
>
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ossec...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ossec-list/fc270a22-8c00-4094-a5b5-fed439442598o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/ossec-list/fc270a22-8c00-4094-a5b5-fed439442598o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 

--- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/f966a44a-fc3c-41ce-b0c8-b837b74b5d87o%40googlegroups.com.

[ossec-list] Re: ACTIVE-RESPONSE NOT WORKING

[Daniel Folch]

Hello, 

First, let us start with the active response configuration of the manager 
and agent, the configuration you shared should be used on the manager side, 
and for the agent you just need to set it like this:

  
no
/var/ossec/etc/wpk_root.pem
yes
  

As a side note, the rule 5720 is triggered when the rule 5716 activates 8 
times in a short period of time, so having both of them in the active 
response is not necessary.

Hydra tests the passwords in the list sequentially and it is really fast so 
if your list only contains few passwords it may be possible for hydra to 
test the correct password from the list before active response can shut 
down the connection form the IP, this should not happen in a real brute 
force attack as the list of passwords would be long enough for active 
response to act in time. A possibility to minimize this phenomenom would be 
to reduce the number of attempts needed before shutting down.

Just to verify could you share the length of the list you are using for 
this test, and if possible could you try running Hydra like this to verify 
that active response is working as intended:

hydra -l agent -x 1:5:aA1 [AGENT_IP] ssh

This will try to test all combinations of lowercase characters, uppercase 
characters, and numbers with a length between 1 and 5, so it should not be 
able to find your password before active response triggers.

Regards, 
Daniel Folch

On Tuesday, September 22, 2020 at 1:07:58 PM UTC+2, conm...@gmail.com wrote:
>
> Hi everybody
> I have seen an article about configuring active-response to block SSH 
> bruteforce on https://wazuh.com/blog/blocking-attacks-active-response/
>
> I have configured the direction and added some ssh related rules hoping 
> that it will prevent the attack, but it doesn't work.
> I configured the following in ossec.conf:
> 
>  firewall-drop 
>  firewall-drop.sh 
>  srcip 
>  yes 
> 
>
> 
>  firewall-drop 
>  local 
>  5712,5716,5720 
>  1800 
> 
>
> I still find the password to login after bruteforce, I use the following 
> command to attack:
> hydra -l agent -P /home/attacker/Desktop/list.txt 192.168.10.2 -t 4 ssh
>
> Is there any way the active-response can prevent this
> thanks everyone
>

-- 

--- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/fc270a22-8c00-4094-a5b5-fed439442598o%40googlegroups.com.

[ossec-list] Windows Server agent not sending notifications to Linux server

[Daniel Gerep]

Hi all,

I am starting to use OSSEC so I may be doing something wrong here.

I have OSSEC installed as a server in my Linux VM and the Agent in my 
Windows Server 2012 VM.

My server has the default configuration plus this:

  
 ossec-slack
 ossec-slack.sh
  
 no
  

  
no
ossec-slack
local
3
  

  
secure
  

In my Server, using the agent_control I can see my agent is *active*

[root@gateway1-proxy bin]# ./agent_control -l

OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: gateway1-proxy (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: clearing-optimizer, IP: XX.XX.X.X, Active

With that, I believe my server and agent are communicating as expected.

In my server's log, I have a lot of:

2020/08/17 19:25:18 ossec-remoted: WARN: Duplicate error:  global: 22, 
local: 7947, saved global: 22, saved local:7948
2020/08/17 19:25:18 ossec-remoted(1407): ERROR: Duplicated counter for 
'clearing-optimizer'.

I have found an old post here in this group and applied the suggestion but 
the same error appears again after a while. I have also tried removing the 
agent and adding again, with a different ID and name but again, after a 
while, the error appears.

In my agent, I have the default configuration plus this:

  
no
server
3
  

So, in my understanding, this is sending any active-response event to the 
server, is that correct?

Also, another question, is there a way to trigger an event in my agent 
(Windows) so I can check if the server is receiving the notification 
correctly?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/010078f3-af73-4b7d-ba9c-88bf1f1694b0n%40googlegroups.com.

[ossec-list] Re: wazuh languages

[Daniel Folch]

Hello hiwot,

Currently, Wazuh has integrations with Slack, Pagerduty, and Virustoal, you 
can find how to use them here:
https://documentation.wazuh.com/3.12/user-manual/manager/manual-integration.html

Also, you can build your own custom integrations, in these blogposts you 
can find a couple of examples of how to do this:
https://wazuh.com/blog/how-to-integrate-external-software-using-integrator/
https://wazuh.com/blog/aws-sns-integration/

Regards,
Daniel Folch

On Wednesday, February 12, 2020 at 10:40:03 AM UTC+1, hiwot wrote:
>
> what are the integrated tools of wazuh
>

-- 

--- 
You received this message because you are subscribed 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/c23e75cf-9e7b-4755-ae1d-01133b14d875%40googlegroups.com.

[ossec-list] Rootcheck rule for windows - mistake in rule or problem with 64bit system?

['Daniel Bode' via ossec-list]

Hello,

i am trying to create an Ossec rootcheck file regarding to cis benchmarks
for windows server. I noticed that some rules are not working on my Windows
Server 2012 R2 (64bit) test-vm.

For example:

#2.3.7.9 Ensure 'Interactive logon: Smart card removal behavior' is set to
'Lock Workstation' or higher
[CIS - Microsoft Windows Server 2012 R2 - 2.3.7.9: Ensure 'Interactive
logon: Smart card removal behavior' is set to 'Lock Workstation' or higher]
[any] [https://workbench.cisecurity.org/benchmarks/288]
r:HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
-> ScRemoveOption -> 0;

I am not sure if this rule is created with a mistake or if the problem  is
related to the windows regsitry redirection o bit systems
(https://github.com/ossec/ossec-hids/issues/301)
<https://github.com/ossec/ossec-hids/issues/301>. Is there a workaround to
check this hives with rootchecks or are all the keys in
hkey_local_machine\software and hkey_current_user\software "useless" for
this kind of checks on 64bit Windows? I have seen that there is a
workaround in this post, but im not able to implement that.

Thank's for your support.

Best Regards

Daniel

-- 

--- 
You received this message because you are subscribed 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] Auto-ossec not working

[Daniel Saliba]

Hi guys, I am trying to use auto-ossec from binary defense for automatic 
pairing but when running the auto_ossec.exe (for windows) I get the 
following;

Client side:
[
*] Connected to auto enrollment server at IP: 10.18.119.14[*] Pulled 
hostname and IP, encrypted data, and now sending to server.
[
*] We received our new pairing key for OSSEC, closing server connection.[*] 
Removing any old keys.
[
*] Successfully imported the new pairing key.[*] Stopping the OSSEC 
service, just in case its running.
[
*] Overwriting the ossec.conf to incorporate server host IP address.[*] 
Finished. Started the OSSEC service. Auto Enrollment for OSSEC is now finish

Server side:
Client connected with ('10.18.139.101', 58745)
new() missing 1 required positional argument: 'mode'
Traceback (most recent call last):
File "auto_server.py", line 164, in handle
data = aescall(secret, data, "decrypt")
File "auto_server.py", line 145, in aescall
cipher = AES.new(secret)
TypeError: new() missing 1 required positional argument: 'mode'
Pairing complete. Terminating connection to client.


But the agent is not being registered and hence no key can be retrieved and 
added to the agent config. Can you please 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: Alerts generated despite level '0' rule being hit

[Daniel B.]

Yes, via ./ossec-control -r

On Thursday, January 26, 2017 at 4:41:20 PM UTC-5, Daniel B. wrote:
>
>
> <https://lh3.googleusercontent.com/-PjI5QG1OEt4/WIpsiYbmInI/AP8/XaaQ35illHgeh_zq_oAtMKNU6giFsek7QCLcB/s1600/2017-01-26_1638.png>
>
>
>
> 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] Alerts generated despite level '0' rule being hit

[Daniel B.]

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

[Daniel B.]

I'm a dummy. I didn't realize there was a  option. I was only using 
the  field. 

Thanks Jesus, you're a real life saver.

On Wednesday, January 18, 2017 at 12:35:42 PM UTC-5, Jesus Linares wrote:
>
> 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

[Daniel B.]

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: '100001'
>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] local_decoder.xml -- can't override (ignore) parent decoder

[Daniel B.]

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.

Re: [ossec-list] Selecting multiple, discreet weekdays

[Daniel Cid]

It should work with spaces or commas:

monday, tuesday, friday

thanks,

On Fri, Nov 18, 2016 at 1:24 PM,  wrote:

> Is it possible to select multiple, discreet days using the weekday
> function?
>
> I can get the rule to run if I select a single day and it looks like I
> should be able to specify weekends or weekdays.  What I would like to do is
> to specify certain days, in this case Sunday, Monday, Wednesday and
> Friday.  I tried using the pipe to "or" them together (Sunday|Monday|etc.,)
> but that gives me "OSSEC analysisd: Testing rules failed. Configuration
> error. Exiting." when I restart.
>
> Is there a way to do this with a single  specification or will I
> have to write a composite rule?
>
> Natassia
>
> --
>
> ---
> You received this message because you are subscribed 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] Syscheck not alerting on realtime scans

[Daniel Bray]

Dan,

Really appreciate your help and attention to this. I guess I will just have
to drop the idea of "nightly scans", and go with something like this:

28800
no
yes
yes

This should force the scan on start, and thereby force the realtime scan to
kick in soon after that completes. Then, just run regular scans every 8
hours ( 28800 seconds ). That should be a good enough approach, and keep
things scanned regularly and monitored. Honestly, that gives more of a 24/7
feel any way.

Thanks again, at least now we know.

On Tue, Aug 2, 2016 at 9:01 AM, dan (ddp)  wrote:

> On Tue, Aug 2, 2016 at 8:55 AM, Daniel Bray  wrote:
> > OK, I think that is the issue. With the settings like this:
> >
> > 1am
> > 82800
> > no
> > yes
> > no
> >
> > It is not doing the realtime scan until after 1am. I confirmed this
> today.
> > When I got in this morning and started editing some files on one of the
> > servers, I started to get realtime alerts. I quickly checked the log
> files,
> > and this is what I see:
> >
> > 2016/08/02 01:00:45 ossec-rootcheck: INFO: Starting rootcheck scan.
> > 2016/08/02 01:07:51 ossec-rootcheck: INFO: Ending rootcheck scan.
> > 2016/08/02 01:08:31 ossec-syscheckd: INFO: Starting syscheck scan
> > (forwarding database).
> > 2016/08/02 01:08:31 ossec-syscheckd: INFO: Starting syscheck database
> > (pre-scan).
> > 2016/08/02 03:14:52 ossec-syscheckd: INFO: Initializing real time file
> > monitoring (not started).
> > 2016/08/02 03:34:28 ossec-syscheckd: INFO: Real time file monitoring
> > started.
> >
> > A, OKso, it is waiting until the 1am hour, it kicks off the
> regular
> > scan, and once completed, then enables the realtime scan. OK, not really
> > what we want, but at least we are onto something.  What we want, though,
> is
> > nightly scans at a specific time (1am) but realtime scans all the time
> 24/7.
> > What would be the correct settings for that?
> >
>
> If what you have doesn't work, I'm not sure there are correct settings to
> do it.
>
> You could probably setup cron to kick off a scan every morning at 1,
> but I don't think there's currently a way to do it in the config.
>
> >
> > On Tue, Aug 2, 2016 at 8:47 AM, dan (ddp)  wrote:
> >>
> >> On Mon, Aug 1, 2016 at 10:32 AM, Daniel Bray 
> wrote:
> >> > Can someone verify that all the proper settings are in place to allow
> >> > for
> >> > realtime scans on some directories? We are running CentOS 6 servers
> >> > (manager
> >> > and agents/clients), and we use the Atomic install method.
> >> >
> >> > Here is the latest available Atomic version installed (also noted
> >> > inotify is
> >> > installed)
> >> > $ rpm -qa | egrep "inotify|ossec"
> >> > ossec-hids-2.8.3-53.el6.art.x86_64
> >> > inotify-tools-3.14-1.el6.x86_64
> >> > ossec-hids-client-2.8.3-53.el6.art.x86_64
> >> >
> >> >
> >> > Here is the important part of /var/ossec/etc/shared/agent.conf
> >> > 
> >> >   
> >> > 1am
> >> > 82800
> >> > no
> >> > yes
> >> > no
> >> >
> >> > 
> >> > /bin,/sbin,/usr,/opt
> >> >  >> > realtime="yes">/etc,/root,/var/named,/var/www
> >> > ...
> >> >
> >> > Here is the agent /var/ossec/etc/ossec.conf file
> >> > 
> >> >   
> >> > 10.10.10.10
> >> >   
> >> > 
> >> >
> >> > The above exists on all our agents/clients.
> >> >
> >> > On the manager, it pretty much matches up exactly, with the exception
> >> > that
> >> > the server is installed, and not the client:
> >> > $  rpm -qa | egrep "inotify|ossec"
> >> > inotify-tools-3.14-1.el6.x86_64
> >> > ossec-hids-server-2.8.3-53.el6.art.x86_64
> >> > ossec-hids-2.8.3-53.el6.art.x86_64
> >> >
> >> >
> >> > I have gone in an updated all servers (yum -y update) and rebooted to
> >> > the
> >> > latest kernel available on CentOS 6. I've waited a few days for the
> >> > normal
> >> > scans to complete, and I am seeing alerts for nightly changed files.
> >> > However, when I run a test on a file that exists in /root or /etc, I
> >> > never
> >> > get alerte

Re: [ossec-list] Syscheck not alerting on realtime scans

[Daniel Bray]

OK, I think that is the issue. With the settings like this:

1am
82800
no
yes
no

It is not doing the realtime scan until after 1am. I confirmed this today.
When I got in this morning and started editing some files on one of the
servers, I started to get realtime alerts. I quickly checked the log files,
and this is what I see:

2016/08/02 01:00:45 ossec-rootcheck: INFO: Starting rootcheck scan.
2016/08/02 01:07:51 ossec-rootcheck: INFO: Ending rootcheck scan.
2016/08/02 01:08:31 ossec-syscheckd: INFO: Starting syscheck scan
(forwarding database).
2016/08/02 01:08:31 ossec-syscheckd: INFO: Starting syscheck database
(pre-scan).
2016/08/02 03:14:52 ossec-syscheckd: INFO: Initializing real time file
monitoring (not started).
2016/08/02 03:34:28 ossec-syscheckd: INFO: Real time file monitoring
started.

A, OKso, it is waiting until the 1am hour, it kicks off the regular
scan, and once completed, then enables the realtime scan. OK, not really
what we want, but at least we are onto something.  What we want, though, is
nightly scans at a specific time (1am) but realtime scans all the time
24/7. What would be the correct settings for that?


On Tue, Aug 2, 2016 at 8:47 AM, dan (ddp)  wrote:

> On Mon, Aug 1, 2016 at 10:32 AM, Daniel Bray  wrote:
> > Can someone verify that all the proper settings are in place to allow for
> > realtime scans on some directories? We are running CentOS 6 servers
> (manager
> > and agents/clients), and we use the Atomic install method.
> >
> > Here is the latest available Atomic version installed (also noted
> inotify is
> > installed)
> > $ rpm -qa | egrep "inotify|ossec"
> > ossec-hids-2.8.3-53.el6.art.x86_64
> > inotify-tools-3.14-1.el6.x86_64
> > ossec-hids-client-2.8.3-53.el6.art.x86_64
> >
> >
> > Here is the important part of /var/ossec/etc/shared/agent.conf
> > 
> >   
> > 1am
> > 82800
> > no
> > yes
> > no
> >
> > 
> > /bin,/sbin,/usr,/opt
> >  > realtime="yes">/etc,/root,/var/named,/var/www
> > ...
> >
> > Here is the agent /var/ossec/etc/ossec.conf file
> > 
> >   
> > 10.10.10.10
> >   
> > 
> >
> > The above exists on all our agents/clients.
> >
> > On the manager, it pretty much matches up exactly, with the exception
> that
> > the server is installed, and not the client:
> > $  rpm -qa | egrep "inotify|ossec"
> > inotify-tools-3.14-1.el6.x86_64
> > ossec-hids-server-2.8.3-53.el6.art.x86_64
> > ossec-hids-2.8.3-53.el6.art.x86_64
> >
> >
> > I have gone in an updated all servers (yum -y update) and rebooted to the
> > latest kernel available on CentOS 6. I've waited a few days for the
> normal
> > scans to complete, and I am seeing alerts for nightly changed files.
> > However, when I run a test on a file that exists in /root or /etc, I
> never
> > get alerted. The test is simply
> > $ sudo vim /etc/hosts.allow
> > ...and I add/remove some entries, and :wq out for the update.
> >
> > After a clean update and reboot, here is the relevant log entries:
> > 2016/08/01 14:25:13 ossec-syscheckd: DEBUG: Starting ...
> > 2016/08/01 14:25:13 ossec-rootcheck: DEBUG: Starting ...
> > 2016/08/01 14:25:13 ossec-rootcheck: Starting queue ...
> > 2016/08/01 14:25:13 ossec-syscheckd: INFO: (unix_domain) Maximum send
> buffer
> > set to: '124928'.
> > 2016/08/01 10:25:14 ossec-agentd(4102): INFO: Connected to the server
> > (10.10.10.10:1514).
> > 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
> > '/var/log/messages'.
> > 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
> > '/var/log/secure'.
> > 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
> > '/var/log/maillog'.
> > 2016/08/01 14:25:19 ossec-logcollector: INFO: Started (pid: 2120).
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: (unix_domain) Maximum send
> buffer
> > set to: '124928'.
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Started (pid: 2124).
> > 2016/08/01 14:25:19 ossec-rootcheck: INFO: Started (pid: 2124).
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/bin'.
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/sbin'.
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/usr'.
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/opt'.
> > 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/etc'.
> &

Re: [ossec-list] Re: Syscheck not alerting on realtime scans

[Daniel Bray]

Victor,

The nightly scans are working just fine. That's not the problem The problem
is the real time scans are not working. Each night around 1am, I get
various reports of changed or added filesall good there. However,
during the day or really any time, if I edit/add/delete files in /etc or
/root, I am not instantly getting alerted. In other words, the realtime
scan is not monitoring those directories, even though it states:

2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time
monitoring: '/etc'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time
monitoring: '/root'.


On Mon, Aug 1, 2016 at 6:25 PM, Victor Fernandez  wrote:

> Hi Daniel.
>
> I had never used  before, but I think it works for weekly
> scans since OSSEC prints this log (even when setting frequency=84800):
>
> 2016/08/01 14:27:33 ossec-syscheckd: INFO: Syscheck scan frequency: 604800
> seconds
>
> This amount of time is one week, so I think that  works only
> for weekly scans, and then you should also introduce the the 
> parameter, since it appears to have no default value. For example:
>
> 1am
> monday
>
> I tested that configuration and Syscheck appears to work properly.
>
> Hope it helps.
>
> Best regards.
>
>
> On Monday, August 1, 2016 at 7:32:13 AM UTC-7, Daniel Bray wrote:
>>
>> Can someone verify that all the proper settings are in place to allow for
>> realtime scans on some directories? We are running CentOS 6 servers
>> (manager and agents/clients), and we use the Atomic install method.
>>
>> Here is the latest available Atomic version installed (also noted inotify
>> is installed)
>> $ rpm -qa | egrep "inotify|ossec"
>> ossec-hids-2.8.3-53.el6.art.x86_64
>> inotify-tools-3.14-1.el6.x86_64
>> ossec-hids-client-2.8.3-53.el6.art.x86_64
>>
>>
>> Here is the important part of /var/ossec/etc/shared/agent.conf
>> 
>>   
>> 1am
>> 82800
>> no
>> yes
>> no
>>
>> 
>> /bin,/sbin,/usr,/opt
>> > report_changes="yes" 
>> realtime="yes">/etc,/root,/var/named,/var/www
>> ...
>>
>> Here is the agent /var/ossec/etc/ossec.conf file
>> 
>>   
>> 10.10.10.10
>>   
>> 
>>
>> The above exists on all our agents/clients.
>>
>> On the manager, it pretty much matches up exactly, with the exception
>> that the server is installed, and not the client:
>> $  rpm -qa | egrep "inotify|ossec"
>> inotify-tools-3.14-1.el6.x86_64
>> ossec-hids-server-2.8.3-53.el6.art.x86_64
>> ossec-hids-2.8.3-53.el6.art.x86_64
>>
>>
>> I have gone in an updated all servers (yum -y update) and rebooted to the
>> latest kernel available on CentOS 6. I've waited a few days for the normal
>> scans to complete, and I am seeing alerts for nightly changed files.
>> However, when I run a test on a file that exists in /root or /etc, I never
>> get alerted. The test is simply
>> $ sudo vim /etc/hosts.allow
>> ...and I add/remove some entries, and :wq out for the update.
>>
>> After a clean update and reboot, here is the relevant log entries:
>> 2016/08/01 14:25:13 ossec-syscheckd: DEBUG: Starting ...
>> 2016/08/01 14:25:13 ossec-rootcheck: DEBUG: Starting ...
>> 2016/08/01 14:25:13 ossec-rootcheck: Starting queue ...
>> 2016/08/01 14:25:13 ossec-syscheckd: INFO: (unix_domain) Maximum send
>> buffer set to: '124928'.
>> 2016/08/01 10:25:14 ossec-agentd(4102): INFO: Connected to the server (
>> 10.10.10.10:1514).
>> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
>> '/var/log/messages'.
>> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
>> '/var/log/secure'.
>> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file:
>> '/var/log/maillog'.
>> 2016/08/01 14:25:19 ossec-logcollector: INFO: Started (pid: 2120).
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: (unix_domain) Maximum send
>> buffer set to: '124928'.
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Started (pid: 2124).
>> 2016/08/01 14:25:19 ossec-rootcheck: INFO: Started (pid: 2124).
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/bin'.
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/sbin'.
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/usr'.
>> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/opt'.
>> 2016/08/01 14:25:19 ossec-syscheckd:

[ossec-list] Syscheck not alerting on realtime scans

[Daniel Bray]

Can someone verify that all the proper settings are in place to allow for 
realtime scans on some directories? We are running CentOS 6 servers 
(manager and agents/clients), and we use the Atomic install method.

Here is the latest available Atomic version installed (also noted inotify 
is installed)
$ rpm -qa | egrep "inotify|ossec"
ossec-hids-2.8.3-53.el6.art.x86_64
inotify-tools-3.14-1.el6.x86_64
ossec-hids-client-2.8.3-53.el6.art.x86_64


Here is the important part of /var/ossec/etc/shared/agent.conf

  
1am
82800
no
yes
no


/bin,/sbin,/usr,/opt
/etc,/root,/var/named,/var/www
...

Here is the agent /var/ossec/etc/ossec.conf file

  
10.10.10.10
  


The above exists on all our agents/clients. 

On the manager, it pretty much matches up exactly, with the exception that 
the server is installed, and not the client:
$  rpm -qa | egrep "inotify|ossec"
inotify-tools-3.14-1.el6.x86_64
ossec-hids-server-2.8.3-53.el6.art.x86_64
ossec-hids-2.8.3-53.el6.art.x86_64


I have gone in an updated all servers (yum -y update) and rebooted to the 
latest kernel available on CentOS 6. I've waited a few days for the normal 
scans to complete, and I am seeing alerts for nightly changed files. 
However, when I run a test on a file that exists in /root or /etc, I never 
get alerted. The test is simply
$ sudo vim /etc/hosts.allow
...and I add/remove some entries, and :wq out for the update.

After a clean update and reboot, here is the relevant log entries:
2016/08/01 14:25:13 ossec-syscheckd: DEBUG: Starting ...
2016/08/01 14:25:13 ossec-rootcheck: DEBUG: Starting ...
2016/08/01 14:25:13 ossec-rootcheck: Starting queue ...
2016/08/01 14:25:13 ossec-syscheckd: INFO: (unix_domain) Maximum send 
buffer set to: '124928'.
2016/08/01 10:25:14 ossec-agentd(4102): INFO: Connected to the server 
(10.10.10.10:1514).
2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
'/var/log/messages'.
2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
'/var/log/secure'.
2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
'/var/log/maillog'.
2016/08/01 14:25:19 ossec-logcollector: INFO: Started (pid: 2120).
2016/08/01 14:25:19 ossec-syscheckd: INFO: (unix_domain) Maximum send 
buffer set to: '124928'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Started (pid: 2124).
2016/08/01 14:25:19 ossec-rootcheck: INFO: Started (pid: 2124).
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/bin'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/sbin'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/usr'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/opt'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/etc'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/root'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: 
'/var/named'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/var/www'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
monitoring: '/etc'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
monitoring: '/root'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
monitoring: '/var/named'.
2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
monitoring: '/var/www'.
2016/08/01 14:25:33 ossec-syscheckd: Setting SCHED_BATCH returned: 0



Is there anything obvious that I'm missing in the configs?


-- 

--- 
You received this message because you are subscribed 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: reportd not sending any email

[Daniel Cid]

Try this patch from here:

https://bitbucket.org/dcid/ossec-hids/commits/eb98bdae15cec6ccf04190d0badbd3b0de6f84b7

As it may fix the problem.

thanks,

On Mon, Apr 18, 2016 at 7:16 PM, theresa mic-snare
 wrote:
> will need to take a proper look at what's causing those segfaults
> tomorrow...
>
>
> Am Dienstag, 19. April 2016 00:11:45 UTC+2 schrieb theresa mic-snare:
>>
>> oh no!!
>> OSSEC segfaulted
>>
>> 2016-04-19T00:01:58.311800+02:
>> 00 tron kernel: ossec-monitord[20021]: segfault at 1a ip 7f68290ab8b5
>> sp 7fff84248bc0 error 4 in libc-2.12.so[7f6829008000+18a000]
>>
>> since this was 1 Minute after midnight I suspect reportd causes this
>>
>> this is what the OSSEC log has to say:
>>
>> 2016/04/19 00:01:53 ossec-monitord: INFO: Starting daily reporting for
>> 'OSSEC: Authentication Report'
>> 2016/04/19 00:01:58 ossec-monitord: INFO: Report 'OSSEC: Authentication
>> Report' completed. Creating output...
>> 2016/04/19 00:02:13 ossec-monitord: INFO: Starting daily reporting for
>> 'Daily report: File changes'
>> 2016/04/19 00:02:18 ossec-monitord: INFO: Report 'Daily report: File
>> changes' completed. Creating output...
>>
>> a few seconds later another segfault
>>
>> 2016-04-19T00:02:18.278790+02:
>> 00 tron kernel: ossec-monitord[20062]: segfault at 1a ip 7f68290ab8b5
>> sp 7fff84248bc0 error 4 in libc-2.12.so[7f6829008000+18a000]
>>
>> Hmm... :(
>>
>> Am Montag, 18. April 2016 17:37:48 UTC+2 schrieb dan (ddpbsd):
>>>
>>> On Mon, Apr 18, 2016 at 11:34 AM, theresa mic-snare
>>>  wrote:
>>> > Awesome, thanks for the tip Dan!
>>> > I will look for it tonight, if it actually works and does send a
>>> > report,
>>> > then I will send a PR with a disclaimer on the documentation page,
>>> > because
>>> > it isn't mentioned there yet.
>>> >
>>>
>>> Much appreciated!
>>>
>>> > I have also looked at the code to see if I could find any indicator
>>> > when the
>>> > email would be sent...but alas, I haven't found anything there either.
>>> >
>>>
>>> My bad memory is telling me monitord is the place to look.
>>>
>>> >
>>> > Am Montag, 18. April 2016 17:24:37 UTC+2 schrieb theresa mic-snare:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I've configured reportd to send reports on syscheck and successful
>>> >> authentication
>>> >>
>>> >> 
>>> >>authentication_success
>>> >>OSSEC: Authentication Report
>>> >>1...@456.com
>>> >>yes
>>> >>   
>>> >>
>>> >>   
>>> >>  syscheck
>>> >>  Daily report: File changes
>>> >>  1...@456.com
>>> >>
>>> >>
>>> >>
>>> >> However, I can run those reports fine in the terminal, but it doesn't
>>> >> send
>>> >> any reports through email.
>>> >>
>>> >> Yes: I have checked that ossec-maild is running it is, I swear!
>>> >> Yes: I have checked the spam/junk folder in my inbox as well I
>>> >> swear!
>>> >>
>>> >> When I run reportd manually it displays the report just fineand
>>> >> even
>>> >> in the logs it says
>>> >>
>>> >> 2016/04/18 17:13:49 ossec-reportd: INFO: Report completed. Creating
>>> >> output...
>>> >>
>>> >> I'd expect it at least to say this after I restart OSSEC as well?
>>> >>
>>> >> When does ossec-reportd run or does it have to be started through a
>>> >> cronjob?
>>> >> Does the mailing of reports work for you?
>>> >>
>>> >> best,
>>> >> theresa
>>> >
>>> > --
>>> >
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "ossec-list" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to ossec-list+...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

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

Re: [ossec-list] Disk usage monitor not working in RHEL5

[Daniel Cid]

Curious how was that not working. Can you give some details?

By default, it will send each line as a separated log message and we
have rules to alert if any of the entries
are over 95% utilization. Have the original running here on Centos 5,6
and 7 without any issues.

thanks,



On Fri, Apr 15, 2016 at 6:15 AM, Robert Micallef  wrote:
> For anyone who encounters this issue where disk usage alerts are not working
> on Redhat 5, the issue is that in RHEL5 'df -h' output is multiline.
>
> You can easily fix it by modifying the ossec agent conf. Modify the 'df -h'
> to 'df -Pkh' and add an alias.
>
>   
> command
> df -Pkh
> df -h
>   
>
> --
>
> ---
> You received this message because you are subscribed 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] Disable Email Alerts from a particular source ip

[Daniel Cid]

That's correct as long as the srcip is being decoded. You may need two
rules just in case:


7
1.2.3.0/24
Ignoring rule any level above 7 from Whitelisted IPs



7
 1.2.3.\d+ 
Ignoring rule any level above 7 from Whitelisted IPs


The second one is a bit dangerous as it may open you up to log
injections, but you can use that as a start or tie it down to only
some logs formats.

thanks,

On Tue, Mar 1, 2016 at 10:00 AM, calvin ratti  wrote:
> Hi,
>
> I have a VA scanner which I have added in the Whitelist to prevent Active
> Response from blocking the scans. What I also understand from here is that
> to prevent email alerts, I should create a custom rule. Is the following
> syntax proper or am i missing something:
>
> 
> 7
> 1.2.3.4/24
> Ignoring rule any level above 7 from Whitelisted
> IPs
> 
>
> rule id is unique, we have configured to send email alerts only for level 7
> & above.
>
> -Cal
>
> --
>
> ---
> You received this message because you are subscribed 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: DNS caching for ?

[Daniel Cid]

This is this the kind of thing that is likely better (easily)
implemented outside of the main
ossec managers. Maybe an external tool or cron.

I use the following shell script for example (added to cron to run
every 10min to restart ossec in case the IP changes):


#!/bin/sh
mydomain=`cat /var/ossec/etc/ossec.conf |grep "server-hostname>" | cut
-d ">" -f 2 | cut -d "<" -f 1`
myip=`host $mydomain |grep "has address" | head -n 1 | cut -d " " -f 4`

if [ "x$myip" = "x" ]; then
echo "$0: DNS lookup failed."
exit 1;
fi

ls /tmp/oldossecip >/dev/null 2>&1
if [ ! $? = 0 ]; then
echo $myip > /tmp/oldossecip
/var/ossec/bin/ossec-control restart
exit 0;
fi

oldip=`cat /tmp/oldossecip`

if [ ! "x$oldip" = "x$myip" ]; then
echo $myip > /tmp/oldossecip
/var/ossec/bin/ossec-control restart
exit 0;
fi

exit 0;


Try it out and see if it works for you.



On Fri, Feb 26, 2016 at 10:32 PM, Barry Kaplan  wrote:
> Another question: My original scenario was when there was NO dns yet to
> resolve -- only later did the dns record get added. In that case. What I was
> seeing in that case was the agent would keep issue the error that it could
> not connect. But if the agent was not even able to resolve to an ip why
> would it bother to keep trying to connect?
>
> --
>
> ---
> You received this message because you are subscribed 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] What is the use case for OSSEC hybrid mode

[Daniel Cid]

I personally use it mostly on very busy servers to limit the amount of
events being sent by the agent
to the manager.

Say a very busy web server that generates thousands of logs per second.
Instead of sending all events centrally, I use the hybrid mode to do the
initial analysis locally and only send the real alerts centrally (which is
just a few per minute).

thanks,

On Thu, Feb 25, 2016 at 1:33 PM, Manoveg Saxena  wrote:

> Hi,
>
> I am not able to understand when should I use hybrid mode.
>
> I have one server and 4 agents.
> My server also have many applications and a web server which I want to
> monitor along with that web servers and other applications on agents.
> Therefore should I go for
> 1)  hybrid on server and agent on other servers
> 2)  or server and agent setup
>
> Thanks,
> Manoveg
>
> --
>
> ---
> You received this message because you are subscribed 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: Hybrid or dual install?

[Daniel Cid]

Yes, I use the hybrid mode quite a bit too. It basically automates the
process of installing the local + agent without having to do both
separately.

thanks,

On Thu, Feb 18, 2016 at 2:10 PM, Kat  wrote:

> I use Hybrid modes for 1000s of agents and mixed managers. It allows me to
> distribute managers, and still  have centralized collection. If I lose the
> WAN, the hybrids continue to process alerts,  and once the WANs are
> restored the data resumes to the central host. They have proven to be
> extremely reliable and I have had no issues. I do run with as high as
> 20,000 agents in some cases with no issues.
>
> Cheers
> Kat
>
>
> On Thursday, February 18, 2016 at 7:36:10 AM UTC-8, James Dough wrote:
>>
>> Looking at the hybrid install type; it installs two versions of ossec,
>> that have been reduced. One server role and one agent role.
>>
>> Is the hybrid as reliable? I don't see nearly as much documentation on
>> it. Is it a safer bet to go with dual install?
>>
>> --
>
> ---
> You received this message because you are subscribed 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] strange in 'full_command' output

[Daniel Cid]

Our major limitation is the size of the UDP packet when sending from the
agent->manager. We can't reliably split the message into multiple
datagrams, so we restrict by size, forcing it to always fit into 1 packet.
Moving to TCP would
solve this limitation (this is something I am trying to work right now  -->
move to TCP+OpenSSL for the agent->manager communication).

thanks,

On Tue, Feb 2, 2016 at 4:24 PM, Santiago Bassett  wrote:

> There are several email threads in this list reporting similar issues. I
> recommend you to keep an eye on those as well. Haven't had much time to
> look into it, but it seems there are serveral places where the message can
> be cut off. In src/headers/defs.h you will find some constants that are use
> to limit those sizes.
>
> This one seems interesting.
>
> src/headers/defs.h:#*define* OS_MAXSTR   OS_SIZE_6144/* Size for
> logs, sockets, etc  */
>
> On Tue, Feb 2, 2016 at 12:21 PM, q 
> wrote:
>
>>
>> Santiago,thank you for idea!
>>
>> ;)
>>
>>
>>
>>
>>
>> On 02.02.2016 20:30, Santiago Bassett wrote:
>>
>> I think this is due to a limitation on the alert message size. I guess,
>> you will need to look in the code and recompile if you want this to work.
>>
>> On Thu, Jan 28, 2016 at 3:12 PM, q > > wrote:
>>
>>>
>>> list,sorry for typo
>>>
>>> the first example is not "from ossec-alerts.log" but "from ossec.log"
>>>
>>> cheers.
>>>
>>>
>>> On 29.01.2016 01:49, q wrote:
>>> > Hello list!
>>> >
>>> > OSSEC can "cut" some data from 'full_command' output.
>>> >
>>> >
>>> >
>>> > this is from ossec-alerts.log
>>> >
>>> > ossec: output: 'tcp_netstat':
>>> > Active Internet connections (only servers)
>>> > Proto Recv-Q Send-Q Local Address   Foreign
>>> > Address State   PID/Program name
>>> > tcp0  0 0.0.0.0:22
>>> > 0.0.0.0:*   LISTEN  2743/sshd
>>> > tcp0  0 0.0.0.0:443
>>> > 0.0.0.0:*   LISTEN  4865/nginx
>>> > tcp0  0 0.0.0.0:587
>>> > 0.0.0.0:*   LISTEN  2623/rsyslogd
>>> > tcp0  0 0.0.0.0:80
>>> > 0.0.0.0:*   LISTEN  12159/ossec-authd
>>> > tcp0  0 ::1:25
>>> > :::*LISTEN  2996/master
>>> > tcp0  0 127.0.0.1:25
>>> > 0.0.0.0:*  LISTEN  2996/master
>>> > tcp0  0 127.0.0.1:27017
>>> > 0.0.0.0:*   LISTEN  5132/mongod
>>> > tcp0  0 127.0.0.1:3306
>>> > 0.0.0.0:*LISTEN  2885/mysqld
>>> > tcp0  0 127.0.0.1:
>>> > 0.0.0.0:*LISTEN  8089/uwsgi
>>> > tcp0  0 :::587
>>> > :::*LISTEN  2623/r
>>> >
>>> >
>>> >
>>> > and this is from ossec-alerts.log
>>> >
>>> > Active Internet connections (only servers)
>>> > Proto Recv-Q Send-Q Local Address   Foreign
>>> > Address State   PID/Program name
>>> > tcp0  0 0.0.0.0:22
>>> > 0.0.0.0:*   LISTEN  2743/sshd
>>> > tcp0  0 0.0.0.0:443
>>> > 0.0.0.0:*   LISTEN  4865/nginx
>>> > tcp0  0 0.0.0.0:587
>>> > 0.0.0.0:*   LISTEN  2623/rsyslogd
>>> > tcp0  0 ::1:25
>>> > :::*LISTEN  2996/master
>>> > tcp0  0 127.0.0.1:25
>>> > 0.0.0.0:*   LISTEN  2996/master
>>> > tcp0  0 127.0.0.1:27017
>>> > 0.0.0.0:*   LISTEN  5132/mongod
>>> > tcp0  0 127.0.0.1:3306
>>> > 0.0.0.0:*   LISTEN  2885/mysqld
>>> > tcp0  0 127.0.0.1:
>>> > 0.0.0.0:*   LISTEN  8089/uwsgi
>>> > tcp0  0 :::587
>>> > :::*LISTEN  2623/rsyslogd
>>> >
>>> >
>>> >
>>> > Last string from /var/ossec/logs/ossec.log
>>> > tcp0  0 :::587
>>> > :::*LISTEN  2623/rsyslogd
>>> >
>>> >
>>> > and last string from /var/ossec/logs/alerts/ossec-alerts
>>> > tcp0  0 :::587
>>> > :::*LISTEN  2623/r
>>> >
>>> >
>>> >
>>> > Also,check_diff dont works properly due this issue.
>>> > I think it's bug.
>>> >
>>> >
>>> >
>>> > My ossec is 2.8 (rpm from Atomic repo)
>>> >
>>> > part of my config:
>>> >
>>> > 
>>> > tcp_netstat
>>> > full_command
>>> > netstat -tpln |sort
>>> > 
>>> >
>>> >
>>> >
>>> > Thank you!
>>> >
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ossec-list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ossec-list+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ossec-list" group.
>> To unsubscribe from thi

Re: [ossec-list] syscheck not working with restrict option

[Daniel Cid]

Awesome :)

On Fri, Jan 29, 2016 at 3:06 PM, Luke Hansey 
wrote:

> Works great now.  Thank you for the work on this.  No worries about the
> time.  It's developmental :)  Plus, I have a little firmer grasp on OSSEC
> now.
>
> On Thursday, January 28, 2016 at 4:58:11 PM UTC-8, Daniel Cid wrote:
>>
>> The issue was in my branch there. Mind getting the latest again? Should
>> be working now:
>>
>> https://bitbucket.org/dcid/ossec-hids/get/tip.tar.gz
>>
>> Sorry for the waste of time :/
>>
>> thanks,
>>
>> On Thu, Jan 28, 2016 at 1:34 PM, Luke Hansey 
>> wrote:
>>
>>> Thanks for the reply, Santiago.
>>>
>>> Here is what I am seeing.  On agent:
>>>
>>> 2016/01/28 11:42:06 ossec-syscheckd: INFO: Monitoring directory:
>>> '/var/www/vhosts/'.
>>> 2016/01/28 11:42:06 ossec-syscheckd: INFO: Directory set for real time
>>> monitoring: '/var/www/vhosts/'.
>>> 2016/01/28 11:43:08 ossec-syscheckd: INFO: Starting syscheck scan
>>> (forwarding database).
>>> 2016/01/28 11:43:08 ossec-syscheckd: INFO: Starting syscheck database
>>> (pre-scan).
>>> 2016/01/28 11:48:59 ossec-syscheckd: INFO: Initializing real time file
>>> monitoring (not started).
>>> 2016/01/28 11:49:00 ossec-syscheckd: INFO: Finished creating syscheck
>>> database (pre-scan completed).
>>> 2016/01/28 11:49:12 ossec-syscheckd: INFO: Ending syscheck scan
>>> (forwarding database).
>>> 2016/01/28 11:49:32 ossec-syscheckd: INFO: Starting real time file
>>> monitoring.
>>> 2016/01/28 11:49:32 ossec-rootcheck: INFO: Starting rootcheck scan.
>>> 2016/01/28 11:55:02 ossec-rootcheck: INFO: Ending rootcheck scan.
>>>
>>> On my server I'm watching this agent's syscheck queue:
>>>
>>> Every 1.0s: cat '(blah.blah.com) 10.0.1.2->syscheck' | grep '.php$'
>>>
>>> +++3232368:33261:0:0:41591364ec9f9f74e6180f91ede53f24:f3f7f713f0b6fffcb582cce39ad2b433c2f12ef0
>>> !1454017663 /usr/bin/php
>>>
>>> I've created a test.php file in /var/www/vhosts/
>>> test.com/httpdocs/test.php as well as edited an existing PHP file in
>>> the same directory.
>>>
>>> Nothing changes, so I run from server:
>>>
>>> /var/ossec/bin/agent_control -r -u 001
>>>
>>> OSSEC HIDS agent_control: Restarting Syscheck/Rootcheck on agent: 001
>>>
>>> Still the queue/syscheck file for this agent does not change.  File size
>>> is the same as well.  Before this process I also ran:
>>>
>>> /var/ossec/bin/syscheck_control -u 001 and it emptied the file.  But
>>> once syscheck ran again, it was exactly the same size as it was before
>>> (334K), which seems small.
>>>
>>> I'm running v2015-12 latest dev that Dan pushed a few days ago.  I feel
>>> like I'm missing something obvious...
>>>
>>> On Wednesday, January 27, 2016 at 2:54:09 PM UTC-8, Santiago Bassett
>>> wrote:
>>>>
>>>> Are you sure your config is not working?
>>>>
>>>> I just tested this and it works for me:
>>>>
>>>> >>> restrict=".txt1|.txt2">/root
>>>>
>>>> I created three test files:
>>>>
>>>> root@vpc-ossec-manager:~# ls test.txt*
>>>>
>>>> test.txt1  test.txt2  test.txt3
>>>>
>>>> And this is what I get in my syscheck file:
>>>>
>>>> root@vpc-ossec-manager:~# cat /var/ossec/queue/syscheck/syscheck |
>>>> grep test.txt
>>>>
>>>> +++3:33188:0:0:764efa883dda1e11db47671c4a3bbd9e:55ca6286e3e4f4fba5d0448333fa99fc5a404a73
>>>> !1453933436 /root/test.txt1
>>>>
>>>> +++5:33188:0:0:d8e8fca2dc0f896fd7cb4cb0031ba249:4e1243bd22c66e76c2ba9eddc1f91394e57f9f83
>>>> !1453933436 /root/test.txt2
>>>>
>>>> There is nothing for test.txt3
>>>>
>>>> I am using 2.9 version (development branch)
>>>>
>>>> Best
>>>>
>>>> On Tue, Jan 26, 2016 at 4:34 PM, Luke Hansey >>> > wrote:
>>>>
>>>>> If I use:
>>>>>
>>>>> >>>> restrict=".php|.js">/var/www/vhosts/
>>>>>
>>>>> syscheck logs no changes to any file.
>>>>>
>>>>> If I use:
>>>>>
>>>>> /var/www/vhosts/
>>>>>
>>

Re: [ossec-list] Re: Global Mail limit

[Daniel Cid]

I added this limit early on to prevent a flood of emails in case of a
config mistake or an attack.

Plus, operationally speaking, I doubt any team can realistically handle and
investigate more than 10,000+ emails in an hour :)

thanks,





On Fri, Jan 29, 2016 at 1:16 PM, Eero Volotinen 
wrote:

> Well, why there is such low limit without #define INT_MAX_VALUE YY
>
> Is should be like (Mail->maxperhour > INT_MAX_VALUE) ?
>
>
>
>
> --
> Eero
>
> 2016-01-28 16:22 GMT+02:00 :
>
>> Hi,
>>
>> I found that limit and it's hardcoded at function Read_Global(), in
>> src/config/global-config.c
>>
>> if ((Mail->maxperhour <= 0) || (Mail->maxperhour > )) {
>> merror(XML_VALUEERR, __local_name, node[i]->element, node[i]->content);
>> return (OS_INVALID);
>> }
>>
>> You may increase this limit as you need it and recompile your OSSEC
>> manager, but there's no way to use a greater number of emails by modifying
>> a config file.
>>
>> I hope this will help you.
>>
>> Best regards.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ossec-list+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] syscheck not working with restrict option

[Daniel Cid]

The issue was in my branch there. Mind getting the latest again? Should be
working now:

https://bitbucket.org/dcid/ossec-hids/get/tip.tar.gz

Sorry for the waste of time :/

thanks,

On Thu, Jan 28, 2016 at 1:34 PM, Luke Hansey 
wrote:

> Thanks for the reply, Santiago.
>
> Here is what I am seeing.  On agent:
>
> 2016/01/28 11:42:06 ossec-syscheckd: INFO: Monitoring directory:
> '/var/www/vhosts/'.
> 2016/01/28 11:42:06 ossec-syscheckd: INFO: Directory set for real time
> monitoring: '/var/www/vhosts/'.
> 2016/01/28 11:43:08 ossec-syscheckd: INFO: Starting syscheck scan
> (forwarding database).
> 2016/01/28 11:43:08 ossec-syscheckd: INFO: Starting syscheck database
> (pre-scan).
> 2016/01/28 11:48:59 ossec-syscheckd: INFO: Initializing real time file
> monitoring (not started).
> 2016/01/28 11:49:00 ossec-syscheckd: INFO: Finished creating syscheck
> database (pre-scan completed).
> 2016/01/28 11:49:12 ossec-syscheckd: INFO: Ending syscheck scan
> (forwarding database).
> 2016/01/28 11:49:32 ossec-syscheckd: INFO: Starting real time file
> monitoring.
> 2016/01/28 11:49:32 ossec-rootcheck: INFO: Starting rootcheck scan.
> 2016/01/28 11:55:02 ossec-rootcheck: INFO: Ending rootcheck scan.
>
> On my server I'm watching this agent's syscheck queue:
>
> Every 1.0s: cat '(blah.blah.com) 10.0.1.2->syscheck' | grep '.php$'
>
> +++3232368:33261:0:0:41591364ec9f9f74e6180f91ede53f24:f3f7f713f0b6fffcb582cce39ad2b433c2f12ef0
> !1454017663 /usr/bin/php
>
> I've created a test.php file in /var/www/vhosts/test.com/httpdocs/test.php
> as well as edited an existing PHP file in the same directory.
>
> Nothing changes, so I run from server:
>
> /var/ossec/bin/agent_control -r -u 001
>
> OSSEC HIDS agent_control: Restarting Syscheck/Rootcheck on agent: 001
>
> Still the queue/syscheck file for this agent does not change.  File size
> is the same as well.  Before this process I also ran:
>
> /var/ossec/bin/syscheck_control -u 001 and it emptied the file.  But once
> syscheck ran again, it was exactly the same size as it was before (334K),
> which seems small.
>
> I'm running v2015-12 latest dev that Dan pushed a few days ago.  I feel
> like I'm missing something obvious...
>
> On Wednesday, January 27, 2016 at 2:54:09 PM UTC-8, Santiago Bassett wrote:
>>
>> Are you sure your config is not working?
>>
>> I just tested this and it works for me:
>>
>> > restrict=".txt1|.txt2">/root
>>
>> I created three test files:
>>
>> root@vpc-ossec-manager:~# ls test.txt*
>>
>> test.txt1  test.txt2  test.txt3
>>
>> And this is what I get in my syscheck file:
>>
>> root@vpc-ossec-manager:~# cat /var/ossec/queue/syscheck/syscheck | grep
>> test.txt
>>
>> +++3:33188:0:0:764efa883dda1e11db47671c4a3bbd9e:55ca6286e3e4f4fba5d0448333fa99fc5a404a73
>> !1453933436 /root/test.txt1
>>
>> +++5:33188:0:0:d8e8fca2dc0f896fd7cb4cb0031ba249:4e1243bd22c66e76c2ba9eddc1f91394e57f9f83
>> !1453933436 /root/test.txt2
>>
>> There is nothing for test.txt3
>>
>> I am using 2.9 version (development branch)
>>
>> Best
>>
>> On Tue, Jan 26, 2016 at 4:34 PM, Luke Hansey 
>> wrote:
>>
>>> If I use:
>>>
>>> >> restrict=".php|.js">/var/www/vhosts/
>>>
>>> syscheck logs no changes to any file.
>>>
>>> If I use:
>>>
>>> /var/www/vhosts/
>>>
>>> Works fine and logs changes to any file.
>>>
>>> Am I missing something when using the *restrict *option?
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ossec-list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ossec-list+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] Testing integratord

[Daniel Cid]

Mind sending the last 20-30 lines of your ossec.log? It can give us an idea
to what is going on.

thanks,

On Thu, Jan 28, 2016 at 1:42 PM, Marcelo  wrote:

> Dear Daniel,
>
> I did the installation of integrator, but I do not understand why my
> server had lost the connection with my agents. To service back works, I
> need restart the ossec. Can you help me?
>
> I have downloaded this: dcid-ossec-hids-d29f2859d5c6.tar.gz
> PS: Apologize me for my poor english, my Portuguese is better
>
> Em 27-01-2016 16:57, Daniel Cid escreveu:
> > I have been working on the integrator daemon (ossec-integratord) to
> > allow OSSEC
> > to easily integrate with external APIs to send alerts & notifications.
> >
> > I have pushed it to my personal fork and I am looking for testers, and
> > people interested to try it out to help flush out any bugs/issues.
> >
> > So far, we added support for Slack & PagerDuty.
> >
> > Latest code for it here:
> >
> https://bitbucket.org/dcid/ossec-hids/src/3ed5ef68d33be4c36edba32e3893d30f7bbbc4e9/src/os_integrator/?at=default
> >
> > And setup instructions:
> >
> https://blog.sucuri.net/2016/01/server-security-integrating-ossec-with-slack-and-pagerduty.html
> >
> > *you should be able to safely upgrade directly to:
> > https://bitbucket.org/dcid/ossec-hids/get/tip.tar.gz if that makes it
> > easier.
> >
> >
> > Also, if you have suggestions for more integrations, let me know.
> >
> > 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
> > <mailto:ossec-list+unsubscr...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

[ossec-list] Testing integratord

[Daniel Cid]

I have been working on the integrator daemon (ossec-integratord) to allow
OSSEC
to easily integrate with external APIs to send alerts & notifications.

I have pushed it to my personal fork and I am looking for testers, and
people interested to try it out to help flush out any bugs/issues.

So far, we added support for Slack & PagerDuty.

Latest code for it here:
https://bitbucket.org/dcid/ossec-hids/src/3ed5ef68d33be4c36edba32e3893d30f7bbbc4e9/src/os_integrator/?at=default

And setup instructions:
https://blog.sucuri.net/2016/01/server-security-integrating-ossec-with-slack-and-pagerduty.html

*you should be able to safely upgrade directly to:
https://bitbucket.org/dcid/ossec-hids/get/tip.tar.gz if that makes it
easier.


Also, if you have suggestions for more integrations, let me know.

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: Integrity checksum size changed to 0 or from 0 - false positive

[Daniel Cid]

Yes, that would be an issue. Have you tried not sending the output to a 
file and using the check_diff option on the rules itself?

You could do:

  
full_command
iptables -S
iptables_status
3600
  

And then write a rule to alert on changes:

  
530
ossec: output: 'iptables_status

Iptables changed
  

See if that works.

thanks,


On Monday, January 25, 2016 at 8:51:31 AM UTC-4, ZaNN wrote:
>
> Hi all,
>
> I have configured a checksum alert in real time that triggers and e-mail 
> alert each time a file is being modified. This file is an output of an 
> iptables command executed in all agents every hour:
>
>   
> full_command
> iptables -S  > 
> /var/ossec/active-response/iptables_diff.txt
> iptables_status
> 3600
>   
>
> The problem is that lot of times false positives are received due to size 
> changed *to 0 or from 0*. Not every hour definitely. 
>
> Integrity checksum changed for: 
> '/var/ossec/active-response/iptables_diff.txt'*Size changed from '1089' to 
> '0'*
> What changed:
> 1,20d0
> < -P INPUT DROP
> < -P FORWARD DROP
> < -P OUTPUT ACCEPT
> < -N LOGGING
> < -N OUTPUT-NOLOG
> < -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
> < -A INPUT -p icmp -j ACCEPT 
> < -A INPUT -i lo -j ACCEPT 
> < -A INPUT -s 10.0.0.0/8 -p tcp -m state --state NEW -m tcp --dport 22 -j 
> ACCEPT 
> < -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
> < -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT 
> < -A OUTPUT -d 8.8.8.8/32 -p udp -m udp --dport 53 -m state --state NEW -j 
> OUTPUT-NOLOG 
> < -A OUTPUT -d 8.8.4.4/32 -p udp -m udp --dport 53 -m state --state NEW -j 
> OUTPUT-NOLOG 
> < -A OUTPUT -p udp -m udp --dport 123 -m state --state NEW -j OUTPUT-NOLOG 
> < -A OUTPUT -d 192.168.116.0/24 -p udp -m udp --dport 1514 -m state --state 
> NEW -j OUTPUT-NOLOG 
> < -A OUTPUT -d 192.168.116.0/24 -p udp -m udp --dport 514 -m state --state 
> NEW -j OUTPUT-NOLOG 
> Old md5sum was: '0b43600d67c9fdde33912771c81927e2'
> New md5sum is : 'd41d8cd98f00b204e9800998ecf8427e'
> Old sha1sum was: 'e991b6897be54bfc0fd2ef0410fd5e50d54317b6'
> New sha1sum is : 'da39a3ee5e6b4b0d3255bfef95601890afd80709'
>
>
> Integrity checksum changed for: 
> '/var/ossec/active-response/iptables_diff.txt'*Size changed from '0' to 
> '1089'*
> What changed:
> 0a1,20
>
> -P INPUT DROP
> -P FORWARD DROP
> -P OUTPUT ACCEPT
> -N LOGGING
> -N OUTPUT-NOLOG
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
> -A INPUT -p icmp -j ACCEPT 
> -A INPUT -i lo -j ACCEPT 
>
>
>
>  
>
>
> I suspect that this behaviour is related to real time (inotify) and rewrite 
> the file each time the command is executed ( > ). Is there any best practice 
> to avoid this false 
> positives? maybe a delay in real time check? 
>
> Thanks in advance
>
>
>

-- 

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

Re: [ossec-list] Re: OSSEC - Windows Event Log - PowerShell Alerts

[Daniel]

So basically what you're doing is looking for INFO logs and then matching 
the log content and not the actual log ID? Interesting. My general rule 
workflow is this: 
If OS=WINDOWS, then if TYPE=ERROR/INFO/WARN/etc, then if EVENTID=x, then 
create alert with LEVEL=y.

Types can be referenced in /rules/msauth_rules.xml, with 18101 
being informational. Also, check out 
"http://www.ossec.net/ossec-docs/OSSEC-book-ch4.pdf";

My basic powershell rule looks like the following:


  
18101
^400$|^403$
PowerShell
PowerShell Started/Stopped.
From "Windows PowerShell.evtx"
  



On Wednesday, December 2, 2015 at 4:02:25 PM UTC-5, Phillipa Moorea wrote:
>
> Thanks for all the help from you (Santiago), from dan, some other posts on 
> here, github repository issues, a book I bought on ossec for $10, and the 
> work of the OSSEC developers that made the 2.8.3 update, and of course the 
> people in the AlienVault Labs!
>
> I was now able to get the alerts working.  I analyzed the PowerShell logs 
> and changed my rules a bit.  Here is what I changed it too:
>
> 
>   
> 18100,18101
> CommandType=Script
> Powershell Script.
>   
>   
> 18100,18101
> CommandType=Cmdlet
> Powershell Command.
>   
>   
> 18100,18101
> CommandType=Function
> Powershell Function.
> 
>   
> 100210
> NewCommandState=Started
> Powershell Script (500-Started).
>   
>   
> 100210
> NewCommandState=Stopped
> Powershell Script (501-Stopped).
> 
>   
> 100211
> NewCommandState=Started
> Powershell Command (500-Started).
>   
>   
> 100211
> NewCommandState=Stopped
> Powershell Command (501-Stopped).
> 
>   
> 100212
> NewCommandState=Started
> Powershell Function (500-Started).
>   
> ...

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Tuesday, December 1, 2015 at 9:38:30 AM UTC-5, Daniel Bray wrote:
>
> On Mon, Nov 30, 2015 at 5:28 PM, Ryan Schulze  wrote:
>
>>
>> Is this the only rule in your local_rules.xml that isn't working, or are 
>> all rules in your local_rules.xml not working?
>>
>>
> So far, this is the only rule that I just can't seem to stop emailing. I 
> have other rules, and when I check them against ossec-logtest, they come 
> back as "Level: 0", which I've correctly configured. I wait, and no email 
> alerts come in, which is the expected behavior. In fact, I have about 12 
> rules filtering out various known issues. It's just this one that will not 
> stop emailing, and wouldn't you know it, it is rather a common "alert" that 
> comes in a few hundred times a day. 
>
>

Spoke too soon. I've found another rule that is not working (new rule, just 
enabled today):
  
10.10.10.10
decrypt: mac verify failed for connection|decrypt: replay check 
failed
Ignore mac verify and replay check alerts
  

Here is the test log entry:

Dec  1 17:09:28 10.10.10.10 46508: *Dec  1 17:12:31.321: 
%CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection 
id=4705 spi=F1D214CD seqno=F1D214CD

ossec-logtest shows:
**Phase 1: Completed pre-decoding.
   full event: 'Dec  1 17:09:28 10.10.10.10 46508: *Dec  1 
17:12:31.321: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for 
connection id=4705 spi=F1D214CD seqno=F1D214CD'
   hostname: '10.10.10.10'
   program_name: '46508'
   log: '*Dec  1 17:12:31.321: %CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: 
mac verify failed for connection id=4705 spi=F1D214CD seqno=F1D214CD'

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

**Phase 3: Completed filtering (rules).
   Rule id: '100013'
   Level: '0'
   Description: 'Ignore mac verify and replay check alerts'


However, the emails are still getting generated with:

Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."

Portion of the log(s):

 

Dec  1 17:09:28 10.10.10.10 46508: *Dec  1 17:12:31.321: 
%CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection 
id=4705 spi=F1D214CD seqno=F1D214CD
 

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Mon, Nov 30, 2015 at 5:28 PM, Ryan Schulze  wrote:

>
> Is this the only rule in your local_rules.xml that isn't working, or are
> all rules in your local_rules.xml not working?
>
>
So far, this is the only rule that I just can't seem to stop emailing. I
have other rules, and when I check them against ossec-logtest, they come
back as "Level: 0", which I've correctly configured. I wait, and no email
alerts come in, which is the expected behavior. In fact, I have about 12
rules filtering out various known issues. It's just this one that will not
stop emailing, and wouldn't you know it, it is rather a common "alert" that
comes in a few hundred times a day.

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Mon, Nov 30, 2015 at 11:26 AM, dan (ddp)  wrote:
>
>
> Last idea at the moment:
> Copy archives.log. Open the copy in a text editor. Find an entry you
> want to test against and delete everything else.
> Delete the archives.log header from your chosen entry.
> Run that through ossec-logtest:
> `cat copy-of-archives.log | /var/ossec/bin/ossec-logtest`
>
> See if it still gets reported as a 0. Maybe there's some odd spacing
> issue that isn't maintained when copy/pasting it.
>
>
Still gets reported as 0, but email is Level 2.

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 27, 2015 at 8:16:39 AM UTC-5, dan (ddpbsd) wrote:
>
> And strangely enough, this works just fine for me (ignored when fed 
> through logger). 
>
> Can you update to the latest OSSEC source from github and try that? 
>

Updated to latest github update, and issue remains. Logtest shows Level 0, 
alerts come to email as level 2.


Side note: Kudos to the developers, the upgrade was VERY easy over top the 
existing RPM install:
git clone https://github.com/ossec/ossec-hids.git
cd ossec-hids
./install
 - You already have OSSEC installed. Do you want to update it? (y/n): y
 - Do you want to update the rules? (y/n): y
done! Nice and quick.

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

I've pretty much already done that, and have had the same results. I've 
tried it with 1002 and without, I've tried it with  
or with . Each time, logtest catches it as a "will not alert", but 
the emails still continue to come in.



On Wednesday, November 25, 2015 at 3:00:57 PM UTC-5, LostInThe Tubez wrote:
>
> Let's keep things simple for the purposes of troubleshooting. Verify a 
> basic rule works, then you can get as complex as you like. Try using this: 
>
>  
> 1002 
> Update peer failed with code 22 
> testing  
>  
>
>  Also, copy/paste the exact alert message when/if you get one. Be very 
> careful not to replace white space if you are sanitizing the data. It will 
> allow us to corroborate what you are seeing. 
>
>
> From: ossec...@googlegroups.com  [mailto:
> ossec...@googlegroups.com ] On Behalf Of Daniel Bray 
> Sent: Wednesday, November 25, 2015 12:20 PM 
> To: ossec-list > 
> Subject: Re: [ossec-list] ossec-logtest returns Level 0 but still getting 
> email alerts Level 2 
>
> On Wednesday, November 25, 2015 at 1:46:15 PM UTC-5, LostInThe Tubez 
> wrote: 
> On the OSSEC server, open /var/ossec/rules/syslog_rules.xml. Search for 
> rule 1002, right there towards the top. Note the options element, which 
> contains alert_by_email. That option tells OSSEC to ignore your 
> email_alert_level and just send an email every time this rule matches.  As 
> you have seen, rule 1002 is a catch-all heuristics rule that attempts to 
> identify problems in logs based on certain keywords. 
>
>
> Thank you, that explains why level 2 alerts are generating the emails for 
> the "BAD_WORDS". I was under the impression that the default level of 7 was 
> for all types of rules, but that is clear now. 
>
> I'm now left with the feeling of that is the main cause of these alerts 
> coming in, even though I have the filters in local_rules.xml, level 2 
> alerts are still coming in. Even when logtest shows that it should stop. 
> Here is another simple example of a local_rule working for logtest, but 
> still generating email alerts . 
>
> /var/ossec/rules/local_rules.xml 
>
> accelerator 
> Update peer failed with code 22 
> Ignore Expand Warnings 
>
>
> /var/ossec/bin/ossec-logtest 
> 2015/11/25 19:15:23 ossec-testrule: INFO: Reading local decoder file. 
> 2015/11/25 19:15:24 ossec-testrule: INFO: Started (pid: 6713). 
> ossec-testrule: Type one log per line. 
>
> Nov 25 19:11:45 x.x.x.x accelerator[4124]: Update peer failed with 
> code 22. 
>
>
> **Phase 1: Completed pre-decoding. 
>full event: 'Nov 25 19:11:45 x.x.x.x accelerator[4124]: Update 
> peer failed with code 22.' 
>hostname: 'x.x.x.x' 
>program_name: 'accelerator' 
>log: 'Update peer failed with code 22.' 
>
> **Phase 2: Completed decoding. 
>No decoder matched. 
>
> **Phase 3: Completed filtering (rules). 
>Rule id: '100010' 
>Level: '0' 
>Description: 'Ignore Expand Warnings' 
>
>
> So, even though logtest shows it will be a Level: '0', I still get an 
> email alert as: 
> Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." 
>
> -- 
>
> --- 
> You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Wednesday, November 25, 2015 at 1:46:15 PM UTC-5, LostInThe Tubez wrote:
>
> On the OSSEC server, open /var/ossec/rules/syslog_rules.xml. Search for 
> rule 1002, right there towards the top. Note the options element, which 
> contains alert_by_email. That option tells OSSEC to ignore your 
> email_alert_level and just send an email every time this rule matches.  As 
> you have seen, rule 1002 is a catch-all heuristics rule that attempts to 
> identify problems in logs based on certain keywords. 
>
>
>
Thank you, that explains why level 2 alerts are generating the emails for 
the "BAD_WORDS". I was under the impression that the default level of 7 was 
for all types of rules, but that is clear now.

I'm now left with the feeling of that is the main cause of these alerts 
coming in, even though I have the filters in local_rules.xml, level 2 
alerts are still coming in. Even when logtest shows that it should stop. 
Here is another simple example of a local_rule working for logtest, but 
still generating email alerts .

/var/ossec/rules/local_rules.xml
  
accelerator
Update peer failed with code 22
Ignore Expand Warnings
  

/var/ossec/bin/ossec-logtest
2015/11/25 19:15:23 ossec-testrule: INFO: Reading local decoder file.
2015/11/25 19:15:24 ossec-testrule: INFO: Started (pid: 6713).
ossec-testrule: Type one log per line.

Nov 25 19:11:45 x.x.x.x accelerator[4124]: Update peer failed with code 
22.


**Phase 1: Completed pre-decoding.
   full event: 'Nov 25 19:11:45 x.x.x.x accelerator[4124]: Update 
peer failed with code 22.'
   hostname: 'x.x.x.x'
   program_name: 'accelerator'
   log: 'Update peer failed with code 22.'

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

**Phase 3: Completed filtering (rules).
   Rule id: '100010'
   Level: '0'
   Description: 'Ignore Expand Warnings'


So, even though logtest shows it will be a Level: '0', I still get an email 
alert as:

Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

Thank you Pedro. I've actually taken a step back from this, and I'm trying
to figure out why the emails are getting sent in the first place. If the
default level is 7, and I haven't changed that:

  
yes
myem...@mydomain.com
my.smtp.server
os...@mydomain.com
127.0.0.1
yes
  

  
1
7
  


then I do not understand why level 2 emails are coming in:

Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."





On Mon, Nov 23, 2015 at 12:24 PM, Pedro S.  wrote:

> Hi Daniel, sorry for late response.
>
> I don't know for real what is happening with your alerts but i'll keep
> giving you some advices, we'll see if we can make this work.
>
> Maild read directly from alerts.log, search for "mail" flag and if it is
> present send the email, that means if your alerts is printing out into
> alerts.log file it should be sent by email.
>
> So, first try to locate the alert 10005 (or 17) in your alerts.log
> file.
> Second, in your ossec.conf file between  tags include the
> following for better testing:*  and do_not_group*
>
> It is very important that the alert your looking to be send via email
> actually be present on alerts.log file.
>
> Good luck! Keep us up to date.
>
>
> El lunes, 23 de noviembre de 2015, 5:03:18 (UTC-8), Daniel Bray escribió:
>>
>>
>> On Monday, November 16, 2015 at 8:28:27 AM UTC-5, Daniel Bray wrote:
>>>
>>> With the updated alert_by_email settings, this has stopped the email
>>> alerts. I see it hitting the WebUI as alert level 2, but no emails are
>>> coming in.
>>>
>>
>>
>> Unfortunately, with everything put back to the default settings, this
>> issue remains. I'm seeing other issues with some filters as well. Not sure
>> what else to do. It must be a bad install or version I'm running.
>>
> --
>
> ---
> 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/uXdwCE64oRU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] ossec-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Monday, November 16, 2015 at 8:28:27 AM UTC-5, Daniel Bray wrote:
>
> With the updated alert_by_email settings, this has stopped the email 
> alerts. I see it hitting the WebUI as alert level 2, but no emails are 
> coming in. 
>


Unfortunately, with everything put back to the default settings, this issue 
remains. I'm seeing other issues with some filters as well. Not sure what 
else to do. It must be a bad install or version I'm running. 

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Monday, November 16, 2015 at 7:47:24 AM UTC-5, Daniel Bray wrote:
>
> OK, I'm a little lost as to what this is trying to prove, but the updated 
> settings are in place. I'm waiting for an alert to come through. 
>
>
With the updated alert_by_email settings, this has stopped the email 
alerts. I see it hitting the WebUI as alert level 2, but no emails are 
coming in. 

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 13, 2015 at 2:30:24 PM UTC-5, Pedro S. wrote:
>
> Okay try this:
>
> Temporaly remove "alert_by_email" from rule 1002 on 
> syslog_rules.xml.
> Now add "alert_by_email" in your custom rule.
> Restart OSSEC and generate the alert.
>
> What im trying here is to stop OSSEC from sending 1002 rule email, i think 
> that "alert_by_email" option force OSSEC to send an email alert and stop 
> him to keep looking to reach 17 rule. Just guessing.
>
>
> Btw, sorry for my english, as you would imagine, it is not my mother 
> language.
>

OK, I'm a little lost as to what this is trying to prove, but the updated 
settings are in place. I'm waiting for an alert to come through. 

Interesting discovery that I just noticed, within the WebUI. For every 
alert that comes in, I'm seeing two entries now. The new one that Dan had 
me update, which changes it to Alert level 1 (not sending an email). The 
other that I'm used to seeing is Alert level 2 (sending en email). So, it 
would appear that my local_rule is working, but it is not overwriting the 
default rules. This is very confusing. I've changed the local_rule back to 
level 2 along with the requested "alert_by_email" update.

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Fri, Nov 13, 2015 at 2:16 PM, dan (ddp)  wrote:

> I was hoping it would help with the production use, but since it was
> working for me I guess that doesn't matter. I'm pretty much stumped at
> the moment.
>

I'm running this on CentOS 6 with ossec-hids-server-2.8.2-49.el6.art.x86_64
(Atomic)
I'm curious if it's an issue with the version I'm using.

-- 

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

Re: [ossec-list] ossec-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 13, 2015 at 2:03:45 PM UTC-5, dan (ddpbsd) wrote:
>
> Try setting the rule to level 2
>
>
>
Doing that results in:
**Phase 3: Completed filtering (rules).
   Rule id: '17'
   Level: '2'
   Description: 'Ignore MIP Alerts'
**Alert to be generated.
 

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 13, 2015 at 12:17:09 PM UTC-5, dan (ddpbsd) wrote:
>
> Ok, this information is working for me as well. I have tested it on a 
> local install and an agent/server install (changing the hostname as 
> appropriate). 
>
> Is the agent name testserver? Do the hostname of the system and the 
> agent name match? 
>


 Yes, that all matches up. In fact, I've tried with multiple hostnames or 
just one hostname, and each time the logtest catches it as "Level: '0' - 
Description: 'Ignore MIP Alerts'"no matter what I throw at it, but the 
emails/alerts keep coming in as "Rule: 1002 fired (level 2)". 

I'm even waiting for the email to come in, grabbing the "Portion of the 
log(s):" from the email and pasting it into the logtest, and each time it 
comes up as "Level: '0' - Description: 'Ignore MIP Alerts'".

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

Sorry about that, it is just a simple typo. I didn't want to copy&paste the
actual rule, as it had some semi-private information in it.  I copied and
pasted my actual rule 15 to a test rule 17, so please just ignore
that.  Here is the actual updated test rule I'm trying:

  
1002
testserver
mip
HAEngine\.*INFO|HAEngine\.*WARNING|Failed to send pseudo-TCP
segment frame
Ignore MIP Alerts
  

Here is the current log entry I'm testing:
Nov 13 16:07:17 testserver mip:  : HAEngine : WARNING   : 2 : Replay
protection check failed

And here is the current results:
**Phase 1: Completed pre-decoding.
   full event: 'Nov 13 16:07:17 testserver mip:  : HAEngine : WARNING
: 2 : Replay protection check failed'
   hostname: 'testserver'
   program_name: 'mip'
   log: ' : HAEngine : WARNING   : 2 : Replay protection check
failed'

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

**Phase 3: Completed filtering (rules).
   Rule id: '17'
   Level: '0'
   Description: 'Ignore MIP Alerts'


However, the email alerts are still coming in. I'm trying to start some of
this up in debug mode, so I can gather further information.




On Fri, Nov 13, 2015 at 11:27 AM, dan (ddp)  wrote:

> On Fri, Nov 13, 2015 at 11:16 AM, Pedro S.  wrote:
> > My confusion was the rule he wrote here has SID 15 and the logtest
> > result has SID 17, sorry about that.
> >
>
> You're right, I totally missed that. Now I'm wondering what 17 is.
>
> > Still i'll try to create a generic rule to make sure OSSEC is loading new
> > rules.
> >
> > Anyways if Dan already has tested it, the rule is working, it should be
> your
> > OSSEC is not loading the rule properly.
> >
> >
> > El viernes, 13 de noviembre de 2015, 8:04:05 (UTC-8), dan (ddpbsd)
> escribió:
> >>
> >> On Fri, Nov 13, 2015 at 10:59 AM, Pedro S.  wrote:
> >> > Hi Daniel,
> >> >
> >> > The alerts you changed to level 0 it isn't the same that you write
> some
> >> > lines before, isn't it?
> >> > You turn to 0 rule SID 15 but the alert you show us has SID 1002.
> >> >
> >>
> >> The log message used in the ossec-logtest example matches the log
> >> message that is in the alert. The problem is that ossec-logtest shows
> >> that the log message should match rule 15, but ossec-analysisd is
> >> matching the log message to 1002.
> >>
> >>
> >> > For testing purposes try to deactivate (change to level 0) rule 1002
> and
> >> > check if it is still generating these alerts.
> >> >
> >>
> >> Don't do this. There's no reason to change that to 0. Even for
> >> testing. I've been using OSSEC for a little while now, and I don't
> >> think that would have ever helped with anything.
> >>
> >> >
> >> >
> >> >
> >> >
> >> > El viernes, 13 de noviembre de 2015, 7:44:37 (UTC-8), Daniel Bray
> >> > escribió:
> >> >>
> >> >> On Friday, November 13, 2015 at 10:33:04 AM UTC-5, Daniel Bray wrote:
> >> >>>>
> >> >>>>  I'm waiting to see if it generates an alert.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> Nope, issue remains. Very confusing.
> >> >
> >> > --
> >> >
> >> > ---
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "ossec-list" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to ossec-list+...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ossec-list+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ossec-list" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ossec-list/uXdwCE64oRU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] ossec-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 13, 2015 at 10:33:04 AM UTC-5, Daniel Bray wrote:
>
>  I'm waiting to see if it generates an alert.
>>
>
>

Nope, issue remains. Very confusing.  

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

On Friday, November 13, 2015 at 8:51:45 AM UTC-5, dan (ddpbsd) wrote:
>
> Or are you sure the manager restarted? Most of the time when I've seen 
> this behavior on the list analysisd did not actually stop, so it 
> didn't pickup the new rules. Running `/var/ossec/bin/ossec-control 
> stop`, then verifying all of the processes are stopped is a prudent 
> course of action. 
>


Hmmm, not sure this would cause it, but this is what I saw:
sudo /var/ossec/bin/ossec-control stop
Killing ossec-monitord ..
Killing ossec-logcollector ..
Killing ossec-remoted ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
ossec-execd not running ..
OSSEC HIDS v2.8 Stopped

sudo ps aux| grep ossec
ossecm4828  0.0  0.0  10508   260 ?SNov10   0:00 
/var/ossec/bin/ossec-maild

So, it stopped everything, except ossec-maild. I missed this the first 
time, because I specifically checked for analysisd instead of just "ossec". 
 So, I manually killed the ossec-maild process and started everything back. 
I'm waiting to see if it generates an alert.

-- 

--- 
You received this message because you are subscribed 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-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

Yes, all my local rules are under the  and yes, 
I made sure to stop and restart everything.

On Thursday, November 12, 2015 at 8:37:35 PM UTC-5, Santiago Bassett wrote:
>
> Hi Daniel,
>
> not sure if that matters but is your local rule in the same  "syslog,errors,">, as rule 1002 is? You sure you restarted the manger 
> right?
>
> Best
>
> On Thu, Nov 12, 2015 at 7:06 AM, Daniel Bray  > wrote:
>
>> I'm running ossec-hids-server-2.8.2-49.el6.art.x86_64 (Atomic repo)
>>
>> I've updated /var/ossec/rules/local_rules.xml with the following rule:
>>
>>   
>> 1002
>> testserver1|testserver2
>> mip
>> HAEngine\.*INFO|HAEngine\.*WARNING|Failed to send pseudo-TCP 
>> segment frame
>> Ignore MIP Alerts
>>   
>>
>>
>> I've tested the rule with:
>> ossec-testrule: Type one log per line.
>>
>> Nov 12 13:48:50 testserver1 mip:  : HAEngine : WARNING   : 2 : Replay 
>> protection check failed
>>
>>
>> **Phase 1: Completed pre-decoding.
>>full event: 'Nov 12 13:48:50 testserver1 mip:  : HAEngine : 
>> WARNING   : 2 : Replay protection check failed '
>>hostname: 'testserver1'
>>program_name: 'mip'
>>log: ' : HAEngine : WARNING   : 2 : Replay protection check 
>> failed '
>>
>> **Phase 2: Completed decoding.
>>No decoder matched.
>>
>> **Phase 3: Completed filtering (rules).
>>Rule id: '17'
>>Level: '0'
>>Description: 'Ignore MIP Alerts'
>>
>>
>>
>> I've restarted everything, but the servers are still generating alerts:
>>
>> OSSEC HIDS Notification.
>> 2015 Nov 12 14:58:37
>>
>> Received From: (testserver1)
>> Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
>> Portion of the log(s):
>>
>> Nov 12 14:58:36 testserver1 mip:  : HAEngine : WARNING   : 2 : Replay 
>> protection check failed
>>
>>  --END OF NOTIFICATION
>>
>>
>>
>> Can anybody shed some light on what's going on, or what I should try next?
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

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

[ossec-list] ossec-logtest returns Level 0 but still getting email alerts Level 2

[Daniel Bray]

I'm running ossec-hids-server-2.8.2-49.el6.art.x86_64 (Atomic repo)

I've updated /var/ossec/rules/local_rules.xml with the following rule:

  
1002
testserver1|testserver2
mip
HAEngine\.*INFO|HAEngine\.*WARNING|Failed to send pseudo-TCP
segment frame
Ignore MIP Alerts
  


I've tested the rule with:
ossec-testrule: Type one log per line.

Nov 12 13:48:50 testserver1 mip:  : HAEngine : WARNING   : 2 : Replay
protection check failed


**Phase 1: Completed pre-decoding.
   full event: 'Nov 12 13:48:50 testserver1 mip:  : HAEngine : WARNING
  : 2 : Replay protection check failed '
   hostname: 'testserver1'
   program_name: 'mip'
   log: ' : HAEngine : WARNING   : 2 : Replay protection check
failed '

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

**Phase 3: Completed filtering (rules).
   Rule id: '17'
   Level: '0'
   Description: 'Ignore MIP Alerts'



I've restarted everything, but the servers are still generating alerts:

OSSEC HIDS Notification.
2015 Nov 12 14:58:37

Received From: (testserver1)
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Nov 12 14:58:36 testserver1 mip:  : HAEngine : WARNING   : 2 : Replay
protection check failed

 --END OF NOTIFICATION



Can anybody shed some light on what's going on, or what I should try next?

-- 

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

[ossec-list] Hybrid mode automated install

[Daniel Townend]

We are wanting to deploy ossec with active response but also to send logs 
to OSSIM. I can't see an option for hybrid mode on the automated install 
config file, is there any way to automate this installation?

-- 

--- 
You received this message because you are subscribed 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] Ignoring multiple user logon or logoff checks

[Daniel Bray]

I am trying to ignore rule 18107 and 18149, but only for certain accounts 
(including the servers/machines).

Server OS: CentOS 6 (latest patches)
OSSEC: ossec-hids-server-2.8.2-49.el6.art.x86_64

Here is what I have in my /var/ossec/rules/local_rules.xml file.

  
18107
Account Name: nagiosservice|User Name: \S+\$|Account Name: 
\S+\$
Ignore Nagios and M$ server Logon checks
  

  
18149
Account Name: nagiosservice|User Name: \S+\$|Account Name: 
\S+\$
Ignore Nagios and M$ sever Logoff checks
  

I have read over multiple similar issues to this problem, but all the past 
fixes are not working. 

Another oddity, is that the running the /var/ossec/bin/ossec-logtest 
against the sample:

WinEvtLog: Security: AUDIT_SUCCESS(4634): 
Microsoft-Windows-Security-Auditing: TEST-SERVER-01$: TEST: 
test-server-01.test.local: An account was logged off. Subject: Security ID: 
S-1-5-18 Account Name: TEST-SERVER-01$ Account Domain: TEST Logon ID: 
0x4b02faa4 Logon Type: 3 This event is generated when a logon session is 
destroyed. It may be positively correlated with a logon event using the 
Logon ID value. Logon IDs are only unique between reboots on the same 
computer.


Does indicate that it should be ignored:

**Phase 1: Completed pre-decoding.
full event: 'WinEvtLog: Security: AUDIT_SUCCESS(4634): 
Microsoft-Windows-Security-Auditing: TEST-SERVER-01$: TEST: 
test-server-01.test.local: An account was logged off. Subject: Security ID: 
S-1-5-18 Account Name: TEST-SERVER-01$ Account Domain: TEST Logon ID: 
0x4b02faa4 Logon Type: 3 This event is generated when a logon session is 
destroyed. It may be positively correlated with a logon event using the 
Logon ID value. Logon IDs are only unique between reboots on the same 
computer.'
hostname: 'ust-ossec-01'
program_name: '(null)'
log: 'WinEvtLog: Security: AUDIT_SUCCESS(4634): 
Microsoft-Windows-Security-Auditing: TEST-SERVER-01$: TEST: 
test-server-01.test.local: An account was logged off. Subject: Security ID: 
S-1-5-18 Account Name: TEST-SERVER-01$ Account Domain: TEST Logon ID: 
0x4b02faa4 Logon Type: 3 This event is generated when a logon session is 
destroyed. It may be positively correlated with a logon event using the 
Logon ID value. Logon IDs are only unique between reboots on the same 
computer.'

**Phase 2: Completed decoding.
decoder: 'windows'
status: 'AUDIT_SUCCESS'
id: '4634'
extra_data: 'Microsoft-Windows-Security-Auditing'
dstuser: 'TEST-SERVER-01#39;
system_name: 'test-server-01.test.local'

**Phase 3: Completed filtering (rules).
Rule id: '100014'
Level: '0'
Description: 'Ignore Nagios and M$ sever Logoff checks'

 
However, I'm still seeing the alerts within WebUI.

Any help would be appreciated,
-DB



-- 

--- 
You received this message because you are subscribed 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: Monitor Windows Services Shutdown

[Daniel Baker]

More Information:  PCI 10.2.6 Initialization, stopping, or pausing of the 
audit logs
My focus is on Windows Services Stop events

I do not have any logs in archives.log


On Monday, October 5, 2015 at 10:59:25 AM UTC-6, Brent Morris wrote:
>
> It's easier for us to test if you can post it from your archives.log on 
> ossec :)
>
> On Monday, October 5, 2015 at 9:52:20 AM UTC-7, Daniel Baker wrote:
>>
>> - http://schemas.microsoft.com/win/2004/08/events/event 
>> <http://schemas.microsoft.com/win/2004/08/events/event>*">
>> - 
>>
>>   1100 
>>   0 
>>   4 
>>   103 
>>   0 
>>   0x4020 
>>
>>   2719810 
>>
>>
>>   Security 
>>   Security-Test 
>>
>>   
>> - 
>>   > xmlns="*http://manifests.microsoft.com/win/2004/08/windows/eventlog 
>> <http://manifests.microsoft.com/win/2004/08/windows/eventlog>*" /> 
>>   
>>   
>>
>> On Monday, October 5, 2015 at 10:25:48 AM UTC-6, dan (ddpbsd) wrote:
>>>
>>>
>>> On Oct 5, 2015 12:23 PM, "Daniel Baker"  wrote:
>>> >
>>> >
>>> >
>>> > On Monday, October 5, 2015 at 8:38:17 AM UTC-6, Daniel Baker wrote:
>>> >>
>>> >> I'm looking for a way to have OSSEC trigger on Event ID 1100 Service 
>>> Shutdown in Windows.
>>> >
>>> >
>>> > This is what I'm trying to add to the local_rules.xml file:
>>> >
>>> > 
>>> > 18104
>>> > ^1100$
>>> > Windows Service Stopped
>>> >  
>>> >
>>>
>>> Do you have a log we can test with?
>>>
>>> > -- 
>>> >
>>> > --- 
>>> > You received this message because you are subscribed 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: Monitor Windows Services Shutdown

[Daniel Baker]

 -  http://schemas.microsoft.com/win/2004/08/events/event*";>
-  
   
  1100 
  0 
  4 
  103 
  0 
  0x4020 
   
  2719810 
   
   
  Security 
  Security-Test 
   
  
-  
  http://manifests.microsoft.com/win/2004/08/windows/eventlog*"; /> 
  
  

On Monday, October 5, 2015 at 10:25:48 AM UTC-6, dan (ddpbsd) wrote:
>
>
> On Oct 5, 2015 12:23 PM, "Daniel Baker" > 
> wrote:
> >
> >
> >
> > On Monday, October 5, 2015 at 8:38:17 AM UTC-6, Daniel Baker wrote:
> >>
> >> I'm looking for a way to have OSSEC trigger on Event ID 1100 Service 
> Shutdown in Windows.
> >
> >
> > This is what I'm trying to add to the local_rules.xml file:
> >
> > 
> > 18104
> > ^1100$
> > Windows Service Stopped
> >  
> >
>
> Do you have a log we can test with?
>
> > -- 
> >
> > --- 
> > You received this message because you are subscribed 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: Monitor Windows Services Shutdown

[Daniel Baker]

On Monday, October 5, 2015 at 8:38:17 AM UTC-6, Daniel Baker wrote:
>
> I'm looking for a way to have OSSEC trigger on Event ID 1100 Service 
> Shutdown in Windows.
>

This is what I'm trying to add to the local_rules.xml file:


18104
^1100$
Windows Service Stopped
 

-- 

--- 
You received this message because you are subscribed 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] Monitor Windows Services Shutdown

[Daniel Baker]

I'm looking for a way to have OSSEC trigger on Event ID 1100 Service 
Shutdown in Windows.

-- 

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

Re: [ossec-list] OSSEC WUI can't read alerts.log

[Daniel]

Interesting that ossec-wui isn't supported. I downloaded the appliance 
right from ossec.net and was following the instructions.

Went through my running processes and checked out their configs... sure 
enough, kibana is also included.

Opened up a browser to localhost:5601 and Kibana is still running like a 
champ. Not even going to try to fix the wui since I'm more familiar with 
ELK.

Thanks for the help, Eero.

On Saturday, August 8, 2015 at 4:31:42 PM UTC-4, Eero Volotinen wrote:
>
> Well, 
>
> Check memory_limit on php also.
>
> Ossec wui is no longer supported. You should use kibana+elastic search 
> instead of it.
>
> Eero
>
> Eero
> Thanks for the quick response. 
>
> I chown'ed alerts.log from ossec.ossec to ossec.apache and still got the 
> error. 
>
> I then chmod'ed alerts.log from 640 to 666 and still got the error.
>
> Alerts.log is still growing, though. Up to 4.2G.
>
> On Saturday, August 8, 2015 at 3:29:32 PM UTC-4, Eero Volotinen wrote:
>>
>> Well, you need to give correct permissions to apache as wui is running 
>> under apache uid..
>>
>> Eeeo
>> 8.8.2015 8.27 ip. "Daniel Twardowski"  kirjoitti:
>>
>>>
>>> I'm using OSSEC Server Virtual Appliance 2.8.2 and last night I 
>>> configured a few domain controllers to send it their logs. When I came in 
>>> today, the WUI is displaying an error of:
>>> "Warning:  fopen(/var/ossec/logs/alerts/alerts.log): failed to open 
>>> stream: Value too large for defined data type in 
>>> /opt/lampp/htdocs/ossec-wui/lib/os_lib_alerts.php on line 839"
>>>
>>> My alerts.log file is 3.5G. If I delete it and restart ossec services, 
>>> the file is recreated at 3.5G. Is this an issue with file size? If so, can 
>>> I up the log rotation to more than just once a day? And how would I flush 
>>> whatever buffer keeps recreating the 3.5G alerts.log file so I can get back 
>>> to reviewing logs?
>>>
>>> Similar, but unanswered message from 2013:
>>> https://groups.google.com/forum/#!msg/ossec-list/topCxSvvmBk/5t4YEfPTTYUJ
>>>
>>> Thanks.
>>>
>>> Dan
>>>
>>> -- 
>>>
>>> --- 
>>> You received this message because you are subscribed 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 WUI can't read alerts.log

[Daniel]

Thanks for the quick response. 

I chown'ed alerts.log from ossec.ossec to ossec.apache and still got the 
error. 

I then chmod'ed alerts.log from 640 to 666 and still got the error.

Alerts.log is still growing, though. Up to 4.2G.

On Saturday, August 8, 2015 at 3:29:32 PM UTC-4, Eero Volotinen wrote:
>
> Well, you need to give correct permissions to apache as wui is running 
> under apache uid..
>
> Eeeo
> 8.8.2015 8.27 ip. "Daniel Twardowski" > 
> kirjoitti:
>
>>
>> I'm using OSSEC Server Virtual Appliance 2.8.2 and last night I 
>> configured a few domain controllers to send it their logs. When I came in 
>> today, the WUI is displaying an error of:
>> "Warning:  fopen(/var/ossec/logs/alerts/alerts.log): failed to open 
>> stream: Value too large for defined data type in 
>> /opt/lampp/htdocs/ossec-wui/lib/os_lib_alerts.php on line 839"
>>
>> My alerts.log file is 3.5G. If I delete it and restart ossec services, 
>> the file is recreated at 3.5G. Is this an issue with file size? If so, can 
>> I up the log rotation to more than just once a day? And how would I flush 
>> whatever buffer keeps recreating the 3.5G alerts.log file so I can get back 
>> to reviewing logs?
>>
>> Similar, but unanswered message from 2013:
>> https://groups.google.com/forum/#!msg/ossec-list/topCxSvvmBk/5t4YEfPTTYUJ
>>
>> Thanks.
>>
>> Dan
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 

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

[ossec-list] OSSEC WUI can't read alerts.log

[Daniel Twardowski]

I'm using OSSEC Server Virtual Appliance 2.8.2 and last night I configured 
a few domain controllers to send it their logs. When I came in today, the 
WUI is displaying an error of:
"Warning:  fopen(/var/ossec/logs/alerts/alerts.log): failed to open stream: 
Value too large for defined data type in 
/opt/lampp/htdocs/ossec-wui/lib/os_lib_alerts.php on line 839"

My alerts.log file is 3.5G. If I delete it and restart ossec services, the 
file is recreated at 3.5G. Is this an issue with file size? If so, can I up 
the log rotation to more than just once a day? And how would I flush 
whatever buffer keeps recreating the 3.5G alerts.log file so I can get back 
to reviewing logs?

Similar, but unanswered message from 2013:
https://groups.google.com/forum/#!msg/ossec-list/topCxSvvmBk/5t4YEfPTTYUJ

Thanks.

Dan

-- 

--- 
You received this message because you are subscribed 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] rootcheck rule at sev 7 (bad word match)?

[Daniel X]

Cool. That's what I was looking for.  I think I'm just going to remove my
labeling from the sev levels in my dashboards.  It might be useful to have
a note on that page advising that these labels may not always be true today.

Thanks.

Daniel

On 18 June 2015 at 09:39, dan (ddp)  wrote:

>
> On Jun 17, 2015 7:26 PM, "Daniel X"  wrote:
> >
> > Thanks for the reply Dan,
> >
> > I understand that line in the default rules.  What I don't understand is
> how Sev 7 is (according to the doc I linked to above):
> >
> >  _07 - “Bad word” matching. They include words like “bad”, “error”, etc.
> These events are most of the time unclassified and may have some security
> relevance.'_
> >
> > yet Sev 11 is described as (and thus seems more fitting to me):
> >
> > _11 - Integrity checking warning - They include messages regarding the
> modification of binaries or the presence of rootkits (by rootcheck)._
> >
> > I'm thinkng this doc may not be entirely correct in it's descriptions so
> will probably just ignore the descriptions.
> >
>
> It's a generic document written probably 10+ years ago. I thought it might
> be interesting in a general or historical sense, so I made sure to include
> it.
> I feel like the severity of the file integrity alerts was lessened or not
> raised to that level because the alerts aren't that interesting.
>
> > Daniel
> >
> > On 17 June 2015 at 23:24, dan (ddp)  wrote:
> >>
> >> On Wed, Jun 10, 2015 at 2:15 AM, Daniel X 
> wrote:
> >> > Hi OSSECers,
> >> >
> >> >
> >> > I've recently been working with Splunk dashboarding (using the Splunk
> for
> >> > OSSEC app as a starting point).
> >> >
> >> > One of the features I've expanded is the 'top severities list', where
> I've
> >> > named the severities according to the Rules Classification
> documentation
> >> > (
> http://ossec-docs.readthedocs.org/en/latest/manual/rules-decoders/rule-levels.html
> )
> >> >
> >> > What I've noticed is that the 'Integrity Checksum Changed' signature
> is
> >> > coming in as Severity 7 (Bad Word Match), and looking into the rules
> I can
> >> > see that reflected, and the only thing I see at sev "11" are the IDS
> rules.
> >> >
> >> > Below are relevant sections in the rules in OSSEC 2.8.1.  Is it
> correct that
> >> > rule id 510 has level="7"?  I'm going to change it 10 11 in my local
> config,
> >> > but it'd be good to know the intentions of this if it's not an
> oversight.
> >> >
> >>
> >> Yes, level 7 appears to be correct:
> >>
> https://github.com/ossec/ossec-hids/blob/master/etc/rules/ossec_rules.xml#L61
> >>
> >> > rules/ids_rules.xml
> >> >  
> >> > 509
> >> > Host-based anomaly detection event
> >> > (rootcheck).
> >> > rootcheck,
> >> > 
> >> >   
> >> >
> >> >
> >> > rules/ids_rules.xml
> >> >   
> >> >   
> >> > 20151
> >> > 
> >> > 
> >> > srcip, id
> >> > Multiple IDS events from same source ip
> 
> >> > (ignoring now this srcip and id).
> >> >   
> >> >
> >> >   
> >> > 20152
> >> > 
> >> > id
> >> > Multiple IDS alerts for same id 
> >> > (ignoring now this id).
> >> >   
> >> >
> >> > Thanks!
> >> >
> >> > --
> >> >
> >> > ---
> >> > You received this message because you are subscribed to the Google
> Groups
> >> > "ossec-list" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an
> >> > email to ossec-list+unsubscr...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups "ossec-list" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to ossec-list+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to ossec-list+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] rootcheck rule at sev 7 (bad word match)?

[Daniel X]

Thanks for the reply Dan,

I understand that line in the default rules.  What I don't understand is
how Sev 7 is (according to the doc I linked to above):

 _07 - “Bad word” matching. They include words like “bad”, “error”, etc.
These events are most of the time unclassified and may have some security
relevance.'_

yet Sev 11 is described as (and thus seems more fitting to me):

_11 - Integrity checking warning - They include messages regarding the
modification of binaries or the presence of rootkits (by rootcheck)._

I'm thinkng this doc may not be entirely correct in it's descriptions so
will probably just ignore the descriptions.

Daniel

On 17 June 2015 at 23:24, dan (ddp)  wrote:

> On Wed, Jun 10, 2015 at 2:15 AM, Daniel X 
> wrote:
> > Hi OSSECers,
> >
> >
> > I've recently been working with Splunk dashboarding (using the Splunk for
> > OSSEC app as a starting point).
> >
> > One of the features I've expanded is the 'top severities list', where
> I've
> > named the severities according to the Rules Classification documentation
> > (
> http://ossec-docs.readthedocs.org/en/latest/manual/rules-decoders/rule-levels.html
> )
> >
> > What I've noticed is that the 'Integrity Checksum Changed' signature is
> > coming in as Severity 7 (Bad Word Match), and looking into the rules I
> can
> > see that reflected, and the only thing I see at sev "11" are the IDS
> rules.
> >
> > Below are relevant sections in the rules in OSSEC 2.8.1.  Is it correct
> that
> > rule id 510 has level="7"?  I'm going to change it 10 11 in my local
> config,
> > but it'd be good to know the intentions of this if it's not an oversight.
> >
>
> Yes, level 7 appears to be correct:
>
> https://github.com/ossec/ossec-hids/blob/master/etc/rules/ossec_rules.xml#L61
>
> > rules/ids_rules.xml
> >  
> > 509
> > Host-based anomaly detection event
> > (rootcheck).
> > rootcheck,
> > 
> >   
> >
> >
> > rules/ids_rules.xml
> >   
> >   
> > 20151
> > 
> > 
> > srcip, id
> > Multiple IDS events from same source ip 
> > (ignoring now this srcip and id).
> >   
> >
> >   
> > 20152
> > 
> > id
> > Multiple IDS alerts for same id 
> > (ignoring now this id).
> >   
> >
> > Thanks!
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ossec-list+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

[ossec-list] rootcheck rule at sev 7 (bad word match)?

[Daniel X]

Hi OSSECers,


I've recently been working with Splunk dashboarding (using the Splunk for
OSSEC app as a starting point).

One of the features I've expanded is the 'top severities list', where I've
named the severities according to the Rules Classification documentation (
http://ossec-docs.readthedocs.org/en/latest/manual/rules-decoders/rule-levels.html
)

What I've noticed is that the 'Integrity Checksum Changed' signature is
coming in as Severity 7 (Bad Word Match), and looking into the rules I can
see that reflected, and the only thing I see at sev "11" are the IDS rules.

Below are relevant sections in the rules in OSSEC 2.8.1.  Is it correct
that rule id 510 has level="7"?  I'm going to change it 10 11 in my local
config, but it'd be good to know the intentions of this if it's not an
oversight.

rules/ids_rules.xml
 
509
Host-based anomaly detection event (rootcheck).
rootcheck,

  


rules/ids_rules.xml
  
  
20151


srcip, id
Multiple IDS events from same source ip 
(ignoring now this srcip and id).
  

  
20152

id
Multiple IDS alerts for same id 
(ignoring now this id).
  

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] Ignore file for n seconds after initialisation?

[Daniel X]

I've been working with getting OSSEC deployed in a distributed, mixed
environment, which hosts which are frequently destroyed and recreated.

I've managed to get the install and rules fairly well set up thus far, but
am hitting a small issue presently, which is that a couple of files are
being alerted very soon after start, the files being /etc/resolv.conf and
/etc/shadow-

Presently I'm starting OSSEC as a very last step of our host install, but
I'm figuring DHCP has yet to finalise resolv.conf, and the local users
being setup during a preceeding install step means that shadow- is yet to
be written at the time OSSEC is starting.  At least that's my random ideas
so far.

What I'm wondering is if I can ignore these files for the first, say,
minute after OSSEC starts?  Otherwise I may have to ignore these files
completely, which may be low impact anyhow given that DHCP may legitimately
overwrite resolv.conf and shadow- is essentially a backup.

Any ideas greatly appreciated!

Dan

-- 

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

Re: [ossec-list] Where are file integrity file permissions stored?

[Daniel X]

A couple of days ago I needed to parse integrity logs myself and found the
above thread useful.  Ended up writing up a quick n dirty bash script to do
so and thought I'd post it here incase anyone finds it useful.  It's
certainly not my finest work but I may get around to turning it into
something better.

Presently it takes single lines which are hardcoded as variables in the
script but shouldn't be much work to have it parse a file.

https://gist.github.com/auraltension/8b8af776647657b579cc

$ ./ossec-syscheck-decoder.sh
File: /etc/sudoers
Date: Tue Jun  2 15:45:45 AEST 2015
# of changes: 0 changes
File Size: 4002 Bytes
File Mode: 100440
ownership: 0:0
sha1sum: 7f8136e115bc8877afdda1cb9c357da7ecdbb8d2

-- 

--- 
You received this message because you are subscribed 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] Windows Application and System logs

[Daniel Wagner]

Eventlog.  Will try the eventchannel and report.  Thank you.

On Friday, May 15, 2015 at 4:52:20 AM UTC-7, dan (ddpbsd) wrote:
>
> On Wed, May 13, 2015 at 10:20 PM, Daniel Wagner  > wrote: 
> > Hello all, 
> > 
> > I've installed OSSEC HIDS Agent v2.8 on a few Windows 2008R2 servers and 
> > Windows 2003 servers and am receiving the Security logs on  my OSSEC 
> > server, but not the Application and System logs. 
> > 
> > My config file is the default from the install which has a  
> > entry for all three logs. 
> > 
> > The OSSEC agent log shows: 
> > INFO: Analyzing event log :Application 
> > INFO: Analyzing event log :Security 
> > INFO: Analyzing event log :System 
> > 
> > Querying 'WinEvtLog: Application' produces no results.  Querying 
> > 'WinEvtLog: Security' show numerous events from all my servers. 
> > 
> > Any ideas on why the Application and System logs are not being 
> processed? 
> > 
>
> Are you using the eventlog or eventchannel log format? eventchannel 
> might produce better results (although I don't know for sure, and 
> can't test it). 
>
> > -- 
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "ossec-list" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to ossec-list+...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

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

Re: [ossec-list] Windows Application and System logs

[Daniel Wagner]

Will try and update.  Thank you.

On Thursday, May 14, 2015 at 7:59:03 AM UTC-7, LostInThe Tubez wrote:
>
> Have you turned on logall 
> <https://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.global.html>
>  
> and looked in /var/ossec/logs/archives/archives.log to verify you aren’t 
> getting anything from the System and Application logs? It may be that you 
> simply aren’t getting any entries from those logs that are triggering 
> alerts. This seems unlikely, but in theory possible, depending on how busy 
> these servers are and how you have your system audit policy setup.
>
>  
>
> *From:* ossec...@googlegroups.com  [mailto:
> ossec...@googlegroups.com ] *On Behalf Of *Daniel Wagner
> *Sent:* Wednesday, May 13, 2015 7:20 PM
> *To:* ossec...@googlegroups.com 
> *Subject:* [ossec-list] Windows Application and System logs
>
>  
>
> Hello all,
>
> I've installed OSSEC HIDS Agent v2.8 on a few Windows 2008R2 servers and
> Windows 2003 servers and am receiving the Security logs on  my OSSEC
> server, but not the Application and System logs.
>
> My config file is the default from the install which has a 
> entry for all three logs.
>
> The OSSEC agent log shows:
> INFO: Analyzing event log :Application
> INFO: Analyzing event log :Security
> INFO: Analyzing event log :System
>
> Querying 'WinEvtLog: Application' produces no results.  Querying
> 'WinEvtLog: Security' show numerous events from all my servers.
>
> Any ideas on why the Application and System logs are not being processed?
>
> -- 
>
> --- 
> You received this message because you are subscribed 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] Windows Application and System logs

[Daniel Wagner]

Hello all,

I've installed OSSEC HIDS Agent v2.8 on a few Windows 2008R2 servers and
Windows 2003 servers and am receiving the Security logs on  my OSSEC
server, but not the Application and System logs.

My config file is the default from the install which has a 
entry for all three logs.

The OSSEC agent log shows:
INFO: Analyzing event log :Application
INFO: Analyzing event log :Security
INFO: Analyzing event log :System

Querying 'WinEvtLog: Application' produces no results.  Querying
'WinEvtLog: Security' show numerous events from all my servers.

Any ideas on why the Application and System logs are not being processed?

-- 

--- 
You received this message because you are subscribed 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] use_fqdn

[Daniel Sanabria]

Hi,

I'm running ossec-hids 2.8.1 on centos and when trying to use the use_fqdn 
setting for the syslog_output properties I get the following in the ossec 
logs and the service fail to start:

ossec.log
2015/04/07 13:15:46 ossec-config(1230): ERROR: Invalid element in the 
configuration: 'use_fqdn'.
2015/04/07 13:15:46 ossec-config(1202): ERROR: Configuration error at 
'/var/ossec/etc/ossec.conf'. Exiting.

ossec.conf section
  
127.0.0.1
7
yes
  

The documentation seems to imply that the feature is available on 2.8.1 
(http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.syslog_output.html)
 
but github tell us otherwise.

Can someone confirm if the documentation is accurate or not and what my 
options are to stop ossec from truncating the hostname when generating 
syslog messages?

Thanks in advance,

Daniel 

-- 

--- 
You received this message because you are subscribed 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: Bypassing Asterisk rules

[Daniel Calvo Castro]

Thank you for your reply, I´ll be working on that and share it when done.

Kind Regards




2015-03-11 2:10 GMT+01:00 Brent Morris :
> You might need to flesh out the rules for asterisk.  I didn't see anything
> based on INVITE in the asterisk section of the decodes or the built-in
> rules.
>
> Sometimes it's necessary to add what you want to watch for in the
> local_rules.xml - it shouldn't be too tough to add a  for
> what you're looking for.
>
>
> On Monday, March 9, 2015 at 10:04:02 AM UTC-7, Van Nistelroot wrote:
>>
>> Hi list,
>>
>> When you attack PBX by enumerating users, you can do it via INVITE,
>> REGISTER and OPTIONS.
>>
>> ossec is only able to detect REGISTER requests, but nothing happens
>> when successfully  try to enumerate vía INVITE ( tried myself )
>>
>> I´m doing something wrong or ossec has to be tweaked?
>>
>> Kind Regards,
>>
>> Daniel
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

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

[ossec-list] Bypassing Asterisk rules

[Daniel Calvo Castro]

Hi list,

When you attack PBX by enumerating users, you can do it via INVITE,
REGISTER and OPTIONS.

ossec is only able to detect REGISTER requests, but nothing happens
when successfully  try to enumerate vía INVITE ( tried myself )

I´m doing something wrong or ossec has to be tweaked?

Kind Regards,

Daniel

-- 

--- 
You received this message because you are subscribed 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] Asterisk rules for Ubuntu

[Daniel Calvo Castro]

Hi dan,

I´ve finally solved the issue, there was an regexp issue in ossim
plugin for ossec ( ossec-single-line.cfg ), so now ossim is correctly
parsing srcip and dstip in UI.

Kind Regards


2015-02-10 14:07 GMT+01:00 dan (ddp) :
> On Tue, Feb 10, 2015 at 8:01 AM, dan (ddp)  wrote:
>>
>> On Feb 10, 2015 7:57 AM, "Daniel Calvo Castro"
>>  wrote:
>>>
>>> Hi again
>>>
>>> These brackets are for emphasis, sorry for not to clarify this, but it
>>> clearly looks like it is a regexp issue, I´m going to deal with it now
>>> and I´ll post if I´m able to solve it. May be some other people are
>>> dealing with this, any help would really appreciated. It is a ticket
>>> opened on github as suggested? I´ll do that in such case
>>>
>>
>> I opened one about the regex issue I'm seeing with this.
>>
>
> Which was ultimately not an issue. Somehow utf-8 characters polluted
> the log message I was testing with.
>
>>> Kind Regards
>>>
>>> 2015-02-10 13:31 GMT+01:00 dan (ddp) :
>>> > On Mon, Feb 9, 2015 at 4:23 PM, Daniel Calvo Castro
>>> >  wrote:
>>> >> Just today I´ve been experiencing same issues trying to get OSSIM +
>>> >> OSSEC
>>> >> working with an asterisk box, I´ve followed this link [1], and trying
>>> >> to
>>> >> enumerate users I´m able to correlate and fire mails correctly with
>>> >> OSSIM,
>>> >> but UI always show $SRCIP 0.0.0.0 so seems useless to configure
>>> >> post-actions
>>> >> like DROP $SRCIP.
>>> >>
>>> >> Taking a look at the link provided, his log appears only to contain src
>>> >> IP,
>>> >> like that:
>>> >>
>>> >> May 19 11:42:17 asterisk asterisk[5200]: NOTICE[14808]:
>>> >> chan_sip.c:15889 in
>>> >> handle_request_register: Registration from
>>> >> ‘”355″’
>>> >> failed for ‘[[[192.168.210.48]]]’ – No matching peer found
>>> >>
>>> >> You can see "failed for 'x.x.x.x' only
>>> >>
>>> >> But seems like in recent versions like me ( stable Elastix  and ossec
>>> >> 2.8 ),
>>> >> log says "failed for 'x.x.x.x:UDPPORT'  so I figured it could be some
>>> >> regexp
>>> >> issue, time to check.
>>> >>
>>> >> - log from post provided and default regexp in decoder.xml
>>> >> "\d+.\d+.\d+.\d+"
>>> >> in regexpr.com correctly matches SRCIP but it fails, you can try
>>> >> yourself:
>>> >>
>>> >> May [[19 11:42:17] asterisk asterisk[5200]: NOTICE[14808]:
>>> >> chan_sip.c:15889 in handle_request_register: Registration from
>>> >> ‘”355″’ failed for ‘192.168.210.48’ – No
>>> >> matching peer found
>>> >>
>>> >
>>> > Are these brackets really in the log message, or are they there for
>>> > emphasis?
>>> >
>>> >> - Escaping dot characters solves the problem, \d+\.\d+\.\d+\.\d+
>>> >> correctly
>>> >
>>> > \. matches any single character.
>>> >
>>> >> matches IP address, and for IP:UDPPORT you can use
>>> >> \d+\.\d+\.\d+\.\d+\:\d+.
>>> >>
>>> >> But placing all this tweakings in decoder and restarting ossec server
>>> >> did
>>> >> not work, OSSIM always matches SRCIP like 0.0.0.0. In fact, I modified
>>> >> this
>>> >> ossec as is the event seen in OSSIM UI when I run svwar:
>>> >>
>>> >
>>> > For some reason I can't get the regex to work with the single quotes
>>> > around the IP address.
>>> >
>>> >> 
>>> >> 6201
>>> >> No matching peer found
>>> >> Login session failed (invalid extension).
>>> >> invalid_login,
>>> >> 
>>> >>
>>> >>
>>> >> I´ll keep trying tomorrow, keep in touch please!
>>> >>
>>> >> Kind Regards,
>>> >>
>>> >> Daniel
>>> >>
>>> >> [1] https://sysbrain.wordpress.com/2010/05/24/asterisk-ossec-part-ii/
>>> >>
>>> >> 2015-02-09 20:21 GMT+01:00 dan (ddp) :
>>> >>>
>>> >>> On Mon, Feb 9, 2015 at 2:10 PM

Re: [ossec-list] Asterisk rules for Ubuntu

[Daniel Calvo Castro]

Hi again

These brackets are for emphasis, sorry for not to clarify this, but it
clearly looks like it is a regexp issue, I´m going to deal with it now
and I´ll post if I´m able to solve it. May be some other people are
dealing with this, any help would really appreciated. It is a ticket
opened on github as suggested? I´ll do that in such case

Kind Regards

2015-02-10 13:31 GMT+01:00 dan (ddp) :
> On Mon, Feb 9, 2015 at 4:23 PM, Daniel Calvo Castro
>  wrote:
>> Just today I´ve been experiencing same issues trying to get OSSIM + OSSEC
>> working with an asterisk box, I´ve followed this link [1], and trying to
>> enumerate users I´m able to correlate and fire mails correctly with OSSIM,
>> but UI always show $SRCIP 0.0.0.0 so seems useless to configure post-actions
>> like DROP $SRCIP.
>>
>> Taking a look at the link provided, his log appears only to contain src IP,
>> like that:
>>
>> May 19 11:42:17 asterisk asterisk[5200]: NOTICE[14808]: chan_sip.c:15889 in
>> handle_request_register: Registration from ‘”355″’
>> failed for ‘[[[192.168.210.48]]]’ – No matching peer found
>>
>> You can see "failed for 'x.x.x.x' only
>>
>> But seems like in recent versions like me ( stable Elastix  and ossec 2.8 ),
>> log says "failed for 'x.x.x.x:UDPPORT'  so I figured it could be some regexp
>> issue, time to check.
>>
>> - log from post provided and default regexp in decoder.xml "\d+.\d+.\d+.\d+"
>> in regexpr.com correctly matches SRCIP but it fails, you can try yourself:
>>
>> May [[19 11:42:17] asterisk asterisk[5200]: NOTICE[14808]:
>> chan_sip.c:15889 in handle_request_register: Registration from
>> ‘”355″’ failed for ‘192.168.210.48’ – No
>> matching peer found
>>
>
> Are these brackets really in the log message, or are they there for emphasis?
>
>> - Escaping dot characters solves the problem, \d+\.\d+\.\d+\.\d+ correctly
>
> \. matches any single character.
>
>> matches IP address, and for IP:UDPPORT you can use \d+\.\d+\.\d+\.\d+\:\d+.
>>
>> But placing all this tweakings in decoder and restarting ossec server did
>> not work, OSSIM always matches SRCIP like 0.0.0.0. In fact, I modified this
>> ossec as is the event seen in OSSIM UI when I run svwar:
>>
>
> For some reason I can't get the regex to work with the single quotes
> around the IP address.
>
>> 
>> 6201
>> No matching peer found
>> Login session failed (invalid extension).
>> invalid_login,
>> 
>>
>>
>> I´ll keep trying tomorrow, keep in touch please!
>>
>> Kind Regards,
>>
>> Daniel
>>
>> [1] https://sysbrain.wordpress.com/2010/05/24/asterisk-ossec-part-ii/
>>
>> 2015-02-09 20:21 GMT+01:00 dan (ddp) :
>>>
>>> On Mon, Feb 9, 2015 at 2:10 PM, Security 
>>> wrote:
>>> > Could be.
>>> > I don't know if I have to write to the dev mailing list to have it fixed
>>> > in
>>> > the next release.
>>> > I'm running my modified version on 3 asterisk instances and I'm very
>>> > happy
>>> > with the results.
>>> >
>>>
>>> Your best option is to open an issue on the github.
>>> https://github.com/ossec/ossec-hids
>>> If I remember I'll try to come up with a rule that covers both the old
>>> and new log samples we have.
>>>
>>> > Regards,
>>> >
>>> > Simon Gillet
>>> >
>>> > Le 9 févr. 2015 à 14:08, dan (ddp)  a écrit :
>>> >
>>> > On Sun, Feb 8, 2015 at 5:26 PM, Security 
>>> > wrote:
>>> >
>>> > Hello,
>>> >
>>> > I think the Asterisk rules could be wrong. Or at least for Ubuntu.
>>> > OSSEC always failed blocking brute force attempt on Asterisk.
>>> > A standart log entry for brute force attempt looks like:
>>> >
>>> > Dec 17 22:37:25 new asterisk[20110]: NOTICE[20127]: chan_sip.c:25030 in
>>> > handle_request_register: Registration from '"6100" '
>>> > failed for '85.25.110.243:5188' - Wrong password
>>> >
>>> >
>>> > This log sample is different than the one we were provided previously.
>>> >
>>> > I changed the rules in the decoder.xml files and I have no much better
>>> > results.
>>> >
>>> > Let me know if I'm wrong, I'm not a OSSEC expert but now I block the
>>> > brute
>>> > force attempts.
>>>

Re: [ossec-list] Asterisk rules for Ubuntu

[Daniel Calvo Castro]

Just today I´ve been experiencing same issues trying to get OSSIM + OSSEC
working with an asterisk box, I´ve followed this link [1], and trying to
enumerate users I´m able to correlate and fire mails correctly with OSSIM,
but UI always show $SRCIP 0.0.0.0 so seems useless to configure
post-actions like DROP $SRCIP.

Taking a look at the link provided, his log appears only to contain src IP,
like that:

May 19 11:42:17 asterisk asterisk[5200]: NOTICE[14808]: chan_sip.c:15889 in
handle_request_register: Registration from ‘”355″’
failed for ‘[[[192.168.210.48]]]’ – No matching peer found

You can see "failed for 'x.x.x.x' only

But seems like in recent versions like me ( stable Elastix  and ossec 2.8
), log says "failed for 'x.x.x.x:UDPPORT'  so I figured it could be some
regexp issue, time to check.

- log from post provided and default regexp in decoder.xml
"\d+.\d+.\d+.\d+" in regexpr.com correctly matches SRCIP but it fails, you
can try yourself:

May [[19 11:42:17] asterisk asterisk[5200]: NOTICE[14808]:
chan_sip.c:15889 in handle_request_register: Registration from
‘”355″’ failed for ‘192.168.210.48’ – No
matching peer found

- Escaping dot characters solves the problem, \d+\.\d+\.\d+\.\d+ correctly
matches IP address, and for IP:UDPPORT you can use \d+\.\d+\.\d+\.\d+\:\d+.

But placing all this tweakings in decoder and restarting ossec server did
not work, OSSIM always matches SRCIP like 0.0.0.0. In fact, I modified this
ossec as is the event seen in OSSIM UI when I run svwar:


6201
No matching peer found
Login session failed (invalid extension).
invalid_login,



I´ll keep trying tomorrow, keep in touch please!

Kind Regards,

Daniel

[1] https://sysbrain.wordpress.com/2010/05/24/asterisk-ossec-part-ii/

2015-02-09 20:21 GMT+01:00 dan (ddp) :

> On Mon, Feb 9, 2015 at 2:10 PM, Security 
> wrote:
> > Could be.
> > I don't know if I have to write to the dev mailing list to have it fixed
> in
> > the next release.
> > I'm running my modified version on 3 asterisk instances and I'm very
> happy
> > with the results.
> >
>
> Your best option is to open an issue on the github.
> https://github.com/ossec/ossec-hids
> If I remember I'll try to come up with a rule that covers both the old
> and new log samples we have.
>
> > Regards,
> >
> > Simon Gillet
> >
> > Le 9 févr. 2015 à 14:08, dan (ddp)  a écrit :
> >
> > On Sun, Feb 8, 2015 at 5:26 PM, Security 
> > wrote:
> >
> > Hello,
> >
> > I think the Asterisk rules could be wrong. Or at least for Ubuntu.
> > OSSEC always failed blocking brute force attempt on Asterisk.
> > A standart log entry for brute force attempt looks like:
> >
> > Dec 17 22:37:25 new asterisk[20110]: NOTICE[20127]: chan_sip.c:25030 in
> > handle_request_register: Registration from '"6100" '
> > failed for '85.25.110.243:5188' - Wrong password
> >
> >
> > This log sample is different than the one we were provided previously.
> >
> > I changed the rules in the decoder.xml files and I have no much better
> > results.
> >
> > Let me know if I'm wrong, I'm not a OSSEC expert but now I block the
> brute
> > force attempts.
> >
> > Regards,
> >
> > Simon Gillet
> >
> > I changed this rule:
> >
> > 
> >  asterisk
> >  ^NOTICE[\d+]: \S+ in \S+: Registration from 
> >  ^\S+ failed for
> '(\d+.\d+.\d+.\d+)'
> >  srcip
> > 
> >
> > To this one:
> >
> > 
> >  asterisk
> >  ^NOTICE[\d+]: \S+ in \S+: Registration from \S+ \S+
> >  ^failed for '(\S+):(\d+)'
> >  srcip,srcport
> > 
> >
> > And this rule:
> >
> > 
> >  asterisk
> >  Registration from 
> >  failed for '(\d+.\d+.\d+.\d+)'
> >  srcip
> > 
> >
> > To this one:
> >
> > 
> >  asterisk
> >  Registration from 
> >  failed for '(\S+):(\d+)'
> >  srcip,srcport
> > 
> >
> > --
> >
> > ---
> > You received this message because you are subscribed 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-l

[ossec-list] Email alerts for certain groups only not working...

[Daniel Kertby]

Hi,

We want to split notifications so that the right staff get the right alerts.

As I understood it, email_to is required in the global section of 
ossec.conf (why not optionally?). We don't want all alerts to one address, 
so we created a dummy email address on our
mail gateway. 

# BELOW WORKS


  
yes
ip-address
user@system
ossec-email-dummy@mail_gateway
yes
  

# BELOW WORKS

   
secure-gateway
network_guy@domain
   

   
netscreenfw
network_guy@domain
   

# BELOW DOESN*T WORK

   
syslog
system_admin@domain
   

   
local
system_admin@domain
   


Assistance how to get the local,syslog group alerts emailed to 
system_admin@domain would be appreciated since I don't get it to work.


Regards,
Daniel




-- 

--- 
You received this message because you are subscribed 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: Decoders and rules for Juniper SA2500 and Juniper SSG-320M

[Daniel Kertby]

Ok, an update.

I got the default decoder for Netscreen to work even for the SSG-320M by 
removing line 1128 (  ) in decoder.xml. This doesn't seem 
to work with the logs where
the date is provided in parenthesis at the end of the line.

For the SA2500 secure gateway, I created a decoder which seems to work. 
It's probably not a beauty but it seems to work at least. 

local_decoder.xml
=

  ^Juniper: \d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d - \w\w-\d\d - 

  [ (\S+) ] (\S+) [] - 
  srcip, user



  sa2500
  (\S+) : (\S+)
  action, data




Corresponding rule which tags everything alert lever 12. A good start for 
further development and gives a head up to react.

local_rules.xml

  
sa2500
Alert from the SA2500 Secure Gateway
  


Suggestions how to improve the work above is appreciated but remember - Im 
a newbie on writing this stuff..

Regards,
Daniel

 

On Thursday, April 3, 2014 10:13:39 PM UTC+2, Daniel Kertby wrote:
>
> Hi people,
>
> Anyone have decoders and rule for the SA2500 and the SSG-320M and would 
> like to share their work?
>
> Anything is more than nothing for me, thanks! :)
>
> Regards,
> Daniel
>

-- 

--- 
You received this message because you are subscribed 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] Decoders and rules for Juniper SA2500 and Juniper SSG-320M

[Daniel Kertby]

Hi people,

Anyone have decoders and rule for the SA2500 and the SSG-320M and would
like to share their work?

Anything is more than nothing for me, thanks! :)

Regards,
Daniel

-- 

--- 
You received this message because you are subscribed 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] Netscreen Firewall Logs

[Daniel Kertby]

Hi again,
sorry for a delayed reply.
I had accidentally installed 2.6 but upgraded to 2.7.1.
Still got the same issue though...

Im home but appreciate feedback how to continue troubleshoot the issue...

/Daniel


On Wed, Apr 2, 2014 at 3:01 PM, dan (ddp)  wrote:

> On Wed, Apr 2, 2014 at 8:50 AM, Daniel Kertby  wrote:
> > Sorry for the confusion, the # hashes where putted there by me to
> masquerade
> > hostnames/ip's.
> >
> > I tried the ossec-logtest now and pasted infro from "NetScreen
> device_id=",
> > skipped the first part of the info the archives.log file, a bit unsure
> what
> > should be included.
> >
> >
> ---
> >
> > 2014/04/02 01:01:01 ossec-testrule: INFO: Started (pid: 29953).
> > ossec-testrule: Type one log per line.
> >
> >
> > NetScreen device_id=  [Root]system-warning-00518: Admin
> > user "theuser" login attempt for Web(https) management (port 47873) from
> > :54031 failed. (2014-04-02 00:01:01)
> >
> >
> > **Phase 1: Completed pre-decoding.
> >full event: 'NetScreen device_id=
> > [Root]system-warning-00518: Admin user "" login attempt for
> > Web(https) management (port 47873) from :54031 failed.
> > (2014-04-02 00:01:01)'
> >hostname: ''
> >program_name: '(null)'
> >log: 'NetScreen device_id=
> > [Root]system-warning-00518: Admin user "" login attempt for
> > Web(https) management (port 47873) from :54031 failed.
> > (2014-04-02 00:01:01)'
> >
> > **Phase 2: Completed decoding.
> >No decoder matched.
> >
>
> So it isn't getting decoded properly. The first step in tracking down
> the issue is to find out why it isn't being decoded.
> It looks like the version of OSSEC in the ancient post you replied to
> decoded it. What version of OSSEC are you using?
>
> > **Phase 3: Completed filtering (rules).
> >Rule id: '1002'
> >Level: '2'
> >Description: 'Unknown problem somewhere in the system.'
> > **Alert to be generated.
> >
> >
> >
> ---
> >
> >
> > On Wednesday, April 2, 2014 1:57:53 PM UTC+2, dan (ddpbsd) wrote:
> >>
> >>
> >> On Apr 2, 2014 7:54 AM, "Daniel Kertby"  wrote:
> >> >
> >> > Hi all,
> >> >
> >> > Im experience the same issue when trying to setup ossec monitoring
> for a
> >> > Juniper Netscreen SSG-320M.
> >> > Failed web user login is hitting the 1002 rule, info from archives.log
> >> > provided below:
> >> >
> >> > 014 Apr 02 23:59:59 #ossec-hostname# -> #FW_IP# #FW_hostname#:
> NetScreen
> >> > device_id=#FW_hostname#  [Root]system-warning-00518: Admin user
> "#username#"
> >> > login attempt for Web(https) management (port 47873) from
> #client_IP#:54031
> >> > failed. (2014-04-02 23:59:59)
> >> >
> >>
> >> Maybe it's the hashes?
> >> Have you tried using ossec-logtest to see how ossec is parsing the log
> >> message?
> >>
> >> > Any help appreciated!
> >> >
> >> > Regards,
> >> > Daniel
> >> >
> >> > On Thursday, August 16, 2012 2:52:42 PM UTC+2, dan (ddpbsd) wrote:
> >> >>
> >> >> On Thu, Aug 16, 2012 at 6:48 AM, oorhan  wrote:
> >> >> > hi Dan,
> >> >> >
> >> >> > Thank you for your reply.
> >> >> >
> >> >> > The original netscreen log message has timestamp. Log is taken from
> >> >> > another
> >> >> > syslog server.
> >> >> >
> >> >>
> >> >>
> >> >> According to your alert.log entry the log message does not have a
> >> >> timestamp.
> >> >>
> >> >> An example of an alert.log entry complete with a timestamp:
> >> >> ** Alert 1336394319.2684: - syslog,sudo
> >> >> 2012 May 07 08:38:39 arrakis->/var/log/secure
> >> >> Rule: 5402 (level 3) -> 'Successful sudo to ROOT executed'
> >> >> User: ddp
> >> >> 2012-05-07T08

Re: [ossec-list] Netscreen Firewall Logs

[Daniel Kertby]

Sorry for the confusion, the # hashes where putted there by me to 
masquerade hostnames/ip's.

I tried the ossec-logtest now and pasted infro from "NetScreen device_id=", 
skipped the first part of the info the archives.log file, a bit unsure what 
should be included.

---

   2014/04/02 01:01:01 ossec-testrule: INFO: Started (pid: 29953).
   ossec-testrule: Type one log per line.


   NetScreen device_id=  [Root]system-warning-00518: 
   Admin user "theuser" login attempt for Web(https) management (port 47873) 
   from :54031 failed. (2014-04-02 00:01:01)


   **Phase 1: Completed pre-decoding.
  full event: 'NetScreen device_id= 
[Root]system-warning-00518: Admin user "" login attempt for 
   Web(https) management (port 47873) from :54031 failed. 
   (2014-04-02 00:01:01)'
  hostname: ''
  program_name: '(null)'
  log: 'NetScreen device_id= 
[Root]system-warning-00518: Admin user "" login attempt for 
   Web(https) management (port 47873) from :54031 failed. 
   (2014-04-02 00:01:01)'

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

---
 

On Wednesday, April 2, 2014 1:57:53 PM UTC+2, dan (ddpbsd) wrote:
>
>
> On Apr 2, 2014 7:54 AM, "Daniel Kertby" > 
> wrote:
> >
> > Hi all,
> >
> > Im experience the same issue when trying to setup ossec monitoring for a 
> Juniper Netscreen SSG-320M.
> > Failed web user login is hitting the 1002 rule, info from archives.log 
> provided below:
> >
> > 014 Apr 02 23:59:59 #ossec-hostname# -> #FW_IP# #FW_hostname#: NetScreen 
> device_id=#FW_hostname#  [Root]system-warning-00518: Admin user 
> "#username#" login attempt for Web(https) management (port 47873) from 
> #client_IP#:54031 failed. (2014-04-02 23:59:59)
> >
>
> Maybe it's the hashes?
> Have you tried using ossec-logtest to see how ossec is parsing the log 
> message?
>
> > Any help appreciated!
> >
> > Regards,
> > Daniel
> >
> > On Thursday, August 16, 2012 2:52:42 PM UTC+2, dan (ddpbsd) wrote:
> >>
> >> On Thu, Aug 16, 2012 at 6:48 AM, oorhan  wrote: 
> >> > hi Dan, 
> >> > 
> >> > Thank you for your reply. 
> >> > 
> >> > The original netscreen log message has timestamp. Log is taken from 
> another 
> >> > syslog server. 
> >> > 
> >>
> >>
> >> According to your alert.log entry the log message does not have a 
> timestamp. 
> >>
> >> An example of an alert.log entry complete with a timestamp: 
> >> ** Alert 1336394319.2684: - syslog,sudo 
> >> 2012 May 07 08:38:39 arrakis->/var/log/secure 
> >> Rule: 5402 (level 3) -> 'Successful sudo to ROOT executed' 
> >> User: ddp 
> >> 2012-05-07T08:38:38.338172-04:00 arrakis sudo:  ddp : TTY=ttyp1 ; 
> >> PWD=/home/ddp ; USER=root ; COMMAND=/sbin/ifconfig em0 down 
> >>
> >>
> >> You can enable the logall option to make sure though. 
> >>
> >> Looking at the sample you gave me though (the one in alerts.log since 
> >> I don't trust the other one), I can see why it isn't decoded as a 
> >> netscreen entry.  The decoder thinks the first parts of the log will 
> >> be "NetScreen device_id." In your sample it starts with: "SSG350M: 
> >> NetScreen device_id." So find out why the SSG350M is showing up 
> >> instead of a timestamp and you should be golden. 
> >>
> >> Otherwise if the log sample you provided is incorrect, post a sample 
> >> from the archives.log so we can try and track this down. 
> >>
> >>
> >> > 
> >> > " 
> >> > 
> >> > Aug 15 10:30:14 136.10.247.130 SSG350M: NetScreen 
> device_id=Juniper111 
> >> > [Root]system-warning-00518: Admin user "userid" login attempt for 
> Web(http) 
> >> > management (port 20480) from 1.1.1.1:22560 failed. (2012-08-15 
> 11:33:36) 
> >> > 
> >> > " 
> >> > 
> >> > Log message on your test was a part of alert.lo

Re: [ossec-list] Netscreen Firewall Logs

[Daniel Kertby]

Hi all,

Im experience the same issue when trying to setup ossec monitoring for a 
Juniper Netscreen SSG-320M.
Failed web user login is hitting the 1002 rule, info from archives.log 
provided below:

014 Apr 02 23:59:59 #ossec-hostname# -> #FW_IP# #FW_hostname#: NetScreen 
device_id=#FW_hostname#  [Root]system-warning-00518: Admin user 
"#username#" login attempt for Web(https) management (port 47873) from 
#client_IP#:54031 failed. (2014-04-02 23:59:59)

Any help appreciated!

Regards,
Daniel

On Thursday, August 16, 2012 2:52:42 PM UTC+2, dan (ddpbsd) wrote:
>
> On Thu, Aug 16, 2012 at 6:48 AM, oorhan > 
> wrote: 
> > hi Dan, 
> > 
> > Thank you for your reply. 
> > 
> > The original netscreen log message has timestamp. Log is taken from 
> another 
> > syslog server. 
> > 
>
>
> According to your alert.log entry the log message does not have a 
> timestamp. 
>
> An example of an alert.log entry complete with a timestamp: 
> ** Alert 1336394319.2684: - syslog,sudo 
> 2012 May 07 08:38:39 arrakis->/var/log/secure 
> Rule: 5402 (level 3) -> 'Successful sudo to ROOT executed' 
> User: ddp 
> 2012-05-07T08:38:38.338172-04:00 arrakis sudo:  ddp : TTY=ttyp1 ; 
> PWD=/home/ddp ; USER=root ; COMMAND=/sbin/ifconfig em0 down 
>
>
> You can enable the logall option to make sure though. 
>
> Looking at the sample you gave me though (the one in alerts.log since 
> I don't trust the other one), I can see why it isn't decoded as a 
> netscreen entry.  The decoder thinks the first parts of the log will 
> be "NetScreen device_id." In your sample it starts with: "SSG350M: 
> NetScreen device_id." So find out why the SSG350M is showing up 
> instead of a timestamp and you should be golden. 
>
> Otherwise if the log sample you provided is incorrect, post a sample 
> from the archives.log so we can try and track this down. 
>
>
> > 
> > " 
> > 
> > Aug 15 10:30:14 136.10.247.130 SSG350M: NetScreen device_id=Juniper111 
> > [Root]system-warning-00518: Admin user "userid" login attempt for 
> Web(http) 
> > management (port 20480) from 1.1.1.1:22560 failed. (2012-08-15 
> 11:33:36) 
> > 
> > " 
> > 
> > Log message on your test was a part of alert.log. 
> > 
> > here is my Logtest results..but we are still unable to decode it. Any 
> idea? 
> > 
> > 
> > Aug 15 10:30:14 136.10.247.130 SSG350M: NetScreen device_id=Juniper111 
> > [Root]system-warning-00518: Admin user "userid" login attempt for 
> Web(http) 
> > management (port 20480) from 1.1.1.1:22560 failed. (2012-08-15 
> 11:33:36) 
> > 
> > 
> > **Phase 1: Completed pre-decoding. 
> >full event: 'Aug 15 10:30:14 136.10.247.130 SSG350M: NetScreen 
> > device_id=Juniper111  [Root]system-warning-00518: Admin user "userid" 
> login 
> > attempt for Web(http) management (port 20480) from 1.1.1.1:22560failed. 
> > (2012-08-15 11:33:36)' 
> >hostname: '136.10.247.130' 
> > 
> >program_name: 'SSG350M' 
> >log: 'NetScreen device_id=Juniper111  [Root]system-warning-00518: 
> > Admin user "userid" login attempt for Web(http) management (port 20480) 
> from 
> > 1.1.1.1:22560 failed. (2012-08-15 11:33:36)' 
> > 
> > **Phase 2: Completed decoding. 
> >decoder: 'netscreenfw' 
> >action: 'warning' 
> >id: '00518' 
> > 
>
> Looks like it's being decoded to me. I must be misunderstanding something. 
>
> > **Phase 3: Completed filtering (rules). 
> >Rule id: '4502' 
> >Level: '9' 
> >Description: 'Netscreen warning message.' 
> > **Alert to be generated. 
> > 
> > 
> > 
> > 
> > 15 Ağustos 2012 Çarşamba 16:20:34 UTC+3 tarihinde dan (ddpbsd) yazdı: 
> >> 
> >> On Wed, Aug 15, 2012 at 7:03 AM, Ozgur Orhan  
> wrote: 
> >> > 
> >> > 
> >> > 
> >> > Hi All, 
> >> > 
> >> > 
> >> > 
> >> > We have issues configuring Ossec server to receive Netscreen firewall 
> >> > logs. Logs are decoded as syslog not netscreen firewall. 
> >> > 
> >> > 
> >> > 
> >> > Here are my configuration steps; 
> >> > 
> >> > First, firewalls are configured sending audit logs via syslog. 
> >> > 
> >> > We changed ossec.conf file as below to allow syslog; 
> >&

Re: [ossec-list] Error 1203

[Daniel]

How were you able to recreate the user and group? I am having a new 
installation on my personal machine to test run things and I am having the 
same issue you did, except I haven't been able to have my agent run at all! 
Can't imagine how the user/group were deleted. Any insight would be a great 
help! 

On Thursday, 8 December 2011 10:26:02 UTC-5, PS wrote:
>
> No problem. I was able to start the agent after recreating the user and 
> group. Thanks!
>
> Victor Pineiro
>
>
> On Dec 8, 2011, at 10:07 AM, "dan (ddp)" > 
> wrote:
>
> > On Thu, Dec 8, 2011 at 10:04 AM, PS > 
> wrote:
> >> So it looks like the user ossec and group ossec where deleted. I can 
> see in
> >> syslog where it says that userdel was used to delete user 'ossec'
> >> 
> >> I am not sure what did it. It had to be some script. Is there a way for 
> me
> >> to find out what did it?
> >> 
> >> I am the only person who manages this server.
> >> 
> >> The syslog entry looks like this:
> >> Dec 4 23:48:53 system userdel[2558]: delete user 'ossec'
> >> 
> >> I'm not sure how to tie that event to a process or script that may have 
> done
> >> it.
> >> 
> > 
> > You can look through the logs to see what was going on, and I guess
> > check through the scripts on your system for something that would
> > delete users.
> > 
> >> Thanks!
> >> 
> >> Victor Pineiro
> >> Sent from my iPad
> >> 
> >> On Dec 8, 2011, at 6:28 AM, "dan (ddp)" > 
> wrote:
> >> 
> >> What happened to your ossec group?
> >> 
> >> On Dec 8, 2011 6:02 AM, "PS" > wrote:
> >>> 
> >>> Hello list,
> >>> 
> >>> I am seeing error 1203 when attempting to run any of the scripts from 
> the
> >>> "/var/ossec/bin" folder.
> >>> 
> >>> I have looked around for a fix and have not been able to find one. I 
> have
> >>> seen that a couple of other people have had the same issue. When I 
> first
> >>> installed it, I was able to start the agent and it was sending events 
> to the
> >>> server. I just happened to look at the server and noticed that the 
> agent was
> >>> disconnected. Nothing has changed since installation. Any clues?
> >>> 
> >>> [root@system bin]# ./ossec-control start
> >>> Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
> >>> 2011/12/08 07:51:49 ossec-execd(1203): ERROR: Invalid user '' or group
> >>> 'ossec' given.
> >>> 
> >>> [root@system bin]# ./manage_agents -l
> >>> 2011/12/08 07:51:51 manage_agents(1203): ERROR: Invalid user '' or 
> group
> >>> 'ossec' given.
> >>> 
> >>> -r-xr-x--- 1 root 500 222857 Dec  4 08:32 agent-auth
> >>> -r-xr-x--- 1 root 500 297452 Dec  4 08:32 manage_agents
> >>> -r-xr-x--- 1 root 500 550237 Dec  4 08:32 ossec-agentd
> >>> -r-xr-x--- 1 root 500   4647 Jul 11 21:36 ossec-control
> >>> -r-xr-x--- 1 root 500 103724 Dec  4 08:32 ossec-execd
> >>> -r-xr-x--- 1 root 500 380464 Dec  4 08:32 ossec-logcollector
> >>> -r-xr-x--- 1 root 500 506300 Dec  4 08:32 ossec-syscheckd
>
>

-- 

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

[ossec-list] Re: Ossec agent ossec.conf issue

[Daniel Jochims]

I know that they are not there, but I keep them in the config for older 
servers that will still have those files/paths. The errors are not my 
problem, I'm just looking for what other peoples ossec.conf on their agent 
look like. I'm trying to get a perspective on other files that they may be 
monitoring on that I currently am not. An example is how I'm trying to 
monitor bcdedit.exe. That file was the replacement for boot.ini in newer 
windows operating systems. I'm just not getting it implemented correctly, 
which is why im looking for a more experienced persons agents ossec.conf 
file to base rules off of.

On Friday, July 5, 2013 9:29:52 AM UTC-5, David Blanton wrote:

> If you've removed those paths/directories to being monitored, try 
> restarting OSSEC and the agent as well.
>
> /var/ossec/bin/agent_control -R ### 
>

-- 

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

[ossec-list] Ossec agent ossec.conf issue

[Daniel Jochims]

I'm trying to set up ossec agents on windows server 03/08/12. Would anybody 
have an example custom ossec.conf agent file they could share? I know that 
newer windows servers do not have all the files that are originally listed 
in the default ossec.conf , so i was wondering what others have started to 
monitor in place of them.
 
 
Checking my agent log, this is what I'm getting with the default agent 
ossec.conf :

2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\boot.ini': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/CONFIG.NT': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/AUTOEXEC.NT': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/debug.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/drwatson.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/drwtsn32.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/edlin.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/eventtriggers.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/rcp.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/rexec.exe': No such file or directory 
2013/07/03 13:01:23 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/rsh.exe': No such file or directory 
2013/07/03 13:01:25 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/telnet.exe': No such file or directory 
2013/07/03 13:01:25 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/tftp.exe': No such file or directory 
2013/07/03 13:01:25 ossec-agent: WARN: Error opening directory: 
'C:\Windows/System32/tlntsvr.exe': No such file or directory 
2013/07/03 13:01:25 ossec-agent: WARN: Error opening directory: 
'C:\Windows\System32\bcdedit.exe': No such file or directory 
2013/07/03 13:01:25 ossec-agent: INFO: Finished creating syscheck database 
(pre-scan completed).
 
 
An example of what I'm trying to do would be :
 
C:\Windows\System32\bcdedit.exe
 
boot.ini was replaced in windows vista+ with BCD so this would be something 
I'd like to check on. I tried to implement this into the conf file but I'm 
getting no luck getting it to work. 
 
Any suggestions are gladly taken.

-- 

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

Re: [ossec-list] White-list for certain agent using Agent.conf && Twitter to Ossec

[Daniel Cid]

Twitter changed their authentication method and doesn't allow what we were
doing with ossec-tweeter. It would have to be
re-written to support oauth.

thanks,


On Thu, Apr 4, 2013 at 9:50 AM, Jeroen van Doorenmalen <
jeroen.van.doorenma...@gmail.com> wrote:

> Hello guys,
>
> I'm having some kind of trouble trying use the
> /var/ossec/etc/shared/agent.conf file.
>
> We want to make use of agent.conf so we can make configurations for
> specific agents locally on the ossec server. Now i'm trying to make a
> white-list for a certain agent for example
>
> 
>
>192.168.164.1
>
>
>   
> apache
> /var/log/apache2/error.log
>   
>
>   
> apache
> /var/log/apache2/access.log
>   
>
> 
>
> This should white-list 192.168.164.1 for the ossec client. Which means
> 192.168.164.1 will not trigger active-response.
> Though we made this configuration. When we test this configuration
> active-response still drops the connection between the two.
>
> The only way i found out to white-list 192.168.164.1 is to add the
> white-list locally to the agent's ossec,conf.
>
> How can i use the Agent.conf file to white-list 192.168.164.1 for a
> specific agent? Or perhaps using a different way.
>
>
>
> Twitter to ossec.
>
> Second problem we are having is using the Ossec to twitter option. We
> should be possible to send the alerts which pop up to a certain twitter
> account. When we try to do this we get a certain error. Does anyong know
> more about this?
>
> Thu Apr  4 05:45:15 PDT 2013
> /var/ossec/active-response/bin/ossec-tweeter.sh
> --2013-04-04 05:45:15--  http://twitter.com/statuses/update.xml
> Resolving twitter.com (twitter.com)... 199.59.150.39, 199.59.149.230,
> 199.59.148.82
> Connecting to twitter.com (twitter.com)|199.59.150.39|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://twitter.com/statuses/update.xml [following]
>
> --2013-04-04 05:45:17--  https://twitter.com/statuses/update.xml
> Connecting to twitter.com (twitter.com)|199.59.150.39|:443... connected.
> HTTP request sent, awaiting response... 401 Unauthorized
> Unknown authentication scheme.
> Authorization failed.
>
> P.S. To test this we are using a VMWare virtual Ubuntu 12.10 Server
>
> Kind regards, Jeroen
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

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

Re: [ossec-list] Ossec 2.6 Compile errors on Mac Os 10.7.3

[Daniel]

How is it you do this? 

On Friday, 27 April 2012 14:49:09 UTC-4, dan (ddpbsd) wrote:
>
> Use the real gcc instead of Apple's llvm/clang/whatever it is these days. 
>
> On Fri, Apr 27, 2012 at 2:18 PM, Gappa > 
> wrote: 
> > hi everyone, 
> > i'm trying to install ossec on my Mac. 
> > 
> > I get this error: 
> > 
> > gcc -g -Wall -I../../ -I../../headers  -DDEFAULTDIR=\"/var/ossec\" 
> > -DUSE_OPENSSL -DDarwin -DHIGHFIRST-DARGV0=\"sha1_op\" 
> -DXML_VAR=\"var\" 
> > -DOSSECHIDS -c sha1_op.c 
> > 
> > In file included from sha1_op.c:27: 
> > 
> > sha_locl.h: In function ‘sha1_block_host_order’: 
> > 
> > sha_locl.h:261: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:261: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:262: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:262: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > ……….. 
> > 
> > ………. 
> > 
> > sha_locl.h:344: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:345: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:345: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > sha_locl.h:345: error: unsupported inline asm: input constraint with a 
> > matching output constraint of incompatible type! 
> > 
> > make[2]: *** [sha1] Error 1 
> > 
> > make[1]: *** [os_crypto] Error 2 
> > 
> > 
> > I searched for some prerequisites to install on the Mac and i only found 
> > XCode, i have it. 
> > 
> > Can anyone help me with this error? 
> > 
> > Thanks 
> > 
> > Gappa 
>

-- 

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

Re: [ossec-list] recover SERVER keys?

[Daniel Cid]

Yes, just get the client.keys from all the agents and make a single
client.keys file on the
server with all of them.

The issue is the remote message ids, that you will need to clear on
each agent (delete the rids directory)
or the agents will not accept the messages from the manager.

thanks,

--
Daniel B. Cid
http://dcid.me

On Thu, Feb 14, 2013 at 2:13 PM, Kat  wrote:
> Well - it happened - I lost a server (hardware raid failure and corrupted
> drives).
> So here is the question - all the agents have keys, but I lost the other end
> - is there ANY way to rebuild a server from this sort of thing and recover?
>
> I can't think of anything, since it is all built around the original server
> key (lost), but it never hurts to ask..
>
> And before you all yell at me about backups -- yes, I know. All my other
> systems are backed up, just not this one. :-(
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 

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

Re: [ossec-list] Monitoring command output check_diff is getting mixed up.

[Daniel Cid]

Hi Brenden,

In your initial rule, the match syntax was wrong:

ossec: output: 'wget -o /dev/null -O -
http\//www.unruleable.org/blog/ | sha1sum'

OSSEC was actually looking for the string sha1sum OR the command
output name ( | sha1sum we treat as a
separator).

As for the key, we use the rule id as the storage key, so you would
need a different rule for each
one of those sites.

thanks,

--
Daniel B. Cid
http://dcid.me

On Fri, Dec 7, 2012 at 2:47 PM, Brenden Walker  wrote:
> On Fri, 7 Dec 2012 13:18:33 -0500 "dan (ddp)"  wrote:
>> On Fri, Dec 7, 2012 at 12:47 PM, Brenden Walker
>>  wrote:
>> > On Fri, 7 Dec 2012 12:31:24 -0500 "dan (ddp)" 
>> > wrote:
>> >> On Fri, Dec 7, 2012 at 12:22 PM, Brenden Walker
>> >>  wrote:
>> >> > I'm trying to monitor a few websites for changes, I followed some
>> >> > examples online other than needing to change http:\\ to http/\\
>> >> > in the match (that's how it appears in archives.log):
>> >> >
>> >> >
>> >> > Added to ossec.conf
>> >> >
>> >> >   
>> >> > full_command
>> >> > wget -o /dev/null -O - http://www.poxodd.com |
>> >> > sha1sum 7200
>> >> >   
>> >> >   
>> >> > full_command
>> >> > wget -o /dev/null -O -
>> >> > http://www.unruleable.org/blog/ | sha1sum
>> >> > 7200 
>> >> >
>> >>
>> >> Use es to better differentiate between these commands.
>> >
>> > Figures I was missing something simple.  Any idea how ossec
>> > differentiates these?  When I changed my config to a call to
>> > checksites.sh I got this:
>> >
>> > Received From: goonsquad->/opt/ossec/checksites.sh
>> > Rule: 150013 fired (level 10) -> "Website change detected"
>> > Portion of the log(s):
>> >
>> > ossec: output: '/opt/ossec/checksites.sh':
>> > www.poxodd.com
>> > 9506ac8e36f9727c2567d7ee90d117cb557b24d9  -
>> > www.unruleable.org/blog/
>> > 81ddc99e3c2ee60518a3b219f561117185284bf0  -
>> > www.diablops.com
>> > 83626f4b502af0e55329cc6634078b6bf7ca2443  -
>> > gta.diablps.com
>> > 68e498cf5f10bef32d8fc0a0b4e9ffbc79832861  -
>> > Previous output:
>> > ossec: output: 'wget -o /dev/null -O - http\//gta.diablops.com |
>> > sha1sum': 58aaa26e0e263ced83260b07abba280b84d3df39  -
>> >
>> >
>> > Which leads me to believe that an alias is required for command
>> > output entries, otherwise they'd all get muddled up??
>>
>> I'm fighting a horrible headache at the moment, so I'm probably
>> missing something simple here.
>>
>> Originally you had 3 commands, all of them the same except for a small
>> bit. Since the differences were deep enough into the command the
>> output was getting mixed up. So did adding an alias to each of those
>> commands help?
>>
>> When the commands aren't basically the same they don't get mixed up. I
>> personally think aliases make things easier, so I always use them.
>
>
> I changed the discreet command checks into a single call to a shell script. 
> AND aliased it (I agree, good idea there).  I figured that it would be better 
> this way as I can simply add a site to the check script (sure it'll give me 
> an initial alert when I change, but that's good).
>
> What I find weird is that it compared the previous output from this no longer 
> existing  section:
>
>   
>  full_command
>  wget -o /dev/null -O - http://www.poxodd.com | 
> sha1sum 7200
>  7200
>   
>
> With this new and completely un-related  section:
>
>   
> web_modifications
> full_command
> /opt/ossec/checksites.sh
> 7200
>   
>
>
> I removed the per site  sections.  What I can't figure out is what 
> ossec is using as a key to previous command output?  It's certainly using 
> nothing in the  section as these two have nothing in common there.  
> Which is why I suspect that alias is really required, or this is a simple bug.
>
>

Re: [ossec-list] Problem with rule 35051

[Daniel Requena]

I asked for regex, because there are alot of website "variations" like:
facebook.com:443, static.ak.facebook.com,
facebook.com/plugins/-alot_of_chars, etc...
Thanks for your help.


2012/12/6 dan (ddp) 

> On Tue, Dec 4, 2012 at 11:15 AM, Daniel Requena  wrote:
> > Thank you!
> > I'm pretty sure I already tried the 35005 "interception" approach, but
> I'll
> > try again.
> > Just for the record, is it possible to "match" multiple sites on a single
> > rule, like this? Or even using a regex?
> >
>
> The pipe ("|") should work, regex doesn't help.
>
> >
> >   
> > 35005
> >
> > facebook.com|facebook.com:443|static.facebook.com
> |...etc...
> >
> > ignore facebook
> >   
> >
> >  Regards.
> >
> >
> > 2012/12/4 dan (ddp) 
> >
> >> On Tue, Dec 4, 2012 at 7:30 AM, Daniel Requena 
> wrote:
> >> > Hi
> >> >
> >> >Just extracted from squid access.log
> >> >
> >> > 1354623033.296  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> >> > s-static.ak.facebook.com:443 - NONE/- text/html
> >> > 1354623033.297  1 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> >> > s-static.ak.facebook.com:443 - NONE/- text/html
> >> > 1354623033.297  1 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> >> > www.facebook.com:443 - NONE/- text/html
> >> > 1354623033.298  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> >> > www.facebook.com:443 - NONE/- text/html
> >> > 1354623033.299  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> >> > s-static.ak.facebook.com:443 - NONE/- text/html
> >> > 1354623033.299  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> >> > www.facebook.com:443 - NONE/- text/html
> >> > 1354623033.303  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> >> > www.facebook.com:443 - NONE/- text/html
> >> >
> >> >  This is the alert that is generated from it:
> >> >
> >> > Received From: (proxy) 10.0.0.55->/var/log/squid/access.log
> >> > Rule: 35051 fired (level 10) -> "Multiple attempts to access forbidden
> >> > file
> >> > or directory from same source ip."
> >> > Portion of the log(s):
> >> >
> >>
> >> Ok, that rule fires due to multiple alerts. So if we ignore the
> >> original alert, this one won't fire.
> >>
> >> This is from a fairly basic 2.7:
> >> # cat /tmp/f  | /var/ossec/bin/ossec-logtest
> >> 2012/12/04 08:49:44 ossec-testrule: INFO: Reading local decoder file.
> >> 2012/12/04 08:49:44 ossec-testrule: INFO: Started (pid: 29617).
> >> ossec-testrule: Type one log per line.
> >>
> >>
> >>
> >> **Phase 1: Completed pre-decoding.
> >>full event: '1354623033.296  0 10.0.0.202 TCP_DENIED/403
> >> 3789 CONNECT s-static.ak.facebook.com:443 - NONE/- text/html'
> >>hostname: 'arrakis'
> >>program_name: '(null)'
> >>log: '0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> >> s-static.ak.facebook.com:443 - NONE/- text/html'
> >>
> >> **Phase 2: Completed decoding.
> >>decoder: 'squid-accesslog'
> >>srcip: '10.0.0.202'
> >>action: 'TCP_DENIED'
> >>id: '403'
> >>url: 's-static.ak.facebook.com:443'
> >>
> >> **Phase 3: Completed filtering (rules).
> >>Rule id: '35005'
> >>Level: '5'
> >>Description: 'Forbidden: Attempt to access forbidden file or
> >> directory.'
> >> **Alert to be generated.
> >>
> >>
> >> So we need to ignore 35005. Let's try this:
> >>
> >>   
> >> 35005
> >> facebook.com
> >> ignore facebook
> >>   
> >>
> >> Your match was ".facebook.com/," but this does not
> >> appear in the log messages you provided.
> >>
> >> So the logtest output with the new rule:
> >> # cat /tmp/f  | /var/ossec/bin/ossec-logtest
> >> 2012/12/04 08:51:31 ossec-testrule: INFO: Reading local decoder file.
> >> 2012/12/04 08:51:31 ossec-testrule: INFO: Started (pid: 25432).
> >> ossec-testrule: Type one log per line.
> >>
> >>
> >>
> >> **Phase 1: Completed pre-decoding.
&g

Re: [ossec-list] Problem with rule 35051

[Daniel Requena]

Thank you!
I'm pretty sure I already tried the 35005 "interception" approach, but I'll
try again.
Just for the record, is it possible to "match" multiple sites on a single
rule, like this? Or even using a regex?

  
35005
facebook.com|facebook.com:443| <http://facebook.com>
static.facebook.com|...etc...
ignore facebook
  

 Regards.


2012/12/4 dan (ddp) 

> On Tue, Dec 4, 2012 at 7:30 AM, Daniel Requena  wrote:
> > Hi
> >
> >Just extracted from squid access.log
> >
> > 1354623033.296  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> > s-static.ak.facebook.com:443 - NONE/- text/html
> > 1354623033.297  1 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> > s-static.ak.facebook.com:443 - NONE/- text/html
> > 1354623033.297  1 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> > www.facebook.com:443 - NONE/- text/html
> > 1354623033.298  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> > www.facebook.com:443 - NONE/- text/html
> > 1354623033.299  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> > s-static.ak.facebook.com:443 - NONE/- text/html
> > 1354623033.299  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> > www.facebook.com:443 - NONE/- text/html
> > 1354623033.303  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT
> > www.facebook.com:443 - NONE/- text/html
> >
> >  This is the alert that is generated from it:
> >
> > Received From: (proxy) 10.0.0.55->/var/log/squid/access.log
> > Rule: 35051 fired (level 10) -> "Multiple attempts to access forbidden
> file
> > or directory from same source ip."
> > Portion of the log(s):
> >
>
> Ok, that rule fires due to multiple alerts. So if we ignore the
> original alert, this one won't fire.
>
> This is from a fairly basic 2.7:
> # cat /tmp/f  | /var/ossec/bin/ossec-logtest
> 2012/12/04 08:49:44 ossec-testrule: INFO: Reading local decoder file.
> 2012/12/04 08:49:44 ossec-testrule: INFO: Started (pid: 29617).
> ossec-testrule: Type one log per line.
>
>
>
> **Phase 1: Completed pre-decoding.
>full event: '1354623033.296  0 10.0.0.202 TCP_DENIED/403
> 3789 CONNECT s-static.ak.facebook.com:443 - NONE/- text/html'
>hostname: 'arrakis'
>program_name: '(null)'
>log: '0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> s-static.ak.facebook.com:443 - NONE/- text/html'
>
> **Phase 2: Completed decoding.
>decoder: 'squid-accesslog'
>srcip: '10.0.0.202'
>action: 'TCP_DENIED'
>id: '403'
>url: 's-static.ak.facebook.com:443'
>
> **Phase 3: Completed filtering (rules).
>Rule id: '35005'
>Level: '5'
>Description: 'Forbidden: Attempt to access forbidden file or
> directory.'
> **Alert to be generated.
>
>
> So we need to ignore 35005. Let's try this:
>
>   
> 35005
> facebook.com
> ignore facebook
>   
>
> Your match was ".facebook.com/," but this does not
> appear in the log messages you provided.
>
> So the logtest output with the new rule:
> # cat /tmp/f  | /var/ossec/bin/ossec-logtest
> 2012/12/04 08:51:31 ossec-testrule: INFO: Reading local decoder file.
> 2012/12/04 08:51:31 ossec-testrule: INFO: Started (pid: 25432).
> ossec-testrule: Type one log per line.
>
>
>
> **Phase 1: Completed pre-decoding.
>full event: '1354623033.296  0 10.0.0.202 TCP_DENIED/403
> 3789 CONNECT s-static.ak.facebook.com:443 - NONE/- text/html'
>hostname: 'arrakis'
>program_name: '(null)'
>log: '0 10.0.0.202 TCP_DENIED/403 3789 CONNECT
> s-static.ak.facebook.com:443 - NONE/- text/html'
>
> **Phase 2: Completed decoding.
>decoder: 'squid-accesslog'
>srcip: '10.0.0.202'
>action: 'TCP_DENIED'
>id: '403'
>url: 's-static.ak.facebook.com:443'
>
> **Phase 3: Completed filtering (rules).
>Rule id: '100102'
>Level: '0'
>Description: 'ignore facebook'
>
> So it's ignored. Now we test the multiple attempts thing, and I get
> nothing but 100102 alerts.
>
>
> >
> >
> > About the upgrade, I'm doing it right now.
> >
> > On Monday, December 3, 2012 6:06:15 PM UTC-2, dan (ddpbsd) wrote:
> >>
> >> On Mon, Dec 3, 2012 at 2:13 PM, Daniel Requena 
> wrote:
> >> > Hi,
> >> >
> >> >  I'm trying to customize the behavior of the rule 35051
> >> > (squid_rules.xml) in order to not have it fired if someone tries to
> >> > access
> >> > facebook website.
> >> >  This rule keeps annoying me, because Facebook "like" button is
> >> > EVERYWHERE and my proxy server blocks it.
> >> >  I wrote this piece of rule on my local_rules.xml but with no
> >> > success.
> >> >
> >> >  
> >> > 35051
> >> > .facebook.com/
> >> > Squid cache report
> >> > 
> >> >
> >> >  Does anybody have the same problem? I'm I doing something wrong?
> >> >  I appreciate any help.
> >> >
> >> > Regards.
> >> >
> >>
> >> Can you provide a log sample?
> >>
> >> > ps: I'm using Ossec Server v2.5.1
> >>
> >> Upgrade.
>



-- 
Atenciosamente
  Daniel Requena

Re: [ossec-list] Problem with rule 35051

[Daniel Requena]

Hi 

   Just extracted from squid access.log

1354623033.296  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT 
s-static.ak.facebook.com:443 - NONE/- text/html
1354623033.297  1 10.0.0.202 TCP_DENIED/403 3789 CONNECT 
s-static.ak.facebook.com:443 - NONE/- text/html
1354623033.297  1 10.0.0.202 TCP_DENIED/403 3765 CONNECT 
www.facebook.com:443 - NONE/- text/html
1354623033.298  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT 
www.facebook.com:443 - NONE/- text/html
1354623033.299  0 10.0.0.202 TCP_DENIED/403 3789 CONNECT 
s-static.ak.facebook.com:443 - NONE/- text/html
1354623033.299  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT 
www.facebook.com:443 - NONE/- text/html
1354623033.303  0 10.0.0.202 TCP_DENIED/403 3765 CONNECT 
www.facebook.com:443 - NONE/- text/html

 This is the alert that is generated from it:

Received From: (proxy) 10.0.0.55->/var/log/squid/access.log
Rule: 35051 fired (level 10) -> "Multiple attempts to access forbidden file or 
directory from same source ip."
Portion of the log(s):



About the upgrade, I'm doing it right now.

On Monday, December 3, 2012 6:06:15 PM UTC-2, dan (ddpbsd) wrote:
>
> On Mon, Dec 3, 2012 at 2:13 PM, Daniel Requena 
> > 
> wrote: 
> > Hi, 
> > 
> >  I'm trying to customize the behavior of the rule 35051 
> > (squid_rules.xml) in order to not have it fired if someone tries to 
> access 
> > facebook website. 
> >  This rule keeps annoying me, because Facebook "like" button is 
> > EVERYWHERE and my proxy server blocks it. 
> >  I wrote this piece of rule on my local_rules.xml but with no 
> success. 
> > 
> >   
> > 35051 
> > .facebook.com/ 
> > Squid cache report 
> >  
> > 
> >  Does anybody have the same problem? I'm I doing something wrong? 
> >  I appreciate any help. 
> > 
> > Regards. 
> > 
>
> Can you provide a log sample? 
>
> > ps: I'm using Ossec Server v2.5.1 
>
> Upgrade. 
>

[ossec-list] Problem with rule 35051

[Daniel Requena]

Hi,

 I'm trying to customize the behavior of the rule 35051 
(squid_rules.xml) in order to not have it fired if someone tries to access 
facebook website.
 This rule keeps annoying me, because Facebook "like" button is 
EVERYWHERE and my proxy server blocks it.
 I wrote this piece of rule on my local_rules.xml but with no success.

 
35051
.facebook.com/
Squid cache report


 Does anybody have the same problem? I'm I doing something wrong?
 I appreciate any help.

Regards.

ps: I'm using Ossec Server v2.5.1

Re: [ossec-list] xferlog decoder

[Daniel Cid]

This decoder is a bit broken :/

It is actually matching for:

^Mon OR
^Tue OR
^Wed OR .. OR ..
^Sun  \S\S\S\s+\d+..

We should probably just change it for:

^\w\w\w \S+\s+\d+ \d\d:\d\d:\d\d \S+ \d+
/\.+/active-response

Can you try to see if it fixes ?

thanks,

--
Daniel B. Cid
http://dcid.me

On Thu, Nov 15, 2012 at 10:17 AM, Xavier Mertens  wrote:
> Hello OSSEC'ers!
>
> Is there a woking decoder for 'xferlog' FTP files somwhere? I'm trying to
> write my own but I'm facing a strange issue:
>
> xferlog samples are detected as active-response logs (decoder: ar_log). I
> slightly modified the orginal  regex but the problem remains!?
>
> Why this decoder:
>
> 
> ^Mon|^Tue|^Wed|^Thu|^Fri|^Sat|^Sun \S\S\S\s+\d+
> \d\d:\d\d:\d\d \D\D\D \d\d\d\d /\S+/active-response
> /bin/(\S+) (\S+) - (\S+) (\d+.\d+)
> (\d+)
> action, status, srcip, id, extra_data
> 
>
> Matches this event:
>
> Thu Nov 15 13:51:15 2012 744 fakehost.be 2045663232 /home/ftp/file.txt b _ o
> r ftpread ftp 0 * c
>
> ossec-logtest reports:
>
> # ../bin/ossec-logtest
> 2012/11/15 15:16:12 ossec-testrule: INFO: Reading local decoder file.
> 2012/11/15 15:16:12 ossec-testrule: INFO: Started (pid: 21697).
> ossec-testrule: Type one log per line.
>
> Thu Nov 15 13:51:15 2012 744 fakehost.be 2045663232 /home/ftp/file.txt b _ o
> r ftpread ftp 0 * c
>
>
> **Phase 1: Completed pre-decoding.
>full event: 'Thu Nov 15 13:51:15 2012 744 fakehost.be 2045663232
> /home/ftp/file.txt b _ o r ftpread ftp 0 * c'
>hostname: 'boogey'
>program_name: '(null)'
>log: 'Thu Nov 15 13:51:15 2012 744 fakehost.be 2045663232
> /home/ftp/file.txt b _ o r ftpread ftp 0 * c'
>
> **Phase 2: Completed decoding.
>decoder: 'ar_log'
>
> **Phase 3: Completed filtering (rules).
>Rule id: '600'
>Level: '0'
>Description: 'Active Response Messages Grouped'
>
> I'm lost... :-)
>
> /x
>
> --
> My server is com

Re: [ossec-list] ERROR: Timeout while connecting to host:

[Daniel Flores]

t: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:245a8e325a2f64cfbe55504b8fa02c25:486c9b2e93752d67ff1ecabedcd90895d9b01e28
/etc/rc.d/rc6.d/K05saslauthd
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:e5d9911c8c40240e1d1b15e37b745267:253c483f716297ffd99c5cb6dfc68d8f6b491c8e
/etc/rc.d/rc6.d/K35winbind
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:0048de510a7a4380b6cf5946946afac9:4db333d183c13b8265f3a4a24a89c66c2176f571
/etc/rc.d/rc6.d/K85mdmonitor
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:908f244e1099aabfc71c4a4da9c0fbf8:a9ce31fc3127b7be1b4bc437d541ccb829cdb9eb
/etc/rc.d/rc6.d/K01tog-pegasus
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:34fbeec1d4a8d124bd11c7d1270e2045:3f27b370667845a6fad4c4b5a46af9622789f4ae
/etc/rc.d/rc6.d/K50tux
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:16ed84999704cda362fc5365aa73301d:7f6d5b433a9d1cefbf3afdc093187ad9e70fe244
/etc/rc.d/rc6.d/K99lvm2-monitor
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:363d838bf795f9c70ba66c58f68cf3fb:a82a87ef394f212ecc6c298bad264914959dbfa4
/etc/rc.d/rc6.d/K92iptables
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:d693116d06499f90c0e0c91c1d71903a:bb7facb1ac04f60ca76a9520ba17e34f5c284eaf
/etc/rc.d/rc6.d/K94diskdump
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:610f5e0d53172fcfa29c40f91a875468:bc90974ba6c38896167a5351c076465b99bcfb12
/etc/rc.d/rc6.d/K50snmpd
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:c0d5b854a49d78358e0e1a6c08fda8c6:94a0cd370044fa3ce7ef701904d6c6bf460abeab
/etc/rc.d/rc6.d/K05anacron
stat: unrecognized option `--printf'
Try `stat --help' for more information.
FWD:
:5785b45089aaa5fb1f33107e31568f4f:6b332a779f5b3da518cc0562b20263be3076fe01

I asume it's working but when i execute it with ossec user i get this:

SGAMONITORL:/var/ossec# sudo -u ossec ./agentless/ssh_integrity_check_linux
root@10.10.1.210 /et
spawn ssh root@10.10.1.210
===
"Estas accediendo a un servidor propiedad de Adserti.
El usuario autorizado es responsable de proteger la informacion,
mantener el secreto profesional e informar del mal uso de los sistemas.

El acceso no autorizado a este sistema o el uso indebido del mismo
estan prohibidos y es contrario a las politicas de Adserti.
Adserti se reserva el derecho de monitoreo mediante el uso de la tecnologia.
En caso de que sea detectada o revelada una posible actividad delictiva
o no etica, el personal de seguridad puede proporcionar la evidencia para
aplicar las medidas diciplinarias pertinentes."
==
Last login: Wed Oct 24 14:02:06 2012 from 11.10.1.114
[root@sgasrv7l ~]#
ERROR: Timeout while connecting to host: root@10.10.1.210 .


Daniel Flores

Re: [ossec-list] ERROR: Timeout while connecting to host:

[Daniel Flores]

2012/10/24 dan (ddp) 

> On Wed, Oct 24, 2012 at 2:44 PM, Daniel Flores
>  wrote:
> > Hi, I am using agentless to monitor one server running Red Hat, but the
> > problem is that when ossec user executes the ssh_integrity_check_linux I
> get
> > this:
> >
> > SGAMONITORL:/var/ossec# sudo -u ossec
> ./agentless/ssh_integrity_check_linux
> > root@10.10.1.210 /etc
> > spawn ssh root@10.10.1.210
> >
> ===
> > "Estas accediendo a un servidor propiedad de Adserti.
> > El usuario autorizado es responsable de proteger la informacion,
> > mantener el secreto profesional e informar del mal uso de los sistemas.
> >
> > El acceso no autorizado a este sistema o el uso indebido del mismo
> > estan prohibidos y es contrario a las politicas de Adserti.
> > Adserti se reserva el derecho de monitoreo mediante el uso de la
> tecnologia.
> > En caso de que sea detectada o revelada una posible actividad delictiva
> > o no etica, el personal de seguridad puede proporcionar la evidencia para
> > aplicar las medidas diciplinarias pertinentes."
> >
> ==
> > Last login: Wed Oct 24 13:23:50 2012 from 11.10.1.114
> > [root@sgasrv7l ~]#
> > ERROR: Timeout while connecting to host: root@10.10.1.210 .
> > SGAMONITORL:/var/ossec#
> >
> >
> > the first part is mi ssh banner, and it logs in with root user as I'm
> > expecting, but then it doesn't executes commands and logs me off
> >
> > I don't know why with the ossec user is not executing the next commands
> >
> > Can you help me please???
> >
> > Daniel Flores
>
> Without looking at the script, I'm guessing the lack of a password
> prompt is causing the issue.
>

mi ssh.exp script is the next:

#!/usr/bin/env expect

# @(#) $Id$
# Agentless monitoring
#
# Copyright (C) 2009 Trend Micro Inc.
# All rights reserved.
#
# This program is a 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 FSF - Free Software
# Foundation.


if {[string compare $pass "NOPASS"] == 0} {
source $sshnopasssrc
return
}


expect {
"WARNING: REMOTE HOST" {
send_user "\nERROR: RSA host key for '$hostname' has changed.
Unable to access.\n"
exit 1;
}
"*sure you want to continue connecting*" {
send "yes\r"
expect "* Password:*" {
send "$pass\r"
source $sshloginsrc
}
}
"ssh: connect to host*" {
send_user "\nERROR: Unable to connect to remote host: $hostname .\n"
exit 1;
}
"no address associated with name" {
send_user "\nERROR: Unable to connect to remote host: $hostname .\n"
exit 1;
}
"*Connection refused*" {
send_user "\nERROR: Unable to connect to remote host: $hostname .\n"
exit 1;
}
"*Connection closed by remote host*" {
send_user "\nERROR: Unable to connect to remote host: $hostname .\n"
exit 1;
}
"* Password:*" {
send "$pass\r"
source $sshloginsrc
}
timeout {
send_user "\nERROR: Timeout while connecting to host: $hostname .
\n"
exit 1;
}
}

And the ssh_integrity_check_linux:

#!/usr/bin/env expect

# @(#) $Id$
# Agentless monitoring
#
# Copyright (C) 2009 Trend Micro Inc.
# All rights reserved.
#
# This program is a 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 FSF - Free Software
# Foundation.


# Main script.
source "/var/ossec/agentless/main.exp"


# SSHing to the box and passing the directories to check.
if [catch {
spawn ssh $hostname
} loc_error] {
send_user "ERROR: Opening connection: $loc_error.\n"
exit 1;
}


source $sshsrc
source $susrc

set timeout 600
send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do tail
\$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` &&
sha1=`sha1sum \$i | cut -d \" \" -f 1` && echo FWD: `stat --printf
\"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
send "exit\r"

expect {
timeout {
send_user "ERROR: Timeout while running commands on host: $hostname
.\n"
exit 1;
}
eof {
send_user "\nINFO: Finished.\n"
exit 0;
}
}

exit 0;

Thanks

-- 
Daniel Flores

[ossec-list] ERROR: Timeout while connecting to host:

[Daniel Flores]

Hi, I am using agentless to monitor one server running Red Hat, but the 
problem is that when ossec user executes the ssh_integrity_check_linux I 
get this:

SGAMONITORL:/var/ossec# sudo -u ossec ./agentless/ssh_integrity_check_linux 
root@10.10.1.210 /etc
spawn ssh root@10.10.1.210
===
"Estas accediendo a un servidor propiedad de Adserti.
El usuario autorizado es responsable de proteger la informacion,
mantener el secreto profesional e informar del mal uso de los sistemas.

El acceso no autorizado a este sistema o el uso indebido del mismo
estan prohibidos y es contrario a las politicas de Adserti.
Adserti se reserva el derecho de monitoreo mediante el uso de la tecnologia.
En caso de que sea detectada o revelada una posible actividad delictiva
o no etica, el personal de seguridad puede proporcionar la evidencia para
aplicar las medidas diciplinarias pertinentes."
==
Last login: Wed Oct 24 13:23:50 2012 from 11.10.1.114
[root@sgasrv7l ~]# 
ERROR: Timeout while connecting to host: root@10.10.1.210 . 
SGAMONITORL:/var/ossec#


the first part is mi ssh banner, and it logs in with root user as I'm 
expecting, but then it doesn't executes commands and logs me off

I don't know why with the ossec user is not executing the next commands

Can you help me please???

Daniel Flores

Re: [ossec-list] Re: Is it possible to disable alert.log and use only database?

[Daniel Cid]

How many events/alerts per second do you have? I don't think writing
to a log file
will cause any issue (and if is, it will be much worse when writing to the db).

thanks,

--
Daniel B. Cid
http://dcid.me

On Wed, Sep 26, 2012 at 4:01 AM, kay kay  wrote:
> Disk utilization is too high.
>
> вторник, 25 сентября 2012 г., 22:41:09 UTC+4 пользователь JB написал:
>>
>> May I ask why do you want to disable alert.log?
>>
>

Re: [ossec-list] case insensitive regex?

[Daniel Cid]

The regex is case insensitive by default. So just

Ownership was

Should work.

thanks,

--
Daniel B. Cid
http://dcid.me


On Tue, Aug 28, 2012 at 3:01 PM, dkoleary  wrote:
> Hey;
>
> As mentioned in other posts, I'm trying to monitor the /etc directory but
> alert on /etc/passwd & shadow only if their permissions/ownership change.
> The rules used to read:
>
> 
>syscheck,
>/etc/passwd|/etc/shadow
>Logging but not alerting changes to passwd/shadow
> files
> 
>
> 
>13
>[Oo]wnership was
>Ownership change for password or shadow file!
> 
>
> however, after testing them out, the second rule isn't getting kicked off.
> The alert shows:
>
> ** Alert 1346175104.45945: - local,syslog,
> 2012 Aug 28 12:31:44 nilrhutl02->syscheck
> Rule: 13 (level 1) -> 'Logging but not alerting changes to passwd/shadow
> files'
> Integrity checksum changed for: '/etc/shadow'
> Ownership was '1', now it is '0'
> Group ownership was '503', now it is '0'
>
> I suspect that has to do with the regular expression [Oo] which attempts to
> find a capital or lower case 'o'.  I replaced the [Oo] with a \w for any
> word character which I suspect will work; however, that feels like a bit of
> a kludge.
>
> Is there a way to make searches case insensitive or a better way to search
> for the work ownership regardless of the case of the first letter?
>
> Thanks.
>
> Doug O'Leary

Re: [ossec-list] Client.keys Permission error

[Daniel Cid]

Yes, the ossecr user (or ossec group) needs permission to read it.

thanks,

On Wed, Aug 22, 2012 at 1:00 PM, OSSEC junkie  wrote:
> I am getting permission errors on client.keys:
> 2012/08/22 08:44:38 ossec-remoted(4111): INFO: Maximum number of
> agents allowed: '3500'.
> 2012/08/22 08:44:38 ossec-remoted(1410): INFO: Reading authentication keys 
> file.
> 2012/08/22 08:44:38 ossec-remoted(1103): ERROR: Unable to open file
> '/etc/client.keys'.
> 2012/08/22 08:44:38 ossec-remoted(1750): ERROR: No remote connection
> configured. Exiting.
>
>
> My configuration (permissions) for the file is:
>
> root@wu-tang:/var/ossec/etc# ls -al
> total 184
> dr-xr-x---  3 root ossec  4096 Aug 20 06:02 .
> dr-xr-x--- 13 root ossec  4096 Aug 20 05:59 ..
> -r--r-  1 root root  57369 Aug 20 06:22 client.keys
>
> I assume it needs to be root:ossec but wanted to get final confirmation.
>
> Can you let me know please?

Re: [ossec-list] Simplest question ever (?) - timestamp

[Daniel Cid]

Yes, we could do some interesting rules there :)

The issue is that OSSEC stores the alerts in a sequential mode and it
wouldn't be able
to go back in time and store the alerts on the proper position based
on the log time. Plus,
it would be a big mess if servers are on a different timezone or do
not have the times in sync...

thanks,

--
Daniel B. Cid
http://dcid.me



On Wed, Aug 15, 2012 at 3:51 PM, dan (ddp)  wrote:
> On Wed, Aug 15, 2012 at 2:45 PM, Kat  wrote:
>> Is there a way to tell OSSEC to use the timestamp of the actual logfile
>> entry rather than its own "internal timestamp of when it sees the alert"?
>>
>> This should be a configuration option - *hint hint*
>>
>> Unless there is already a way to do this.
>>
>> thanks
>> K
>
> There's currently no way to do this, and I don't see it happening.
>
> Although, I do want to see OSSEC taking the event's timestamp into
> account, and possibly send an additional alert for strange timestamps
> (old events, predictions of future events, etc).

Re: [ossec-list] Changing timezone in all OSSEC components

[Daniel Cid]

That should do it. Just move the new locatime to /var/ossec/etc and
restart ossec.

thanks,

--
Daniel B. Cid
http://dcid.me

On Thu, Jul 5, 2012 at 3:42 AM, C. L. Martinez  wrote:
> Hi all,
>
>  Due to a restructuring that I make in our infrastructure, I need to
> modify the time zone of all OSSEC components: manager and agents.
> Apart of modifying the localtime file under /var/ossec, should I
> perform some other action?
>
> Thanks.

Re: [ossec-list] What happened to ossec rootcheck ?

[Daniel Cid]

The site got migrated, so a few files will be missing until it is all in order.

thanks,

--
Daniel B. Cid
http://dcid.me

On Mon, Jul 2, 2012 at 9:47 AM, Peter M Abraham
 wrote:
> Good day:
>
> http://www.ossec.net/rootcheck/files/ uses to have the latest rootcheck
> available as as separate download.
>
> It appears to be missing.
>
> What happened to it?
>
> Thank you.
>

[ossec-list] Re: Ossec agent installation

[Daniel Flores]

Thank you so much ddp.

Daniel Flores

On 14 jun, 14:10, "dan (ddp)"  wrote:
> On Thu, Jun 14, 2012 at 3:01 PM, Daniel Flores
>
>  wrote:
> > Tnks ddp,
> > I opened the port but still can´t connect them,  I have my server in
> > Ubuntu server 12.04 LTS, it's IP is 11.10.1.xxx and the agent i want to
> > reach is 192.168.100.xxx I installed the agent, got the key, import the key
> > and run the agent  but it doesn´t run.
> > In the firewall I have a rule which allows traffic by port udp 1514 both
> > ways from server 192.168... to the ossec server 11.10.1.xxx. But still agent
> > doesn't run
> > I don´t know what else todo.
>
> You haven't really done much. Being lost at this point is a bad sign.
>
> First, did you check the firewall's logs to see if it blocked the traffic?
> Next, if your OSSEC server is 11.10.1.xxx you need 11.10.1.xxx:1514
> open. The agent needs to be able to reach the OSSEC server's 1514
> (udp) port.
> Next, make sure iptables on the Ubuntu OSSEC server isn't blocking the 
> traffic.
> Next, use tcpdump on the OSSEC server to make sure the traffic is
> getting to the OSSEC server. If it is, check for responses from the
> OSSEC server. Also make sure the agent's IP address shows up
> correctly. If it isn't what you entered in manage_agents you've done
> something wrong.
> Also, check the /var/ossec/logs/ossec.log for any log entries related
> to this agent.
>
>
>
>
>
>
>
>
>
> > best regards
> > Saludos.
> > Daniel Flores
>
> > 2012/6/14 dan (ddp) 
>
> >> On Thu, Jun 14, 2012 at 1:46 PM, Daniel Flores
> >>  wrote:
> >> > Hi, I am installing an agent in Windows, i have 2 LAN's connected by 2
> >> > firewalls, in one LAN is the OSSEC server and in the other LAN is the
> >> > agent, what i want to know is which port the ossec agent uses to
> >> > connect to the server?
>
> >> > Thanks
> >> > Daniel Flores
>
> >> By default the server listens on udp 1514. Traffic should be allowed both
> >> ways.
>
> > --
> > Daniel Flores