wazuh / wazuh

Wazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.

Wazuh

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts.

Wazuh capabilities

A brief presentation of some of the more common use cases of the Wazuh solution.

Intrusion detection

Wazuh agents scan the monitored systems looking for malware, rootkits and suspicious anomalies. They can detect hidden files, cloaked processes or unregistered network listeners, as well as inconsistencies in system call responses.

In addition to agent capabilities, the server component uses a signature-based approach to intrusion detection, using its regular expression engine to analyze collected log data and look for indicators of compromise.

Log data analysis

Wazuh agents read operating system and application logs, and securely forward them to a central manager for rule-based analysis and storage. When no agent is deployed, the server can also receive data via syslog from network devices or applications.

The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.

File integrity monitoring

Wazuh monitors the file system, identifying changes in content, permissions, ownership, and attributes of files that you need to keep an eye on. In addition, it natively identifies users and applications used to create or modify files.

File integrity monitoring capabilities can be used in combination with threat intelligence to identify threats or compromised hosts. In addition, several regulatory compliance standards, such as PCI DSS, require it.

Vulnerability detection

Wazuh agents pull software inventory data and send this information to the server, where it is correlated with continuously updated CVE (Common Vulnerabilities and Exposure) databases, in order to identify well-known vulnerable software.

Automated vulnerability assessment helps you find the weak spots in your critical assets and take corrective action before attackers exploit them to sabotage your business or steal confidential data.

Configuration assessment

Wazuh monitors system and application configuration settings to ensure they are compliant with your security policies, standards and/or hardening guides. Agents perform periodic scans to detect applications that are known to be vulnerable, unpatched, or insecurely configured.

Additionally, configuration checks can be customized, tailoring them to properly align with your organization. Alerts include recommendations for better configuration, references and mapping with regulatory compliance.

Incident response

Wazuh provides out-of-the-box active responses to perform various countermeasures to address active threats, such as blocking access to a system from the threat source when certain criteria are met.

In addition, Wazuh can be used to remotely run commands or system queries, identifying indicators of compromise (IOCs) and helping perform other live forensics or incident response tasks.

Regulatory compliance

Wazuh provides some of the necessary security controls to become compliant with industry standards and regulations. These features, combined with its scalability and multi-platform support help organizations meet technical compliance requirements.

Wazuh is widely used by payment processing companies and financial institutions to meet PCI DSS (Payment Card Industry Data Security Standard) requirements. Its web user interface provides reports and dashboards that can help with this and other regulations (e.g. GPG13 or GDPR).

Cloud security

Wazuh helps monitoring cloud infrastructure at an API level, using integration modules that are able to pull security data from well known cloud providers, such as Amazon AWS, Azure or Google Cloud. In addition, Wazuh provides rules to assess the configuration of your cloud environment, easily spotting weaknesses.

In addition, Wazuh light-weight and multi-platform agents are commonly used to monitor cloud environments at the instance level.

Containers security

Wazuh provides security visibility into your Docker hosts and containers, monitoring their behavior and detecting threats, vulnerabilities and anomalies. The Wazuh agent has native integration with the Docker engine allowing users to monitor images, volumes, network settings, and running containers.

Wazuh continuously collects and analyzes detailed runtime information. For example, alerting for containers running in privileged mode, vulnerable applications, a shell running in a container, changes to persistent volumes or images, and other possible threats.

WUI

The Wazuh WUI provides a powerful user interface for data visualization and analysis. This interface can also be used to manage Wazuh configuration and to monitor its status.

Modules overview

Security events

Integrity monitoring

Vulnerability detection

Regulatory compliance

Agents overview

Agent summary

Orchestration

Here you can find all the automation tools maintained by the Wazuh team.

• Wazuh AWS CloudFormation

• Docker containers

• Wazuh Ansible

• Wazuh Chef

• Wazuh Puppet

• Wazuh Kubernetes

• Wazuh Bosh

• Wazuh Salt

Branches

• master branch contains the latest code, be aware of possible bugs on this branch.
• stable branch on correspond to the last Wazuh stable version.

Software and libraries used

Software	Version	Author	License
bzip2	1.0.8	Julian Seward	BSD License
cJSON	1.7.12	Dave Gamble	MIT License
cPython	3.10.13	Guido van Rossum	Python Software Foundation License version 2
cURL	8.5.0	Daniel Stenberg	MIT License
Flatbuffers	23.5.26	Google Inc.	Apache 2.0 License
GoogleTest	1.11.0	Google Inc.	3-Clause "New" BSD License
jemalloc	5.2.1	Jason Evans	2-Clause "Simplified" BSD License
Lua	5.3.6	PUC-Rio	MIT License
libarchive	3.7.2	Tim Kientzle	3-Clause "New" BSD License
libdb	18.1.40	Oracle Corporation	Affero GPL v3
libffi	3.2.1	Anthony Green	MIT License
libpcre2	10.42.0	Philip Hazel	BSD License
libplist	2.2.0	Aaron Burghardt et al.	GNU Lesser General Public License version 2.1
libYAML	0.1.7	Kirill Simonov	MIT License
liblzma	5.4.2	Lasse Collin, Jia Tan et al.	GNU Public License version 3
Linux Audit userspace	2.8.4	Rik Faith	LGPL (copyleft)
msgpack	3.1.1	Sadayuki Furuhashi	Boost Software License version 1.0
nlohmann	3.7.3	Niels Lohmann	MIT License
OpenSSL	3.0.12	OpenSSL Software Foundation	Apache 2.0 License
pacman	5.2.2	Judd Vinet	GNU Public License version 2 (copyleft)
popt	1.16	Jeff Johnson & Erik Troan	MIT License
procps	2.8.3	Brian Edmonds et al.	LGPL (copyleft)
RocksDB	8.3.2	Facebook Inc.	Apache 2.0 License
rpm	4.18.2	Marc Ewing & Erik Troan	GNU Public License version 2 (copyleft)
sqlite	3.45.0	D. Richard Hipp	Public Domain (no restrictions)
zlib	1.3.1	Jean-loup Gailly & Mark Adler	zlib/libpng License

• PyPi packages

Documentation

• Full documentation
• Wazuh installation guide

Get involved

Become part of the Wazuh's community to learn from other users, participate in discussions, talk to our developers and contribute to the project.

If you want to contribute to our project please don’t hesitate to make pull-requests, submit issues or send commits, we will review all your questions.

You can also join our Slack community channel and mailing list by sending an email to [email protected], to ask questions and participate in discussions.

Stay up to date on news, releases, engineering articles and more.

• Wazuh website
• Linkedin
• YouTube
• Twitter
• Wazuh blog
• Slack announcements channel

Authors

Wazuh Copyright (C) 2015-2023 Wazuh Inc. (License GPLv2)

Based on the OSSEC project started by Daniel Cid.

wazuh's Issues

New release planned?

Last release is more than half a year old (and 652 commits behind master).
Any plans to make a new release soon?

chocolatey

https://chocolatey.org/packages/ossec.wazuh.agent

I can also add you all as maintainers

now if I just had a script to set api key and were to phone home , puppet/etc for windows could just as easily, automate this too.

deploy these to server vm's to be watched.

manage_agents unable to access /dev/random due to chroot

Hi.

I was trying to implement this https://github.com/wazuh/docker-ossec/blob/master/Dockerfile#L14
to this fork.

And I'm struggling from the same issue ossec/ossec-hids#425
Get same error just in Ubuntu 14.04.3 and also inside of your docker ELK container.

root@642f170bea07:/# echo "127.0.0.1,DEFAULT_LOCAL_AGENT" > /var/ossec/default_agent
root@642f170bea07:/# /var/ossec/bin/manage_agents -f /default_agent
Bulk load file: /default_agent
Opening: [/default_agent]
2016/01/20 16:00:21 manage_agents: ERROR: randombytes failed for all possible methods for accessing random data
root@642f170bea07:/# strace /var/ossec/bin/manage_agents -f /default_agent
bash: strace: command not found
root@642f170bea07:/# apt-get install strace
Reading package lists... Done
...
Setting up strace (4.8-1ubuntu5) ...

root@642f170bea07:/# strace /var/ossec/bin/manage_agents -f /default_agent
execve("/var/ossec/bin/manage_agents", ["/var/ossec/bin/manage_agents", "-f", "/default_agent"], [/* 9 vars */]) = 0
brk(0)                                  = 0x16fd000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacfc000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=16378, ...}) = 0
mmap(NULL, 16378, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbbbacf8000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0po\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=141574, ...}) = 0
mmap(NULL, 2217264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbba8be000
mprotect(0x7fbbba8d7000, 2093056, PROT_NONE) = 0
mmap(0x7fbbbaad6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7fbbbaad6000
mmap(0x7fbbbaad8000, 13616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbbbaad8000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1840928, ...}) = 0
mmap(NULL, 3949248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbba4f9000
mprotect(0x7fbbba6b4000, 2093056, PROT_NONE) = 0
mmap(0x7fbbba8b3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7fbbba8b3000
mmap(0x7fbbba8b9000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbbba8b9000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacf7000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacf5000
arch_prctl(ARCH_SET_FS, 0x7fbbbacf5740) = 0
mprotect(0x7fbbba8b3000, 16384, PROT_READ) = 0
mprotect(0x7fbbbaad6000, 4096, PROT_READ) = 0
mprotect(0x625000, 4096, PROT_READ)     = 0
mprotect(0x7fbbbacfe000, 4096, PROT_READ) = 0
munmap(0x7fbbbacf8000, 16378)           = 0
set_tid_address(0x7fbbbacf5a10)         = 435
set_robust_list(0x7fbbbacf5a20, 24)     = 0
futex(0x7fff6edf4ef0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7fbbbacf5740) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fbbba8c49f0, [], SA_RESTORER|SA_SIGINFO, 0x7fbbba8ce340}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fbbba8c4a80, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fbbba8ce340}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 9), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacfb000
write(1, "Bulk load file: /default_agent\n", 31Bulk load file: /default_agent
) = 31
open("/dev/urandom", O_RDONLY)          = 3
read(3, ")\262\375\354", 4)             = 4
close(3)                                = 0
brk(0)                                  = 0x16fd000
brk(0x171e000)                          = 0x171e000
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=475, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacfa000
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 475
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7fbbbacfa000, 4096)            = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=16378, ...}) = 0
mmap(NULL, 16378, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbbbacf1000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\23\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=39824, ...}) = 0
mmap(NULL, 2135368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbba2ef000
mprotect(0x7fbbba2f8000, 2093056, PROT_NONE) = 0
mmap(0x7fbbba4f7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7fbbba4f7000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`A\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=97296, ...}) = 0
mmap(NULL, 2202328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbba0d5000
mprotect(0x7fbbba0ec000, 2093056, PROT_NONE) = 0
mmap(0x7fbbba2eb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7fbbba2eb000
mmap(0x7fbbba2ed000, 6872, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbbba2ed000
close(3)                                = 0
mprotect(0x7fbbba2eb000, 4096, PROT_READ) = 0
mprotect(0x7fbbba4f7000, 4096, PROT_READ) = 0
munmap(0x7fbbbacf1000, 16378)           = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=16378, ...}) = 0
mmap(NULL, 16378, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbbbacf1000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240!\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=47760, ...}) = 0
mmap(NULL, 2143784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbb9ec9000
mprotect(0x7fbbb9ed4000, 2093056, PROT_NONE) = 0
mmap(0x7fbbba0d3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7fbbba0d3000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=47712, ...}) = 0
mmap(NULL, 2144392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbbb9cbd000
mprotect(0x7fbbb9cc8000, 2093056, PROT_NONE) = 0
mmap(0x7fbbb9ec7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7fbbb9ec7000
close(3)                                = 0
mprotect(0x7fbbb9ec7000, 4096, PROT_READ) = 0
mprotect(0x7fbbba0d3000, 4096, PROT_READ) = 0
munmap(0x7fbbbacf1000, 16378)           = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 3
lseek(3, 0, SEEK_CUR)                   = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=599, ...}) = 0
mmap(NULL, 599, PROT_READ, MAP_SHARED, 3, 0) = 0x7fbbbacfa000
lseek(3, 599, SEEK_SET)                 = 599
munmap(0x7fbbbacfa000, 599)             = 0
close(3)                                = 0
setgroups(1, [8378])                    = 0
setresgid(-1, 8378, -1)                 = 0
setgid(8378)                            = 0
chdir(0x41a56b)                         = 0
chroot(0x41a56b)                        = 0
chdir(0x41ca4d)                         = 0
rt_sigaction(SIGHUP, {...}, {...}, 8)   = 0
rt_sigaction(SIGINT, {...}, {...}, 8)   = 0
rt_sigaction(SIGQUIT, {...}, {...}, 8)  = 0
rt_sigaction(SIGTERM, {...}, {...}, 8)  = 0
rt_sigaction(SIGALRM, {...}, {...}, 8)  = 0
rt_sigaction(SIGPIPE, {...}, {...}, 8)  = 0
write(1, 0x7fbbbacfb000, 26Opening: [/default_agent]
)            = 26
open(0x7fff6edf6efc, O_RDONLY)          = 3
open(0x41b349, O_WRONLY|O_CREAT|O_APPEND, 0666) = 4
fstat(4, {...})                         = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacfa000
fstat(4, {...})                         = 0
lseek(4, 0, SEEK_SET)                   = 0
close(4)                                = 0
munmap(0x7fbbbacfa000, 4096)            = 0
fstat(3, {...})                         = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacfa000
read(3, 0x7fbbbacfa000, 4096)           = 30
chmod(0x41b349, 0440)                   = 0
open(0x41cd72, O_RDONLY)                = -1 ENOENT (No such file or directory)
open(0x41cd7f, O_RDONLY)                = -1 ENOENT (No such file or directory)
open(0x7fbbba6771f0, O_RDONLY|O_CLOEXEC) = 4
fstat(4, {...})                         = 0
fstat(4, {...})                         = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacf9000
read(4, 0x7fbbbacf9000, 4096)           = 118
lseek(4, -62, SEEK_CUR)                 = 56
read(4, 0x7fbbbacf9000, 4096)           = 62
close(4)                                = 0
munmap(0x7fbbbacf9000, 4096)            = 0
open(0x41c9e8, O_WRONLY|O_CREAT|O_APPEND, 0666) = 4
fstat(4, {...})                         = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbbbacf9000
fstat(4, {...})                         = 0
lseek(4, 24258, SEEK_SET)               = 24258
write(4, 0x7fbbbacf9000, 112)           = 112
close(4)                                = 0
munmap(0x7fbbbacf9000, 4096)            = 0
write(2, 0x7fff6edf1fb0, 202016/01/20 16:01:01 )            = 20
write(2, 0x7fff6edf2080, 91manage_agents: ERROR: randombytes failed for all possible methods for accessing random data)            = 91
write(2, 0x7fbbba8b8243, 1
)             = 1
exit_group(1)                           = ?
+++ exited with 1 +++

this mentioned workaround ossec/ossec-hids#425 (comment) also fixes the issue

cd /var/ossec/
mkdir dev
mount -o bind /dev dev/

I have checked the code and this fix ossec/ossec-hids#426 exists in custom repo.

Could you please have a look into this issue ?

Ossec logrotate output

Hello,

Here is an issue I opened on ossec/ossec-hids#963 , but they said I should create it here.

I'm currently getting spammed by ossec every night, during logrotate, there is a restart of ossec, but the output is not managed hence, logrotate send the output by e-mail :

/etc/cron.daily/logrotate:
Killing ossec-logcollector ..
Killing ossec-syscheckd ..
Killing ossec-agentd ..
Killing ossec-execd ..
OSSEC HIDS v2.8.3 Stopped
Starting OSSEC HIDS v2.8.3 (by Trend Micro Inc.)...
Started ossec-execd...
2016/10/03 06:53:16 ossec-agentd: INFO: Using notify time: 600 and max time to reconnect: 1800
Started ossec-agentd...
Started ossec-logcollector...
Started ossec-syscheckd...
Completed.

If I take rsysolg has example, the postrotate command send output to /dev/nul :
invoke-rc.d rsyslog rotate > /dev/null

I tried this solution but I still get this output :

2016/11/14 06:33:10 ossec-agentd: INFO: Using notify time: 600 and max time to reconnect: 1800
Any idea ?

.spec file used for building RPMs?

Hello,

I'd like to rebuild ossec-wazuh RPM packages for our environment, but I cannot find any up-to-date .spec file. It's probably just me, but can you help me with that? How do you build your RPMs?

Thank you,
Vaclav

Add support for Xenial

Ubuntu 16.04 was released on April and will be a LTS distro, it would be nice to have packages for this release. As it is, this module cannot be used on 16.04.

Kibana Doesnt work on Ossec Unix System

Hi There,
I am new to a company as a network technician.
I have been tasked with fixing their kibana system, I don't have any UNIX or Linux background apart from installing a few Linux systems.

The machine runs on a VM the reports still work we can work with it but currently the dashboard doesn't load at all.. when you do "service kibana4 status" it will say Kibana is running but then after about 30 minutes, it will say Kibana is not running.

I would love all the help i can get. My colleague knows a lot of code and is familiar with UNIX systems so if any code is needed he can enter this with me.

Apparently this is a Necessity for the company. So it currently works just the dashboard doesn't- if the logs don't get stored we are pretty screwed from my understanding.

Regards,
Chris.

Kibana 4.1 integration - index.js

Hello,
I'm currently doing the POC with ES 1.5.2. That means I have to use Kibana 4.1.2.

In your Dockerfile https://github.com/wazuh/docker-ossec-elk/blob/master/Dockerfile#L67 you copy index.js file to Kibana.

There is a function EsApiClient Inside this file and default config points to elasticsearch at localhost.

 if (!config.hosts && !config.host) {
      config.host = 'http://localhost:9200';
    }

Do this file needs to be copied ? there's nothing about it in documentation :-(
What's the best way to change this config.host variable (I'm using ES cluster on external nodes) ? is there any config file that index.js use ?

Geo IP Mapping for Windows Logs

Hi!

Using the Wuzah Ossec fork with ELK and I can't seem to get the GEOIP dashboards in Kibana to display remote addresses from Windows logs.

I can see the filter I need to use "Source Network Address" instead of "srcip" in the Logstash config template. However I don;t get any Geo IP results in the front end.

Any pointers?

Thanks,
Steve

Kibana dashboard JSON doesn't load properly

The current JSON file specifies the index to pull data as the literal [ossec-]YYYY.MM.DD, which isn't likely to be the index match. It's more normal to have ossec-*

File: https://github.com/wazuh/wazuh/blob/1b6de44e9dc70fb056f804ebac58cabd9a357912/extensions/kibana/4.1/kibana-ossecwazuh-dashboards.json

"searchSourceJSON": "{\"index\":\"[ossec-]YYYY.MM.DD\",\"query\":{\"query_string\":{\"analyze_wildcard\":true,\"query\":\"*\"}},\"highlight\":{\"pre_tags\":[\"@kibana-highlighted-field@\"],\"post_tags\":[\"@/kibana-highlighted-field@\"],\"fields\":{\"*\":{}}},\"filter\":[]}"

If you change the index to

"{\"index\":\"ossec-*\"

It loads properly.

This looks like it's been fixed in the OSCAP dashboards: https://github.com/wazuh/wazuh/blob/1b6de44e9dc70fb056f804ebac58cabd9a357912/extensions/kibana/openscap-dashboards/new_kibana-ossecwazuh-dashboards.json

Replace Logstash Forwarder with Filebeat

Since the Logstash Forwarder is no longer in development and has been replaced with Filebeat it is best to replace it.

This is the logstash input config I have

    ## OSSEC-Wazuh filebeat
    beats {
            port => 5045
            type => "ossec-alerts"
            codec => "json"
            tags => "ossec"
    }

wazuh-agent rpm is unavailable for EL5 x86_64

While trying to install the Wazuh agent on a 64-bit EL5 host, I noticed that there isn't any rpm package available on your repo (just like the 32-bit arch or the EL6 and EL7 version).
The file location should be http://ossec.wazuh.com/el/5/x86_64/wazuh-agent-1.1.1-2.el5.x86_64.rpm
Maybe it was caused by a failure during the last build (2016-10-21)?
Can you please fix that?
Thanks a lot

P.s.: Looking at the google's cache, it seems that the package existed 'till the 8 Oct 16
http://webcache.googleusercontent.com/search?q=cache:30I-gmtGKdsJ:ossec.wazuh.com/el/5/x86_64/+&cd=1&hl=it&ct=clnk&gl=it&client=ubuntu

OpenBSD compilation failure. sys/epoll.h: No such file or directory

I'm unable to compile wazuh on OpenBSD 6.0-STABLE.

I'm happy to try/test all possible solutions.

1- What kind of installation do you want (server, agent, local, hybrid or help)? local

  - Local installation chosen.

2- Setting up the installation environment.

 - Choose where to install the OSSEC HIDS [/var/ossec]:

    - Installation will be made at  /var/ossec .

3- Configuring the OSSEC HIDS.

  3.1- Do you want e-mail notification? (y/n) [y]:
   - What's your e-mail address? [email protected]

   - We found your SMTP server as: mx.asdf.com
   - Do you want to use it? (y/n) [y]: n

   - What's your SMTP server ip/host? smtp.asdf.com

  3.2- Do you want to run the integrity check daemon? (y/n) [y]:

   - Running syscheck (integrity check daemon).

  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

   - Running rootcheck (rootkit detection).

  3.4- Active response allows you to execute a specific
       command based on the events received. For example,
       you can block an IP address or disable access for
       a specific user.
       More information at:
       http://www.ossec.net/en/manual.html#active-response

   - Do you want to enable active response? (y/n) [y]:

     - Active response enabled.

   - By default, we can enable the host-deny and the
     firewall-drop responses. The first one will add
     a host to the /etc/hosts.deny and the second one
     will block the host on iptables (if linux) or on
     ipfilter (if Solaris, FreeBSD or NetBSD).
   - They can be used to stop SSHD brute force scans,
     portscans and some other forms of attacks. You can
     also add them to block on snort events, for example.

   - Do you want to enable the firewall-drop response? (y/n) [y]: n

     - firewall-drop disabled.

   - Default white list for the active response:
      - 195.130.131.4
      - 195.130.130.4

   - Do you want to add more IPs to the white list? (y/n)? [n]: y
   - IPs (space separated): 192.168.0.221

  3.6- Setting the configuration to analyze the following logs:
    -- /var/log/messages
    -- /var/log/authlog
    -- /var/log/secure
    -- /var/log/xferlog
    -- /var/log/maillog

 - If you want to monitor any other file, just change
   the ossec.conf and add a new localfile entry.
   Any questions about the configuration can be answered
   by visiting us online at http://www.ossec.net .


   --- Press ENTER to continue ---



5- Installing the system
 - Running the Makefile
    CC external/cJSON/cJSON.o
    LINK libcJSON.a
    RANLIB libcJSON.a
cd external/zlib-1.2.8/ && ./configure && gmake libz.a
Checking for gcc...
Checking for shared library support...
Building shared library libz.so.1.2.8 with gcc.
Checking for off64_t... No.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.
gmake[1]: Entering directory '/home/joris/wazuh-1.1.1/src/external/zlib-1.2.8'
gcc -O3  -DHAVE_HIDDEN   -c -o adler32.o adler32.c
gcc -O3  -DHAVE_HIDDEN   -c -o crc32.o crc32.c
gcc -O3  -DHAVE_HIDDEN   -c -o deflate.o deflate.c
gcc -O3  -DHAVE_HIDDEN   -c -o infback.o infback.c
gcc -O3  -DHAVE_HIDDEN   -c -o inffast.o inffast.c
gcc -O3  -DHAVE_HIDDEN   -c -o inflate.o inflate.c
gcc -O3  -DHAVE_HIDDEN   -c -o inftrees.o inftrees.c
gcc -O3  -DHAVE_HIDDEN   -c -o trees.o trees.c
gcc -O3  -DHAVE_HIDDEN   -c -o zutil.o zutil.c
gcc -O3  -DHAVE_HIDDEN   -c -o compress.o compress.c
gcc -O3  -DHAVE_HIDDEN   -c -o uncompr.o uncompr.c
gcc -O3  -DHAVE_HIDDEN   -c -o gzclose.o gzclose.c
gcc -O3  -DHAVE_HIDDEN   -c -o gzlib.o gzlib.c
gcc -O3  -DHAVE_HIDDEN   -c -o gzread.o gzread.c
gcc -O3  -DHAVE_HIDDEN   -c -o gzwrite.o gzwrite.c
ar rc libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
gmake[1]: Leaving directory '/home/joris/wazuh-1.1.1/src/external/zlib-1.2.8'
cd external/lua/ && gmake posix
gmake[1]: Entering directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3'
cd src && gmake posix
gmake[2]: Entering directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3/src'
gmake all SYSCFLAGS="-DLUA_USE_POSIX"
gmake[3]: Entering directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3/src'
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lapi.o lapi.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lcode.o lcode.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lctype.o lctype.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ldebug.o ldebug.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ldo.o ldo.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ldump.o ldump.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lfunc.o lfunc.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lgc.o lgc.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o llex.o llex.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lmem.o lmem.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lobject.o lobject.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lopcodes.o lopcodes.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lparser.o lparser.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lstate.o lstate.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lstring.o lstring.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ltable.o ltable.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ltm.o ltm.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lundump.o lundump.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lvm.o lvm.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lzio.o lzio.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lauxlib.o lauxlib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lbaselib.o lbaselib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lbitlib.o lbitlib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lcorolib.o lcorolib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ldblib.o ldblib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o liolib.o liolib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lmathlib.o lmathlib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o loslib.o loslib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lstrlib.o lstrlib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o ltablib.o ltablib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o loadlib.o loadlib.c
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o
ranlib liblua.a
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o lua.o lua.c
cc -o ossec-lua   lua.o liblua.a -lm
liblua.a(lmathlib.o): In function `math_randomseed':
lmathlib.c:(.text+0x226): warning: warning: rand() may return deterministic values, is that what you want?
liblua.a(loslib.o): In function `os_tmpname':
loslib.c:(.text+0x52): warning: warning: strcpy() is almost always misused, please use strlcpy()
liblua.a(lobject.o): In function `luaO_pushvfstring':
lobject.c:(.text+0x448): warning: warning: sprintf() is often misused, please use snprintf()
cc -O2 -Wall -DLUA_COMPAT_ALL -DPREFIX=\"/var/ossec\" -DLUA_USE_POSIX    -c -o luac.o luac.c
cc -o ossec-luac   luac.o liblua.a -lm
liblua.a(lobject.o): In function `luaO_pushvfstring':
lobject.c:(.text+0x448): warning: warning: sprintf() is often misused, please use snprintf()
gmake[3]: Leaving directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3/src'
gmake[2]: Leaving directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3/src'
gmake[1]: Leaving directory '/home/joris/wazuh-1.1.1/src/external/lua-5.2.3'
    CC os_maild/mail_list.o
    CC os_maild/os_maild_client.o
    CC os_maild/config.o
    CC os_maild/sendcustomemail.o
    CC os_maild/sendmail.o
    CC os_maild/maild.o
    CC os_crypto/blowfish/bf_op.o
    CC os_crypto/blowfish/bf_skey.o
    CC os_crypto/blowfish/bf_enc.o
    CC os_crypto/md5/md5.o
    CC os_crypto/md5/md5_op.o
    CC os_crypto/sha1/sha1_op.o
    CC os_zlib/os_zlib.o
    LINK os_zlib.a
    RANLIB os_zlib.a
    CC os_crypto/shared/msgs.o
    CC os_crypto/shared/keys.o
    CC os_crypto/md5_sha1/md5_sha1_op.o
    LINK os_crypto.a
    RANLIB os_crypto.a
    CC config/csyslogd-config.o
    CC config/alerts-config.o
    CC config/syscheck-config.o
    CC config/dbd-config.o
    CC config/rules-config.o
    CC config/client-config.o
    CC config/global-config.o
    CC config/email-alerts-config.o
    CC config/config.o
    CC config/reports-config.o
    CC config/remote-config.o
    CC config/integrator-config.o
    CC config/active-response.o
    CC config/agentlessd-config.o
    CC config/rootcheck-config.o
    CC config/localfile-config.o
    LINK config.a
    RANLIB config.a
    CC shared/agent_op.o
    CC shared/randombytes.o
    CC shared/string_op.o
    CC shared/validate_op.o
    CC shared/custom_output_search_replace.o
    CC shared/hash_op.o
    CC shared/mq_op.o
    CC shared/read-agents.o
shared/read-agents.c: In function '_do_print_attrs_syscheck':
shared/read-agents.c:164: warning: the address of 'perm_str' will never be NULL
shared/read-agents.c: In function '_do_print_file_syscheck':
shared/read-agents.c:331: warning: the address of 'read_day' will never be NULL
shared/read-agents.c: In function '_do_print_syscheck':
shared/read-agents.c:456: warning: the address of 'read_day' will never be NULL
shared/read-agents.c: In function '_do_print_rootcheck':
shared/read-agents.c:669: warning: the address of 'read_day' will never be NULL
shared/read-agents.c:670: warning: the address of 'old_day' will never be NULL
shared/read-agents.c:677: warning: the address of 'json_buffer' will never be NULL
    CC shared/regex_op.o
    CC shared/rules_op.o
    CC shared/math_op.o
    CC shared/debug_op.o
    CC shared/dirtree_op.o
    CC shared/privsep_op.o
    CC shared/list_op.o
    CC shared/pthreads_op.o
    CC shared/help.o
    CC shared/wait_op.o
    CC shared/file_op.o
    CC shared/report_op.o
    CC shared/mem_op.o
    CC shared/sig_op.o
    CC shared/store_op.o
    CC shared/fs_op.o
    CC shared/read-alert.o
    CC shared/file-queue.o
    LINK shared.a
    RANLIB shared.a
    CC os_net/os_net.o
    LINK os_net.a
    RANLIB os_net.a
    CC os_regex/os_match_execute.o
    CC os_regex/os_regex_free_substrings.o
    CC os_regex/os_regex_execute.o
    CC os_regex/os_regex_strbreak.o
    CC os_regex/os_regex_maps.o
    CC os_regex/os_match_free_pattern.o
    CC os_regex/os_match_compile.o
    CC os_regex/os_regex_free_pattern.o
    CC os_regex/os_regex_startswith.o
    CC os_regex/os_regex_compile.o
    CC os_regex/os_match.o
    CC os_regex/os_regex_str.o
    CC os_regex/os_regex.o
    CC os_regex/os_regex_match.o
    LINK os_regex.a
    RANLIB os_regex.a
    CC os_xml/os_xml_writer.o
    CC os_xml/os_xml_node_access.o
    CC os_xml/os_xml_access.o
    CC os_xml/os_xml.o
    CC os_xml/os_xml_variables.o
    LINK os_xml.a
    RANLIB os_xml.a
    CC ossec-maild
    CC os_csyslogd/alert.o
    CC os_csyslogd/csyslogd.o
    CC os_csyslogd/main.o
    CC os_csyslogd/config.o
    CC ossec-csyslogd
libcJSON.a(cJSON.o): In function `print_number':
cJSON.c:(.text+0x125b): warning: warning: strcpy() is almost always misused, please use strlcpy()
os_csyslogd/csyslogd.o: In function `field_add_truncated':
csyslogd.c:(.text+0x37a): warning: warning: strcat() is almost always misused, please use strlcat()
libcJSON.a(cJSON.o): In function `print_number':
cJSON.c:(.text+0x131d): warning: warning: sprintf() is often misused, please use snprintf()
    CC agentlessd/agentlessd.o
    CC agentlessd/main.o
    CC ossec-agentlessd
    CC os_execd/win_execd.o
    CC os_execd/execd.o
    CC os_execd/config.o
    CC os_execd/exec.o
    CC ossec-execd
shared.a(hash_op.o): In function `OSHash_setSize':
hash_op.c:(.text+0x366): warning: warning: random() may return deterministic values, is that what you want?
    CC logcollector/read_snortfull.o
    CC logcollector/read_multiline.o
    CC logcollector/read_mysql_log.o
    CC logcollector/logcollector.o
    CC logcollector/read_nmapg.o
    CC logcollector/main.o
    CC logcollector/read_syslog.o
    CC logcollector/read_win_event_channel.o
    CC logcollector/read_mssql_log.o
    CC logcollector/read_win_el.o
    CC logcollector/config.o
    CC logcollector/read_fullcommand.o
    CC logcollector/read_djb_multilog.o
    CC logcollector/read_postgresql_log.o
    CC logcollector/read_command.o
    CC logcollector/read_ossecalert.o
    CC ossec-logcollector
logcollector/logcollector.o: In function `LogCollectorStart':
logcollector.c:(.text+0x734): warning: warning: rand() may return deterministic values, is that what you want?
    CC remoted/syslogtcp.o
    CC remoted/syslog.o
    CC remoted/main.o
    CC remoted/remoted.o
    CC remoted/secure.o
remoted/secure.c:11:23: error: sys/epoll.h: No such file or directory
remoted/secure.c: In function 'HandleSecure':
remoted/secure.c:43: error: storage size of 'request' isn't known
remoted/secure.c:98: error: invalid application of 'sizeof' to incomplete type 'struct epoll_event'
remoted/secure.c:99: warning: implicit declaration of function 'epoll_create'
remoted/secure.c:105: error: 'EPOLLIN' undeclared (first use in this function)
remoted/secure.c:105: error: (Each undeclared identifier is reported only once
remoted/secure.c:105: error: for each function it appears in.)
remoted/secure.c:108: warning: implicit declaration of function 'epoll_ctl'
remoted/secure.c:108: error: 'EPOLL_CTL_ADD' undeclared (first use in this function)
remoted/secure.c:122: warning: implicit declaration of function 'epoll_wait'
remoted/secure.c:130: error: invalid use of undefined type 'struct epoll_event'
remoted/secure.c:130: error: dereferencing pointer to incomplete type
remoted/secure.c:164: error: 'EPOLL_CTL_DEL' undeclared (first use in this function)
remoted/secure.c:43: warning: unused variable 'request'
gmake: *** [Makefile:894: remoted/secure.o] Error 1

 Error 0x5.
 Building error. Unable to finish the installation.

ruleset updater

@snaow I just noticed that you copied updater to this repo - development branch.
What is your approach with it ? Are you going to completely get rid of ossec-rules repo and move everything here ?
I'm asking in terms of creating a proper Dockefile that will support ruleset updates.

syntax error in host-deny.sh

Hi, not sure that it's the right section for this issue, sorry if not. I've installed rpm packages from "WAZUH OSSEC Repository" on some centOS7 servers and found a problem with host-deny.sh.
At lines 114 and 117, whitespaces around the "=" sign after TMP_FILE cause a bash error ("command not found"). Removing whitespaces solves the problem.
Regards.

preloaded-vars.conf USER_INSTALL_TYPE variable different?

I modified my previous bootstrap code used with ossec-hids to try and use ossec-wazuh. There seems to be some issue with the USER_INSTALL_TYPE variable. Maybe a problem in my code?
:

git clone https://github.com/wazuh/ossec-wazuh.git
  cat<<EOF > ossec-wazuh/etc/preloaded-vars.conf
  # preloaded-vars.conf, Daniel B. Cid (dcid @ ossec.net).
  #
  # Use this file to customize your installations.
  # It will make the install.sh script pre-load some
  # specific options to make it run automatically
  # or with less questions.

  # PLEASE NOTE:
  # When we use n or y in here, it should be changed
  # to n or y in the language your are doing the
  # installation. For example, in portuguese it would
  # be s or n.

  # USER_LANGUAGE defines to language to be used.
  # It can be \"en\", \"br\", \"tr\", \"it\", \"de\" or \"pl\".
  # In case of an invalid language, it will default
  # to English \"en\"
  USER_LANGUAGE=\"en\"     # For english
  #USER_LANGUAGE=\"br\"     # For portuguese


  # If USER_NO_STOP is set to anything, the confirmation
  # messages are not going to be asked.
  USER_NO_STOP=\"y\"


  # USER_INSTALL_TYPE defines the installation type to
  # be used during install. It can only be \"local\",
  # \"agent\" or \"server\".
  #USER_INSTALL_TYPE=\"local\"
  USER_INSTALL_TYPE=\"agent\"
  #USER_INSTALL_TYPE=\"server\"
  ...

seems to crash and not finish the install when it hits the USER_INSTALL_TYPE, either it does not like the \ or has the type changed?

Replacement for sha1 and md5 checksum ?

Hi guys,

since the announcement of the sha1 collision and md5 being vulnerable for a while as well, I wondered if there were considerations to replace sha1/md5 with something more reliable and secure like sha256 for syscheck/fim. what are your thoughts on the impact?

resources:
https://shattered.io/
http://valerieaurora.org/hash.html
https://www.thesslstore.com/blog/sha-1-collision-created/

just a thought. what do you think?

cheers,
theresa

OSSEC HA

Hello guys,

thanks for what you have had done.
This is a wonderful job.

I have a question about High Availability - do you have any experience for multiple servers that could be shared ?

According to this https://groups.google.com/forum/#!topic/ossec-list/TYCfLxNGwlw
Looks like it's not too complicated, since your version of OSSEC proxies everything into ELK.
the only thing that has to be shared is clients.key.

Maybe you can give me some advice.

Thanks again.

ossec-reportd

trying to run ossec-reportd and I am not receiving any info. I am using the following command from ossec website.

cat /var/ossec/logs/alerts/alerts.json | /var/ossec/bin/ossec-reportd -f level 10

I changed the "alerts.log" to "alerts.json". when I run this I get the reported has complete and there are zero alerts.
if I run the report with the "alerts.log", I get "invalid pointer"

ES mappings for timestamp is different for 2.2.x

To get the mapping to work I had to change te @timestamp format to:

      "format": "strict_date_optional_time||epoch_millis"

DNS not resolving for wazuh.com

I am trying to get ossec working, and all of the documentation points to a debian apt repository, but wazuh.com doesn't resolve anymore.

Ubuntu 16.04 Repo signature key SHA1 (apt 1.2.7)

Ubuntu 16.04 complains about using a weak signature key when running apt-get update.
Is it possible to fix your key to use SHA2?

Followed instructions to install the key:
$ apt-key adv --fetch-keys http://ossec.wazuh.com/repos/apt/conf/ossec-key.gpg.key

$ apt-get update
W: http://ossec.wazuh.com/repos/apt/ubuntu/dists/xenial/InRelease:Signature by key 9FE55537D1713CA519DFB85114B9C8DB9A1B1C65 uses weak digest algorithm (SHA1)

Ref:

ros-infrastructure/buildfarm_deployment#130

Invalid query in Kibana visualization "High Risk Alerts / PCI DSS"

Hello,

Looks like I found small mistake in file kibana-ossecwazuh-dashboards.json, string 574 - query is a "rule.AlertLevel > 10", but I think it should be "rule.AlertLevel: { 10 TO *}".

Integrator not running

I followed the docs at - https://github.com/wazuh/wazuh-documentation/blob/master/source/manual_integrator.rst

The integrator does not appear to be running.

I don't see anything relevant in the ossec.log or the integrations.log.

I have generated events that match the filter.

Terminal output

root@host:/var/ossec# /var/ossec/bin/ossec-control enable integrator
root@host:/var/ossec# /var/ossec/bin/ossec-control restart
Killing ossec-monitord .. 
Killing ossec-logcollector .. 
Killing ossec-syscheckd .. 
Killing ossec-analysisd .. 
ossec-maild not running ..
ossec-execd not running ..
ossec-integratord not running ..
OSSEC HIDS v2.8 Stopped
Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
2016/09/02 02:29:09 ossec-maild: INFO: E-Mail notification disabled. Clean Exit.
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.
root@host:/var/ossec# /var/ossec/bin/ossec-control status
ossec-monitord is running...
ossec-logcollector is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild not running...
ossec-execd not running...
ossec-integratord not running...
root@host-0:/var/ossec# 

Settings

  <integration>
   <name>slack</name>
   <hook_url>https://hooks.slack.com/services/REDACTED</hook_url>
   <level>7</level>
  </integration>

Edit:

If I run the integratord in the foreground it seems to work

root@host:/var/ossec# /var/ossec/bin/ossec-integratord -t 
root@host:/var/ossec# /var/ossec/bin/ossec-integratord -f
2016/09/02 02:52:25 ossec-integratord: INFO: Started (pid: 57697).
2016/09/02 02:52:25 ossec-integratord: INFO: Enabling integration for: 'slack'.

If I then stop it running in the foreground and then check the status it shows as running, but I need to be able to do this non-interactively since I'll start the whole process off using configuration management tools.

Build in skip_nfs

Hello, from what I can see it doesn't appear that the skip_nfs flag is compiled in to the latest packages. I get an error like:
./ossec-syscheckd -t
2016/03/15 20:15:53 ossec-config(1230): ERROR: Invalid element in the configuration: 'skip_nfs'.
2016/03/15 20:15:53 ossec-config(1202): ERROR: Configuration error at '/var/ossec/etc/ossec.conf'. Exiting.
2016/03/15 20:15:53 ossec-syscheckd(1202): ERROR: Configuration error at '/var/ossec/etc/ossec.conf'. Exiting.

integration not working for alerts on the manager server

To reproduce I have a slack integration setup with a rule_id set to 5710 (Attempt to login using a non-existent user). When I try to log into my other agents with a non-existent user the integration triggers correctly. When I try to log into the OSSEC manager server with a non-existent user the integration does not get triggered.

Looking at /var/ossec/logs/alerts/alerts.json I do see the alert for the login attempt on the manager server and it also shows up in Kibana so I know it is logging correctly.

Apache modsec issue ?

Hello,

Thanks for your work, Wazuh is an amazing solution :)

I have a question about modsecurity. I added localfile in my ossec configuration to check modsec_audit.log but all logs sent to ossec-master and to Kibana are not clean and exploitable.
I just have rules.id 1003 match 'Non standard syslog message (size too large).'

Is there a specific configuration for the log format in modsecurity ?

Thanks,

Best,

OpenSCAP Version dependency

the SCAP rules currently included with wazuh (e.g. ssg-debian-8-ds.xml) require at least OVAL Version 5.11.

Debian jessie includes "1.0.9-1+b2", which only supports OVAL version 5.10.1, causing this errors like this:

File '/var/ossec/wodles/oscap/content/ssg-debian-8-ds.xml' line 1835: Element '{http://oval.mitre.org/XMLSchema/oval-definitions-5#linux}systemdunitdependency_test': This element is not expected.

Version 1.2-1jessie of wazuh-agent and wazuh-manager depend on libopenscap8, it would be better if the wazuh packages would only recommend/suggest libopenscap8 in the appropiate version (>= 1.2.4) if the openscap package is not necessary to run wazuh.

Building for OSX

When trying to build for OSX (El Capitan in this case, but it will most versions), I get the following error:

 CC remoted/secure.o
remoted/secure.c:10:10: fatal error: 'sys/epoll.h' file not found
#include <sys/epoll.h>

It seems that epoll is Linux only, and for use on OSX kqueue is required. This issue seems to be an issue with this fork, as the standard OSSEC does compile and install.

I'd really like to be able to use your ELK stack integration within our enterprise, however we are mostly OSX machines. Is this something on your roadmap?

Error in GeoLiteCity [solved]

Hi Guys,

First I would like to congratulate all people involved in this project. I knew Wazuh a little time ago and get in love immediately, I hope to be able to contribute to the community soon after to get more experience in Wazuh + ELK.

Unfortunately i'm facing an error with GeoLiteCity, I have the following settings in 01-ossec-singlehost.conf file on field filter:

filter {
geoip {
source => "srcip"
target => "geoip"
database => "/etc/logstash/GeoLiteCity.dat"
add_field => [ "[geoip][location]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][location]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][location]", "float"]
rename => [ "geoip", "GeoLocation" ]
remove_field => [ "timestamp" ]
}
}

I'm using logstash, elasticsearch and kibana 5.2.0 version. I got geolitecity from http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz and the md5sum is:

477c74652d812fc7665ac06c1befb68b GeoLiteCity.dat

When I try to start logstash I get the following error in logstash-plain.log:

[2017-02-04T16:56:52,087][ERROR][logstash.filters.geoip ] The GeoLite2 MMDB database provided is invalid or corrupted. {:exception=>com.maxmind.db.InvalidDatabaseException: Could not find a MaxMind DB metadata marker in this file (GeoLiteCity.dat). Is this a valid MaxMind DB file?, :field=>"srcip"}
[2017-02-04T16:56:52,093][ERROR][logstash.agent ] Pipeline aborted due to error {:exception=>com.maxmind.db.InvalidDatabaseException: Could not find a MaxMind DB metadata marker in this file (GeoLiteCity.dat). Is this a valid MaxMind DB file?, :backtrace=>["com.maxmind.db.Reader.findMetadataStart(com/maxmind/db/Reader.java:278)", "com.maxmind.db.Reader.(com/maxmind/db/Reader.java:129)", "com.maxmind.db.Reader.(com/maxmind/db/Reader.java:116)", "com.maxmind.geoip2.DatabaseReader.(com/maxmind/geoip2/DatabaseReader.java:37)", "com.maxmind.geoip2.DatabaseReader.(com/maxmind/geoip2/DatabaseReader.java:27)", "com.maxmind.geoip2.DatabaseReader$Builder.build(com/maxmind/geoip2/DatabaseReader.java:133)", "java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:498)", "RUBY.register(/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-filter-geoip-4.0.4-java/lib/logstash/filters/geoip.rb:143)", "RUBY.suppress_all_warnings(/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-filter-geoip-4.0.4-java/lib/logstash/filters/geoip.rb:21)", "RUBY.register(/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-filter-geoip-4.0.4-java/lib/logstash/filters/geoip.rb:130)", "RUBY.register(/usr/share/logstash/vendor/jruby/lib/ruby/1.9/forwardable.rb:201)", "RUBY.start_workers(/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:235)", "org.jruby.RubyArray.each(org/jruby/RubyArray.java:1613)", "RUBY.start_workers(/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:235)", "RUBY.run(/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:188)", "RUBY.start_pipeline(/usr/share/logstash/logstash-core/lib/logstash/agent.rb:302)", "java.lang.Thread.run(java/lang/Thread.java:745)"]}

If I comment all filter settings in 01-ossec-singlehost.conf everything works good, although I get others errors when try to import wazuh-kibana5-dashboards.json to Kibana. Could someone help me solve this issue?

What does wazuh mean, and how to pronounce?

I'm curious, and didn't find the answer through Google.

Bundled kibana4 init Script Runs As Root

The kibana4 init script that is included in extensions/kibana runs the service as root. Kibana listens on a non-privileged port, so it'd be great if the service ran as an unprivileged account.

It appears that the upstream provider of this script added support for defining a user on May 20th:
panophobicPanda/scripts@52bf2ce

Could we get those changes merged in (I am not savvy enough to submit a pull request)?

Alerting Daemon hangup

Following is a log of slack integration for alerts which we have done.

2017/01/24 11:17:35 ossec-integratord: ERROR: Unable to run integration for slack -> /var/ossec/integrations/slack

After some time, such kind of error message appears out of blue and we stop getting the alerts from the ossec system to our slack channel. Although the alert.log is getting filled with new alerts, but I am unable to get the alerts on slack. And if i check the status of ossec service, it shows as running.

The issue doesnt get fixed until i restart the ossec service

Possible false positive in Debian Stretch

Hi,

I have been receiving the following alert:

Host-based anomaly detection event (rootcheck).
Trojaned version of file '/bin/grep' detected. Signature used: 'bash|givemer|/dev/' (Generic).

I have tested in the server the following command:
strings /bin/grep | grep -E 'bash|givemer|/dev/'

With the result:
/dev/null

Debsum result:

debsums grep
/bin/egrep OK
/bin/fgrep OK
/bin/grep OK
/usr/bin/rgrep OK
/usr/share/doc/grep/copyright OK
/usr/share/locale/de/LC_MESSAGES/grep.mo OK
/usr/share/locale/es/LC_MESSAGES/grep.mo OK
/usr/share/locale/fr/LC_MESSAGES/grep.mo OK
/usr/share/locale/ja/LC_MESSAGES/grep.mo OK
/usr/share/locale/zh_CN/LC_MESSAGES/grep.mo OK
/usr/share/locale/zh_TW/LC_MESSAGES/grep.mo OK

I have been looking around worried that may be a hack but so far chkrootkit and other tests doesn't show this positive.

I was wondering if this may be a false positive from ossec side.

Thanks in advance!

OSSEC Live Rule Swap / Reload

Team,

Thanks for the work you are doing on OSSEC, it is great.

One feature / addition that I could see being useful is the ability to do a live rule reload / swap via a HUP or some arbitrary kill signal. Suricata is doing that currently:
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Live_Rule_Swap

I would really like the ability to track the Wazuh ruleset without having bounce the managers each time the rules are updated. This would be even more useful within the Docker containers.

Thanks!

Feature Request: Pull in GeoIP Changes from DCID

@dcid has added some great features in the past few months to his own personal fork of OSSEC:
https://github.com/dcid/ossec-hids/blob/master/CHANGELOG

I'm not very savvy with Git, but I was hoping that someone would be willing to take a look as his repository and merge some of his changes. In particular I'm interested in his support of different_geoip to alert on simultaneous logins for the same user from two separate locations.

Note: If it is inappropriate to submit an Issue rather than learning how to generate the proper Pull Request(s) then please accept my apologies!

win_agent.c OS_ReadKeys incorrect parameters

Master branch:
src/win32/win_agent.c

Line 205 OS_ReadKeys is missing the third parameter which I assume should be the number 0.

OS_ReadKeys($keys, 1, 0);

TARGET=winagent won't build, obviously, without that

Update OSSEC from the master

OSSEC have added some additional functionality allowing the notify time to be changed when an ossec agent disconnects. I use the Wazuh branch of OSSEC and i have not seen this functionality added. See commit: ossec/ossec-hids#1020

UDP bad chksum when i try to add an agent

Hi,
i'm an ossec user by some time and i recentely knew your project: is amazing.
I have an ossec server but now i setup a new elk-ossec server with your ossec fork.
I added to new elk-ossec all my agents BEFORE the update to ossec-wazuh of agents.
All ok.
i upgrade the agetns: all ok.
Now i have a new vps: so i install ossec-wazuh without install/config before the ossec-hids and, when i try to connect the agent to the server, the UDP checksum go bad.
i open a tcpdump in the elk-ossec server
[root@elk bin]# tcpdump -i eth0 -vvv -X port 1514
and i see the packet arrived from my agent client
vps.mydomain.com.54467 > 10.255.255.3.fujitsu-dtcns: [udp sum ok] UDP, length 73
10.255.255.3.fujitsu-dtcns > vps.mydomain.com.54467: [bad udp cksum 83de!] UDP, length 73

so the connection go wrong. it repeat this try without work.
I investigate if i had network trouble but all it's ok for me.
So i try removing ossec-wazuh and installing ossec-hids and re-adding the client:
all ok now !!! no bad chksum on udp packet.
After that i upgrade to ossec-wazuh and all works fine.

Thanks you for all.

Gionni

Unable to use environment variables as responses in order to configure the wazuh-agent

Following the instructions found in https://raw.githubusercontent.com/wazuh/ossec-wazuh/master/doc/manage_agents.txt, I was trying to implement an unattended agent setup using the environment variables as responses for the manage_agent command (using ansible).
Even if I correctly set all the 6 required env-vars (OSSEC_ACTION OSSEC_AGENT_NAME OSSEC_AGENT_IP OSSEC_AGENT_ID OSSEC_AGENT_KEY OSSEC_ACTION_CONFIRMED), the manage_agent command produces an incorrect base-64 hash which doesn't match the manager key.
So, on the manager, I see many of these log lines:

1403 - Incorrectly formated message”

If I copy-and-paste the OSSEC_AGENT_KEY interactively, it works.
The workaround for us was to create an expect script to feed the manage_agent command with the responses. This way, it works.
I double-check the OSSEC_AGENT_ID variable value for spurious newline or blank characters but I can't find any difference between the "agent key string" passed in interactive mode or as a env variable.

The steps to reproduce the issue are:

• create a new agent key on the manager with manage_agents -a 10.1.1.1 -n testhost
• extract the agent key with manage_agents -e <AGENT_ID>
• log on the testhost (10.1.1.1) and set these variables:

 export OSSEC_ACTION: a
 export OSSEC_AGENT_NAME: testhost
 export OSSEC_AGENT_IP: 10.1.1.1
 export OSSEC_AGENT_ID: <AGENT_ID>
 export OSSEC_AGENT_KEY: <AGENT_KEY>
 export OSSEC_ACTION_CONFIRMED: y

• run the manage_agents without many parameters
• verify that the base64 hash in the client_keys file on the manager and the agent host is different (while it should be the same)

ossec-remoted complains it can't open /etc/client.keys when it actually finds wrong permissions on /var/ossec/etc/client.keys

I had ossec installed from source on a machine (Amazon Linux, somewhat RHEL6-like), and I have now stopped it, installed with your puppet module (from the el6 rpm) and copied over the old client.keys file to /var/ossec/etc/.
however on each restart, ossec-remoted says it can't find the file and dies:

2016/11/02 13:17:04 ossec-remoted(4111): INFO: Maximum number of agents allowed: '16384'.
2016/11/02 13:17:04 ossec-remoted(1410): INFO: Reading authentication keys file.
2016/11/02 13:17:04 ossec-remoted(1103): ERROR: Unable to open file '/etc/client.keys'.
2016/11/02 13:17:04 ossec-remoted(1750): ERROR: No remote connection configured. Exiting.

I have no idea where it got the path from, but I copied the file there just in case, and it still quits. the file is definitely full of the old clients' details and manage_agents sees it fine. What am I missing?

Windows Event Logs

The Wazuh fork is really promising but it comes with the flaw of ossec is that it handles Windows Event Logs rather badly. There is so much content in them that can help identify problems that is not parsed, for example any usernames, file paths, domains and so on.

Parsing every single possible event format is not the best course of action but possibly the only option. I know that Windows Event Logs have more meta data in them than you can view through the xml view. Ossec sadly is not aware of it so to bring Wazuah to a level above Ossec getting that detailed information is incredibly valuable.

Are there any plans to modify the ossec client to get that information?

build issue during directory copy

when building wazuh ossec on different platforms, a user may encounter a build issue with a new install. Steps required:

1. clone wazuh per directions. Run normal install, for example, server, installs with no issues
2. copy same folder over to a new host to install, for example, an agent. Run install for agent, system fails at agent-auth build. This is caused because a change in the build platform, in one example, RHEL 6 to 7 or RHEL 7 to Debian and a "make clean" is not inferred during a normal build process.

Suggestion is to add a "make clean" before the build process, if binaries are detected in any of the src folders.

Slack Integration Message truncation Issue

Hey there,

I had enabled slack integration with OSSEC, but the thing is that the alert messages are getting truncated before they are sent. For e.g. :

2016 Oct 04 13:01:42 test->/var/log/audit/audit.log
Rule:80739 (level 5): Auditd: account state error detected
IP:x.x.x.x
type=USER_ERR msg=audit(1475566301.994:186187): pid=7599 uid=0 auid=4294967295 ses=4294967295 msg= op=PAM:bad_ident acct= ? exe= /usr/sbin/sshd hostname=42.104....

The ellipses at the end are generated by the integratord it seems, since i tried logging the contents in the integrations/slack shell script to see as to what content is being generated?

Please help here to fix this.

integration with OSSIM?

You guys have done amazing work on the upgraded version of OSSEC. I wonder if anyone has thought of doing a guide for integration in the OSSIM? I have used Santiago's guide to actually do this, however, the new rulesets do not fire in this case because the IDs have not been integrated into the OSSIM DB. This would be a great add-on/enhancement. I might be willing to put a PR in as I have done some work on this, but wanted to wait on the final release of the new version.

date parsing anomoly

I have several systems that have a date stamp that does not decode correctly. Namely, the date portion only has one space after the month name, e.g.

Nov 9 14:43:26 hostname kdumpctl: kexec: failed to load kdump kernel
ossec-logtest:
**Phase 1: Completed pre-decoding.
full event: 'Nov 9 14:43:26 hostname kdumpctl: kexec: failed to load kdump kernel'
hostname: 'ossec-manager'
program_name: '(null)'
log: 'Nov 9 14:43:26 hostname kdumpctl: kexec: failed to load kdump kernel'

Using the log entry with 2 spaces between the month and day:

Nov 9 14:43:26 hostname kdumpctl: kexec: failed to load kdump kernel

**Phase 1: Completed pre-decoding.
full event: 'Nov 9 14:43:26 hostname kdumpctl: kexec: failed to load kdump kernel''
hostname: 'hostname'
program_name: 'kdumpctl'
log: 'kexec: failed to load kdump kernel''

Note in the second case the program_name is identified correctly. I think the code is in
ossec-wazuh/src/analysisd/cleanevent.c.

Let me know if you have questions,

John

wazuh-elastic2-template.json contains fields with period in mapping names

Tried to execute http://wazuh-documentation.readthedocs.io/en/latest/ossec_elk_elasticsearch.html#ossec-alerts-template

But got:
{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"Field name [file.mode] cannot contain '.'"}],"type":"mapper_parsing_exception","reason":"Failed to parse mapping [wazuh]: Field name [file.mode] cannot contain '.'","caused_by":{"type":"mapper_parsing_exception","reason":"Field name [file.mode] cannot contain '.'"}},"status":400}

This was against ElasticSearch 2.4.4 (provided by cloud.elastic.co)

Importing Ossec alerts index gives error

I get the following error when importing the ossec alerts index.

Error: Could not locate that index-pattern-field (id: SyscheckFile.path) at FieldAggParamFactory.FieldAggParam.deserialize (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:85866:16) at https://54.92.229.48/bundles/kibana.bundle.js?v=10000:91516:29 at Array.forEach (native) at AggConfigFactory.AggConfig.fillDefaults (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:91494:28) at new AggConfig (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:91408:13) at https://54.92.229.48/bundles/kibana.bundle.js?v=10000:92112:19 at Array.map (native) at new AggConfigs (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:92110:35) at VisFactory.Vis.setState (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:85312:20) at SavedVis._updateVis (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:93999:17)

I also get the following error when viewing the ossec Alerts Dashboard

Error: Request to Elasticsearch failed: {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Expected geo_point type on field [GeoLocation.location], but got [double]"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"ossec-2016.11.21","node":"Y_yAabWIRHuj7pdKx_aDqg","reason":{"type":"illegal_argument_exception","reason":"Expected geo_point type on field [GeoLocation.location], but got [double]"}}]}} at https://54.92.229.48/bundles/kibana.bundle.js?v=10000:81088:39 at Function.Promise.try (https://54.92.229.48/bundles/commons.bundle.js?v=10000:61158:23) at https://54.92.229.48/bundles/commons.bundle.js?v=10000:61127:31 at Array.map (native) at Function.Promise.map (https://54.92.229.48/bundles/commons.bundle.js?v=10000:61126:31) at callResponseHandlers (https://54.92.229.48/bundles/kibana.bundle.js?v=10000:81060:23) at https://54.92.229.48/bundles/kibana.bundle.js?v=10000:80561:17 at processQueue (https://54.92.229.48/bundles/commons.bundle.js?v=10000:42404:29) at https://54.92.229.48/bundles/commons.bundle.js?v=10000:42420:28 at Scope.$eval (https://54.92.229.48/bundles/commons.bundle.js?v=10000:43648:29)

Not sure if they are related or not. Might be user error.
Im running this on Ubuntu 14.04. Fresh install.

I used the guide here http://documentation.wazuh.com/en/latest/installation.html

Same logs is lost on the master

I'm collecting all commands on the system via syslog and 'd like to process it with ossec.
Any command should generate alert level 1 and it's ok if I enter one or two commands.
But sometimes if I enter 10x ls and 10x id and then check the alerts.log I get only 1 x ls and 1 x id in the logfile. Seems there're some kind of alerts truncating but I can't find how to avoid this.
I checked the agent-logcollector first and it simply sends all logs to remoted.

Strange garbage characters in PCI_DSS-field

We have been running wazuh for a few weeks, mostly for the analysisd-functionality. We use logstash to consume a kafka topic, and send the desired logs to a file, which analysisd then looks over. Logstash then picks up the resulting alerts.json-file and sends forward into Elasticsearch. Over all we are very pleased with it. However, we have noticed a few interresting issues with the PCI_DSS-field recently though.

It seems that all events that have the group "pci_dss_11.4" gets one or more tailing garbage characters in the resulting PCI_DSS array element. This is an example:

{"rule":{"level":6,"comment":"SSH insecure connection attempt (scan).","sidid":5706,"firedtimes":1,"groups":["syslog","sshd","recon"],"PCI_DSS":["11.4}�"]},"srcip":"10.10.0.20","full_log":"May 30 15:12:09 aserver sshd[2360]: Did not receive identification string from 10.10.0.20","program_name":"sshd","decoder":{"parent":"sshd","name":"sshd"},"hostname":"aserver","timestamp":"2016 May 30 15:12:14","location":"/var/ossec/logs/logstash/logstash.log"}

This seems to be true for all alerts generated that has that group. From what I have seen it doesn't matter if it has more than one groups or just the 11.4 one. The same problem occurs either way.

The big issue with this for us, is that logstash sometimes barfs on the messages that contains this extra character in the alerts.json-file, resulting in some messages not being picked up. It can be mitigated by removing the group from the rules that we are interrested in, but it is not feasable in the long run of course, and will likely be wiped by future rule updates, etc etc.

Have anyone seen this before? We are running the latest release 1.1.1 from https://github.com/wazuh/ossec-wazuh/releases