Probably upstream changes (the container is built from centos:latest) broke the wazuh-manager container. The which binary which is a requirement for the wazuh-manager package installation is missing. Fixed in #15.

It is probably best to not build against centos:latest but use a specific version tag instead to avoid future breakage.

hi m getting these errors, and i dont think elastic cache created ok with the docker . (ubuntu 16.4)

kibana_1 | Elastic is unavailable - sleeping
logstash_1 | [2018-03-24T21:46:19,121][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working {:healthcheck_url=>http://elasticsearch:9200/, :path=>"/"}
logstash_1 | [2018-03-24T21:46:19,125][WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. {:url=>"http://elasticsearch:9200/", :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::SocketException] Connection refused (Connection refused)"}
kibana_1 | % Total % Received % Xferd Average Speed Time Time Time Current
kibana_1 | Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed connect to elasticsearch:9200; Connection refused

from the outside i can reach 9200 but from the inside not really.

root@net-wazhu:~# netstat -anp | egrep -i 9200
tcp6 0 0 :::9200 :::* LISTEN 4274/docker-proxy

my iptables are :
root@net-wazhu:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain DOCKER (2 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.25.0.3 tcp dpt:55000
ACCEPT tcp -- anywhere 172.25.0.3 tcp dpt:1515
ACCEPT udp -- anywhere 172.25.0.3 udp dpt:1514
ACCEPT udp -- anywhere 172.25.0.3 udp dpt:syslog
ACCEPT tcp -- anywhere 172.25.0.5 tcp dpt:5000
ACCEPT tcp -- anywhere 172.25.0.6 tcp dpt:https
ACCEPT tcp -- anywhere 172.25.0.6 tcp dpt:http
ACCEPT tcp -- anywhere 172.25.0.2 tcp dpt:9200

Chain DOCKER-ISOLATION (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere

Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

but the docker itself throwing me out
root@net-wazhu:# docker exec -i -t 668f1be1b64e /bin/bash
[root@elasticsearch elasticsearch]# netstat -anp | egrep -i 9200
bash: netstat: command not found
[root@elasticsearch elasticsearch]#
root@net-wazhu:#

Could you help - I am trying to mount volume in wazuh manager - alerts to host. This is so that the filebeat container can tail the alerts file and send out to another logstash.

Please let me know if you see a problem with my compose file.

version: '2'

services:
  wazuh:
    image: wazuh/wazuh
    hostname: wazuh-manager
    restart: always
    ports:
      - "1514:1514/udp"
      - "1515:1515"
      - "514:514/udp"
      - "55000:55000"
    networks:
        - docker_elk
    volumes:
      - ./wazuh/ruleset:/var/ossec/data/ruleset:Z
      - alerts:/var/ossec/data/logs/alerts:Z
    depends_on:
      - elasticsearch

  filebeat:
    build:
      context: filebeat/
    depends_on:
    - ossec:ro
    hostname: filebeat
    networks:
      - docker_elk
    restart: always
    volumes_from:
    - wazuh:ro
    depends_on:
    - wazuh

  logstash:
    image: wazuh/wazuh-logstash
    hostname: logstash
    restart: always
    command: -f /etc/logstash/conf.d
#    volumes:
#      - ./logstash/config/.:/etc/logstash/conf.d
    links:
     - kibana
     - elasticsearch:elasticsearch
    ports:
      - "5000:5000"
    networks:
        - docker_elk
    depends_on:
      - elasticsearch
    environment:
      - LS_HEAP_SIZE=2048m
      - XPACK_MONITORING_ENABLED=false

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.2.1
    hostname: elasticsearch
    restart: always
    ports:
      - "9200:9200"
      - "9300:9300"
    environment:
      - node.name=node-1
      - cluster.name=wazuh
      - network.host=0.0.0.0
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - xpack.monitoring.enabled=false
      - xpack.ml.enabled=false
      - xpack.watcher.enabled=false
      - xpack.graph.enabled=false
      - "ES_JAVA_OPTS=-Xms1g -Xmx1g"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    mem_limit: 2g
#    volumes:
#      - my-path:/usr/share/elasticsearch/data:Z
    networks:
        - docker_elk

  kibana:
    image: wazuh/wazuh-kibana
    hostname: kibana
    restart: always
#    ports:
#      - "5601:5601"
    networks:
        - docker_elk
    depends_on:
      - elasticsearch
    links:
      - elasticsearch:elasticsearch
      - wazuh
    entrypoint: /wait-for-it.sh elasticsearch
    environment:
      - "NODE_OPTIONS=--max-old-space-size=3072"
  nginx:
    image: wazuh/wazuh-nginx
    hostname: nginx
    restart: always
    entrypoint: /run.sh
    environment:
      - NGINX_PORT=443
    ports:
      - "80:80"
      - "443:443"
#    volumes:
#      - my-path:/etc/nginx/conf.d:Z
    networks:
      - docker_elk
    depends_on:
      - kibana
    links:
      - kibana

volumes:
  alerts:
      

networks:
  docker_elk:
    driver: bridge
    ipam:
      config:
      - subnet: 172.25.0.0/24

Testing: Upgrade Wazuh minor version

Basic tests

• Full deployment of the environment. Check data flow and visualize alerts in Kibana.

• Agent registration.

• Upgrade the Wazuh manager from a lower version.

• Check data base templates. Register a Wazuh agent in a lower version of Wazuh manager. Upgrade the manager to the latest version and register a second agent.

• Check the correct functioning of all volumes.

Review this Wazuh mailing list post: https://groups.google.com/forum/#!topic/wazuh/pCzCwZG1rRw

Add options when the user is using X-Pack security on Elasticsearch, Logstash and Kibana.

Regards,
Juanjo

Hello there,
I've searched in wazuh documentation, forums and more, and I couldn't find an answer to my question:
I've deployed this wazuh/ELK stack through docker using the docker-compose.yml file available in this repository and the server part is working great.

I now would like to install an agent on my host and register it under wazuh server so that I can manage my host easily, active firewall-drop active-response on host, etc...

I've done what the documentation told me to: logged Under my wazuh container, started the agent manager, get the key of my new agent. Then Under my host, I installed wazuh-agent package with apt-get, then I ran /var/ossec/bin/manage-agents and add my agent key but I can't make it work...

I think it could be a network issue:
I'm not sure how I should declare my wazuh's server IP. I tried:

• using my host IP,
• using my wazuh container IP,
• using my docker network Gateway
  --> nothing works...

<ossec_config> <client> <server-ip>$wazuh_container_IP or $host_IP</server-ip>

Do you have any idea what I've messed up ?
Thanks a lot,
Best regards =)

When installing behind a Cooperate Proxy, Kibana cant download the Webapp even with http_proxy set via:

environment:
    - http_proxy= ...
    - https_proxy= ...

It produces following Error

Elastic is up - executing command
Attempting to transfer from https://packages.wazuh.com/wazuhapp/wazuhapp-2.1.0_5.5.2.zip
Error: Client request error: connect ETIMEDOUT 13.32.14.7:443
Plugin installation was unsuccessful due to error "Client request error: connect

How am i suppost to get past this ?
Does the http_proxy env variable get honored ?

Best Regards
Florian

Hello team,

When deploying the Wazuh cluster using Kubernetes we have a problem in the master node, which does not know how to solve the pod "hostname" in the cluster configuration in ossec.conf.

ConfigMap: https://github.com/wazuh/wazuh-kubernetes/blob/master/wazuh_managers/wazuh-master-conf.yaml#L325

        <nodes>
            <node>wazuh-manager-master-0.wazuh-cluster.wazuh.svc.cluster.local</node>
        </nodes>

Error:

ERROR: Error 3004 - Error in cluster configuration: Master IP not valid. Valid ones are: 11.22.33.44

Cause: https://github.com/wazuh/wazuh/blob/v3.7.2/framework/wazuh/cluster/cluster.py#L87-L88

We are going to implement an alternative solution in Docker.

Regards,

Alfonso Ruiz-Bravo

In order to do changes in filebeat.yml easily we can add filebeat folder as mount folder and let docker-compose.yml mount the folder through the volumes volumes section.

Hello,

Could you please tell me why when mounting a folder in my docker-compose.yml file - to the /var/ossec/data/ruleset folder , that all files are seen and upon reading - permission denied.?

Example:

    volumes:
      - ./wazuh/ruleset/.:/var/ossec/data/ruleset

Error:

wazuh_1          | chmod: changing permissions of '/var/ossec/data/ruleset': Permission denied
wazuh_1          | chmod: changing permissions of '/var/ossec/data/ruleset/VERSION': Permission denied
wazuh_1          | chmod: changing permissions of '/var/ossec/data/ruleset/decoders': Permission denied
wazuh_1          | chmod: changing permissions of '/var/ossec/data/ruleset/decoders/0005-wazuh_decoders.xml': Permission denied

I have forced a container recreate with "docker-compose up --force-recreate"

I have also tried editing the /wazuh/Dockerfile with:

USER root
COPY ruleset/* /var/ossec/data/ruleset/
RUN chown 1000:1000 /var/ossec/data/ruleset
RUN chmod 755 /var/ossec/data/ruleset

I have no joy at these configs. Could you all help - Ive been banging my head on the keyboard with this issue.

Thank you!

Hi team, it'd be needed to check the behavior of the containers when executing the new /manager/restart API endpoint. In theory, it has a tail -f, also it should restart the daemons and keep working.

• Perform request, check API response is OK.
• Daemons were restarted properly.
• Manager keeps working after the restart.
• No error logs for Wazuh API nor Wazuh manager.

Thanks!

The upgrade is failing due to:

.templates.db files
It will be fixed en Wazuh v3.8.0 (wazuh/wazuh#2050) but we need a workaround:
The following files must be removed before the upgrade:

• /var/ossec/queue/db/.template.db
• /var/ossec/var/db/.template.db

internal_options.conf
Since we save the internal_options.conf in etc, it will not be overwritten during an upgrade. If Wazuh expects new settings in that file, it will fail.
We need to remove it and push the new one.

We need to include Search Guard as part of the Docker deployment.

Related: wazuh/wazuh-kubernetes#16

Hello team,

Creating a module to have our own image of Wazuh-Elasticsearch has become necessary.

In addition to the inconvenience of having dependencies from one container in a different container, it is not the proper way to proceed.

A clear example is a case where an Elasticsearch container drops.

In that case, if the Elasticsearch container is created again, the Wazuh alerts template will not be loaded nor will the Wazuh API credentials be loaded, as these are steps that are being executed in the Kibana container entrypoint.

Best regards,

Alfonso Ruiz-Bravo

Hello,

I am giving the cointainers a try and upon starting compose all containers start up and I see all listening ports 443/80. I am assuming NGINX is proxying the 443 traffic to :5601 - to Kibana.
I cant seem to get to Kibana , although all is running and the browser does try and resolve - with a 502 reply. I try my URL of https://10.0.1.199

502 Bad Gateway
nginx/1.13.8

I guessed at the password - foo/bar (could this be the issue?)

[cuckoo@wazuh1 ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
93347887cf31 wazuh/wazuh-logstash "/usr/local/bin/docke" About an hour ago Up 2 minutes 5044/tcp, 0.0.0.0:5000->5000/tcp, 9600/tcp wazuhdocker_logstash_1
6c77cb734116 wazuh/wazuh-nginx "/run.sh" About an hour ago Up 2 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp wazuhdocker_nginx_1
6f1e46a43d76 wazuh/wazuh-kibana "/wait-for-it.sh elas" About an hour ago Up 2 minutes 5601/tcp wazuhdocker_kibana_1
c0ac63e8544d wazuh/wazuh "/tmp/run.sh" About an hour ago Up 2 minutes 0.0.0.0:514->514/udp, 0.0.0.0:1515->1515/tcp, 0.0.0.0:1514->1514/udp, 0.0.0.0:55000->55000/tcp wazuhdocker_wazuh_1
30915fcec08f docker.elastic.co/elasticsearch/elasticsearch:6.1.1 "/usr/local/bin/docke" About an hour ago Up 5 seconds 0.0.0.0:9200->9200/tcp, 9300/tcp wazuhdocker_elasticsearch_1
[cuckoo@wazuh1 ~]$ netstat -plntu
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp6 0 0 :::1515 :::* LISTEN -
tcp6 0 0 :::9200 :::* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::55000 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 :::443 :::* LISTEN -
tcp6 0 0 :::5000 :::* LISTEN -
udp 0 0 127.0.0.1:323 0.0.0.0:* -
udp6 0 0 ::1:323 :::* -
udp6 0 0 :::514 :::* -
udp6 0 0 :::1514 :::* -

Thank you.

When i mount the /var/ossec/data folder is get the follow issue:

2017/10/17 13:35:20 wazuh-modulesd: INFO: Process started.
2017/10/17 13:35:20 wazuh-modulesd:oscap: INFO: Module disabled. Exiting...
2017/10/17 13:35:20 wazuh-modulesd:database: INFO: Module started.
2017/10/17 13:35:20 ossec-execd: INFO: Started (pid: 96).
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0005-wazuh_decoders.xml.
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0010-active-response_decoders.xml.
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0015-aix-ipsec_decoders.xml.
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0020-amazon_decoders.xml.
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0025-apache_decoders.xml.
2017/10/17 13:35:20 ossec-remoted: INFO: Started (pid: 110).
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0030-arpwatch_decoders.xml.
2017/10/17 13:35:20 ossec-remoted: INFO: Started (pid: 113).
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0035-asterisk_decoders.xml.
2017/10/17 13:35:20 ossec-analysisd: INFO: Reading decoder file ruleset/decoders/0040-auditd_decoders.xml.
....
2017/10/17 13:35:23 ossec-analysisd: INFO: Reading rules file: 'ruleset/rules/0105-asterisk_rules.xml'
2017/10/17 13:35:23 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2017/10/17 13:35:23 ossec-analysisd: INFO: Reading rules file: 'ruleset/rules/0110-ms_dhcp_rules.xml'
2017/10/17 13:35:23 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2017/10/17 13:35:23 ossec-analysisd: INFO: Reading rules file: 'ruleset/rules/0115-arpwatch_rules.xml'
...
2017/10/17 13:35:24 ossec-remoted: ERROR: (1210): Queue '/queue/ossec/queue' not accessible: 'Connection refused'.
2017/10/17 13:35:24 ossec-remoted: CRITICAL: (1211): Unable to access queue: '/queue/ossec/queue'. Giving up..

When i change

/var/ossec/bin/ossec-control restart

to

/var/ossec/bin/ossec-control stop
/var/ossec/bin/ossec-control start
/var/ossec/bin/ossec-control start

in the /tmp/run.sh, i don't have the issue.
Yes i start is twice.

We are in a state where we have upgraded our servers to ElasticSearch 6.5.2 which means that Kibana will no longer connect to them.

I tried to make a branch and pull request with the changes but get a 403 in doing so.

Hello team,
we should allow the creation of Wazuh docker images (specially the Wazuh manager one) offline.

For this we need:

• List of dependencies, including the base image we are based on (currently phusion:latest)
• Instructions.

Main caveat being dependencies size.

Regards.

Hello team,

It is necessary to add the monitoring activation in Elasticsearch.

curl -XPUT "$el_url/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "xpack.monitoring.collection.enabled": true
  }
}
'

Regards,

Alfonso Ruiz-Bravo

Hello Guys,

Could you recommend a setting for enabling cross cluster searching. I have tried the following with no joy.

Thank you!

in docker-compose.yml

 elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.1.1
    hostname: elasticsearch
    restart: always
    ports:
      - "9200:9200"
      - "9300:9300"
    environment:
      - node.name=wazuh_node-1
      - cluster.name=w-docker-cluster
      - network.host=0.0.0.0
#      - discovery.zen.ping.unicast.hosts=10.0.1.194
#      - discovery.zen.minimum_master_nodes=2
#      - node.master=true
#      - node.data=true
#      - discovery.zen.ping_timeout=10s
      - search.remote.cluster_one=10.0.1.194
      - search.remote.cluster_one.skip_unavailable=true
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - xpack.monitoring.enabled=false
      - xpack.ml.enabled=false
      - xpack.watcher.enabled=false
      - xpack.graph.enabled=false
      - "ES_JAVA_OPTS=-Xms1g -Xmx1g"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    mem_limit: 2g
#    volumes:
#      - my-path:/usr/share/elasticsearch/data
    networks:
        - docker_elk

Looks promising. What's in the roadmap?

Btw, could you please explain main differences between this docker set and wazuh/ossec-elk?

Could you possibly prepare the containers for Wazuh 3.3.1. It seems version 3.3.0 has a bug and its Kibana application doesn't work properly.

$ curl -so docker-compose.yml https://raw.githubusercontent.com/wazuh/wazuh-docker/master/docker-compose.yml

docker-compose up -d

╰─➤

docker ps 125 ↵
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1c45ce73c3e0 wazuh/wazuh-logstash "/tmp/run.sh -f /e..." 7 minutes ago Up 7 minutes 0.0.0.0:5000->5000/tcp wazhu_logstash_1
dce4dbad2fc7 wazuh/wazuh-kibana "sh wait-for-it.sh..." 7 minutes ago Up 7 minutes 0.0.0.0:5601->5601/tcp wazhu_kibana_1
5edde62b2be5 wazuh/wazuh "/tmp/run.sh /usr/..." 7 minutes ago Up 7 minutes 0.0.0.0:514->514/udp, 0.0.0.0:1515->1515/tcp, 0.0.0.0:1514->1514/udp, 0.0.0.0:55000->55000/tcp wazhu_wazuh_1
18ccdf9c4117 elasticsearch:5.5.2 "/docker-entrypoin..." 7 minutes ago Up 7 minutes 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp wazhu_elasticsearch_1

╰─➤ docker exec -it 5edde62b2be5 /bin/bash
[root@wazuh-manager /]# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 07:30 ? 00:00:00 /bin/bash /tmp/run.sh /usr/sbin/init
root 37 1 0 07:30 ? 00:00:00 /var/ossec/bin/ossec-authd -p 1515 -g ossec
ossec 43 1 0 07:31 ? 00:00:00 /bin/node /var/ossec/api/app.js
root 44 1 0 07:31 ? 00:00:00 /bin/bash /usr/bin/filebeat.sh
root 46 44 0 07:31 ? 00:00:00 /usr/share/filebeat/bin/filebeat -path.home /usr/share/filebeat -path.config /etc/filebeat -path.data /var/lib/filebeat -path.logs /var/log/filebeat
root 90 1 0 07:31 ? 00:00:00 /var/ossec/bin/wazuh-modulesd
root 97 1 0 07:31 ? 00:00:00 /var/ossec/bin/ossec-execd
ossec 101 1 0 07:31 ? 00:00:00 /var/ossec/bin/ossec-analysisd
root 106 1 0 07:31 ? 00:00:00 /var/ossec/bin/ossec-logcollector
ossecr 112 1 0 07:31 ? 00:00:00 /var/ossec/bin/ossec-remoted
root 116 1 0 07:31 ? 00:00:02 /var/ossec/bin/ossec-syscheckd
ossec 120 1 0 07:31 ? 00:00:00 /var/ossec/bin/ossec-monitord
root 123 1 0 07:31 ? 00:00:00 tail -f /var/ossec/logs/ossec.log
root 297 0 0 07:38 pts/0 00:00:00 /bin/bash
root 313 297 0 07:39 pts/0 00:00:00 ps -ef
[root@wazuh-manager /]# systemctl
Failed to get D-Bus connection: Operation not permitted
[root@wazuh-manager /]#

╭─[email protected] ~/tool/wazuh ‹system›
╰─➤ docker --version
Docker version 17.06.0-ce, build 02c1d87
╭─[email protected] ~/tool/wazuh ‹system›
╰─➤ docker-compose --version
docker-compose version 1.14.0, build c7bdf9e
╭─[email protected] ~/tool/wazuh ‹system›
╰─➤

i want "systemctl start wazuh-api"

hello
i'm not familiar with docker, but does the elastic container misses in files ?

wazuh-docker-master# docker-compose up
Creating wazuhdockermaster_elasticsearch_1

ERROR: for elasticsearch Cannot create container for service elasticsearch: b'invalid port specification: "None"'
ERROR: Encountered errors while bringing up the project.

Thanks

The image in the docker compose file does not exist on docker hub.

Why don't we use the OSS variants of the ELK stack?

• docker.elastic.co/kibana/kibana-oss:6.4.2
• docker.elastic.co/logstash/logstash-oss:6.4.2

So that we don't have to have issues with X-Pack (we use the OSS version of Elasticsearch).

References:

• https://github.com/wazuh/wazuh-docker/blob/3.6.1_6.4.2/kibana/Dockerfile#L2
• https://github.com/wazuh/wazuh-docker/blob/3.6.1_6.4.2/logstash/Dockerfile#L2

Hello guys,

we are having problems executing the AWS module inside docker. We get the following error:

2018/11/12 23:17:56 wazuh-modulesd:aws-s3: WARNING: Bucket:  -  Unknown error: [Errno 2] No such file or directory: '/proc/sys/net/core/rmem_max'

The specific file is not included in the docker container.

Hello team,

It is necessary to create environment variables to be able to manage the shards and replicas of the Wazuh alert index.

Best regards,

Alfonso Ruiz-Bravo

Hello,

Could you tell me best way to use my own local_rules.xml file in addition to the wazuh rules and parsers?

I tried to mount an external volume with the docker-compose file , with failure each time I try to start all with "docker-compose up"..

Thank you!

Hello team,

We have decided to improve the Kibana settings as follows:

• Add the Wazuh alert index as default.

• Set the Discover time interval to 24 hours instead of 15 minutes.

• Remove the window that asks to report data to Elasticsearch.

Regards,

Alfonso Ruiz-Bravo

Current process involves copying whole folders from older installation into new ones.
For example, the whole /api folder is copied, which results in the Wazuh API crushing.

This process should be seamless.

Hello team,

While testing the Wazuh-Elasticsearch module for Docker we discovered that we got duplicate alerts in Elasticsearch under the following conditions:

Our Docker environment is deployed with volumes enabled for Wazuh and Elasticsearch.

Every time we started the Wazuh container, all the alerts contained in the alerts.json file were inserted back into the Elasticsearch indexes.

For example, we have 10000 alerts in the alerts.json file. The first time the Wazuh container was created the 10000 alerts were inserted correctly and we could visualize them through the Kibana interface.

The second time the container was created, the 10000 alerts were inserted again and we could see through the Kibana interface that we had 20000 alerts and so on.

This is because of Filebeat /var/lib/filebeat/registry file, which is not stored and reads the alerts.json file from the beginning and sends alerts.

There is a volume prepared for Filebeat, but if we don't use it we get this wrong behavior.

The solutions could be to try to store the file in the Wazuh volume or to change the Filebeat configuration so that it does not read from the beginning of the file at the beginning.

Best regards,

Alfonso Ruiz-Bravo

/entrypoint.sh both configures and starts the services, meaning that, in order to run ossec-control actions and have the changes be picked up, there are two hacky solutions I see:

1. Either run those via docker exec and then either restart the container or the services within (neither of which are great for an automated installation), or
2. Volume over a modified copy of wazuh.runit.service and add custom commands before service wazuh-manager start, which means that future changes to that file will not be picked up.

There should be a way to do this explicitly.

Wazuh Version - 3.3.1-1

I'm using the same setup of docker-compose setup but deploying it using kubernetes.
The server is up and running.

When I try to register an agent using the Shell script it gets registered, but there are no events being captured by Wazuh.

One odd thing is that the IP Address - 10.xxx.xxx.1
And also if I register a new agent it fails because the same IP is being assigned in the new agent as well

Hi team, it'd be needed to use environment variables within the Dockerfile, so we can build two different images from the same Dockerfile.

• Research the functionality from the Docker side.
• Test the solution by building different images from the same Dockerfile.

Cheers

Hi,

While upgrading from 3.3.1 to 3.5.0 using docker-compose file, I have faced several issues so I am now wondering what is the correct procedure in order to upgrade a wazuh environment by using this docker-compose file.

In my case I have uncommented the mount for ossec data

    volumes:
      - /mnt/ossec/data:/var/ossec/data:Z

What I did:

1. Remove the wazuh running containers docker-compose down
2. Edit docker-compose.yml to upgrade the versions according to the most recent ones in this repo
3. Start wazuh containers docker-compose up -d

Is this the proper approach? For instance some of the files I had to edit were the rules contained in ruleset, which are in a volume and maintained therefore accross versions. In my case, some of them were referencing frequency="0" as incorrect values.

I had also to create an empty api folder (otherwise wazuh-api wouldn't start), and I am now facing some database issues (missing columns, don't have the details at the moment but can give them if necessary)

I also saw that there is the /wazuh_config special folder that copies part of the relevant configuration as a bootstrap, so maybe I should not put /var/ossec/data under a volume? But then again there is api configuration as well so... again, just trying to figure out the puzzle and what I did the wrong way.

Thanks!

I've been struggling when building the Wazuh Kibana container with the build never returning after running the kibana-plugin install wazuh-app line. I modified the following line (replaced the "." in kibana.kibana with ":") and now the docker build takes ~20 minutes and completes successfully.

line 11: chown -R kibana.kibana /usr/share/kibana &&
changed to: chown -R kibana:kibana /usr/share/kibana &&\

The container cant access /proc/sys/net/core/rmem_max, therefore, fails to correctly process the AWS CloudTrail logs.

Tried to add privileged mode and use sysctls options on the compose, added the dependencies needed by the integration plugin expanding the original Wazuh dockerfile.

Manager/api Dockerfile:
`FROM wazuh/wazuh:3.6.1_6.4.0

RUN apt-get update && apt-get install python-pip && pip install boto3`

Docker compose:
`version: '2.1'

services:
wazuh:
build: wazuh-manager/
hostname: wazuh-manager
restart: always
ports:
- "1514:1514/udp"
- "1515:1515"
- "514:514/udp"
- "55000:55000"
networks:
- docker_elk
volumes:
- /home/appuser/wazuh-data/data:/var/ossec/data:Z
- /home/appuser/wazuh-data/postfix:/etc/postfix:Z
- /home/appuser/wazuh-data/ossec.conf:/wazuh-config-mount/etc/ossec.conf
depends_on:
- logstash
sysctls:
- net.core.rmem_max=212992
privileged: true
logstash:
image: wazuh/wazuh-logstash:3.6.1_6.4.0
hostname: logstash
restart: always
links:
- elasticsearch:elasticsearch
ports:
- "5000:5000"
networks:
- docker_elk
depends_on:
- elasticsearch
environment:
- LS_HEAP_SIZE=2048m
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0
hostname: elasticsearch
restart: always
ports:
- "9200:9200"
environment:
- node.name=node-1
- cluster.name=wazuh
- network.host=0.0.0.0
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms1g -Xmx1g"
ulimits:
memlock:
soft: -1
hard: -1
mem_limit: 2g
volumes:
- /home/appuser/elasticsearch-data:/usr/share/elasticsearch/data:Z
networks:
- docker_elk
kibana:
image: wazuh/wazuh-kibana:3.6.1_6.4.0
hostname: kibana
restart: always
ports:
- "5601:5601"
networks:
- docker_elk
depends_on:
- elasticsearch
links:
- elasticsearch:elasticsearch
- wazuh:wazuh

networks:
docker_elk:
driver: bridge
ipam:
config:
- subnet: 172.25.0.0/24`

Fails with the error:
`Creating appuser_wazuh_1 ... error

ERROR: for appuser_wazuh_1 Cannot start service wazuh: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "open /proc/sys/net/core/rmem_max: no such file or directory"": unknown

ERROR: for wazuh Cannot start service wazuh: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "open /proc/sys/net/core/rmem_max: no such file or directory"": unknown
ERROR: Encountered errors while bringing up the project.`

When running the original container and docker compose got this error
2018/09/24 14:03:42 wazuh-modulesd:aws-s3: INFO: Executing Bucket Analisys: softbox-wazuh-cloudtrail 2018/09/24 14:03:42 wazuh-modulesd:aws-s3: WARNING: Bucket: - Returned exit code 1 2018/09/24 14:03:42 wazuh-modulesd:aws-s3: WARNING: Bucket: - Unknown error: [Errno 2] No such file or directory: '/proc/sys/net/core/rmem_max'

I also added those parameters to the Linux host but can't see it set on the container...

If someone could help me I would be grateful.

Kibana can not install the Wazuh plugin because of mailformed URL

kibana_1         | Attempting to transfer from https://artifacts.elastic.co/downloads/kibana-plugins/https://packages.wazuh.com/wazuhapp/wazuhapp-3.1.0_6.1.2.zip/https://packages.wazuh.com/wazuhapp/wazuhapp-3.1.0_6.1.2.zip-6.1.2.zip
kibana_1         | Plugin installation was unsuccessful due to error "No valid url specified."

The value WAZUH_KIBANA_PLUGIN_URL gets incorrectly parsed and clamped between 2 other urls

hi,
after adding one agents (worked), and set password for accessing kibana, my settings lost after running docker-compose down / up
i did commit the image with the new tag and updated the yml file,
however i only commited the wazuh image, what am i missing ?

Wazuh version: 3.8.0
Elastic version: 6.5.4

• Adapt to new versions (3.8.0 - 6.5.4)
• Update changelog
• Tests
• Tag: v3.8.0
• Draft release

From documentation at https://documentation.wazuh.com/current/docker/wazuh-container.html we're pointed to docker-compose.yml at https://raw.githubusercontent.com/wazuh/wazuh-docker/master/docker-compose.yml.

So docker-compose.yml wants to pull images with tag 3.7.1_6.5.3 (for example wazuh/wazuh:3.7.1_6.5.3)

But there is no image with such tag on Docker hub:

$ docker pull wazuh/wazuh:3.7.1_6.5.3
Error response from daemon: manifest for wazuh/wazuh:3.7.1_6.5.3 not found

Neither it is listed on builds page:
https://hub.docker.com/r/wazuh/wazuh/builds

I assume that latest image should be tagged as 3.7.1_6.5.3 or something like that. Or docker-compose.yml should be fixed. At least I see that latest image contains wazuh version 3.7.1...

$ docker history --no-trunc wazuh/wazuh:latest | grep WAZUH_VERSION
<missing>                                                                 3 hours ago         |2 FILEBEAT_VERSION=6.5.3 WAZUH_VERSION=3.7.1-1 /bin/sh -c sed -i '784s/^/    /' /var/ossec/wodles/aws/aws-s3

Hello!
When use the wazuh manager image built using the Dockerfile, the filebeat.yml has not the correct permissions.

Exiting: error loading config file: config file ("/etc/filebeat/filebeat.yml") can only be writable by the owner but the permissions are "-rw-rw-r--"

Maybe it should be added in the Dockerfile:

RUN chmod go-w /etc/filebeat/filebeat.yml

Configure Wazuh API credentials automatically when building the Wazuh APP/Kibana container.

Hi,

Add the ability to use Kibana behind SSL + basic authentication by using a Nginx reverse proxy.

Regards

hello,

I have edited the logstash.conf file and tried to mount the host folder with error.

[2018-02-14T19:10:59,969][INFO ][logstash.config.source.local.configpathloader] No config files found in path {:path=>"/etc/logstash/conf.d/*"}

My config in docker-compose file for logstash service:

 logstash:
    image: wazuh/wazuh-logstash
    hostname: logstash
    restart: always
    command: -f /etc/logstash/conf.d/
    volumes:
      - ./logstash/config/.:/etc/logstash/conf.d:Z
    links:
     - kibana
     - elasticsearch:elasticsearch
    ports:
      - "5000:5000"
    networks:
        - docker_elk
    depends_on:
      - elasticsearch
    environment:
      - LS_HEAP_SIZE=2048m
      - XPACK_MONITORING_ENABLED=false

My config in logstash/Dockerfile:

FROM docker.elastic.co/logstash/logstash:6.1.3
USER root
COPY ./config/logstash.conf /etc/logstash/conf.d/logstash.conf
RUN chown 1000:1000 /etc/logstash/conf.d
RUN chmod 755 /etc/logstash/conf.d

Could you all tell me what I may be missing?

Thanks!

The current docker-compose.yml file currently has statements which don't match with the latest syntax.

• Not need to use hostname option anymore: docker/compose#2925
• Remove useless comments.
• Update syntax to docker-compose v3.x

Regards

Hi

I am using Wazuh in a docker container, with a docker file based off of https://hub.docker.com/r/wazuh/wazuh/dockerfile. I have added a few things to if apache2-utils and a basic main.cf to get around a few issues. However I am having an issue with the /var/ossec/etc/client.keys file.

Prior to registering a client the file is a symlink to ../data/etc/client.keys

root@wazuh:/# ls -lh /var/ossec/etc/ total 72K -rw-r--r--. 1 root root 6 Jan 24 11:48 authd.pass lrwxrwxrwx. 1 root root 23 Jan 24 11:47 client.keys -> ../data/etc/client.keys

As soon as I register an agent (I am using wazuh-agent-3.8.0-1.msi /q ADDRESS="192.168.56.35" AUTHD_SERVER="192.168.56.35" PASSWORD="wazuh" ) the symlink is "broken" and the file now liike like this

root@wazuh:/# ls -lh /var/ossec/etc/ total 76K -rw-r--r--. 1 root root 6 Jan 24 14:05 authd.pass -rw-rw----. 1 root ossec 78 Jan 24 14:06 client.keys

What this means is the client.keys file is not persisted across redeploy's as the file is not store in the /var/ossec/data folder

Any ideas

Thanks

According to documentation (https://documentation.wazuh.com/2.0/user-manual/manager/output-options/manual-email-report/smtp_authentication.html) there are few extra packages needed to run postfix as local SMTP relay.

Two of them (mailutils and libsasl2-modules) are missing in the latest version of wash container.

Can you please include them in your Dockerfile for future builds?