Re: [ossec-list] Regular OSSEC vs OSSEC Wazuh

[Pedro S]

Hi,

Philip, Wazuh still supports CEF format, it integrates all the 
functionality from OSSEC 2.8.3 and 2.9beta, I am pretty sure you will be 
able to integrate Wazuh with your current Graylog instance, same way you 
can do it with OSSEC.

Regarding to the ruleset, last version from Wazuh rules is not totally 
compatible with OSSEC 2.8.3 because the "dynamic fields", this new 
functionality allow us to extract as many fields as we want on the 
decoders, so we are not limited to the static ones "srcip, srcport, 
extra_data..", moreover you will be able to use those fields later when 
creating rules (I would recommend you to take a look at the Changelog 
)
If the decoders does not contain any dynamic field, you could use them on 
your standard OSSEC.


I don't have any experience with Greylog, but I can see how it could ingest 
data in JSON format (
http://docs.graylog.org/en/2.1/pages/extractors.html#using-the-json-extractor) 
maybe you can use JSON output, that could be an amazing improvement for 
your architecture.


I am feeling curious about the botnet issue, please feel free to explain in 
detail your botnet issue and maybe we can help, it seems interesting :P, 
you mention there is a limit of the decoders fields in your case, what do 
you need to extract ? are you using active response ?

Kind regards,
Pedro Sanchez.

On Tuesday, January 31, 2017 at 11:22:31 AM UTC+1, secuc...@free.fr wrote:
>
> hi 
> Wazuh has rules update and a nice integration of PCI DSS compliance. 
> More and more Wazuh is different from ossec, but i think they contribute 
> on it too. 
>
> I still using ossec with our ELK, but ELK is a pain in the ass to upgrade, 
> so i think graylog 
> is better for searching logs. 
>
> there is siemonster that integrate ossec/wazuh too, great job but still a 
> bit disappointing. 
>
> I really hope Ossec will still have improvement, this is a great tools, 
> but i can only debug for helping. 
>
> The problem we face now, is botnet using each different ip for brute 
> forcing.. that is a limit of the decoder checking only urp/ip/etc.. 
>
> There is a big step bewteen HIDS and SIEM and the cost 
>
> For us, Ossec need better reporting and correlation 
>
> - Mail original - 
> De: "Philip Alexander"  
> À: "ossec-list"  
> Envoyé: Lundi 30 Janvier 2017 19:05:50 
> Objet: [ossec-list] Regular OSSEC vs OSSEC Wazuh 
>
>
> I intend to set up OSSEC and noticed there seem to be two main flavours: 
> regular OSSEC and Wazuh fork. 
>
> From what I've been able to gather, the main advantages of Wazuh are: 
>
> * its ability to integrate with ELK 
> * an improved ruleset 
> * restful API 
>
> I have no interest in using ELK for this project, but we already have a 
> preexisting graylog instance that I'd like to hook up with OSSEC, which 
> should be possible in regular OSSEC using syslog cef format, according to 
> this: https://github.com/Graylog2/graylog-guide-ossec . 
>
> I assume I can still use the improved ruleset even if I run regular OSSEC, 
> atleast I haven't seen anything that indicates otherwise. 
>
> As for the restful API, I'm still very inexperienced and I've only 
> recently heard about REST - I don't even know how I would begin putting it 
> to use - so I'm not sure if I should use the Wazuh fork just for that. 
>
> The objective is to run OSSEC agents on the machines in our cloud 
> environment and point them to an OSSEC Server in a machine that's already 
> being used for log management and monitoring on the same network . 
>
> Are there any other advantages to running Wazuh instead of regular OSSEC? 
> Is there much of a performance difference? Anything else I should take into 
> consideration? 
>
>
> -- 
>
> --- 
> You received this message because you are subscribed 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: Simultaneous Events at 25 EPS, but Missing Alerts

[Pedro S]

Hi Jon,

This is an interesting test, I think we can get a lot of useful information 
from here.

On my experience probably the bottleneck is on remoted socket/buffer or 
logcollector speed performance to read each log line.

For Remoted, try to enable debug mode at the agent, internal_options.conf 
file, remoted.debug=2, and agent.debug=2. You will find at ossec.log each 
line read by logcollector and sent to remoted, this way we can figure out 
if the problem is related to gathering/sending or lately 
receiving/proccesing.

On my tests I can see how everything is being pushed, but just a few events 
on archives are displayed, I think OSSEC also have some protection for 
multiple identical messages.

2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
> 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 'test55'
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
> server.
> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
> '--MARK--: '
> 2016/10/04 11:07:43 ossec-agent: DEBUG: Attempting to send message to 
> server.





On Monday, October 3, 2016 at 8:27:04 PM UTC+2, Jon Goodgion wrote:
>
> I've been curious about the performance of OSSEC in a server/agent 
> architecture, so I have been emulating simultaneous events on a single 
> agent by appending log entries to the agent's syslog.
>
> Using a shell script for loop on the agent, I append 25 consecutive logs 
> that match the format of a telnet failed password log. I figured 25 EPS 
> should be easily captured by OSSEC.
>
> However, on the server, (after enabling logall to archives), it doesn't 
> seem like it is processing all the logs. 
> /var/ossec/logs/archives/archives.log shows:
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[*1*]: refused connect from 81.215.42.24
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[*13*]: refused connect from 81.215.42.158
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[14]: refused connect from 81.215.42.69
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[15]: refused connect from 81.215.42.32
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[16]: refused connect from 81.215.42.41
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[17]: refused connect from 81.215.42.74
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[18]: refused connect from 81.215.42.32
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[19]: refused connect from 81.215.42.222
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[20]: refused connect from 81.215.42.25
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[21]: refused connect from 81.215.42.141
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[22]: refused connect from 81.215.42.248
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[23]: refused connect from 81.215.42.45
>
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[24]: refused connect from 81.215.42.166
> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
> 14:15:55 queen telnetd[25]: refused connect from 81.215.42.178
>
> I put the for loop sequence identifier in the telnetd brackets [ ], and as 
> you can see, this particular test didn't catch anything between the 2nd and 
> 12th log.
>
> Does this have to do with UDP loss? Am I missing something, or possibly 
> need to reconfigure OSSEC a certain way? Any help would be greatly 
> appreciated!
>

-- 

--- 
You received this message because you are subscribed to 

Re: [ossec-list] ossec-authd: Unable to connect

[Pedro S]

t;> connectivity? I am not sure if both server are able to communicate on a 
>> different way, try to use tcpdump on server side and telnet on other.
>> >
>> > Server:
>> >
>> >> tcpdump -i eth0 port 1515 -vv
>> >
>> >  
>> > Agent:
>> >
>> >> telnet server_ip 1515
>> >
>> >
>> >
>> > Try to add it manually, if that works, we can keep going with ossec 
>> authd deployment.
>> >
>> >
>> > On Mon, Oct 3, 2016 at 5:57 PM, Dodain Dodo <moizim...@gmail.com 
>> > wrote:
>> >>
>> >> Hi Pedro,
>> >>
>> >>  Thanks for replying. Sorry, I forgot to mention few details . Firstly 
>> I am using Alienvault USM .Secondly  the ossec server is listening , so the 
>> server part is working, the prob i am getting is that agent/client isn't 
>> able to connect to the server on port 1515 and I am not able to find out 
>> why my agent isnt able to communicate with ossec server on port 1515. For 
>> that i even added port 1515 in iptables , Since agent isn't able to 
>> communicate so tcpdump on server shows 0 packets. 
>> >>
>> >> tcp0  0 0.0.0.0:15150.0.0.0:*   
>> LISTEN  5504/ossec-authd
>> >>  
>> >>
>> >> On Mon, Oct 3, 2016 at 1:21 PM, Pedro Sanchez <pe...@wazuh.com 
>> > wrote:
>> >>>
>> >>> Hi Ali,
>> >>>
>> >>> Could you confirm that ossec-authd is running and listening on the 
>> sensor? You could use
>> >>>>
>> >>>>
>> >>>> netstat -pna | grep 1515
>> >>>
>> >>>
>> >>> The expected output will be similar to:
>> >>>
>> >>>> tcp0  0 0.0.0.0:15150.0.0.0:*   
>> LISTEN  9684/ossec-authd
>> >>>
>> >>>
>> >>> It seems like you have some connectivity problems, be sure that the 
>> agent can actually access to 1515 port, you could use tcpdump at OSSEC 
>> Manager to listen for incoming packets to 1515 port:
>> >>>
>> >>>> root@ubuntu5:/var/ossec/etc# tcpdump -i eth0 port 1515 -vv
>> >>>> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture 
>> size 65535 bytes
>> >>>> 01:20:11.033864 IP (tos 0x0, ttl 128, id 22397, offset 0, flags 
>> [DF], proto TCP (6), length 52)
>> >>>> 192.168.1.30.57495 > 192.168.1.10.1515: Flags [S], cksum 0x4748 
>> (correct), seq 2326532896, win 8192, options [mss 1460,nop,wscale 
>> 8,nop,nop,sackOK], length 0
>> >>>> 01:20:11.033931 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], 
>> proto TCP (6), length 52)
>> >>>> 192.168.1.10.1515 > 192.168.1.30.57495: Flags [S.], cksum 0x839f 
>> (incorrect -> 0x141f), seq 3245350808, ack 2326532897, win 29200, options 
>> [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
>> >>>> 01:20:11.034075 IP (tos 0x0, ttl 128, id 22398, offset 0, flags 
>> [DF], proto TCP (6), length 40)
>> >>>> 192.168.1.30.57495 > 192.168.1.10.1515: Flags [.], cksum 0xbefc 
>> (correct), seq 1, ack 1, win 2053, length 0
>> >>>> 01:20:11.035593 IP (tos 0x0, ttl 128, id 22399, offset 0, flags 
>> [DF], proto TCP (6), length 203)
>> >>>> 192.168.1.30.57495 > 192.168.1.10.1515: Flags [P.], cksum 0xeedb 
>> (correct), seq 1:164, ack 1, win 2053, length 163
>> >>>> 01:20:11.035668 IP (tos 0x0, ttl 64, id 37466, offset 0, flags [DF], 
>> proto TCP (6), length 40)
>> >>>
>> >>>
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Pedro S.
>> >>>
>> >>> On Mon, Oct 3, 2016 at 10:03 AM, Ali Khan <moizim...@gmail.com 
>> > wrote:
>> >>>>
>> >>>> Hi All,
>> >>>>
>> >>>>
>> >>>> I am  trying to use ossec agent-auth to auto agent key registration 
>> with ossec server.
>> >>>>
>> >>>> I did the followoing on server
>> >>>>
>> >>>> openssl genrsa -out /var/ossec/etc/sslmanager.key 2048
>> >>>> openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out 
>> /var/ossec/etc/sslmanager.cert -days 365
>> >>>> /var/ossec/bin/ossec-authd -p 1515 -i >/dev/null 2>&1 &
>> >

[ossec-list] Re: Agents not connecting, traffic visible in tcpdump

[Pedro S]

Hi Cal,


Try disabling counters. They lose synchronisation specially when agents are 
reinstalled.
Edit /var/ossec/etc/internal_options.conf and set 
"remoted.verify_msg_id=0", both agent & manager.

Enable debug mode on both hosts, open internal_options and set debug to 
level 2 (specially in remoted.debug variable).

Sometimes the problem could be related with NAT, try adding the agent with 
"any" option and test if it works (use manage_agent and when prompting for 
IP enter "any").

Open etc/client.keys on OSSEC Manager (be careful! this file is critical) 
and remove duplicated entries, the agent will fail to connect if there is 
more than one entry with the same IP.

Hope it helps,

best regards,

Pedro S.



On Tuesday, August 2, 2016 at 2:08:14 PM UTC-7, Cal wrote:
>
> Hi all,
>
> Been debugging an issue for a few hours, thought I'd ask for another 
> opinion.
>
> The situation:
> I have an OSSEC server with approximately 70 agents connected and 15 or so 
> that won't connect.
>
> Tested so far:
> Tcpdump shows UDP packets from both OSSEC agents and server (running on 
> non-standard port 1520)
> Traceroute from agent to server and other direction, no problem
> Can ping the server from agent
> Can ping the agent from server
>
> Ex:
> server:
> 15:51:00.135367 IP 172.28.156.XX.60625 > 172.28.29.XX.1520: UDP, length 73
>
> agent:
> 15:51:00.135916 IP 172.28.156.XX.60625 > 172.28.29.XX.1520: UDP, length 73
>
> I've tried re-adding the keys to agents several times. Enabled debugging 
> on server, but only noted logs are from the agent:
> 2016/08/02 15:56:39 ossec-agentd: INFO: Trying to connect to server 
> (172.28.29.XX:1520).
> 2016/08/02 15:56:39 ossec-agentd: INFO: Using IPv4 for: 172.28.29.XX
>
> Any ideas where to look next? I've also tried removing the agents, 
> re-adding, re-installing, etc.
>
> Thank you!
>

-- 

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

[ossec-list] Re: Monitoring windoews eventlog kibana

[Pedro S]

Hi,

I am not sure I understood what you need, do have Wazuh already installed 
and working? did you complete all the documentation steps so you can have 
all the out of the box dashboards?

I can see you are receiving Windows events, do you need to create a special 
and dedicated dashboard for Windows Events ?

You will need to use some filters in Kibana, for example:

Get all the windows events: rule.groups: windows
Get windows auth fail: rule.groups: win_authentication_failed

Playing a little bit with that you can made this up in ten minutes (click 
here 
<https://lh3.googleusercontent.com/-qu9R3b5lhYU/V2SfRVQBRPI/AEs/HjBWo-Lkjxc1twKsH7jUKK52kIURK5LsgCLcB/s1600/Screenshot%2BKibana%2Bwindows%2Bendpoints%2Bdashboard.png>to
 
open it in other window):

<https://lh3.googleusercontent.com/-qu9R3b5lhYU/V2SfRVQBRPI/AEs/HjBWo-Lkjxc1twKsH7jUKK52kIURK5LsgCLcB/s1600/Screenshot%2BKibana%2Bwindows%2Bendpoints%2Bdashboard.png>

Maybe you can get some info in the official Kibana dashboards docs. 
<https://www.elastic.co/guide/en/kibana/current/dashboard.html>

If you need some help creating the dashboard just tell us or maybe we can 
talk through another channel (these are OSSEC lists :D)


Best regards,

Pedro S:


On Friday, June 17, 2016 at 9:19:03 AM UTC-7, sant...@gmail.com wrote:
>
> Hello.
> I installed ossec-wazzuh with kibana on linux server
> i want to monitoring winddows eventlog from 2 active directory servers.
> I have configured agent  in linux for this servers and install ossec agent 
> in windows server
>
> The configuration agent from windows is
> 
>
>   192.168.12.14
>
>  
>
> 
> Application
> eventlog
>   
>
>   
> Security
> eventlog
>   
>
>   
> System
> eventlog
>   
>
> I recibe this log in kibana:
>
> {\"rule\":{\"level\":3,\"comment\":\"Windows User 
> Logoff.\",\"sidid\":18149,\"firedtimes\":1,\"groups\":[\"windows\"],\"PCI_DSS\":[\"10.2.5\"]},\"dstuser\":\"Administrador\",\"full_log\":\"2016
>  
> Jun 07 10:33:48 WinEvtLog: Security: AUDIT_SUCCESS(551): Security: 
> Administrador: PC-XP: PC-XP: Cierre de sesi\xF3n iniciada por el usuario:   
>   Nombre usuario: Administrador Dominio:  DOM.local Id. de inicio 
> de sesi\xF3n:  (0x0,0xb73d9)   
>  
> \",\"id\":\"551\",\"status\":\"AUDIT_SUCCESS\",\"data\":\"Security\",\"systemname\":\"PC-XP\",\"decoder\":{\"name\":\"windows\"},\"hostname\":\"agent01\",\"agentip\":\"any\",\"timestamp\":\"2016
>  
> Jun 07 10:33:51\",\"location\":\"WinEvtLog\"}
>
>
> Please, how can i do for add daskboard in kibana graphic interface 
> for the eventolog monitoring?
>

-- 

--- 
You received this message because you are subscribed 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: Quickest way to test an updated local_rules.xml

[Pedro S]

Hi Tahir,

I don't think OSSEC has a tool for do that, the option you have is remove 
previous/old alerts files, remove alerts.log file and restart OSSEC, 
another possibility is to create a intermediate script to search for all 
the occurrences of the alerts and remove them from every past alerts file.

If you need to test the rules you created, you can do that using 
*/var/ossec/bin/ossec-logtest, 
*paste the event you want to test to inspect, you won't need to restart 
OSSEC because ossec-logtest loads the rules every time you run it, but once 
you check that the rule is working you will need to restart OSSEC to apply 
changes.


On Thursday, June 2, 2016 at 12:48:14 PM UTC+2, Tahir Hafiz wrote:
>
> Dear All,
>
> If I make changes to my local_rules.xml and add some rules in there to 
> effectively whitelist some false postives which happen as an environment 
> starts building (i.e make them associate to level 0).
> And then I want to test my new local_rules.xml without having to destroy 
> and start a new environment again - is there a way to wipe clean the alerts 
> file and get OSSEC to do it's precoding, decoding stuff from all the 
> received log entries from the OSSEC agents from fresh?
> So effectively have a fresh alerts file which implements my new changes in 
> the local_rules.xml file.
>
> Cheers
>

-- 

--- 
You received this message because you are subscribed 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: reindexing logs

[Pedro S]

Hi Maxim, 

How are you forwarding the alerts/archives to Kibana?

I think you will need the archives JSON output setting, if you are using 
Wazuh , edit *ossec.conf *and add the following setting:

  
> *yes*
>   



Once you do it, you will find new archives.json events files at:

/var/ossec/logs/archives/archives.json



The next step is forward these archives events to Elasticsearch, in order 
to do it we need to edit Logstash configuration.

My personal advice to index archives events is to create a dedicated index 
pattern just for them, so you will be able to distinguish between events 
and alerts, adding inside "output" section the following configuration:

output {
if [type] == "ossec-alerts" {
elasticsearch {
 hosts => ["127.0.0.1:9200"]
 index => "ossec-%{+.MM.dd}"
 document_type => "ossec"
 template => "/etc/logstash/elastic-ossec-template.json"
 template_name => "ossec"
 template_overwrite => true
}
}
if [type] == "ossec-archives" {
elasticsearch {
 hosts => ["127.0.0.1:9200"]
 index => "ossec-archives-%{+.MM.dd}"
 document_type => "ossec"
 template => "/etc/logstash/elastic-ossec-template.json"
 template_name => "ossec"
 template_overwrite => true
}
}
}


Later in Kibana you will need to create a new index pattern 
(Settings->indices) matching for "ossec-archives-*".

If you need to "reindex" or read the a log file from the beginning using 
Logstash, you can use the file input with option *start_position *set to 
*beginning 
*(+ info) 




On Monday, May 30, 2016 at 4:53:10 PM UTC+2, Maxim Surdu wrote:
>
> i have this archives files with logs but in kibana i can not see them can 
> i reindex this files?
> if i can, please help me step by step
>
> joi, 19 mai 2016, 10:17:51 UTC+3, Maxim Surdu a scris:
>>
>> Hi dear community,
>>
>> i had a problem with logstash, after i resolve it i saw what in kibana 
>> are missing logs, how can i resolve the problem and reindexing all my logs 
>> to kibana
>> I will be thankful if someone will help me step by step
>>
>>
>> i appreciate your help, and a lot of respect for developers and community!
>>
>

-- 

--- 
You received this message because you are subscribed 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: Duplicated counter

[Pedro S]

Hi,

Your configuration is working properly on my environment, what Windows 
version are you running?

EventChannel Bookmark 
<https://msdn.microsoft.com/es-es/library/windows/desktop/bb427418(v=vs.85).aspx>
 identifies 
an event in a channel or log file, bookmarks are created by OSSEC in order 
to subscribe to a event list.
I can see on my lab how the bookmark is created first on tmp/ folder and 
then it is moved to bookmarks/ folder.

Tracing your errors, first one prompts when OSSEC try to rename the 
bookmark tmp file, function *rename_ex *(1 
<https://github.com/wazuh/ossec-wazuh/blob/ab9f716128ab4d1df58fd3c9d0e0bf9fd5cf7150/src/shared/file_op.c#L858>
 
& 2 
<https://github.com/wazuh/ossec-wazuh/blob/5441889d963ce6d8ee3fae0e9f273e701b6c89eb/src/logcollector/read_win_event_channel.c#L575>),
 
second error 
<https://github.com/wazuh/ossec-wazuh/blob/5441889d963ce6d8ee3fae0e9f273e701b6c89eb/src/logcollector/read_win_event_channel.c#L577>
 
is a consequence of the first error.

I can assume the file not longer exist on that folder or OSSEC does not 
have enough permissions to move/rename it, try to run *uninstall.exe *and 
start from scratch installing again OSSEC, if does not work, try to grant 
permissions to group "Administrators".


Best regards,

Pedro S.


On Monday, May 16, 2016 at 2:07:57 PM UTC+2, Abdulvehhab Agin wrote:
>
> Hi Pedro,
>
>
> My ossec.conf and internal_options.conf is attached.
>
>
> I set remoted.verify_msg_id=0 to ignore Duplicated error
>
>
> 13 Mayıs 2016 Cuma 19:57:57 UTC+3 tarihinde Pedro S yazdı:
>>
>> Just to be sure, the variable I was talking about is:
>>
>> # Verify msg id (set to 0 to disable it)
>>> remoted.verify_msg_id=1
>>
>>
>> At /var/ossec/etc/internal_options.conf
>>
>>
>> Best regards,
>>
>> Pedro S.
>>
>>
>> On Friday, May 13, 2016 at 3:53:20 PM UTC+2, Pedro S wrote:
>>>
>>> Hi,
>>>
>>> I don't think *verify_msg *will be related with those errors.
>>>
>>> It seems like those files (EventChannel bookmarks) not longer exist in 
>>> tmp folder or OSSEC does not have enough permissions, try to reinstall the 
>>> agent.
>>> If you prefer, paste here your EventChannel queries so I can test them 
>>> in my labs.
>>>
>>> Best regards,
>>>
>>> Pedro S.
>>>
>>>
>>>
>>> On Fri, May 13, 2016 at 1:37 PM, Abdulvehhab Agin <abdul...@gmail.com> 
>>> wrote:
>>>
>>>> When i change verify_msg_id=0; *i have lots of error in ossec log*
>>>>
>>>>
>>>>
>>>>
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>>>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>>>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>>>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>>>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>>>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>>>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>>>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>>>>
>>>>
>>>>
>>>> 12 Mayıs 2016 Perşembe 10:37:15 UTC+3 tarihinde Pedro S yazdı:
>>>>>
>>>>> Hi,
>>>>>
>>>>> If multiple agents are using the same key, you need to set them 
>>>>> up with their own unique key.
>>>>> If you re-installed an agent and didn't backup the rids files, 
>>>>> you should create a new key for the agent and use that.
>>>>> If you prefer to avoid any counters error, try to deactivate counters, 
>>>>> open file etc/internal_options.conf (Manager & Agent) and set 
>>>>> verify_msg_id=0.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Pedro S.
>>>>>
>>>>> On Wednesday, May 11, 2016 at 10:33:00 PM UTC+2, Abdulvehhab Agin 
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sometimes

[ossec-list] Re: Windows Defender Decoder ?

[Pedro S]

Hi Rob,

*extra_data *is another allowed field used by OSSEC decoders to extract 
information from the event, once it is extracted you can match the field 
content in order to create a rule.
The content of extra_data depends on the decoder which extracted it, in 
Windows decoders  
<https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/decoders/windows_decoders.xml#L350>could
 
be for example: Win source, Parent Image, Protocol, Signature, Start 
function...

Best regards,

Pedro S.

On Tuesday, May 17, 2016 at 5:32:25 PM UTC+2, Rob B wrote:
>
> Thanks Brent.! Funny enough, that day I figured it out and built a 
> whole bunch very similar to your list.  Seems to be working very nicely, as 
> now I find myself leaning to creating some down right creative 
> composites  (finally)
>
> I've been looking for some reference material on the  tag? 
>  How is this used properly?
>
>
>
> Cheers!   Rob
>
>
> On Monday, May 16, 2016 at 5:22:08 PM UTC-4, Brent Morris wrote:
>>
>> Rob - can you post your OSSEC version of the log?  I can check my rules. 
>>  These are a culmination of gleaned rules that I updated some time back 
>> with new event IDs.  Yours is covered in there  but I would like to 
>> test it against a valid OSSEC log.  So if you can post it from the OSSEC 
>> logs, that'd be great.
>>
>> Here they are..
>>
>> 
>> 
>> 
>> 
>>   
>> windows
>> 18101,18102,18103
>> ^Microsoft Antimalware
>> Grouping of Microsoft Security Essentials 
>> rules.
>>   
>>
>>   
>> 720001
>> ^1118$|^1119$
>> virus,
>> Microsoft Security Essentials - Virus detected, but 
>> unable to remove.
>>   
>>   
>> 720001
>> ^1117$
>> virus,
>> Microsoft Security Essentials - Virus detected and 
>> properly removed.
>>   
>>
>>   
>> 720001
>> ^1119$|^1118$|^1117$|^1116$
>> virus,
>> Microsoft Security Essentials - Virus 
>> detected.
>>   
>>
>>   
>> 720001
>> ^1015$
>> virus,
>> Microsoft Security Essentials - Suspicious activity 
>> detected.
>>   
>>
>>
>>   
>> 720001
>> ^5007$
>> Microsoft Security Essentials - Configuration 
>> changed.
>> policy_changed,
>>   
>>   
>> 720001
>> ^5008$
>> Microsoft Security Essentials - Service 
>> failed.
>>   
>>   
>> 720001
>> ^3002$
>> Microsoft Security Essentials - Real time protection 
>> failed.
>>   
>>   
>> 720001
>> ^2012$
>> Microsoft Security Essentials - Cannot use Dynamic 
>> Signature Service.
>>   
>>   
>> 720001
>> ^2004$
>> Microsoft Security Essentials - Loading definitions 
>> failed. Using last good set.
>>   
>>   
>> 720001
>> ^2003$
>> Microsoft Security Essentials - Engine update 
>> failed.
>>   
>>   
>> 720001
>> ^2001$
>> Microsoft Security Essentials - Definitions update 
>> failed.
>>   
>>   
>> 720001
>> ^1005$
>> Microsoft Security Essentials - Scan error. Scan has 
>> stopped.
>>   
>>   
>> 720001
>> ^1002$
>> Microsoft Security Essentials - Scan stopped before 
>> completion.
>>   
>>
>>   
>>   
>>   
>> 720012
>> Virus:DOS/EICAR_Test_File
>> alert_by_email
>> Microsoft Security Essentials - EICAR test file 
>> detected.
>>   
>>   
>> 720011
>> Virus:DOS/EICAR_Test_File
>> alert_by_email
>> Microsoft Security Essentials - EICAR test file 
>> removed.
>>   
>>   
>> 720010
>> Virus:DOS/EICAR_Test_File
>> alert_by_email
>> Microsoft Security Essentials - EICAR test file 
>> detected, but removal failed.
>>   
>>
>>   
>>   
>> 720001
>> ^2000$
>> Microsoft Security Essentials - Signature database 
>> updated.
>>   
>>   
>> 720001
>> ^2002$
>> Microsoft Security Essentials - Scan engine 
>> updated.
>>   
>>   
>> 720001
>> ^1000$|^1001$
>> Microsoft Security Essentials - Scan started or 
>> stopped.
>>   
>>   
>> 720001
>> ^1013$
>> Microsoft Security Essenti

Re: [ossec-list] Re: Duplicated counter

[Pedro S]

Just to be sure, the variable I was talking about is:

# Verify msg id (set to 0 to disable it)
> remoted.verify_msg_id=1


At /var/ossec/etc/internal_options.conf


Best regards,

Pedro S.


On Friday, May 13, 2016 at 3:53:20 PM UTC+2, Pedro S wrote:
>
> Hi,
>
> I don't think *verify_msg *will be related with those errors.
>
> It seems like those files (EventChannel bookmarks) not longer exist in tmp 
> folder or OSSEC does not have enough permissions, try to reinstall the 
> agent.
> If you prefer, paste here your EventChannel queries so I can test them in 
> my labs.
>
> Best regards,
>
> Pedro S.
>
>
>
> On Fri, May 13, 2016 at 1:37 PM, Abdulvehhab Agin <abdulveh...@gmail.com> 
> wrote:
>
>> When i change verify_msg_id=0; *i have lots of error in ossec log*
>>
>>
>>
>>
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not move 
>> (tmp/Security-a06404) to (bookmarks/Security) which returned (5)
>> 2016/05/13 14:33:17 ossec-agent: ERROR: Could not rename_ex() temporary 
>> bookmark (tmp/Security-a06404) to (bookmarks/Security) for (Security)
>>
>>
>>
>> 12 Mayıs 2016 Perşembe 10:37:15 UTC+3 tarihinde Pedro S yazdı:
>>>
>>> Hi,
>>>
>>> If multiple agents are using the same key, you need to set them up with 
>>> their own unique key.
>>> If you re-installed an agent and didn't backup the rids files, 
>>> you should create a new key for the agent and use that.
>>> If you prefer to avoid any counters error, try to deactivate counters, 
>>> open file etc/internal_options.conf (Manager & Agent) and set 
>>> verify_msg_id=0.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Pedro S.
>>>
>>> On Wednesday, May 11, 2016 at 10:33:00 PM UTC+2, Abdulvehhab Agin wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Sometimes ossec server says *"ERROR: Duplicated counter for"* errors. 
>>>> Especially we have mass log, and log sending protocol is UDP, so rids 
>>>> counter' agent and server sometimes inconsistent;
>>>>
>>>>
>>>> When i see this error, I see the agent is inactive. After this; agent 
>>>> wont send any logs.
>>>>
>>>>
>>>> How can i solve this problem?
>>>>
>>>>
>>>> OSSEC version 2.8.3
>>>>
>>>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

--- 
You received this message because you are subscribed 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 category/group - syslog remote

[Pedro S]

Hi,

You can use JSON output from Wazuh, there is an array field containing all 
the groups so you can search later for them in Kibana: "rule.groups: 'ssh' 
AND rule.groups: ''attacks' ".

Output example:

{
>   "decoder": {
> "name": "pam"
>   },
>   "full_log": "May 13 04:30:21 vpc-ossec-manager sshd[15042]: 
> pam_unix(sshd:session): session opened for user root by (uid=0)",
>   "hostname": "vpc-ossec-manager",
>   "location": "/var/log/auth.log",
>   "program_name": "sshd",
>   "rule": {
> "PCI_DSS": [
>   "10.2.5"
> ],
> "comment": "Login session opened.",
> "firedtimes": 1,
> 
>
>
>
> *"groups": [  "pam",  "syslog",  "authentication_success"
> ],*
> "level": 3,
> "sidid": 5501
>   },
>   "timestamp": "2016 May 13 04:30:22"
> }



Kibana example:

<https://lh3.googleusercontent.com/-4ekH5aIoSfw/VzW8jC3QIiI/ADo/enk4kila6ckiYoe7Pzhc4byPEubcoYf4gCLcB/s1600/2016-05-13%2B13_37_22-Discover%2B-%2BKibana.png>
Also will allow you to create visualizations and dashboards.

Best regards,

Pedro S.





On Wednesday, May 11, 2016 at 4:59:22 AM UTC+2, David Lang wrote:
>
> On Tue, 10 May 2016, dan (ddp) wrote: 
>
> > On May 10, 2016 7:38 PM, "'RICARDO STOCCO' via ossec-list" < 
> > ossec...@googlegroups.com > wrote: 
> >> 
> >> Hello, I have a question 
> >> 
> >> It is possible to send ossec group/s when I use syslog_output? 
> >> 
> >> For example, in the file alert.log I have this log: 
> >> 
> >> 
> >> 
> >> ** Alert 1462920563.18241: - 
> syslog,access_control,authentication_failed, 
> >> 
> >> 2016 May 10 15:49:23 localhost->/var/log/secure 
> >> 
> >> Rule: 2501 (level 5) -> 'User authentication failure.' 
> >> 
> >> May 10 15:49:23 localhost pam: gdm-password: 
> pam_unix(gdm-password:auth): 
> > authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= 
> > user=user 
> >> 
> >> 
> >> 
> >> I want to have information about groups in kibana, for searchs: 
> >> 
> >> "syslog,access_control,authentication_failed" 
> >> 
> >> 
> >> 
> >> It is possible? 
> >> 
> >> 
> > 
> > You'll have to modify the source code. 
>
> Or you can have logstash/rsyslog parse the log and tag it as 
> authentication_failed. 
>
> You really do want to have the log parsed before you put it in 
> ElasticSearch. It 
> can do free-form text searches, but if it's parsed you can do a lot more. 
>
> David Lang 
>

-- 

--- 
You received this message because you are subscribed 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: Duplicated counter

[Pedro S]

Hi,

If multiple agents are using the same key, you need to set them up with 
their own unique key.
If you re-installed an agent and didn't backup the rids files, you should 
create a new key for the agent and use that.
If you prefer to avoid any counters error, try to deactivate counters, open 
file etc/internal_options.conf (Manager & Agent) and set verify_msg_id=0.


Regards,


Pedro S.

On Wednesday, May 11, 2016 at 10:33:00 PM UTC+2, Abdulvehhab Agin wrote:
>
> Hi,
>
>
>
> Sometimes ossec server says *"ERROR: Duplicated counter for"* errors. 
> Especially we have mass log, and log sending protocol is UDP, so rids 
> counter' agent and server sometimes inconsistent;
>
>
> When i see this error, I see the agent is inactive. After this; agent wont 
> send any logs.
>
>
> How can i solve this problem?
>
>
> OSSEC version 2.8.3
>
>

-- 

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

[ossec-list] Re: Prerrequisites Instalation OSSEC

[Pedro S]

Hi,

Regarding to the hardware requirements, depends on your environment and how 
much agents do you want to deploy.

Disk: Depends on the traffic load of your agents, if we could know that we 
can calculate the EPS... how long do want to store the logs? I think 300 GB 
or 500 GB should be enough.
RAM: Again, depends on your traffic (for analysisd daemon and remoted 
daemon), 4 GB should be enough.
Processor: I would say any dual-core processor greater than 2.5 Ghz... 
since OSSEC is not multi-thread I am not sure if you will need more than 
that.
SO: OSSEC Manager needs to run on a Linux platform, Redhat/Debian.


Maybe someone can bring us some light here, but those will be the 
requirements on my opinion!

Best regards,

Pedro S.

On Tuesday, April 26, 2016 at 1:08:15 AM UTC+2, Adiel Navarro wrote:
>
>  
>
> What are the hardware prerrequisites to install OSSEC?
>
>  
>
> I need information about disk, memory, processor, operating system, etc.
>
>  
>
> Thanks, 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.

[ossec-list] Re: UTF-8/16 support

[Pedro S]

Didn't hear about that before.

According to the error maybe is because the UTF-8/16 like you said, we can 
find in logcollector read_multiline log 

 
or at syslog collector 
,
 
I would say OSSEC is not detecting the \n character...


On Sunday, April 17, 2016 at 2:05:53 PM UTC+2, DefensiveDepth wrote:
>
> It appears that OSSEC does not support log files encoded with UTF-8/16? I 
> haven't seen any specific documentation on it, so I wanted to confirm. From 
> the screenshot below, you can see that the once a null char is encountered 
> (after the T), it fails to read any further.
>
> http://screencast.com/t/tqozmdlzje
>
> -Josh
>
>
>

-- 

--- 
You received this message because you are subscribed 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: netstat part of syscheck not seeing all ports on initial read

[Pedro S]

Wow you have a good point, maybe OSSEC is running netstat before some ports 
are open! I think OSSEC check diff only with the last output not 
"perpetually" from the first one, in case you can to check the last netstat 
output registered by OSSEC, cat the file:

/var/ossec/queue/diff/your-agent-or-ossec-manager-name/533/last-entry


In case you want to test if the alerts are triggering, modify some port in 
"last-entry" file and reboot the manager/agent, instantly you will see the 
alert generated. For example I modified on last-entry file SSH port to :

ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort':
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
tcp6   0  0 ::1:25  :::*LISTEN
tcp6   0  0 :::22   :::*LISTEN
Previous output:
ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort':
tcp0  0 *0.0.0.0: * 0.0.0.0:*   
LISTEN
tcp6   0  0 ::1:25  :::*LISTEN
tcp6   0  0 :::22   :::*    LISTEN


Regards,

Pedro S.


On Friday, April 15, 2016 at 3:41:21 PM UTC+2, Noway2 wrote:
>
> Good Morning Pedro,
>
> Thank you for the help. Here is the  section in ossec.conf 
> containing the netstat command
>   
> full_command
> netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort
>   
>
> When I execute that command in a shell, I get the full list of ports.  I 
> am really not sure why the initial run - upon startup (?) is giving the 
> truncated list.
>
> Unless...a thought just occurred to me.  I looked in the rc.d directory 
> for the run level (e.g. 5) and see that Ossec starts at S20 whereas a lot 
> of the processes such as Postfix that opens the ports is starting up after 
> Ossec in which case it thinks that the ports have perpetually changed.
>
>
> On Friday, April 15, 2016 at 6:18:38 AM UTC-4, Pedro S wrote:
>>
>> Hi Noway2,
>>
>> I just test it and it is working for me, could you paste your  
>> section? You can open ossec.conf at OSSEC Manager search for "netstat" and 
>> paste that section here.
>>
>> The rule which trigger this alerts is:
>>
>>  
>> 530
>> ossec: output: 'netstat -tan
>> **
>> Listened ports status (netstat) changed (new port opened 
>> or closed).
>> pci_dss_10.2.7,pci_dss_10.6.1,
>>   
>>
>>
>> Regards,
>>
>> Pedro S.
>>
>>

-- 

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

Re: [ossec-list] RootCheck disableing

[Pedro S]

I have reproduced your configuration on my labs, rootcheck is not starting 
again. Could you re-verify that agent.conf file is right on your agent?

On Thursday, April 14, 2016 at 2:38:47 PM UTC+2, eyal gershon wrote:
>
> 2016/04/14 06:03:17 ossec-rootcheck: INFO: Started (pid: 30101).
> 2016/04/14 06:06:05 ossec-rootcheck: INFO: Starting rootcheck scan.
> 2016/04/14 06:06:05 ossec-rootcheck: No rootcheck_files file configured.
> 2016/04/14 06:06:05 ossec-rootcheck: No rootcheck_trojans file configured.
> 2016/04/14 06:17:38 ossec-rootcheck: INFO: Ending rootcheck scan.
>
> The start of the scan is right after the restart of the ossed-hids restart 
> from the original post
>
> On Thursday, April 14, 2016 at 2:57:36 PM UTC+3, dan (ddpbsd) wrote:
>>
>> On Thu, Apr 14, 2016 at 6:27 AM, eyal gershon  
>> wrote: 
>> > Hey, 
>> > 
>> > I tried to disabled the rootcheck on one of the servers. 
>> > I have added the following line to the agent.conf file - 
>> > 
>> >  
>> > yes 
>> >  
>> > 
>> > and after I am restarting the service I get the following output - 
>> > Starting ossec-hids: 2016/04/14 06:16:27 ossec-rootcheck: Rootcheck 
>> > disabled. Exiting. 
>> > ossec-syscheckd: WARN: Rootcheck module disabled. 
>> > 
>> > and a few min later I see in the logs that the rootcheck is running 
>> again. 
>> > any one have an idea why did I miss? 
>> > 
>>
>> Which log messages are you seeing specifically? 
>>
>> > -- 
>> > 
>> > --- 
>> > You received this message because you are subscribed 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: Windows Agent Compilation

[Pedro S]

Hi Kumar,

Creating the windows installer from Linux SO is easy, I have been doing 
that for months, try to take a look into this 
documentation: 
http://documentation.wazuh.com/en/latest/ossec_installation_win.html 
in *"Compiling from sources"* section.

You will need:

CentOS:
$ yum install gcc-c++ gcc scons mingw32-gcc mingw64-gcc zlib-devel bzip2 
unzip 

Debian:
$ apt-get install gcc-mingw-w64 $ apt-get install nsis $ apt-get install 
make

Regards,

Pedro S.



On Thursday, April 14, 2016 at 3:06:16 PM UTC+2, Kumar Mg wrote:
>
> Thank you Victor.
>
>
> We tried with both 2.8.2 as well as the 2.8.3 version. But both were 
> throwing error for make.
>
> The changes were made as suggested, however there were some errors and not 
> sure if all the executables were created. 
>
> These are the only exe files under src\win-pkg
>  
>
> 04/14/2016  05:30 AM   139,059 add-localfile.exe
>
> 04/14/2016  05:30 AM   376,910 manage_agents.exe
>
> 04/14/2016  05:26 AM17,920 ossec-lua.exe
>
> 04/14/2016  05:26 AM   333,565 ossec-luac.exe
>
> 04/14/2016  05:30 AM   141,048 os_win32ui.exe
>
> 04/14/2016  05:30 AM   142,606 setup-iis.exe
>
> 04/14/2016  05:30 AM   159,043 setup-syscheck.exe
>
>7 File(s)  1,310,151 bytes
>
>
> These were the error we got while make.
>
> C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
>
> rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-agent" -Wall 
>  -DARGV0=\"ossec-agent\
>
> " -DCLIENT -DWIN32 -DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c 
> zlib-1.
>
> 2.8/*.c config/*.c shared/*.c os_execd/*.c os_crypto/blowfish/*.c 
> os_crypto/md5/
>
> *.c os_crypto/sha1/*.c os_crypto/md5_sha1/*.c os_crypto/shared/*.c 
> rootcheck/*.c
>
> *.c -I. -Iheaders/ -lwsock32
>
> rootcheck/win-common.c: In function '__os_winreg_querykey':
>
> rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but 
> not us
>
> ed [-Wunused-but-set-variable]
>
>  TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
>
>^
>
> In file included from run_realtime.c:45:0:
>
> headers/shared.h:181:0: warning: "os_calloc" redefined
>
> #define os_calloc(x,y,z) ((z = calloc(x,y)))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0
>
> )
>
> ^
>
> run_realtime.c:29:0: note: this is the location of the previous definition
>
> #define os_calloc(x,y,z) (z = calloc(x,y))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0)
>
> ^
>
> In file included from run_realtime.c:45:0:
>
> headers/shared.h:183:0: warning: "os_strdup" redefined
>
> #define os_strdup(x,y) ((y = strdup(x)))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0)
>
> ^
>
> run_realtime.c:30:0: note: this is the location of the previous definition
>
> #define os_strdup(x,y) (y = strdup(x))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
>
> ^
>
> C:\Users\ADMINI~1\AppData\Local\Temp\cccRUZbH.o:file_op.c:(.text+0x9e6): 
> undefin
>
> ed reference to `_imp__PathFindFileNameA@4'
>
> collect2.exe: error: ld returned 1 exit status
>
>  
>
>
> C:\Users\Administrator\Desktop\ossec_compile\ossec-hids-2.8.3\ossec-hids-2.8.3\s
>
> rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-rootcheck" -Wall 
>  -DARGV0=\"ossec-ro
>
> otcheck\" -DCLIENT -DWIN32 icon.o os_regex/*.c os_net/*.c os_xml/*.c 
> config/*.c
>
> shared/*.c win_service.c rootcheck/*.c -Iheaders/ -I. -lwsock32
>
> rootcheck/rootcheck-config.c: In function 'Read_Rootcheck_Config':
>
> rootcheck/rootcheck-config.c:69:18: warning: variable 'xml_time' set but 
> not use
>
> d [-Wunused-but-set-variable]
>
>  const char *(xml_time[])={xml_rootcheck, "frequency", NULL};
>
>   ^
>
> rootcheck/win-common.c: In function '__os_winreg_querykey':
>
> rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but 
> not us
>
> ed [-Wunused-but-set-variable]
>
>  TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
>
>^
>
> C:\Users\ADMINI~1\AppData\Local\Temp\ccFt34en.o:file_op.c:(.text+0x9e6): 
> undefin
>
> ed reference to `_imp__PathFindFileNameA@4'
>
> collect2.exe: error: ld returned 1 exit status
>
> The lua file compilation has fixed the error at the time of creating 
> executable, but failing now with it not finding 
> ossec-agent-eventchannel.exe at line 149 in ossec-installer.nsi.
>
> We also tried out making the package from Linux server, seems like its not 
> able to find out the required mingw gcc compilers on them. Checking going 
> on.
>
> Regards
> Kumar
>
>

-- 

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

[ossec-list] Re: Email notification for adding new users, new packages, triggering hours later

[Pedro S]

What OS are you running? Linux isn't it? Extracted from OSSEC Docs: *"Real 
time only works with directories, not individual files. So you can monitor 
the /etc or C:\program files directory, but not an individual file like 
/etc/file.txt."*

In my experience, I can tell you real time does not work if syscheck scan 
is running, I mean, if the scan is running realtime option won't work until 
syscheck finishes the scan.

Regards,

Pedro S.

On Thursday, April 14, 2016 at 8:51:20 PM UTC+2, thak wrote:
>
> So after some investigating it seems what's ACTUALLY happening is that the 
> realtime notifications aren't working, and the syscheck 20 hour scan is 
> picking up the changes. Thus, one could reasonably (I think) interpret this 
> as delayed realtime notifications. 
>
> I certainly have the realtime="yes" option set for these directories, and 
> the inotify package installed. Anything else I'm missing? Might give the 
> agents a restart just in case. 
>
> On Thursday, April 14, 2016 at 2:21:02 PM UTC-4, thak wrote:
>>
>> I hadn't really considered the mail server may be the problem - we 
>> naturally utilize sendmail to offload the notifications and route them 
>> through our corporate O365 exchange server. 
>>
>> I was getting some integrity changes hours after the changes actually 
>> occurred (on boxes with realtime=yes and inotify packages installed). I 
>> also double checked my inbox, and this particular alert (for a file being 
>> re-added, i.e. a new version) only appears once in my inbox. 
>>
>> On Wednesday, April 6, 2016 at 4:40:08 PM UTC-4, ba...@x-cart.com wrote:
>>>
>>> did you look to maillog of your server ?
>>> When were actual sent notifications ?
>>> Email may be deferred by couple of reasons:
>>> * graylisting
>>> * mail server overloading or even inactivvity.
>>>
>>> If you want fast and reliable delivery - try to setup additional 
>>> notification engine.
>>> We choose slack, but there're couple of chat systems, that can receive 
>>> notifications by their api.
>>>
>>> среда, 6 апреля 2016 г., 17:33:03 UTC+4 пользователь thak написал:
>>>>
>>>> Any idea what the likely reason would be for this? We were installing 
>>>> some diagnostic packages yesterday afternoon, but I didn't get email 
>>>> notifications until 0430 today. 
>>>>
>>>

-- 

--- 
You received this message because you are subscribed 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: netstat part of syscheck not seeing all ports on initial read

[Pedro S]

Hi Noway2,

I just test it and it is working for me, could you paste your  
section? You can open ossec.conf at OSSEC Manager search for "netstat" and 
paste that section here.

The rule which trigger this alerts is:

 
530
ossec: output: 'netstat -tan
**
Listened ports status (netstat) changed (new port opened 
or closed).
pci_dss_10.2.7,pci_dss_10.6.1,
  


Regards,

Pedro S.





On Thursday, April 14, 2016 at 10:38:59 PM UTC+2, Noway2 wrote:
>
> I have been using Ossec on a couple of my servers for several years now.  
> I recently updated one of them to Ubuntu 14.04 server edition and found 
> that the agent running on that machine was no longer communicating with the 
> server.  I took this as an opportunity to upgrade both machines from 
> version 2.6 to 2.8 and I am running into a new issue that I am not sure how 
> to handle. 
>
> I am getting repeated alerts about the netstat command detecting new ports 
> open.  Specifically I am getting the report shown below:
>
>  
>
>> ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort':
>> tcp0  0 0.0.0.0:110 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:139 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:143 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:25  0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:445 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:465 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:587 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:993 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:995 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 172.16.10.3:53  0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 192.168.0.49:53 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 192.168.0.49:6470.0.0.0:*   LISTEN   
>>   
>> tcp6   0  0 :::139  :::*LISTEN   
>>   
>> tcp6   0  0 ::1:783 :::*  
>> Previous output:
>> ossec: output: 'netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort':
>> tcp0  0 0.0.0.0:110 0.0.0.0:*   LISTEN   
>>   
>> tcp0  0 0.0.0.0:139 0.0.0.0:*   LISTEN   
>>
>>
> According to my interpretation of this output, it is trying to tell me 
> that when the initial scan was run the only ports with applications 
> listening on them were 110 and 139.  I know however this is incorrect 
> because the system was up, active, and had all of these other processes 
> running, nor are they routinely terminated and some of them were even 
> actively connected to at the time, such as port 22 for SSH.
>
> This same message will repeat periodically, claiming that the same two 
> ports were open in the previous reading and all the ports are currently 
> open.  It never seems to update or correct itself.
>
> I tried stopping ossec, going into the /var/ossec/queue directory and 
> deleting everything (there were only two files) and restarting it.  This 
> seemed to silence this error for several hours and then it started again.
>
> I like the idea of the feature and would like to correct it rather than 
> disable it (if that is even possible), but the repeated erroneous alerts 
> are seriously annoying.
>
> Does anyone have a suggestion as to why this feature does not appear to be 
> working correctly and how to fix 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro S]

Thanks! nice work-around.

On Friday, April 15, 2016 at 11:15:30 AM UTC+2, 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.

[ossec-list] Re: When new ossec build is planning ?

[Pedro S]

If you are talking about this 
commit: 
https://github.com/ossec/ossec-hids/commit/dbf841c595a4b6a5a0203b04651b5efb14d95e7d#diff-45abb2823a60f0163e56942090cdb53f

You do not need to reinstall OSSEC to include it, or install a new 
packages, just add the following rule into your 
/var/ossec/rules/proftpd_rules.xml:


 
11200 
unable to open incoming connection 
Couldn't open the incoming connection.  
Check log message for reason. 
 

Regards,

Pedro S.

On Tuesday, April 5, 2016 at 8:06:17 PM UTC+2, ba...@x-cart.com wrote:
>
> Hello!
> I very interested in this commit for support proftpd logs.
>
> Is there're any plans on new ossec deb packages, that will include this 
> commit ?
> Or better way is build ossec myself ?
>
> 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.

Re: [ossec-list] OSSEC agents show as Active even after the OSSEC Process on server is stopped

[Pedro S]

Jesus is totally right.

The time out he is talking about is:* 3*NOTIFY_TIME+30*, *NOTIFY_TIME* by 
default is 600 seconds.

Check the last modification file date on every agent-info/* file and wait 
until that time be more than 30'30''.

Best regards,

Pedro S.


On Thursday, April 7, 2016 at 8:08:02 PM UTC+2, Jesus Linares wrote:
>
> Hi,
>
> in order to know if an agent is connected, disconnected or never connected 
> OSSEC reads the modification date of the files in 
> */var/ossec/queue/agent-info/*:*
>
>- if there is no file for the agent the status is *never connected*
>- if the modification time of the file is less than a defined tiemout, 
>the status is *actived*. If it is greater then the status is 
>*disconnected*.
>
> I guess those files are updated by the Manager each time that the agents 
> send a "keep-alive".
>
> I'm not sure, but I think the timeout is around 30 minutes.
>
> Regards,
> Jesus Linares.
>
> On Tuesday, April 5, 2016 at 5:26:10 PM UTC+2, sandeep wrote:
>>
>> Hello Dan,
>>
>> Thanksf for the reply. Yeah its the old data, I ran ./agent_control 
>> -lc|grep ID:|wc -l to list the count of agents active and it shows as 3k 
>> even though the manager's ossec process is stopped. I am trying to figure 
>> out where the cache is stored. I need to remove that data before starting 
>> the manager's OSSEC process back.
>>
>> Without removing that data, if i start back the manager's ossec process 
>> the 3k count remains the same and the remaining agents do not show up as 
>> active.
>>
>> Thanks,
>> Sandeep.
>>
>

-- 

--- 
You received this message because you are subscribed 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: new files does not creating alert at all

[Pedro S]

Hi,

That decoder is hardcoded 
<https://github.com/wazuh/ossec-wazuh/blob/5441889d963ce6d8ee3fae0e9f273e701b6c89eb/src/analysisd/rules.h#L231>into
 
OSSEC code, so you won't find any decoder called like that.

Best regards,

Pedro S.



On Monday, April 4, 2016 at 8:06:58 PM UTC+2, jingxu...@bettercloud.com 
wrote:
>
> Yes, I noticed the difference, add new file entry will not be real-time. 
> But what if I restart the agent and manager, will it rescan and then 
> generate that event right after I restart everything. 
>
> And also, my issue is I waited for the interval, however, I still would 
> not be able to get a log event even I create some new files and 
> directories. 
>
> My last question is within that rule, the decoder name is 
> syscheck_new_entry, where the decoder file is, I can not find this decoder 
> in the decoders folder.
> Thank you.
>
> On Friday, April 1, 2016 at 6:49:42 AM UTC-4, Jesus Linares wrote:
>>
>> Check out this blog: 
>> http://perezbox.com/2013/07/ossec-detecting-new-files-understanding-how-it-works/
>>
>> Pay attention to the part: "REAL TIME VS ALERT ON NEW".
>>
>> Regards,
>> Jesus Linares.
>>
>> On Thursday, March 31, 2016 at 9:08:37 PM UTC+2, 
>> jingxu...@bettercloud.com wrote:
>>>
>>> I followed the instructions to how to set up alert for add new file as 
>>> follows:
>>>
>>> 
>>>   ossec
>>>   syscheck_new_entry
>>>   File added to the system.
>>>   syscheck,
>>>
>>>
>>> and 
>>>
>>> 
>>>   7200
>>>   yes
>>>   /etc,/bin,/sbin
>>>
>>>
>>> But it never works. I can not get alerts even I restart the agent and 
>>> manager. Could any one help me with this, thanks 
>>>
>>>

-- 

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

[ossec-list] Re: How are the best test to ossec rules

[Pedro S]

Testing OSSEC installation or OSSEC Rules? I am with Dan, define "test" 
hehe, what do you want exactly.

On Tuesday, April 5, 2016 at 4:58:46 PM UTC+2, tchello2008br wrote:
>
> Hi all 
> I want to test my installation , what is the best method ? 
>
> Tks 
>

-- 

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

[Pedro S]

You can set up on OSSEC any SMTP server and it will use it to send the 
emails, BUT OSSEC is not able to use SMTP authentication.

Amazon SES works with TLS authentication so.. I don't think OSSEC 
out-the-box can use Amazon SES.

Instead of that you can probably configure Amazon SES SMTP account into a 
local postfix server, and then set up OSSEC to send emails using postfix (I 
made this before with other SMTP TLS servers).

OSSEC -> postfix -> Amazon SES.




On Wednesday, March 30, 2016 at 11:36:41 AM UTC+2, sandeep wrote:
>
> Hi, 
>
> Can i use third party email provider to send OSSEC emails ? For example 
> AWS's SES service. 
>
> On Thu, Mar 24, 2016 at 3:27 PM, sandeep dubey  > wrote:
>
>> Thanks for the update.
>> On 24-Mar-2016 3:09 PM, "dan (ddp)"  
>> wrote:
>>
>>>
>>> On Mar 24, 2016 12:21 AM, "sandeep dubey" >> > wrote:
>>> >
>>> > Got it, thanks much. Is it suggested to remove that line for these 
>>> rules ? 
>>> >
>>>
>>> That's between you and your security policy. I personally like 1002, I 
>>> even wrote a faq entry on it.
>>>
>>> > On Wed, Mar 23, 2016 at 7:52 PM, dan (ddp) >> > wrote:
>>> >>
>>> >> On Wed, Mar 23, 2016 at 10:19 AM, sandeep dubey
>>> >>  wrote:
>>> >> > Thanks Dan for the reply.
>>> >> >
>>> >> > I couldn't understand your comment -
>>> >> >
>>> >> > Both of these set:
>>> >> > alert_by_email
>>> >> >
>>> >>
>>> >> If you look at /var/ossec/rules/syslog_rules.xml, you can see rule
>>> >> 10100 sets the above option. This means it will always send an email
>>> >> when it is triggered.
>>> >> Rule 1002 has the same option set. So no matter what your minimum rule
>>> >> level is, these rules will trigger emails.
>>> >>
>>> >> > On Wed, Mar 23, 2016 at 7:37 PM, dan (ddp) >> > wrote:
>>> >> >>
>>> >> >> On Wed, Mar 23, 2016 at 10:01 AM, sandeep dubey
>>> >> >>  wrote:
>>> >> >> >> Ok, so it works when you use an individual email address, but 
>>> not when
>>> >> >> >> you use a group?  Which system handles the group email address? 
>>> Can
>>> >> >> >> you check the logs there?
>>> >> >> >
>>> >> >> > Yes, when i use group emails are not being relayed. I am using 
>>> Google
>>> >> >> > service. In logs i don't find anything except mentioned in 
>>> previous
>>> >> >> > thread.
>>> >> >>
>>> >> >> Use tcpdump to see if there is any difference between the 2 email
>>> >> >> addresses.
>>> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> > One more observation is that, even though email alerts is 
>>> configured
>>> >> >> >> > for
>>> >> >> >> > level 8, I am still getting alerts for level 2,3,4 etc.
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> That's very strange. I trust you've verified that the rules of 
>>> level <
>>> >> >> >> 8 that trigger email alerts don't have
>>> >> >> >> "alert_by_email" set.
>>> >> >> >> Which rules with level < 8 are triggering emails?
>>> >> >> >
>>> >> >> >
>>> >> >> > Triggered emails are of level 2,4 and rules id is 1002,10100
>>> >> >> >
>>> >> >>
>>> >> >> Both of these set:
>>> >> >> alert_by_email
>>> >> >>
>>> >> >> --
>>> >> >>
>>> >> >> ---
>>> >> >> You received this message because you are subscribed 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.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Regards,
>>> >> > Sandeep
>>> >> >
>>> >> > --
>>> >> >
>>> >> > ---
>>> >> > You received this message because you are subscribed to the Google 
>>> Groups
>>> >> > "ossec-list" group.
>>> >> > To unsubscribe from this group and stop receiving emails from it, 
>>> send an
>>> >> > email to ossec-list+...@googlegroups.com .
>>> >> > For more options, visit https://groups.google.com/d/optout.
>>> >>
>>> >> --
>>> >>
>>> >> ---
>>> >> You received this message because you are subscribed to the Google 
>>> Groups "ossec-list" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to ossec-list+...@googlegroups.com .
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> >
>>> >
>>> >
>>> > -- 
>>> > Regards,
>>> > Sandeep
>>> >
>>> > -- 
>>> >
>>> > --- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "ossec-list" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to ossec-list+...@googlegroups.com .
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>>>
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "ossec-list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to ossec-list+...@googlegroups.com .
>>> For more 

Re: [ossec-list] How to ignore log ?

[Pedro S]

Did you run ossec-logtest to verify that your log triggers the rule just 
created?

Try to run it and paste the log, if the rule 81 is not being fired 
something went wrong with the rule creation.

On Wednesday, March 30, 2016 at 8:10:39 AM UTC+2, sandeep wrote:
>
> Hi Dan,
>
> Thanks for the detailed step and rule. I tried the same and still getting 
> alert.
> On 29-Mar-2016 9:07 PM, "dan (ddp)"  
> wrote:
>
>> On Tue, Mar 29, 2016 at 11:29 AM, sandeep dubey
>>  wrote:
>> > Hi,
>> >
>> > I am getting this alert form all the hosts -
>> >
>> > Mar 29 13:30:02 cmcloud kernel: [885866.238608] type=1400
>> > audit(1459258202.301:67688): apparmor="DENIED" operation="ptrace"
>> > profile="docker-default" pid=21882 comm="ps" requested_mask="trace"
>> > denied_mask="trace" peer="unconfined"
>> >
>> > to disable this alerts i have written this -
>> > 
>> > no_email_alert
>> > apparmor="DENIED"  profile="docker-default"
>> > IGNORED RULE
>> > 
>> >
>> > and restarted the ossec master service, still getting same alert
>> > what am i missing here ?
>> >
>>
>> The first step is to run the log message through ossec-logtest:
>> ossec-testrule: Type one log per line.
>> **Phase 1: Completed pre-decoding.
>>full event: 'Mar 29 13:30:02 cmcloud kernel: [885866.238608]
>> type=1400 audit(1459258202.301:67688): apparmor="DENIED"
>> operation="ptrace" profile="docker-default" pid=21882 comm="ps"
>> requested_mask="trace" denied_mask="trace" peer="unconfined"'
>>hostname: 'cmcloud'
>>program_name: 'kernel'
>>log: '[885866.238608] type=1400 audit(1459258202.301:67688):
>> apparmor="DENIED" operation="ptrace" profile="docker-default"
>> pid=21882 comm="ps" requested_mask="trace" denied_mask="trace"
>> peer="unconfined"'
>>
>> **Phase 2: Completed decoding.
>>decoder: 'iptables'
>>status: 'DENIED'
>>extra_data: 'ptrace'
>>
>> **Phase 3: Completed filtering (rules).
>>Rule id: '52002'
>>Level: '3'
>>Description: 'Apparmor DENIED'
>> **Alert to be generated.
>>
>>
>> So the log message is currently triggering rule 52002. We'll use this
>> in our rule.
>> The status is DENIED, which can also be useful.
>> So we'll write a basic rule that tries to match on these:
>>
>> 
>>   DENIED
>>   profile="docker-default"
>>   IGNORE RULE
>> 
>>
>> I add this to /var/ossec/rules/local_rules.xml. I set the level to 0
>> because I don't care about it.
>> Then I rerun ossec-logtest:
>> ossec-testrule: Type one log per line.
>> **Phase 1: Completed pre-decoding.
>>full event: 'Mar 29 13:30:02 cmcloud kernel: [885866.238608]
>> type=1400 audit(1459258202.301:67688): apparmor="DENIED"
>> operation="ptrace" profile="docker-default" pid=21882 comm="ps"
>> requested_mask="trace" denied_mask="trace" peer="unconfined"'
>>hostname: 'cmcloud'
>>program_name: 'kernel'
>>log: '[885866.238608] type=1400 audit(1459258202.301:67688):
>> apparmor="DENIED" operation="ptrace" profile="docker-default"
>> pid=21882 comm="ps" requested_mask="trace" denied_mask="trace"
>> peer="unconfined"'
>>
>> **Phase 2: Completed decoding.
>>decoder: 'iptables'
>>status: 'DENIED'
>>extra_data: 'ptrace'
>>
>> **Phase 3: Completed filtering (rules).
>>Rule id: '81'
>>Level: '0'
>>Description: 'IGNORE RULE'
>>
>> With the custom rule in place the log message is adequately ignored.
>>
>> > --
>> > Regards,
>> > Sandeep
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google 
>> Groups
>> > "ossec-list" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an
>> > email to ossec-list+...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 

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

[ossec-list] Re: id "|" or "," ??

[Pedro S]

I think it is hard to simulate correlation on OSSEC, it has some tools as 
you said like frecuency, timeframe, if_matched_sid, if_matched_group... I 
think the best and simple approach is to create two rules matching the 
ID's, but as far as I know It won't work as you desired.

For example:

   
18103
^4000$|^4001$
Match of Windows Event ID 4000 OR 4001
authentication_success,pci_dss_10.2.5,
  


  
18500
^4001$
Match of Windows Event ID 4000 followed of 4001

authentication_success,pci_dss_10.2.5,
  


The second rule will trigger only if there is a previous match of 4000 or 
4001. I don't know any other approach to solve this.
Maybe we can use active response to execute an script which store the info 
and at some point triggers an alert.

I hope someone can bring us some light here.

Regards,

Pedro S.

On Tuesday, March 29, 2016 at 4:21:36 PM UTC+2, Rob B wrote:
>
> Thank you for taking the time to answer with examples Pedro!
>
> One last related question if ya don,t mind..? I am trying to wrap
> my head around a rule firing off after a simple bit of correlation.
> Is it possible?  I know this is the job of the SIEM, but I am trying
> to get the SIEM to only correlate fired upon alerts that are qualified
> by a mechanism first. So, for example, I would like a rule to fire on
> event 4567 that was followed by 4523 then followed by 4625 between 1
> and 50 times, then a 4624... (when all these things match the rule
> fires)
>
> I see that rules have the ability of setting frequency and time frame,
> which would help me, though I am at a loss for the remainder of my
> needs.  Seems an external script may be needed along with a sort of
> temporary repository. ( I may be over thinking this and mucking it up
> )
>
>
> What could you suggest?
>
>
> V/R,
> Rob B.
>
> On Tuesday, March 29, 2016 at 7:41:21 AM UTC-4, Pedro S wrote:
>>
>> If you need to filter for one specific ID you need to use the *pipe |* 
>> option, I don't think you can use "," inside ** tags to 
>> concatenate anything.
>> "," character will be treated like an string character not a regex one so 
>> it will try to match for *"IDNumber,".*
>>
>> As you know, one example of this kind of rule is used on 
>> *msauth_rules.xml:*
>>
>>   
>>> 18105
>>> 
>>> ^529$|^530$|^531$|^532$|^533$|^534$|^535$|^536$|^537$|^539$|^4625$
>>> Windows Logon Failure.
>>> 
>>> win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
>>>   
>>
>>
>> This last one will work, and the following one WON'T work:
>>
>>   
>>> 18105
>>> ^529$,^530$,^531$,^532$,^533$
>>> Windows Logon Failure.
>>> 
>>> win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
>>>   
>>
>>
>>
>> Regards,
>>
>> Pedro S.
>>
>>  
>>
>>
>> On Monday, March 28, 2016 at 9:07:30 PM UTC+2, Rob B wrote:
>>>
>>> Heya Folks,
>>>
>>>   I've been looking for the docs that explain the difference between the 
>>> use of the '|" and the "," when specifying the id numbers within a rule. I 
>>> cant find anything that explains the use.
>>>
>>> Could someone explain to me the differences by way of use?  or provide a 
>>> link that I may have missed?
>>>
>>>
>>>
>>> Two arbitrary use case EXAMPLES of what I am after is:
>>>
>>> A.)  Within sid 18103, look for id 12345 followed by 12346, followed by 
>>> 12347
>>> B.)  Within sid 18103, look for id 11234 and 11254
>>>
>>>
>>> Thank you!
>>>
>>> R.B.
>>>
>>

-- 

--- 
You received this message because you are subscribed 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: id "|" or "," ??

[Pedro S]

If you need to filter for one specific ID you need to use the *pipe |* 
option, I don't think you can use "," inside ** tags to 
concatenate anything.
"," character will be treated like an string character not a regex one so 
it will try to match for *"IDNumber,".*

As you know, one example of this kind of rule is used on *msauth_rules.xml:*

  
> 18105
> 
> ^529$|^530$|^531$|^532$|^533$|^534$|^535$|^536$|^537$|^539$|^4625$
> Windows Logon Failure.
> win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
>   


This last one will work, and the following one WON'T work:

  
> 18105
> ^529$,^530$,^531$,^532$,^533$
> Windows Logon Failure.
> win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
>   



Regards,

Pedro S.

 


On Monday, March 28, 2016 at 9:07:30 PM UTC+2, Rob B wrote:
>
> Heya Folks,
>
>   I've been looking for the docs that explain the difference between the 
> use of the '|" and the "," when specifying the id numbers within a rule. I 
> cant find anything that explains the use.
>
> Could someone explain to me the differences by way of use?  or provide a 
> link that I may have missed?
>
>
>
> Two arbitrary use case EXAMPLES of what I am after is:
>
> A.)  Within sid 18103, look for id 12345 followed by 12346, followed by 
> 12347
> B.)  Within sid 18103, look for id 11234 and 11254
>
>
> Thank you!
>
> R.B.
>

-- 

--- 
You received this message because you are subscribed 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: Change ossec.conf globaly

[Pedro S]

I can't imagine a way to change ossec.conf on every agent if you are not 
using some deployment software (like Puppet).

One solution for further installations is to change default ossec.conf file 
in order to include your EventID exception.

Regards,

Pedro S.

On Monday, March 7, 2016 at 3:02:49 PM UTC+1, Abdulvehhab Agin wrote:
>
> Hi,
>
>
> We have lots of ossec.agent on Windows system; These ossec's generate too 
> much *"Audit Logs"* and we don't want to collects these logs;
>
>
> When i change Ossec.conf  on client manually :
>
>
> ## New Ossec.conf
> 
>
> 
>   Security
>   eventchannel
>   Event/System[EventID!="4648" and EventID!="4656" and 
> EventID!="4658"]
> 
>
> 
>
>
> It works good but, we don't want to change this config manually on each 
> computer; Is there a way to deploy this config via OSSEC Server like 
> shared/agent.conf
>
>
>
> Thanks for any 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: Help needed with Ossec implementation

[Pedro S]

Hi,

If you need to forward to Elastic all the events (not only alerts), try to 
enable the option *yes* (available at Wazuh Fork 
<https://github.com/wazuh/ossec-wazuh>) like this:

ossec.conf

  
 yes
  

You will find a log file at */var/ossec/logs/archives/archives.json, *then 
set up Logstash conf file to read from that file:

input {
  file {
type => "ossec-alerts"
path => "/var/ossec/logs/archives/*archives*.json"
codec => "json"
  }
}

Set the output to Elasticsearch server:

output {
  elasticsearch {
 hosts => ["your_elastic_search_ip:9200"]
 index => "ossec-%{+.MM.dd}"
 document_type => "ossec"
 template => "/etc/logstash/elastic-ossec-template.json"
 template_name => "ossec"
 template_overwrite => true
}
}

If everything goes well, you should see on Kibana every log collect by your 
OSSEC agents.

Be careful, archives option collect *everything *so archives.json/log and 
elasticsearch indexes will be huge if you have a large deployment.

Regards,

Pedro S.


On Thursday, March 3, 2016 at 11:07:05 AM UTC+1, Bhuvanesh Bhuvanachandran 
wrote:
>
> Hi Folks,
>
>  
>
> I am new to Ossec, and trying out the functionalities of Ossec for a 
> requirement in my company. I need some help with some of the concepts that 
> I am trying to achieve.
>
>  
>
> Basically I am using a combination of  Ossec + Logstash + Elastic search  
> Kibana  to get the things visualized in a useful way. All these components 
> integrated successfully.
>
>  
>
> I have one apache web server (for testing purpose ) which is monitored by 
> Ossec agent and the results are getting shipped to the Ossec server.  But 
> when looking at the syslog output  of Ossec server I can only see some 
> suspicious/error log entries of apache; like log entries with 400 error 
> code, that triggers some Ossec rules. On IDS point of view it is perfect. 
> But I need all logs getting shipped to a central server.
>
>  
>
> What I am expecting here is, I want to get all logs of apache (Including 
> 200 status code) get shipped to Ossec server and made available at the 
> syslog output of Ossec server so that logstash can further parse the logs.
>
>  
>
> Is this something possible with Ossec ?  If it is how I can achieve this ? 
> Please advise.
>
>  
>
>  
>
> Thanks & Regards,
>
>  
>
> Bhuvanesh
>

-- 

--- 
You received this message because you are subscribed 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: Decoding long messages - multiple regex statements

[Pedro S]

Hi Fredrik,

I don't think OSSEC allow regex to work backwards, from end to beginning, I 
know that can be specify on other languages with some flags, but I am not 
sure if we can do that here. 

Regarding to your decoder, we have two options, include the extraction of 
"resource" and product" fields on the same decoder:

FULL DECODER


  Checkpoint
  (\w+) \p\w+ \w+ 
src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)\.*resource: 
(\.*);\.*product: (\.*);
  action,srcip,dstip,url,extra_data


Or in a better way, separate the extraction in two different decoders, so 
we can be sure that in case of "resource" and "product" fields do not 
exists, our decoder still will parse and work.

SPLIT DECODERS:


  Checkpoint
  (\w+) \p\w+ \w+ 
src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)
  action,srcip,dstip




  Checkpoint
  \.*resource: (\.*);\.*product: (\.*);
  url,extra_data




LOGTEST OUTPUT
**Phase 1: Completed pre-decoding.
   full event: 'Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1 
allow http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15 product: Application 
Control; service: http; s_port: 58579; product_family: Network;'
   hostname: '127.0.0.1'
   program_name: '(null)'
   log: 'Jan 27 9:32:28 st4600fw01n1 allow http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15 product: Application 
Control; service: http; s_port: 58579; product_family: Network;'


**Phase 2: Completed decoding.
   decoder: 'Checkpoint'
   action: 'allow'
   srcip: '192.168.1.15'
   dstip: '89.208.212.2'
*   url*
*: 'http://www.aliveproxy.com/'   extra_data: 'Application Control'*


**Phase 3: Completed filtering (rules).
   Rule id: '4100'
   Level: '0'
   Description: 'Firewall rules grouped.'


In both decoders, I am using wildcards *.* *and expecting always "*resource*" 
before "*product*", either way won't work. 

You asked about using another "regex" line in the same decoder, it will 
work too, like this:


  Checkpoint
  (\w+) \p\w+ \w+ 
src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)
  *\.*resource: (\.*);\.*product: (\.*);*
  action,srcip,dstip, url, extra_data




Best regards,

Pedro S.



On Wednesday, March 2, 2016 at 11:03:08 AM UTC+1, Fredrik wrote:
>
> Hi All,
>
>
> Came across this where I think I would be helped by extracting fields both 
> in forward (from beginning) and in reverse (from end) order of messages!? 
> Is this possible, if so, is it stupid given that there are other (better) 
> ways to accomplish the same thing :/ ? 
>
> In addition to the fields my current decoder extracts, I was hoping to 
> extract the resource (http://www.aliveproxy.com/) and also the product 
> (Application 
> Control;). My idea was to add a secondary statement, before the  
> statement, something in the lines of:
> $/p\w+\s[...] and work my way backward so that I can extract 
> Application Control and resource . How would you suggest I do this?! 
>
> Thanks again for all the great help - hope my threads (and questions) can 
> be useful for other newstarters outhere trying to get there feet off the 
> ground ;) 
>
> Best regards,
> Fredrik 
>
> LOG-MESSAGE
>
> *Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1 *allow  src: 192.168.1.15; dst: 89.208.212.2; proto: tcp; appi_name: **; 
> app_desc: **; app_id: 10063753; app_category: **; matched_category
> : **; app_properties: **; app_risk: **; app_rule_id: **; 
> app_rule_name: **; web_client_type: Chrome; web_server_type: Microsoft
> -IIS; app_sig_id: 10063753:5; resource: http://www.aliveproxy.com/; 
> proxy_src_ip: 192.168.1.15 product: Application Control; service: http; 
> s_port: 58579; product_family: Network;
>
> MY CURRENT DECODER
>
> 
>   ^\w+ \d+ \d+:\d+:\d+ st4600fw01n\d
>   firewall
> 
>
> 
>   Checkpoint
>   (\w+) \p\w+ \w+ 
> src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)
>   action,srcip,dstip
> 
>
> LOGTEST OUTPUT
>
>
> **Phase 1: Completed pre-decoding.
>full event: 'Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1 
> allow  appi_name: **; app_desc: **; app_id: 10063753; app_category: 
> **; matched_category: **; app_properties: **; app_risk: **; 
> app_rule_id: **; app_rule_name: **; web_client_type: Chrome; 
> web_server_type: Microsoft-IIS; app_sig_id: 10063753:5; resource: 
> http://www.aliveproxy.com/; proxy_src_ip: 192.168.1.15; product: 
> Application Control; service: http; s_port: 58579; product_family: Network;'
>hostname: '127.0.0.1'
>program_name: '(null)'
>log: 'Jan 27 9:32:28 st4600fw01n1 allow  192.168.1.15; dst: 89.208.212.2; proto: tcp; appi_name: **; app_desc: 
> **; app_id: 10063753; app_cate

[ossec-list] Re: help me phase pre-decode

[Pedro S]

Hi Luan,

Pre-decoders are hardcoded in OSSEC code, to modify or add a new predecoder 
you have to write it directly on C code 
<https://github.com/wazuh/ossec-wazuh/blob/master/src/analysisd/cleanevent.c>, 
check for example the syslog pre-decoder. 
<https://github.com/wazuh/ossec-wazuh/blob/master/src/analysisd/cleanevent.c#L77>


Regards,

Pedro S.



On Sunday, February 28, 2016 at 2:43:09 PM UTC+1, luan vo wrote:
>
> Hello everyone , I began to learn OSSEC . Can tell me *pre - decod*e 
> stage can tweak it? thank for all
>

-- 

--- 
You received this message because you are subscribed 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: Log rotation by ossec-monitord

[Pedro S]

Hi,

Archives functionality is designed to log everything (all the events, be 
alerts or not), I think is pretty normal that this file grows so much if 
you have a large environment.

I can't see a way to make OSSEC rotate the file more than daily (or split 
it), if you want to split the file with an external application (like 
logrotate), maybe that works, I just test it and OSSEC does not complain if 
you modify alerts.log or archives.log.
Anyway be aware of not deleting *archives.log* symlink or 
*archives/year/month/ossec-archives-day.log,* OSSEC won't register any 
events until next day.


Regards, 

Pedro S.


On Friday, February 26, 2016 at 2:14:30 PM UTC+1, Openshaw, Dave wrote:
>
> Hello
>
>  
>
> Please tell me, how can I change settings for log rotation by 
> ossec-monitord? I see only options that change compression and signing.
>
> If this is not possible can I use logrotate.d to produce splinter copies 
> of the ‘archives’ file (which is very large in my environment) on a more 
> regular basis than the daily copy ? will chroot limitation allow this ?
>
>  
>
> The reason for this is that we do not use OSSEC as the SIEM in this 
> scenario and therefore parse the archives file on a realtime basis using a 3
> rd party SIEM agent which does not like enormous/dynamic files.
>
>  
>
> Kind Regards
>
> *Dave.O *
>
>  
>
>  
>

-- 

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

[Pedro S]

The proxy server will be a good external solution of course, 

About OSSEC, maybe we need something like "reload", NOT restart, reload 
could allow OSSEC to read again all the configuration files and refresh 
internal structures, sure it won't be easy but.. just thinking.

On Thursday, February 25, 2016 at 8:56:08 PM UTC+1, Antonio Querubin wrote:
>
> On Thu, 25 Feb 2016, Barry Kaplan wrote: 
>
> > Ok, is this something that would be considered for change? In our 
> > environment there is no guarantee that nodes will remain on the same IP. 
> > For this we use consul and dnsmasq to lookup DNS names. 
> > 
> > For now I will hard code server_hostname to the DNS of the ossec server. 
> At 
> > least that value exists when the agent starts. But when the ossec server 
> > dies (AWS nodes die all the time) I will have update and restart every 
> > agent. 
>
> I suspect this is impractical for performance reasons with the current 
> code.  I'd recommend you find a way to proxy the server connection to the 
> real host to mask it's dynamic IP address change from the agents. 
>
> Antonio Querubin 
> e-mail:  to...@lavanauts.org  
> xmpp:  antonio...@gmail.com  
>

-- 

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

Re: [ossec-list] List of OSSEC rules?

[Pedro S]

I'll sent a pull request as soon as posible to ossec-hids, I would like to 
include some few options before sending it.

On Thursday, February 25, 2016 at 8:18:57 PM UTC+1, thak wrote:
>
> Interesting. We maintain a few compliance standards (not PCI) so I will 
> look into it for sure. 
>
> On Thursday, February 25, 2016 at 1:53:36 PM UTC-5, Pedro S wrote:
>>
>> You are welcome! I'll upload it into some website or repository folder.
>>
>> It is some simple but works, in the future I will extract too the PCI 
>> compliance requirement of every rule. If you need the rules with PCI 
>> requirements groups try out Wazuh Ruleset.
>>
>> Regards,
>>
>> Pedro S.
>>
>> On Thu, Feb 25, 2016 at 7:42 PM, thak <tha.k...@gmail.com> wrote:
>>
>>> Whoa, that's awesome! Thanks sir. 
>>>
>>> On Thursday, February 25, 2016 at 7:15:45 AM UTC-5, Pedro S wrote:
>>>>
>>>> Hi thak,
>>>>
>>>> I made a quick Python script that can help you out. It lists all the 
>>>> rules on */var/ossec/rules. *Output example:
>>>>
>>>> mailscanner_rules.xml - Rule 3751 - Level 6 -> Multiple attempts of 
>>>> spam.
>>>> hordeimp_rules.xml - Rule 9300 - Level 0 -> Grouping for the Horde imp 
>>>> rules.
>>>> hordeimp_rules.xml - Rule 9301 - Level 0 -> Horde IMP informational 
>>>> message.
>>>> apache_rules.xml - Rule 30412 - Level 6 -> Shellshock attack attempt
>>>> roundcube_rules.xml - Rule 9400 - Level 0 -> Roundcube messages groupe.d
>>>>
>>>>
>>>> Working with Python 2.7.6
>>>>
>>>> #!/usr/bin/python
>>>> # Rules list
>>>> # pe...@wazuh.com
>>>>
>>>> import sys
>>>> import re
>>>> import os
>>>>
>>>> *rules_directory = "/var/ossec/rules/"*
>>>>
>>>> def GetRulesList(fulldir, filename):
>>>> rule_detected = 0
>>>> rule_description = 0
>>>> level = ""
>>>> sidid = ""
>>>> description = ""
>>>> pattern_idlevel = re.compile(r'>>> pattern_description = 
>>>> re.compile(r'(.+?)')
>>>> pattern_endrule = re.compile(r'')
>>>> try:
>>>> with open(fulldir) as f:
>>>> lines = f.readlines()
>>>> for line in lines:
>>>> if rule_detected == 0:
>>>> match = re.findall(pattern_idlevel, line)
>>>> if match:
>>>> rule_detected = 1
>>>> sidid = match[0][0]
>>>> level = match[0][1]
>>>> else:
>>>> if rule_description == 0:
>>>> match = re.findall(pattern_description, line)
>>>> if match:
>>>> rule_description = 1
>>>> description = match[0]
>>>> if rule_description == 1:
>>>> match = re.findall(pattern_endrule, line)
>>>> if match:
>>>>     print "%s - Rule %s - Level %s -> %s" % 
>>>> (filename,sidid,level,description)
>>>> rule_detected = 0
>>>> rule_description = 0
>>>> level = ""
>>>> sidid = ""
>>>> description = ""
>>>> except EnvironmentError: 
>>>>print ("Error: OSSEC rules directory does not appear to 
>>>> exist")
>>>>
>>>> if __name__ == "__main__":
>>>> print ("Reading rules from directory %s") % (rules_directory)
>>>> for root, directories, filenames in os.walk(rules_directory):
>>>> for filename in filenames:
>>>> if filename[-4:] == ".xml":
>>>> GetRulesList(os.path.join(root,filename), filename)
>>>>
>>>>
>>>>
>>>> Hope it help, regards,
>>>>
>>>> Pedro S.
>>>>
>>>> On Monday, February 22, 2016 

[ossec-list] Re: Server not responding to agent messages (1218/4101)

[Pedro S]

Hi,

Stupid question, acording to your logs:

2016/02/25 21:16:25 ossec-agentd(4101): WARN: Waiting for server reply (not 
started). Tried: ''.

Is server IP setting on the Agent set correctly? Seems like OSSEC is 
reading "" as the remote IP or did you change it on purpose on the 
post?


Like Dan said, try to debug the messages on the server, you can try to 
activate  option on the Manager and check archives/archives.log.


On Friday, February 26, 2016 at 3:27:41 AM UTC+1, James Stallard wrote:
>
> All:
>
> 1st time on board, and I know this sounds like a rookie question, but...I 
> did have ossec runnig ok in another aws environment, now with upgrade to 
> 2.7-2.8.2 in a new env, am having problems
>
> I've just installed 2.8.3 agent & server on CentOS 6.7 (market place 
> version, hardened).
> Configured keys on both via manage_agent & restarted.
> I know i have UDP connectivity since I have tcpdump -v -o eth0 1514 
> running on server and receive this from client:
> tpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
> bytes
>   ip-10-.ec2.internal.51508 > 
> ip-.ec2.internal.fujitsu-dtcns: UDP, length 73
> ...
> These messages correspond with the '''Waiting for server to reply..." 
> messages sent by client" below
>
> These errors on client:
> 016/02/25 21:16:02 ossec-agentd: INFO: Using IPv4 for: 1 .
> 016/02/25 21:16:12 ossec-agentd(1218): ERROR: Unable to send message to 
> server.
> 016/02/25 21:16:24 ossec-agentd(1218): ERROR: Unable to send message to 
> server.
> 016/02/25 21:16:25 ossec-agentd(4101): WARN: Waiting for server reply (not 
> started). Tried: ''.
>
> Nothing in server logs that indicate a message was received.
>
> on client, list_clients -a I get
> *No agent available.
>
> And I don't see anything more when turning on debug mode.
>
> Note sure what else to try.
> I have turned off iptables on both client/server to debug this.
>
> Any ideas would be greatly appreciated.
>
> jms.
>

-- 

--- 
You received this message because you are subscribed 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: Anybody using CIS controls with OSSEC? (https://github.com/awailly/cis-ubuntu-ansible)

[Pedro S]

Hi,

I am not familiar with *cis-ubuntu-ansible* but you can try to debug OSSEC 
log to inspect what exactly is blocking the contact.

Open internal_options.conf and set:

remoted.debug=2
syscheck.debug=2
analysisd.debug=2
logcollector.debug=2
# Unix agentd
agent.debug=2

Restart and review what is happening. You can try a standard telnet 
remoteserver 1514 to see if your host can really send messages using 1514 
UDP.

By the way, as Jesus says, if you need CIS tagging on OSSEC rootchecks use 
that rootchecks.

On Friday, February 26, 2016 at 8:06:56 AM UTC+1, Barry Kaplan wrote:
>
> I am trying to harden up our instances, but I find that after applying 
> these controls the agent can longer contact the agent via UDP.
>
> I'm still trying to figure out exactly which bit is to blame. Has anybody 
> else used the CIS controls on the same instance as OSSEC?
>

-- 

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

Re: [ossec-list] List of OSSEC rules?

[Pedro S]

Hi thak,

I made a quick Python script that can help you out. It lists all the rules 
on */var/ossec/rules. *Output example:

mailscanner_rules.xml - Rule 3751 - Level 6 -> Multiple attempts of spam.
hordeimp_rules.xml - Rule 9300 - Level 0 -> Grouping for the Horde imp 
rules.
hordeimp_rules.xml - Rule 9301 - Level 0 -> Horde IMP informational message.
apache_rules.xml - Rule 30412 - Level 6 -> Shellshock attack attempt
roundcube_rules.xml - Rule 9400 - Level 0 -> Roundcube messages groupe.d


Working with Python 2.7.6

#!/usr/bin/python
# Rules list
# pe...@wazuh.com

import sys
import re
import os

*rules_directory = "/var/ossec/rules/"*

def GetRulesList(fulldir, filename):
rule_detected = 0
rule_description = 0
level = ""
sidid = ""
description = ""
pattern_idlevel = re.compile(r'(.+?)')
pattern_endrule = re.compile(r'')
try:
with open(fulldir) as f:
lines = f.readlines()
for line in lines:
if rule_detected == 0:
match = re.findall(pattern_idlevel, line)
if match:
rule_detected = 1
sidid = match[0][0]
level = match[0][1]
else:
if rule_description == 0:
match = re.findall(pattern_description, line)
if match:
rule_description = 1
description = match[0]
if rule_description == 1:
match = re.findall(pattern_endrule, line)
if match:
print "%s - Rule %s - Level %s -> %s" % 
(filename,sidid,level,description)
rule_detected = 0
rule_description = 0
level = ""
sidid = ""
description = ""
except EnvironmentError: 
   print ("Error: OSSEC rules directory does not appear to exist")
   
if __name__ == "__main__":
print ("Reading rules from directory %s") % (rules_directory)
for root, directories, filenames in os.walk(rules_directory):
for filename in filenames:
    if filename[-4:] == ".xml":
GetRulesList(os.path.join(root,filename), filename)



Hope it help, regards,

Pedro S.

On Monday, February 22, 2016 at 4:38:43 PM UTC+1, thak wrote:
>
> Thanks!
>
> On Monday, February 22, 2016 at 10:27:21 AM UTC-5, dan (ddpbsd) wrote:
>>
>>
>> On Feb 22, 2016 10:22 AM, "thak" <tha.k...@gmail.com> wrote:
>> >
>> > What's the best way to get a list of the rules, ideally by rule # and 
>> short descriptive name (e.g., like the alerts..."Rule: 5403 fired (level 4) 
>> -> "First time user executed sudo."). I need a list to update some security 
>> and compliance documentation prior to an upcoming audit. 
>> >
>>
>> All of the rules are available in the /var/ossec/rules directory. I don't 
>> think it would be too difficult to write a script to grab the names and ids.
>>
>> > -- 
>> >
>> > --- 
>> > You received this message because you are subscribed 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: DNS caching for ?

[Pedro S]

Hi Barry,

If I understood well, you need to resolve the DNS IP Address more than 
once, unfortunately seems like OSSEC won't do it. 

At the very first start, OSSEC reads the file ossec.conf, when detecting a 
 
<https://github.com/wazuh/ossec-wazuh/blob/6c2325e5f45b25adbaccc02ac1977c75c4a56599/src/config/client-config.c#L73>
 
setting, *OS_GetHost *function is called to get the IP Address, that 
function won't be called again until you restart OSSEC.

Regards,

Pedro S.



On Thursday, February 25, 2016 at 10:57:14 AM UTC+1, Barry Kaplan wrote:
>
> I have a situation where ossec.conf is set with  before 
> the DNS entry is set. From what I can tell so far the result of the initial 
> dns lookup is kept forever, requiring the agent to be restarted. Is it the 
> case that a failed DNS will never be retried?
>
> BTW, I'm pretty sure it's not any caching outside of ossec, because the 
> dns server in this case is consul.
>

-- 

--- 
You received this message because you are subscribed 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: Alert message on the subject

[Pedro S]

Hi,

*I did not test it* but try the following:

Open the file /var/ossec/etc/internal_options.conf and modify the line (in 
your OSSEC Manager):

# Maild full subject (0=disabled, 1=enabled)
*maild.full_subject=1*

It seems like OSSEC has two different kind of subjects:

#define MAIL_SUBJECT "OSSEC Notification - %s - Alert level %d"
#define MAIL_SUBJECT_FULL "OSSEC Alert - %s - Level %d - %s"

And use them at os_maild_client.c 
<https://github.com/wazuh/ossec-wazuh/blob/master/src/os_maild/os_maild_client.c#L138>

I hope it helps!

Regards,

Pedro S.



On Tuesday, February 23, 2016 at 7:18:10 PM UTC+1, Jesus Linares wrote:



Hi,
>
> I think you can't change the subject. At least, I can't find anything 
> related to that in the documentation 
> <http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.email_alerts.html>.
>  
> What is your final goal?.
>
> Regards.
> Jesus Linares.
>
> On Tuesday, February 23, 2016 at 6:01:45 PM UTC+1, Junior Karvalho wrote:
>>
>> how do I add the alert message on the subject.
>>
>>
>>
>>
>>
>>
>> * Subject: OSSEC Notification - Alvin - level Alert 3 -> (ossec server 
>> started.)*
>>
>> OSSEC HIDS Notification.
>> 2016 Feb 23 13:35:53
>>
>> Received From: alvin->ossec-monitord
>> Rule: 502 fired (level 3) -> "Ossec server started."
>> Portion of the log(s):
>>
>> ossec: Ossec started.
>>
>>
>>
>>  --END OF NOTIFICATION
>>
>>
>>

-- 

--- 
You received this message because you are subscribed 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: Active responce is not working

[Pedro S]

Sorry I missclicked and sent the post.

test.sh (+x and root:ossec)

#!/bin/sh

ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5

LOCAL=`dirname $0`;
cd $LOCAL
cd ../
PWD=`pwd`


# Logging the call
echo "`date` $0 $1 $2 $3 $4 $5 $6 $7 $8" >> 
${PWD}/../logs/active-responses.log


active-response.log

mar feb 23 08:47:45 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246065.10321 5501 /var/log/auth.log -
mar feb 23 08:47:49 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246069.11280 5501 /var/log/auth.log -
mar feb 23 08:49:25 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246165.12583 5501 /var/log/auth.log -
mar feb 23 08:49:27 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246167.13542 5501 /var/log/auth.log -
mar feb 23 08:54:03 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246443.14673 5501 /var/log/auth.log -
mar feb 23 08:54:05 PST 2016 /var/ossec/active-response/bin/test.sh add - - 
1456246445.15632 5501 /var/log/auth.log -


I hope it helps,

Try to use a basic example like this and see if it is working.

Regards,

Pedro S.


On Tuesday, February 23, 2016 at 5:52:41 PM UTC+1, Pedro S wrote:
>
> Hi, 
>
> I have exactly the same files open:
>
> ossec-exe 43796root3u unix 0x8801d66cfa80 
>  0t01261890 /var/ossec/queue/alerts/execq
> ossec-ana 43800   ossec3u unix 0x8801d66cf380 
>  0t01261891 /queue/ossec/queue
> ossec-ana 43800   ossec4u  REG8,1 
>0  38583 /var/ossec/queue/fts/hostinfo
> ossec-ana 43800   ossec5u  REG8,1 
>  114  38584 /var/ossec/queue/fts/fts-queue
> ossec-ana 43800   ossec6u  REG8,1 
>0  38585 /var/ossec/queue/fts/ig-queue
>
>
> If you add some agents, you will have another file open like:
>
> ossec-rem 43375  ossecr5u unix 0x8801d674c980 
>  0t01232202 /queue/alerts/ar
> ossec-rem 43375  ossecr7u  REG8,1 
>0  38586 /var/ossec/queue/rids/001
> ossec-rem 43375  ossecr8u  REG8,1 
>5  38587 /var/ossec/queue/rids/sender_counter
>
> still not working your active-response?
>
> Here is my full test config right now:
>
> ossec.conf
> 
> test
> test.sh
> 
> no
> 
>
> 
> test
> server
> 0
> 5501
> 
>
>
>
> On Tuesday, February 23, 2016 at 2:31:06 PM UTC+1, Василий Романеев wrote:
>>
>> I tried. 
>> If i understand correct, analyticsd send active responces to execd 
>> Could you please run command lsof | grep ossec | grep queue 
>> to compare with my output ? 
>> Thank you! 
>>
>> root@serv-10244 [~]# lsof | grep ossec | grep queue 
>> ossec-exe  2797  root5u unix 0x88000c3ad0c00t0 
>>  270573469 /var/ossec/queue/alerts/execq 
>> ossec-ana  2803 ossec4u unix 0x8800938353800t0 
>>  270573486 /queue/ossec/queue 
>> ossec-ana  2803 ossec5u  REG9,1  0 
>>8651763 /var/ossec/queue/fts/hostinfo 
>> ossec-ana  2803 ossec    6u  REG9,1102 
>>8651748 /var/ossec/queue/fts/fts-queue 
>> ossec-ana  2803 ossec7u  REG9,1  0 
>>8651749 /var/ossec/queue/fts/ig-queue 
>>
>> 2016-02-23 16:20 GMT+03:00 Pedro S <pe...@wazuh.com>: 
>> > I have been trying to replicate your situation, you can install either 
>> local 
>> > or server installation, it is working on both. 
>> > 
>> > I made it work by adding  tag into  section 
>> like 
>> > this: 
>> > 
>> >  
>> >testar 
>> >server 
>> >6 
>> >    yourRuleID,yourAnotherRuleID 
>> >   
>> > 
>> > Try to specify what rules will trigger your active response. 
>> > 
>> > Remember to set groups and permissions to your script.sh 
>> > 
>> > If you need to extract srcip don't forget to set expect on command 
>> section: 
>> > 
>> >  
>> >  testar 
>> >  srcip 
>> >  testar.sh 
>> >   
>> > 
>> > 
>> > 
>> > 
>> > Regards, 
>> > 
>> > Pedro S. 
>> > 
>> > 
>> > On Tuesday, February 23, 2016 at 1:39:31 PM UTC+1, ba...@x-cart.com 
>> wrote: 
>> >> 
>> >> Now i haven't any whitelist. 
>> >> 
>> >> #ossec.log 
>> >> 2016/02/23 07:

Re: [ossec-list] Re: Active responce is not working

[Pedro S]

Hi, 

I have exactly the same files open:

ossec-exe 43796root3u unix 0x8801d66cfa80 
 0t01261890 /var/ossec/queue/alerts/execq
ossec-ana 43800   ossec3u unix 0x8801d66cf380 
 0t01261891 /queue/ossec/queue
ossec-ana 43800   ossec4u  REG8,1   
 0  38583 /var/ossec/queue/fts/hostinfo
ossec-ana 43800   ossec5u  REG8,1 
 114  38584 /var/ossec/queue/fts/fts-queue
ossec-ana 43800   ossec6u  REG8,1   
 0  38585 /var/ossec/queue/fts/ig-queue


If you add some agents, you will have another file open like:

ossec-rem 43375  ossecr5u unix 0x8801d674c980 
 0t01232202 /queue/alerts/ar
ossec-rem 43375  ossecr7u  REG8,1   
 0  38586 /var/ossec/queue/rids/001
ossec-rem 43375  ossecr8u  REG8,1   
 5  38587 /var/ossec/queue/rids/sender_counter

still not working your active-response?

Here is my full test config right now:

ossec.conf

test
test.sh

no



test
server
0
5501




On Tuesday, February 23, 2016 at 2:31:06 PM UTC+1, Василий Романеев wrote:
>
> I tried. 
> If i understand correct, analyticsd send active responces to execd 
> Could you please run command lsof | grep ossec | grep queue 
> to compare with my output ? 
> Thank you! 
>
> root@serv-10244 [~]# lsof | grep ossec | grep queue 
> ossec-exe  2797  root5u unix 0x88000c3ad0c00t0 
>  270573469 /var/ossec/queue/alerts/execq 
> ossec-ana  2803 ossec4u unix 0x8800938353800t0 
>  270573486 /queue/ossec/queue 
> ossec-ana  2803 ossec5u  REG9,1  0 
>8651763 /var/ossec/queue/fts/hostinfo 
> ossec-ana  2803 ossec6u  REG9,1102 
>8651748 /var/ossec/queue/fts/fts-queue 
> ossec-ana  2803 ossec7u  REG9,1  0 
>8651749 /var/ossec/queue/fts/ig-queue 
>
> 2016-02-23 16:20 GMT+03:00 Pedro S <pe...@wazuh.com >: 
> > I have been trying to replicate your situation, you can install either 
> local 
> > or server installation, it is working on both. 
> > 
> > I made it work by adding  tag into  section 
> like 
> > this: 
> > 
> >  
> >testar 
> >server 
> >6 
> >yourRuleID,yourAnotherRuleID 
> >   
> > 
> > Try to specify what rules will trigger your active response. 
> > 
> > Remember to set groups and permissions to your script.sh 
> > 
> > If you need to extract srcip don't forget to set expect on command 
> section: 
> > 
> >  
> >  testar 
> >  srcip 
> >  testar.sh 
> >   
> > 
> > 
> > 
> > 
> > Regards, 
> > 
> > Pedro S. 
> > 
> > 
> > On Tuesday, February 23, 2016 at 1:39:31 PM UTC+1, ba...@x-cart.com 
> wrote: 
> >> 
> >> Now i haven't any whitelist. 
> >> 
> >> #ossec.log 
> >> 2016/02/23 07:18:57 ossec-analysisd: DEBUG: Active response initialized 
> >> ... 
> >> 2016/02/23 07:18:57 ossec-analysisd: DEBUG: Active response Init 
> >> completed. 
> >> 
> >> #Test active response: 
> >> root@serv-10244 [/var/ossec/active-response/bin]# ./testar.sh action 
> user 
> >> src_ip alert_id rule_id agent_host filename 
> >> root@serv-10244 [/var/ossec/active-response/bin]# cat 
> >> ../../logs/active-responses.log 
> >> Tue Feb 23 07:28:03 EST 2016 ./testar.sh action user src_ip alert_id 
> >> rule_id agent_host filename 
> >> 
> >> Let's go from start. 
> >> I need to execute active responcss on the same server, so, i run 
> >> ossec-configure and select there installation type "local" and active 
> >> responses enabled "yes" 
> >> Next i add active response 
> >> 
> >>
> >> testar 
> >>  
> >> testar.sh 
> >>
> >> 
> >>
> >> testar 
> >> all 
> >> 6 
> >>
> >> 
> >> But active responces still not executed. 
> >> 
> >> 
> >>> Hi, 
> >>> 
> >>> The daemon in charge of executing active-response scripts is 
> >>> "ossec-execd", I think your conf is good, active-response should be 
> active 
> >>> and working, try to force some response and check active-response.log. 
> >>> 
> >

[ossec-list] Re: Active responce is not working

[Pedro S]

I have been trying to replicate your situation, you can install either 
local or server installation, it is working on both. 

I made it work by adding  tag into  section like 
this:


   testar
   *server*
   6
   <*rules_id*>yourRuleID,yourAnotherRuleID
 

Try to specify what rules will trigger your active response.

Remember to set groups and permissions to your *script.sh*

If you need to extract srcip don't forget to set *expect *on command 
section:


 testar
 srcip
 testar.sh
 




Regards,

Pedro S.


On Tuesday, February 23, 2016 at 1:39:31 PM UTC+1, ba...@x-cart.com wrote:
>
> Now i haven't any whitelist.
>
> #ossec.log
> 2016/02/23 07:18:57 ossec-analysisd: DEBUG: Active response initialized ...
> 2016/02/23 07:18:57 ossec-analysisd: DEBUG: Active response Init completed.
>
> #Test active response: 
> root@serv-10244 [/var/ossec/active-response/bin]# ./testar.sh action user 
> src_ip alert_id rule_id agent_host filename
> root@serv-10244 [/var/ossec/active-response/bin]# cat 
> ../../logs/active-responses.log
> Tue Feb 23 07:28:03 EST 2016 ./testar.sh action user src_ip alert_id 
> rule_id agent_host filename 
>
> Let's go from start.
> I need to execute active responcss on the same server, so, i run 
> ossec-configure and select there installation type "local" and active 
> responses enabled "yes"
> Next i add active response 
>
>   
> testar
> 
> testar.sh
>   
>
>   
> testar
> all
> 6
>   
>
> But active responces still not executed.
>
>
> Hi,
>>
>> The daemon in charge of executing active-response scripts is 
>> *"ossec-execd",* I think your conf is good*,* active-response should be 
>> active and working, try to force some response and check 
>> active-response.log.
>>
>> Check ossec.log for entires like:
>>
>> 2016/02/23 03:48:19 ossec-analysisd: INFO: 2 IPs in the white list for 
>> active response.
>> 2016/02/23 03:48:19 ossec-analysisd: INFO: 1 Hostname(s) in the white 
>> list for active response.
>>
>>
>>
>> If you really want to check if active-response is active, try this:
>>
>> Enable debug mode:
>> /var/ossec/bin/ossec-control enable debug
>>
>> Restart OSSEC and check for line:
>>
>> 2016/02/23 11:40:57 ossec-analysisd: DEBUG: Active response initialized 
>> ...
>>
>> The scripts should be placed on /var/ossec/active-response/bin with 
>> execution permissions.
>>
>> Regards,
>>
>> Pedro S.
>>
>>
>> On Tuesday, February 23, 2016 at 11:21:13 AM UTC+1, ba...@x-cart.com 
>> wrote:
>>>
>>> Why active-responces is not working ?
>>> I receive email notification, but active responce had not started.
>>> What may caused a problem?
>>>
>>> #etc/shared/ar.conf:
>>> restart-ossec0 - restart-ossec.sh - 0
>>> restart-ossec0 - restart-ossec.cmd - 0
>>> testar0 - testar.sh - 0
>>> slack0 - slack.py - 0
>>>
>>>
>>> #alert.log
>>> ** Alert 1456222573.17132: mail  - syslog,sshdauthentication_success,
>>> 2016 Feb 23 05:16:13 serv-10244->/var/log/secure
>>> Rule: 5715 (level 7) -> 'SSHD authentication success.'
>>> Src IP: 104.131.225.112
>>> User: root
>>> Feb 23 05:16:12 serv-10244 sshd[16530]: Accepted password for root from 
>>> 104.131.225.112 port 47280 ssh2
>>>
>>> #ossec.conf
>>>   
>>> testar
>>> 
>>> testar.sh
>>>   
>>>
>>>   
>>> slack
>>> user,srcip
>>> slack.py
>>>   
>>>
>>>   
>>> testar
>>> local
>>> 5715,11309
>>>   
>>>
>>>
>>>   
>>> slack
>>> local
>>> 5715,11309
>>>   
>>>
>>>
>>> #ossec.log:
>>> 2016/02/23 05:11:04 ossec-monitord(1225): INFO: SIGNAL Received. Exit 
>>> Cleaning...
>>> 2016/02/23 05:11:04 ossec-logcollector(1225): INFO: SIGNAL Received. 
>>> Exit Cleaning...
>>> 2016/02/23 05:11:04 ossec-remoted(1225): INFO: SIGNAL Received. Exit 
>>> Cleaning...
>>> 2016/02/23 05:11:04 ossec-syscheckd(1225): INFO: SIGNAL Received. Exit 
>>> Cleaning...
>>> 2016/02/23 05:11:04 ossec-analysisd(1225): INFO: SIGNAL Received. Exit 
>>> Cleaning...
>>> 2016/02/23 05:11:04 ossec-maild(1225): INFO: SIGNAL Received. Exit 
>>> Cleaning...
>>> 2016/02/23 05:11:04 ossec-execd(1314): INFO: Shutdown received. 

[ossec-list] Re: Active responce is not working

[Pedro S]

Hi,

The daemon in charge of executing active-response scripts is 
*"ossec-execd",* I think your conf is good*,* active-response should be 
active and working, try to force some response and check 
active-response.log.

Check ossec.log for entires like:

2016/02/23 03:48:19 ossec-analysisd: INFO: 2 IPs in the white list for 
active response.
2016/02/23 03:48:19 ossec-analysisd: INFO: 1 Hostname(s) in the white list 
for active response.



If you really want to check if active-response is active, try this:

Enable debug mode:
/var/ossec/bin/ossec-control enable debug

Restart OSSEC and check for line:

2016/02/23 11:40:57 ossec-analysisd: DEBUG: Active response initialized ...

The scripts should be placed on /var/ossec/active-response/bin with 
execution permissions.

Regards,

Pedro S.


On Tuesday, February 23, 2016 at 11:21:13 AM UTC+1, ba...@x-cart.com wrote:
>
> Why active-responces is not working ?
> I receive email notification, but active responce had not started.
> What may caused a problem?
>
> #etc/shared/ar.conf:
> restart-ossec0 - restart-ossec.sh - 0
> restart-ossec0 - restart-ossec.cmd - 0
> testar0 - testar.sh - 0
> slack0 - slack.py - 0
>
>
> #alert.log
> ** Alert 1456222573.17132: mail  - syslog,sshdauthentication_success,
> 2016 Feb 23 05:16:13 serv-10244->/var/log/secure
> Rule: 5715 (level 7) -> 'SSHD authentication success.'
> Src IP: 104.131.225.112
> User: root
> Feb 23 05:16:12 serv-10244 sshd[16530]: Accepted password for root from 
> 104.131.225.112 port 47280 ssh2
>
> #ossec.conf
>   
> testar
> 
> testar.sh
>   
>
>   
> slack
> user,srcip
> slack.py
>   
>
>   
> testar
> local
> 5715,11309
>   
>
>
>   
> slack
> local
> 5715,11309
>   
>
>
> #ossec.log:
> 2016/02/23 05:11:04 ossec-monitord(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-logcollector(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-remoted(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-syscheckd(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-analysisd(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-maild(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:04 ossec-execd(1314): INFO: Shutdown received. Deleting 
> responses.
> 2016/02/23 05:11:04 ossec-execd(1225): INFO: SIGNAL Received. Exit 
> Cleaning...
> 2016/02/23 05:11:14 ossec-testrule: INFO: Reading local decoder file.
> 2016/02/23 05:11:14 ossec-testrule: INFO: Started (pid: 15157).
> 2016/02/23 05:11:14 ossec-maild: INFO: Started (pid: 15176).
> 2016/02/23 05:11:15 ossec-execd: INFO: Started (pid: 15180).
> 2016/02/23 05:11:15 ossec-analysisd: INFO: Reading local decoder file.
> 2016/02/23 05:11:15 ossec-analysisd: INFO: Reading rules file: 
> 'sshd_rules.xml'
> 2016/02/23 05:11:15 ossec-remoted: INFO: Started (pid: 15192).
> 2016/02/23 05:11:15 ossec-rootcheck: System audit file not configured.
> 2016/02/23 05:11:15 ossec-remoted: INFO: Started (pid: 15193).
> 2016/02/23 05:11:15 ossec-analysisd: INFO: Reading rules file: 
> 'local_rules.xml'
> 2016/02/23 05:11:15 ossec-analysisd: INFO: Total rules enabled: '1258'
> 2016/02/23 05:11:15 ossec-analysisd: INFO: Started (pid: 15184).
> 2016/02/23 05:11:16 ossec-monitord: INFO: Started (pid: 15219).
> 2016/02/23 05:11:16 ossec-remoted(4111): INFO: Maximum number of agents 
> allowed: '256'.
> 2016/02/23 05:11:16 ossec-remoted(1410): INFO: Reading authentication keys 
> file.
> 2016/02/23 05:11:16 ossec-remoted: INFO: No previous counter available for 
> 'local'.
> 2016/02/23 05:11:16 ossec-remoted: INFO: Assigning counter for agent 
> local: '0:0'.
> 2016/02/23 05:11:16 ossec-remoted: INFO: No previous sender counter.
> 2016/02/23 05:11:16 ossec-remoted: INFO: Assigning sender counter: 0:0
> 2016/02/23 05:11:21 ossec-logcollector(1950): INFO: Analyzing file: 
> '/var/log/messages'.
> 2016/02/23 05:11:21 ossec-logcollector(1950): INFO: Analyzing file: 
> '/var/log/secure'.
> 2016/02/23 05:11:21 ossec-logcollector: INFO: Started (pid: 15188).
> 2016/02/23 05:11:22 ossec-syscheckd: INFO: Started (pid: 15215).
> 2016/02/23 05:11:22 ossec-rootcheck: INFO: Started (pid: 15215).
> 2016/02/23 05:11:22 ossec-syscheckd: INFO: Monitoring directory: 
> '/home/woodwork/public_html'.
>
>
> # ps ax | grep ossec
> 15176 ?S  0:00 /var/ossec/bin/ossec-maild
> 15180 ?S  0:00 /var/ossec/bin/ossec-execd
> 15184 ?S  0:00 /var/ossec/bin/ossec-analysisd
> 15188 ?S  0:00 /var/ossec/bin/ossec-logcollector
> 15193 ?Sl 0:00 

Re: [ossec-list] Removing agent by deleting line in client.keys?

[Pedro S]

Hi Barry,

You can run manage_agents with option "-r" and it will remove an agent, so 
you can create some scripts to automatize the process.

/var/ossec/bin/manage_agents -r AGENTID


OSSEC has internally a hash table with client.keys table, removing manually 
from client.keys or using manage_agents -r in both cases you will need to 
restart OSSEC Manager to apply changes.

 

On Monday, February 22, 2016 at 7:21:57 AM UTC+1, Barry Kaplan wrote:
>
> Thanks! Of course it would be much nicer manage_agents was a little nicer 
> to automation...
>

-- 

--- 
You received this message because you are subscribed 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: clamav?

[Pedro S]

Hi,

Maybe clamav-rules are out-of-date, last update was 4 years ago but Jesus 
Linares wrote a few improvements few months ago (ClamAV rules 
<https://github.com/wazuh/ossec-wazuh/blob/master/etc/rules/clam_av_rules.xml>
).

If clamscan has a different format the decoders won't work properly, you 
can test the current decoders and rules using logtest:

/var/ossec/bin/ossec-logtest


Feel free to improve them or paste here some log example so we can figure 
out how to improve them.

Regards,

Pedro S.

On Monday, February 22, 2016 at 5:07:48 PM UTC+1, Barry Kaplan wrote:
>
> Anybody here using clamav? It seems the ossec rules for clamav depend on 
> the syslog format. But clamav-daemon does not run as root, so really it 
> can't scan much of anything. And the clamscan never writes to syslog and 
> its output is in a different format than clamav-daemon. 
>
> Not really an ossec question, but how is clamav useful it cannot see most 
> files?
>

-- 

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

[ossec-list] Re: How to group Syscheck notifications

[Pedro S]

OSSEC by default does not read from it's log (ossec.log or 
active-response.log), you can add them with localfile option.

Regarding to the rules you posted, OSSEC triggers them internally, there is 
no specific log for roocheck or syscheck, when the process ends, OSSEC use 
"SendMSG" function to add the event to a queue which ossec-analysisd will 
read.

515 rule has no errors, every rootcheck alerts depends on 510 rule (general 
rootcheck alert) which depend on 509 (rootcheck event).

Regards,

Pedro S.

On Monday, February 22, 2016 at 5:39:09 PM UTC+1, ba...@x-cart.com wrote:
>
> And one more question: how ossec work with it's logs?
>
> Should i add to to ossec.conf something like this, or ossec send it's log 
> messages direct, without using logfiles ? 
>   
> syslog
> /var/ossec/logs/ossec.log
>   
>
> In file rules/ossec_rules.xml we can found this definitions:
>   
> ossec
> rootcheck
> Rootcheck event.
> rootcheck,
>   
>
>   
> 509
> Host-based anomaly detection event 
> (rootcheck).
> rootcheck,
> 
>   
>   
> 510
> ^Starting rootcheck scan|^Ending rootcheck scan.|
> ^Starting syscheck scan|^Ending syscheck scan.
> Ignoring rootcheck/syscheck scan messages.
> rootcheck,syscheck
>   
>
>
> Why 515 rule depends on 510 ?
> Is this an error ?
>
> понедельник, 22 февраля 2016 г., 17:37:18 UTC+3 пользователь 
> ba...@x-cart.com написал:
>>
>> Hello!
>> I want to send only changed filenames, like it in email(see below) ?
>>
>> Is there're any way, to avoid waiting rule 515 with "Ending syscheck scan"
>> and parse all logs by hands ?
>>
>> Thank you!
>>
>> -- email message with aggregation multiple events to a single 
>> email 
>> OSSEC HIDS Notification.
>> 2016 Feb 22 06:10:15
>>
>> Received From: serv-10244->syscheck
>> Rule: 550 fired (level 7) -> "Integrity checksum changed."
>> Portion of the log(s):
>>
>> Integrity checksum changed for: '/home/woodwork/public_html/
>> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
>> 4e/%%10^10D^10D3B5F4%%import_export.tpl.php'
>> Old md5sum was: 'dceb399d30e95119919656e661204554'
>> New md5sum is : '81245ed3dd02f3406eb8a2fed54d9942'
>> Old sha1sum was: '7d76c4a8134f64290c14706f15e7c7a28256fc51'
>> New sha1sum is : '539cf636a958d88a3e8f1f8fbb468716a9a0a6d1'
>>
>>
>>
>>  --END OF NOTIFICATION
>>
>>
>>
>> OSSEC HIDS Notification.
>> 2016 Feb 22 06:10:15
>>
>> Received From: serv-10244->syscheck
>> Rule: 550 fired (level 7) -> "Integrity checksum changed."
>> Portion of the log(s):
>>
>> Integrity checksum changed for: '/home/woodwork/public_html/
>> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
>> 4e/%%C3^C39^C3917CB7%%zipcode.tpl.php.md5'
>> Old md5sum was: '893a40c51c7f8bf5be98319a30c05a18'
>> New md5sum is : '94a2aab9fc50d05b6838e2bff772ee75'
>> Old sha1sum was: '092003613f24ac04e5214dc24d1dcb0494dbca03'
>> New sha1sum is : 'ed5607668955e07bedc7529f1f18843e174fdcf1'
>>
>>
>>
>>  --END OF NOTIFICATION
>>
>

-- 

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

[ossec-list] Re: How to group Syscheck notifications

[Pedro S]

Hi again,

About getting a list of all modified files, you can execute 
syscheck_control binary to get a list of file by agent,day:

/var/ossec/bin/syscheck_control -i AGENTID


So your active-response script can periodically check that command output 
and look for today changes, the bad thing about this command is you need to 
filter for one specific agent.

Other approach like you said, it is detect when syscheck start and end, 
then capture the rules regarding to syscheck between start and end, I think 
that could be difficult, what do you think about installing an ELK Cluster 
? Using Kibana your users could check easily file integrity changes.

Syscheck alert mechanism is mostly hardcoded on OSSEC, email alerts 
template is hardcoded too, to change the template of syscheck integrity 
alert you will need to modify C code (here 
<https://github.com/wazuh/ossec-wazuh/blob/6c2325e5f45b25adbaccc02ac1977c75c4a56599/src/analysisd/decoders/syscheck.c>
)


Daniel Cid release some weeks ago an integrator, this integrator can 
connect to Slack and forward some alerts, check the full info here: OSSEC 
Integrator 
<https://blog.sucuri.net/2016/01/server-security-integrating-ossec-with-slack-and-pagerduty.html>,
 
we are merging this funcionallity right now on Wazuh fork. 
<https://github.com/wazuh/ossec-wazuh>



On Monday, February 22, 2016 at 4:02:12 PM UTC+1, ba...@x-cart.com wrote:
>
> 1. I want to change text for the alert, my users can't understand what is 
> checksum, they want to know only list of changed files :)
> 2. Some of users want to receive notifications via slack. At the moment, i 
> work on active-responce script, that receive information from logs and send 
> some notifications to users.
> 3. So my question is: What is the best way to collect all syscheck alerts 
> and send them it one message by my active-responce (or integration script)
>
> i see this scenario:
> 1. create temp file on "Starting syscheck scan" event
> 2. on each 550-554 rule filename of changed files to temp file
> 3. On "Ending syscheck scan" event send file to a customer.
>
> Is it good solution, or there is better way.
>
> Thank you for your answers, Pedro!
>
> Pedro S:
>>
>> Hi,
>>  
>> Let me know if I understood right, do you want OSSEC to only send emails 
>> related to syscheck notifications? If it is so, try to add a granular 
>> option on email notifications, you can use "group" setting in your email 
>> alerts configuration.
>> Open and modify ossec.conf file at OSSEC Manager and add the following 
>> lines:
>>
>>   your_...@example.com  
>> syscheck
>>
>>
>> Restart your manager to apply changes. Now OSSEC will only forward 
>> "syscheck" alerts.
>>
>> More info: 
>> http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.email_alerts.html
>>
>>
>> I do not understand what you mean with rule 515 and "Ending rootcheck 
>> scan", please be more specific.
>>
>> Regards,
>>
>> Pedro S.
>>
>> On Monday, February 22, 2016 at 3:37:18 PM UTC+1, ba...@x-cart.com wrote:
>>>
>>> Hello!
>>> I want to send only changed filenames, like it in email(see below) ?
>>>
>>> Is there're any way, to avoid waiting rule 515 with "Ending syscheck 
>>> scan"
>>> and parse all logs by hands ?
>>>
>>> Thank you!
>>>
>>> -- email message with aggregation multiple events to a single 
>>> email 
>>> OSSEC HIDS Notification.
>>> 2016 Feb 22 06:10:15
>>>
>>> Received From: serv-10244->syscheck
>>> Rule: 550 fired (level 7) -> "Integrity checksum changed."
>>> Portion of the log(s):
>>>
>>> Integrity checksum changed for: '/home/woodwork/public_html/
>>> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
>>> 4e/%%10^10D^10D3B5F4%%import_export.tpl.php'
>>> Old md5sum was: 'dceb399d30e95119919656e661204554'
>>> New md5sum is : '81245ed3dd02f3406eb8a2fed54d9942'
>>> Old sha1sum was: '7d76c4a8134f64290c14706f15e7c7a28256fc51'
>>> New sha1sum is : '539cf636a958d88a3e8f1f8fbb468716a9a0a6d1'
>>>
>>>
>>>
>>>  --END OF NOTIFICATION
>>>
>>>
>>>
>>> OSSEC HIDS Notification.
>>> 2016 Feb 22 06:10:15
>>>
>>> Received From: serv-10244->syscheck
>>> Rule: 550 fired (level 7) -> "Integrity checksum changed."
>>> Portion of the log(s):
>>>
>>> Integrity checksum changed for: '/home/woodwork/public_html/
>>> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
>>> 4e/%%C3^C39^C3917CB7%%zipcode.tpl.php.md5'
>>> Old md5sum was: '893a40c51c7f8bf5be98319a30c05a18'
>>> New md5sum is : '94a2aab9fc50d05b6838e2bff772ee75'
>>> Old sha1sum was: '092003613f24ac04e5214dc24d1dcb0494dbca03'
>>> New sha1sum is : 'ed5607668955e07bedc7529f1f18843e174fdcf1'
>>>
>>>
>>>
>>>  --END OF NOTIFICATION
>>>
>>

-- 

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

[ossec-list] Re: How to group Syscheck notifications

[Pedro S]

Hi,
 
Let me know if I understood right, do you want OSSEC to only send emails 
related to syscheck notifications? If it is so, try to add a granular 
option on email notifications, you can use "group" setting in your email 
alerts configuration.
Open and modify ossec.conf file at OSSEC Manager and add the following 
lines:

  your_em...@example.com  
syscheck


Restart your manager to apply changes. Now OSSEC will only forward 
"syscheck" alerts.

More 
info: 
http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.email_alerts.html


I do not understand what you mean with rule 515 and "Ending rootcheck 
scan", please be more specific.

Regards,

Pedro S.

On Monday, February 22, 2016 at 3:37:18 PM UTC+1, ba...@x-cart.com wrote:
>
> Hello!
> I want to send only changed filenames, like it in email(see below) ?
>
> Is there're any way, to avoid waiting rule 515 with "Ending syscheck scan"
> and parse all logs by hands ?
>
> Thank you!
>
> -- email message with aggregation multiple events to a single 
> email 
> OSSEC HIDS Notification.
> 2016 Feb 22 06:10:15
>
> Received From: serv-10244->syscheck
> Rule: 550 fired (level 7) -> "Integrity checksum changed."
> Portion of the log(s):
>
> Integrity checksum changed for: '/home/woodwork/public_html/
> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
> 4e/%%10^10D^10D3B5F4%%import_export.tpl.php'
> Old md5sum was: 'dceb399d30e95119919656e661204554'
> New md5sum is : '81245ed3dd02f3406eb8a2fed54d9942'
> Old sha1sum was: '7d76c4a8134f64290c14706f15e7c7a28256fc51'
> New sha1sum is : '539cf636a958d88a3e8f1f8fbb468716a9a0a6d1'
>
>
>
>  --END OF NOTIFICATION
>
>
>
> OSSEC HIDS Notification.
> 2016 Feb 22 06:10:15
>
> Received From: serv-10244->syscheck
> Rule: 550 fired (level 7) -> "Integrity checksum changed."
> Portion of the log(s):
>
> Integrity checksum changed for: '/home/woodwork/public_html/
> xc4dev/var/templates_c/c7659adfadb0a34875da46831ecaa5
> 4e/%%C3^C39^C3917CB7%%zipcode.tpl.php.md5'
> Old md5sum was: '893a40c51c7f8bf5be98319a30c05a18'
> New md5sum is : '94a2aab9fc50d05b6838e2bff772ee75'
> Old sha1sum was: '092003613f24ac04e5214dc24d1dcb0494dbca03'
> New sha1sum is : 'ed5607668955e07bedc7529f1f18843e174fdcf1'
>
>
>
>  --END OF NOTIFICATION
>

-- 

--- 
You received this message because you are subscribed 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: Centralized agent configuration - multiple matches

[Pedro S]

Hi again James,

I just tested and I can see how both configurations are pushed to the 
agent, OSSEC always push agent.conf entire file to all the agents, you can 
open the file on your agent to check if everything is already received:

*OSSEC file "/var/ossec/etc/shared/merged.mg" *

If you enable debug mode you will see on ossec.log when the merged.mg is 
pushed:

* 016/02/11 05:09:18 ossec-remoted: DEBUG Sending file 'merged.mg' to 
agent.*

Regarding if OSSEC combine all the configuration blocks, i think it does 
because the following C code:

*https://github.com/wazuh/ossec-wazuh/blob/master/src/config/config.c#L201*

There is a *while* loop searching for matchs of "os=?", "name=?" and 
"profile=?", the loop keep going until last element is read, so i think it 
will read everything, not only the first match.


Let me check it and i will update you in a while.






On Thursday, February 11, 2016 at 1:21:46 PM UTC+1, James Glaves wrote:
>
> Hi,
> I push out OSSEC configuration to all our Windows agents using shared 
> agent.conf. I have a question about how the agent interprets the different 
> options:
>
>  
> 
>
> What isn't clear to me, will "agent1" match only the first agent_config it 
> finds? Or will it continue through all the agent_config's and combine the 
> results?
>
> For example, can I combine agent-specific configuration which applies to 
> agent1 only with standard Windows configuration that applies to all Windows 
> agents. Or do I need to include all the standard Windows configuration 
> together with the specific configuration in the single named agent_config?
>
> Example, will this work? Will "agent4" combine IIS, Exchange, and Windows 
> rules?
>
> 
> 
>   
> %PROGRAMFILES%/Application 
> XYZ
>   
> 
>
> 
> 
>   
> %WinDir%\System32\LogFiles\W3SVC1\u_ex%y%m%d.log
> iis
>   
> 
>
> 
> 
>   
> F:\Connectivity Logs\CONNECTLOG%Y%m%d-1.LOG
> iis
>   
> 
>
> 
> 
>   
> Application
> eventlog
>   
>
>   
> Security
> eventlog
>   
>
>   
> System
> eventlog
>   
> 
>
> Thanks,
> jjrbg
>

-- 

--- 
You received this message because you are subscribed 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: Centralized agent configuration - multiple matches

[Pedro S]

I can confirm now that different configuration combine themselves, i made 
the following test:
Server: agent.conf





D:\ossec-test2






> 



%PROGRAMFILES%/Application 111






> 



%PROGRAMFILES%/Application 222






1. Restart ossec server control in debug mode (/var/ossec/bin/ossec-control 
enable debug && /var/ossec/bin/ossec-control restart)
2. Restart agent
2. Wait until *ossec-remoted: DEBUG Sending file 'merged.mg 
<http://merged.mg/>' to agent *message comes up in ossec.log
*3. *Check on Agent host that file* agent.conf* is created and it has the 
following content:

Client: agent.conf



  

D:\ossec-test2

  





  

%PROGRAMFILES%/Application 
> 111

  





  

%PROGRAMFILES%/Application 
> 222

  




4. Check Agent -> ossec.log :

*2016/02/11 16:31:52 ossec-syscheckd: INFO: Monitoring directory: 
> 'D:\ossec-test2'.*
> *2016/02/11 16:31:52 ossec-syscheckd: INFO: Monitoring directory: 
> 'C:\Program Files (x86)/Application 111'.*
> *2016/02/11 16:31:52 ossec-syscheckd: INFO: Monitoring directory: 
> 'C:\Program Files (x86)/Application 222'.*


I had to restart Agent several times until it applies new configuration. 

My personal conclusion is: 
OSSEC Server will write everything from agent.conf into merged.mg which 
will be pushed to agent/merged.mg, the agent will extract from merged.mg to 
agent.conf all the configuration and will read and load all the 
configuration which match name, os or profile, it does not matter if you 
have several different .


I hope i explained myself, like you notice English is not my mother 
language.
 
 
On Thursday, February 11, 2016 at 2:30:56 PM UTC+1, Pedro S wrote:
>
> Hi again James,
>
> I just tested and I can see how both configurations are pushed to the 
> agent, OSSEC always push agent.conf entire file to all the agents, you can 
> open the file on your agent to check if everything is already received:
>
> *OSSEC file "/var/ossec/etc/shared/merged.mg <http://merged.mg>" *
>
> If you enable debug mode you will see on ossec.log when the merged.mg is 
> pushed:
>
> * 016/02/11 05:09:18 ossec-remoted: DEBUG Sending file 'merged.mg 
> <http://merged.mg>' to agent.*
>
> Regarding if OSSEC combine all the configuration blocks, i think it does 
> because the following C code:
>
> *https://github.com/wazuh/ossec-wazuh/blob/master/src/config/config.c#L201 
> <https://github.com/wazuh/ossec-wazuh/blob/master/src/config/config.c#L201>*
>
> There is a *while* loop searching for matchs of "os=?", "name=?" and 
> "profile=?", the loop keep going until last element is read, so i think it 
> will read everything, not only the first match.
>
>
> Let me check it and i will update you in a while.
>
>
>
>
>
>
> On Thursday, February 11, 2016 at 1:21:46 PM UTC+1, James Glaves wrote:
>>
>> Hi,
>> I push out OSSEC configuration to all our Windows agents using shared 
>> agent.conf. I have a question about how the agent interprets the different 
>> options:
>>
>>  
>> 
>>
>> What isn't clear to me, will "agent1" match only the first agent_config 
>> it finds? Or will it continue through all the agent_config's and combine 
>> the results?
>>
>> For example, can I combine agent-specific configuration which applies to 
>> agent1 only with standard Windows configuration that applies to all Windows 
>> agents. Or do I need to include all the standard Windows configuration 
>> together with the specific configuration in the single named agent_config?
>>
>> Example, will this work? Will "agent4" combine IIS, Exchange, and Windows 
>> rules?
>>
>> 
>> 
>>   
>> %PROGRAMFILES%/Application 
>> XYZ
>>   
>> 
>>
>> 
>> 
>>   
>> %WinDir%\System32\LogFiles\W3SVC1\u_ex%y%m%d.log
>> iis
>>   
>> 
>>
>> 
>> 
>>   
>> F:\Connectivity Logs\CONNECTLOG%Y%m%d-1.LOG
>> iis
>>   
>> 
>>
>> 
>> 
>>   
>> Application
>> eventlog
>>   
>>
>>   
>> Security
>> eventlog
>>   
>>
>>   
>> System
>> eventlog
>>   
>> 
>>
>> Thanks,
>> jjrbg
>>
>

-- 

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

[ossec-list] Re: Don't send all windows event logs in client side

[Pedro S]

Hi,

EventChannel supports expressions like !=. Set up your local file like this:

  System  eventchannel 
 Event/System[EventID != 6423 && EventID != 6433]


I just tested it this and it is working:


> Microsoft-Windows-Windows Firewall With Advanced 
> Security/Firewall
> eventchannel
> Event/System[EventID != 2003 && EventID != 2004 && EventID != 
> 2005 && EventID != 2006]
> 


 Regards,

Pedro S.

On Tuesday, February 9, 2016 at 12:52:41 PM UTC+1, Idan Spencer wrote:
>
> Hello ,
> I'm trying to make the HIDS agent ( on a windows machine) not to forward 
> to the ossec server some type of EVENT ID's
> I have HiDS agent 2.8.3 on a Windows Machine and I want it *NOT *to send 
> events from the EVENT viewer that there numbers are 6423,6433 for example, 
> I don't need this event's in the SIEM and to lower the traffic between them.
> I have found in the documentation:
>
>   System  
> eventchannel  
> Event/System[EventID=7040]
>
> but in the type it send's Just this type of ID , I want it to send 
> everything exapet this type of ID.
>
> Any idea how I can do it?
>
> 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.

Re: [ossec-list] Re: Process defunct firewall-drop.sh and host-deny.sh

[Pedro S]

I can tell, host-deny.sh and firewall-drop.sh remain running about 30 secs 
before stop, alerts bigger than 6 with an srcip will trigger 
active-response, if your installation is generating a bunch of this alerts 
that's why maybe you have a bunch of process regarding to this scripts.

On Monday, February 8, 2016 at 12:33:11 PM UTC+1, Pedro S wrote:
>
> OFC it is not a solution, I thought you were not sure what active-response 
> is and you were complaining about those scripts.
>
> Regarding to your problem, I am not sure why this processes remain in 
> Zombie status, i think by default both script should execute, block the IP 
> and after 600 seconds execute again and unblock the IP.
>
> Check /var/ossec/logs/active-respones.log maybe we can find something 
> usefull there.
>
>
>
> On Monday, February 8, 2016 at 11:40:11 AM UTC+1, Giorgio Biondi wrote:
>>
>> Hi Pedro,
>>
>> of course using active response.. the solution can't be 'not using this 
>> feature'..
>>
>> :-)
>>
>>
>>
>> 2016-02-08 11:36 GMT+01:00 Pedro S <pe...@wazuh.com>:
>>
>>> Hi,
>>>
>>> Are you using active response? Those file are regarding to OSSEC 
>>> active-response, if you are not using it you can disable it editing 
>>> ossec.conf file:
>>>
>>>   
>>> yes
>>>   
>>>
>>> Best regards,
>>>
>>> Pedro S.
>>>
>>> On Friday, February 5, 2016 at 9:17:48 AM UTC+1, Giorgio Biondi wrote:
>>>>
>>>> Hi at all
>>>>
>>>> nobody have this behavior ?
>>>>
>>>> Good weekend
>>>>
>>>> Il giorno venerdì 22 gennaio 2016 11:57:46 UTC+1, Giorgio Biondi ha 
>>>> scritto:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have some linuxbox with ossec installed and work fine.
>>>>> One of this have always some (or much more) process in status 'Z' 
>>>>> zombie 
>>>>>
>>>>> See this:
>>>>>
>>>>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME 
>>>>> COMMAND
>>>>> root 25003  0.2  0.1 108212  1952 pts/0S+   11:53   0:00 watch 
>>>>> ps aux | grep Z
>>>>> root 25416  0.0  0.0  0 0 ?Z11:55   0:00 
>>>>> [host-deny.sh] 
>>>>> root 25417  0.0  0.0  0 0 ?Z11:55   0:00 
>>>>> [firewall-drop.s] 
>>>>> root 25418  0.0  0.0  0 0 ?Z11:55   0:00 
>>>>> [host-deny.sh] 
>>>>> root 25419  0.0  0.0  0 0 ?Z11:55   0:00 
>>>>> [firewall-drop.s] 
>>>>> root 25482  0.0  0.0 106060  1248 pts/0S+   11:55   0:00 sh -c 
>>>>> ps aux | grep Z
>>>>> root 25484  0.0  0.0 103256   860 pts/0S+   11:55   0:00 grep Z
>>>>>
>>>>>
>>>>> This process regarding ossec system.. apart this ossec system work 
>>>>> fine.. or seems fine..
>>>>>
>>>>> If stop service ossec I have a very huge load but this is a 'known 
>>>>> behaviur'.
>>>>>
>>>>> All the best.
>>>>>
>>>>> Giorgio Biondi.
>>>>>
>>>> -- 
>>>
>>> --- 
>>> 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/DNaZYCCrapk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> ossec-list+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 

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

[ossec-list] Re: Windows Active Response Default Settings

[Pedro S]

Hi,

Active-response is only supported by installations: local and server.
Local and server installation only works on Linux so Windows does not have 
active-response functionality, that's why it is disabled by default on 
Windows agents.

Refer to OSSEC 
documentation: 
http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.active-response.html

Regards,

Pedro S.

On Thursday, February 4, 2016 at 7:55:42 AM UTC+1, Abdulvehhab Agin wrote:
>
> Hi
>
> Ossec setup which is prepared Windows install ossec.conf file with active 
> response yes at Default
>
> However in linux there is no active response tag which means that it is 
> ready for active response
>
>
> Why in windows installation it is default disabled
>
>

-- 

--- 
You received this message because you are subscribed 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: Windows Active Response Default Settings

[Pedro S]

You are totally alright, excuse me.

OSSEC documentation is really weird, you can find here info about windows 
active response:

http://ossec-docs.readthedocs.org/en/latest/manual/ar/ar-windows.html

About the disabled by default, it is specified here:

https://github.com/ossec/ossec-hids/blob/master/src/win32/ossec.conf#L133

I think OSSEC use that file to compile windows binary, if you change that 
line and compile the agent, it will have active-response active by default.


On Monday, February 8, 2016 at 11:44:43 AM UTC+1, dan (ddpbsd) wrote:
>
>
> On Feb 8, 2016 5:39 AM, "Pedro S" <pe...@wazuh.com > wrote:
> >
> > Hi,
> >
> > Active-response is only supported by installations: local and server.
> > Local and server installation only works on Linux so Windows does not 
> have active-response functionality, that's why it is disabled by default on 
> Windows agents.
> >
> > Refer to OSSEC documentation: 
> http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.active-response.html
> >
>
> The documentation is weird, you can use active reponse on agents as well. 
> It is supported on Windows, but I don't know why it's disabled by default
>
> > Regards,
> >
> > Pedro S.
> >
> >
> > On Thursday, February 4, 2016 at 7:55:42 AM UTC+1, Abdulvehhab Agin 
> wrote:
> >>
> >> Hi
> >>
> >> Ossec setup which is prepared Windows install ossec.conf file with 
> active response yes at Default
> >>
> >> However in linux there is no active response tag which means that it is 
> ready for active response
> >>
> >>
> >> Why in windows installation it is default disabled
> >
> > -- 
> >
> > --- 
> > You received this message because you are subscribed 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: Process defunct firewall-drop.sh and host-deny.sh

[Pedro S]

OFC it is not a solution, I thought you were not sure what active-response 
is and you were complaining about those scripts.

Regarding to your problem, I am not sure why this processes remain in 
Zombie status, i think by default both script should execute, block the IP 
and after 600 seconds execute again and unblock the IP.

Check /var/ossec/logs/active-respones.log maybe we can find something 
usefull there.



On Monday, February 8, 2016 at 11:40:11 AM UTC+1, Giorgio Biondi wrote:
>
> Hi Pedro,
>
> of course using active response.. the solution can't be 'not using this 
> feature'..
>
> :-)
>
>
>
> 2016-02-08 11:36 GMT+01:00 Pedro S <pe...@wazuh.com >:
>
>> Hi,
>>
>> Are you using active response? Those file are regarding to OSSEC 
>> active-response, if you are not using it you can disable it editing 
>> ossec.conf file:
>>
>>   
>> yes
>>   
>>
>> Best regards,
>>
>> Pedro S.
>>
>> On Friday, February 5, 2016 at 9:17:48 AM UTC+1, Giorgio Biondi wrote:
>>>
>>> Hi at all
>>>
>>> nobody have this behavior ?
>>>
>>> Good weekend
>>>
>>> Il giorno venerdì 22 gennaio 2016 11:57:46 UTC+1, Giorgio Biondi ha 
>>> scritto:
>>>>
>>>> Hi,
>>>>
>>>> I have some linuxbox with ossec installed and work fine.
>>>> One of this have always some (or much more) process in status 'Z' 
>>>> zombie 
>>>>
>>>> See this:
>>>>
>>>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>>>> root 25003  0.2  0.1 108212  1952 pts/0S+   11:53   0:00 watch 
>>>> ps aux | grep Z
>>>> root 25416  0.0  0.0  0 0 ?Z11:55   0:00 
>>>> [host-deny.sh] 
>>>> root 25417  0.0  0.0  0 0 ?Z11:55   0:00 
>>>> [firewall-drop.s] 
>>>> root 25418  0.0  0.0  0 0 ?Z11:55   0:00 
>>>> [host-deny.sh] 
>>>> root 25419  0.0  0.0  0 0 ?Z11:55   0:00 
>>>> [firewall-drop.s] 
>>>> root 25482  0.0  0.0 106060  1248 pts/0S+   11:55   0:00 sh -c 
>>>> ps aux | grep Z
>>>> root 25484  0.0  0.0 103256   860 pts/0S+   11:55   0:00 grep Z
>>>>
>>>>
>>>> This process regarding ossec system.. apart this ossec system work 
>>>> fine.. or seems fine..
>>>>
>>>> If stop service ossec I have a very huge load but this is a 'known 
>>>> behaviur'.
>>>>
>>>> All the best.
>>>>
>>>> Giorgio Biondi.
>>>>
>>> -- 
>>
>> --- 
>> 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/DNaZYCCrapk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

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

[ossec-list] Re: Process defunct firewall-drop.sh and host-deny.sh

[Pedro S]

Hi,

Are you using active response? Those file are regarding to OSSEC 
active-response, if you are not using it you can disable it editing 
ossec.conf file:

  
yes
  

Best regards,

Pedro S.

On Friday, February 5, 2016 at 9:17:48 AM UTC+1, Giorgio Biondi wrote:
>
> Hi at all
>
> nobody have this behavior ?
>
> Good weekend
>
> Il giorno venerdì 22 gennaio 2016 11:57:46 UTC+1, Giorgio Biondi ha 
> scritto:
>>
>> Hi,
>>
>> I have some linuxbox with ossec installed and work fine.
>> One of this have always some (or much more) process in status 'Z' zombie 
>>
>> See this:
>>
>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>> root 25003  0.2  0.1 108212  1952 pts/0S+   11:53   0:00 watch ps 
>> aux | grep Z
>> root 25416  0.0  0.0  0 0 ?Z11:55   0:00 
>> [host-deny.sh] 
>> root 25417  0.0  0.0  0 0 ?Z11:55   0:00 
>> [firewall-drop.s] 
>> root 25418  0.0  0.0  0 0 ?Z11:55   0:00 
>> [host-deny.sh] 
>> root 25419  0.0  0.0  0 0 ?Z11:55   0:00 
>> [firewall-drop.s] 
>> root 25482  0.0  0.0 106060  1248 pts/0S+   11:55   0:00 sh -c ps 
>> aux | grep Z
>> root 25484  0.0  0.0 103256   860 pts/0S+   11:55   0:00 grep Z
>>
>>
>> This process regarding ossec system.. apart this ossec system work fine.. 
>> or seems fine..
>>
>> If stop service ossec I have a very huge load but this is a 'known 
>> behaviur'.
>>
>> All the best.
>>
>> Giorgio Biondi.
>>
>

-- 

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

[ossec-list] Re: Can one agent report to two masters?

[Pedro S]

I think the server block listed twice won't do the trick.

Probably is better to have two agents.

On Tuesday, February 2, 2016 at 3:04:04 AM UTC+1, James Dough wrote:
>
> I think it's possible, you just have to have the server block listed 
> twice, and use the same key on both servers. 
> - Untested on my end.
>
> On Saturday, January 30, 2016 at 10:16:13 AM UTC-6, Clay Wells wrote:
>>
>> Hi,
>>
>> Is it possible for one agent report to report to two masters?
>>
>> Some sysadmins are interested in setting up a dev, test, prod 
>> infrastructure for OSSEC.
>>
>> Cheers,
>> Clay
>>
>

-- 

--- 
You received this message because you are subscribed 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 does Courier Fetch x of xxx shards failed mean?

[Pedro S]

Hi,

When are you getting this error exactly? when opening a dashboard? at 
"Discover" tab?

It is a very generic error, there are different approaches to solve this:
- What specs have your machine?
- Are you creating a daily index? how many index have your cluster now?
- How many shards per index?
- Are you using a lot of wildcards (*)?

The point is Elasticsearch can't handle the request on time, one solution 
is edit your elasticsearch.yml and change the following parameters:
threadpool.search.type: fixed
threadpool.search.size: 20
threadpool.search.queue_size: *1*

*BE AWARE! *Increasing queue_size will create so many threads on your 
machine, the best solution is try to find what is causing the error and not 
just increase queue_size, or if you prefer, use a browser debuger and 
inspect HTTP error responses from Elastic, you will see something like: 
*"EsRejectedExecutionException[rejected 
execution (queue capacity 1000) on org.elasticsearch.search.action...", *try 
to adjust queue_size as low as possible.





On Wednesday, February 3, 2016 at 7:47:35 PM UTC+1, Santiago Bassett wrote:
>
> Elasticsearch search queue size? 
> https://github.com/elastic/kibana/issues/3221
>
> On Wed, Feb 3, 2016 at 10:26 AM,  
> wrote:
>
>> Hello Group,
>>
>> I'm wondering what the following error indicates and means:
>> What does Courier Fetch x of xxx shards failed mean?
>>
>> Thanks so much!
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed 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] ERROR: Incorrectly formated message

[Pedro S]

Hi,

Try to add the agent with "any" parameter on IP field (./manage_agents), 
when "ip" question prompt, write "any", just for testing, maybe the agent 
IP when reaching OSSEC it is not the IP you are writting.

On Wednesday, February 3, 2016 at 8:10:45 AM UTC+1, Robert wrote:
>
> Hi Jose,
>
> Yes, same ID, basically this is a new agent (it uses an old server's IP, 
> but i deleted the old agent and created a new one).
> Tried to modify remoted.verify_msg_id=1 to 0 -> restart, but nothing 
> changed :S
>
> Robert
>
>
>
>
> 2016. február 2., kedd 18:36:58 UTC+1 időpontban jose a következőt írta:
>>
>> Hi Robert, the same agent id? 
>>
>> Try this, in  ossecpath/etc/internal-options.conf modify 
>> remoted.verify_msg_id=1 to 0 in both places, agent and manager
>>
>>
>> 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.

Re: [ossec-list] Invalidate all old clients

[Pedro S]

Hi,

ossec-remoted should start by itself, if not, usually is because you don't 
have any agents added. Try to run bin/manage_agents, add an example agent, 
restart OSSEC and remoted should start.

Check client.keys to verify if this "example agent" was added. Check 
permissions of folders etc/ and queue/.

On Wednesday, February 3, 2016 at 5:57:44 AM UTC+1, sandeep wrote:
>
> Hi Santiago,
>
> Thanks for the reply. 
>
> I removed all the old files from the path you mentioned and restarted both 
> master and agent services. Below are the logs i see - 
>
> On Master - 
> 2016/02/03 04:50:43 ossec-remoted(1408): ERROR: Invalid ID for the source 
> ip: 'xxx.xxx.xxx.xxx'.
> 2016/02/03 04:50:49 ossec-remoted(1408): ERROR: Invalid ID for the source 
> ip: 'xxx.xxx.xxx.xxx'.
>
> On Agent - 
> 2016/02/03 04:48:35 ossec-agentd(4101): WARN: Waiting for server reply 
> (not started). Tried: 'ossec.druva.com/yyy.yyy.yyy.yyy'.
> 2016/02/03 04:49:31 ossec-agentd: INFO: Trying to connect to server (
> ossec.druva.com/yyy.yyy.yyy.yyy:1514).
> 2016/02/03 04:49:31 ossec-agentd: INFO: Using IPv4 for: yyy.yyy.yyy.yyy.
>
> I am trying this on AWS EC2 setup, Port 1514 is open and server is 
> listening on same UDP port. OS is Ubuntu 14.04 LTS, Installation is done 
> through repository on both master and agent. 
>
> One more observation, when i restart ossec service all the services comes 
> up without an issue but ossec-remoted doesn't start. I have to run 
> "./ossec-remoted" command from /bin directory every time i do service 
> restart. 
>
> On Wed, Feb 3, 2016 at 12:28 AM, Santiago Bassett  > wrote:
>
>> Hi Sandeep,
>>
>> those issues are probably not related to each other. Removing the 
>> client.keys file, and the files in queue/rids, queue/agent-info 
>> queue/syscheck and queue/rootcheck should be enough.
>>
>> Any error message in your agent or manager log files?
>>
>> On Mon, Feb 1, 2016 at 7:19 AM, sandeep > > wrote:
>>
>>> Hi, 
>>>
>>> what should be the approach to delete all agent and respected entries to 
>>> start from scratch ?
>>>
>>> I have a ossec server and 50+ agents which was in 'inactive' state. I 
>>> decided to upgrade the server and client version (start as fresh). I moved 
>>> client.keys and all files from rids directory and added one new client 
>>> manually, But it fails to communicate to server. 
>>>
>>> -- 
>>>
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "ossec-list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to ossec-list+...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Regards,
> Sandeep
>

-- 

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

[Pedro S]

That would be really cool, OSSEC needs SSL support, I am sure it won't be 
easy!

On Tuesday, February 2, 2016 at 10:51:08 PM UTC+1, Santiago Bassett wrote:
>
> That would be more than awesome!
>
> On Tue, Feb 2, 2016 at 1:27 PM, Daniel Cid  > wrote:
>
>> 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 <
>>> ijaodiasjiodjsalklksdjakld...@mail.ru > 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 <
 ijaodiasjiodjsalklksdjakld...@mail.ru > 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 

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

[Pedro S.]

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

[Pedro S.]

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.

For testing purposes try to deactivate (change to level 0) rule 1002 and 
check if it is still generating these alerts.





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

[Pedro S.]

My confusion was the rule he wrote here has SID 15 and the logtest 
result has SID 17, sorry about that.

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. <sna...@gmail.com > 
> 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.

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

[Pedro S.]

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.

El viernes, 13 de noviembre de 2015, 11:20:47 (UTC-8), Daniel Bray escribió:
>
> 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.