Coder Social home page Coder Social logo

wazuh / wazuh-dashboard Goto Github PK

View Code? Open in Web Editor NEW

This project forked from opensearch-project/opensearch-dashboards

23.0 23.0 49.0 2.26 GB

Wazuh dashboard, the Wazuh UI platform

Home Page: https://wazuh.com

License: Apache License 2.0

Shell 0.40% JavaScript 21.06% TypeScript 76.91% CSS 0.73% HTML 0.01% Handlebars 0.04% Batchfile 0.02% Dockerfile 0.04% EJS 0.05% SCSS 0.73% Makefile 0.02%
analytics apache2 foss search security

wazuh-dashboard's Introduction

Wazuh

Slack Email Documentation Documentation Coverity Twitter YouTube

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

Modules overview

Security events

Overview

Integrity monitoring

Overview

Vulnerability detection

Overview

Regulatory compliance

Overview

Agents overview

Overview

Agent summary

Overview

Orchestration

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

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

Documentation

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.

Authors

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

Based on the OSSEC project started by Daniel Cid.

wazuh-dashboard's People

Contributors

bargs avatar bigfunger avatar bleskes avatar chrisronline avatar cjcenizal avatar cqliu1 avatar epixa avatar flash1293 avatar jbudz avatar jgowdyelastic avatar kobelb avatar lcawl avatar lukasolson avatar mshustov avatar nreese avatar opensearch-trigger-bot[bot] avatar panda01 avatar ppisljar avatar rashidkpc avatar simianhacker avatar sorenlouv avatar spalger avatar stacey-gammon avatar stormpython avatar thomasneirynck avatar timroes avatar tsullivan avatar w33ble avatar walterra avatar ycombinator avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

wazuh-dashboard's Issues

Change compressing format for `tar` archives

Description

We have detected differences in size between RPM and DEB packages. The packages generated by the tools implemented in

are larger than those generated before the fork.

A brief investigation showed up that the tar files use different formats. Pre-fork tools use tar.xz format to generate tarball, while fork tools use tar.gz format. This increase in size is propagated to the RPM and DEB packages, which use the tarball as part of the bundle.

Replace documentation links with Wazuh's

Description

We would like to show the Wazuh's version in the Help menu instead of the version of OpenSearch Dashboards.

Help menu in OpenSearch Dashboards:
image

Help menu in Wazuh Dashboard:
image

The number shown there is the value of the variable opensearchDashboardsVersion, which is equal to version in the package.json file. This won't be a major problem unless it must match the version of the indexer nodes. At least the minor version must match, for example, 2.4.0 in dashboards and 2.4.1 in indexer works, so we cannot simply change this value in the package.json. We'll need to add a new field to this field, for example wazuhVersion, in which we can set the Wazuh version this platform is built for, and read this value in the React component instead of the original opensearchDashboardsVersion variable.

All the related tests must be updated too, and probably we'll need to create new code to read this new value from the package.json and transport it to the required component.

After that, we can define and dynamically generate our documentation links using this value, and use them in the Help menu.

The documentation links are centralized in DocLinksService:

export class DocLinksService {
public setup() {}
public start({ injectedMetadata }: StartDeps): DocLinksStart {
const DOC_LINK_VERSION =
injectedMetadata.getOpenSearchDashboardsBranch() === 'main'
? 'latest'
: injectedMetadata.getOpenSearchDashboardsBranch();
const OPENSEARCH_WEBSITE_URL = 'https://opensearch.org/';
const OPENSEARCH_WEBSITE_DOCS = `${OPENSEARCH_WEBSITE_URL}docs/${DOC_LINK_VERSION}`;
const OPENSEARCH_VERSIONED_DOCS = `${OPENSEARCH_WEBSITE_DOCS}/opensearch/`;
const OPENSEARCH_DASHBOARDS_VERSIONED_DOCS = `${OPENSEARCH_WEBSITE_DOCS}/dashboards/`;
return deepFreeze({
DOC_LINK_VERSION,
OPENSEARCH_WEBSITE_URL,
links: {
opensearch: {
// https://opensearch.org/docs/latest/opensearch/index/
introduction: `${OPENSEARCH_VERSIONED_DOCS}index/`,
installation: {
// https://opensearch.org/docs/latest/opensearch/install/index/
base: `${OPENSEARCH_VERSIONED_DOCS}install/index/`,
// https://opensearch.org/docs/latest/opensearch/install/compatibility/
compatibility: `${OPENSEARCH_VERSIONED_DOCS}install/compatibility/`,
// https://opensearch.org/docs/latest/opensearch/install/docker/
docker: `${OPENSEARCH_VERSIONED_DOCS}install/docker`,
// https://opensearch.org/docs/latest/opensearch/install/docker-security/
dockerSecurity: `${OPENSEARCH_VERSIONED_DOCS}install/docker-security`,
// https://opensearch.org/docs/latest/opensearch/install/helm/
helm: `${OPENSEARCH_VERSIONED_DOCS}install/helm/`,
// https://opensearch.org/docs/latest/opensearch/install/tar/
tar: `${OPENSEARCH_VERSIONED_DOCS}install/tar/`,
// https://opensearch.org/docs/latest/opensearch/install/ansible/
ansible: `${OPENSEARCH_VERSIONED_DOCS}install/ansible/`,
// https://opensearch.org/docs/latest/opensearch/install/important-settings/
settings: `${OPENSEARCH_VERSIONED_DOCS}install/important-settings/`,
// https://opensearch.org/docs/latest/opensearch/install/plugins/
plugins: `${OPENSEARCH_VERSIONED_DOCS}install/plugins/`,
},

Create default config files for Wazuh

Description

We need to create the default configuration files for Wazuh. More precisely, the opensearch_dashboards.yml file.

Also, some of the base changes were applied directly to the source code, and later had to be reverted due to tests not passing. These changes will be applied using the corresponding configuration options.

Changes

  • #17
  • expandedHeader

Change the default app

Due to the menu redesign, the application called wazuh will be removed. We need to change the default application to an existing one.

Tasks

  • Adapt the setting in the default configuration file (opensearch_dashboards.yml)
  • Replace the redirections to the current app/wazuh by the new one. Example: home button.

how to turn off http to https redirect in Wazuh Dashboard?

I have installed wazuh ova in my vm and when i turn off the https in wazuh and then try to access it, it automatically redirects my http://192.168.x.x/ to https://192.168.x.x/.

I did the following changes in the file located at etc/wazuh-dashboard/opensearch_dashboards.yml
server.ssl.enabled
server.ssl.key
server.ssl.certificate

I commented these three lines and the https was turned off, but when I opened the link with http://ip/ it redirected it to https://ip/ and since https was turned off, the dashboard didn't load.

So how can I turn off the redirecting of http to https?

Create `docker-compose` development environment

Description

To develop, we need a development environment. We have need to create a development environment for the Wazuh Dashboard app to run, tests and build the source code of the app and the security plugin.

We'll follow the same approach as in our Wazuh Kibana app environments.

Tasks

  • Create a docker compose environment, following our Docker strategy

Considerations

  • Create the docker folder and add the new files there (scripts, configuration files, ...).

Compatibility with OpenSearch 2.9.0

Description

We need to ensure the UI compatibility with the next version of OpenSearch v2.9.0.
This update is still being discussed, but we need to be aware of potential issues.

For that, we need to:

  • Review opensearch and opensearch-dashboard release notes for this release.
  • Identify improvements and potential impact on the UI.
  • Create new tracking and development branches. https://github.com/wazuh/wazuh-dashboard/tree/4.7.0-2.9.0
  • Develop a testing environment to verify our components would work under this new build.

Issues

  • List here the detected issues

Wazuh Dashboard: PoC - tests

Description

Cypress tests are hosted into a different repository, and the CI workflow is configured to use pull requests' base branch as reference to checkout the tests' repository.

As we do not want to fork the tests' repository for the time being, a possible solution would be to patch the Cypress workflow to checkout the tests's repository at the version we want. given as an input (file, env variable...).

This issue aims to provide a proof of concept.

Build packages using GitHub Actions

Description

The original repository contains several GitHub actions, with different processes that may allow us to build packages. This issue aims to track our investigation and testing process of those actions.

Test distribution packages

Description

In this issue, we'll be testing the packages generated with the tools included in opensearch-project/opensearch-build#71.

The objective is to test the building mechanism and check if we can provide the same operating system compatibility as OpenSearch.

Attach the testing results (evidence) and the reproducibility (Vagrantfile, commands, ...) of the test below.

OS Version
RHEL/CentOS 7/8
Rocky Linux/AlmaLinux 8
Ubuntu 16.04/18.04/20.04
Windows Server 2019

Tests

During the tests, follow the installation instructions from OpenSearch for the given operating system (package type).

  • Test RPM package in RHEL/CentOS 7/8
  • Test RPM package in Rocky Linux/AlmaLinux 8
  • Test DEB package in Ubuntu 16.04/18.04/20.04
  • Test TAR (Windows) package in Windows Server 2019
  • Test TAR (Linux) package in any of the supported operating systems*

*This test can be performed in Docker or locally, while others are preferred in VMs.

Research about the generation of OS packages (rpm, deb)

Description

We need to investigate how to produce production packages in rpm and deb formats.

Currently, we only generate production packages in tar.gz format. See #46.

Additional info

These are the tools used by CI/CD:

Replace README

Description

Update the README with the project information.

Custom branding (II)

We want to be able to customize some parts of the dashboard experience, so our community can tailor the experience for their users.

  • Remove Wazuh wording from the health check page

image

  • Remove duplicated help entries

image

  • Customize icons / text on the left menu

image

  • Customize logo and color in the login screen

image

  • Customize loading page logo

image

We need to this to be configurable in our configuration files and from the user interface / API.
Also, we should explore CSS options enabling the interface to update dynamically.

We must consider the work being done already in opensearch:

https://github.com/opensearch-project/OpenSearch-Dashboards/issues?q=is:issue+is:open+branding

If our solution could benefit all opensearch community, we should open a PR in their repository, and try to incorporate the changes into the upstream.

Compatibility with OpenSearch 2.7.0

Description

We need to ensure the UI compatibility with the next version of OpenSearch v2.7.0.

For that, we need to:

  • Review opensearch and opensearch-dashboard latest stable changelog for this version.
  • Identify improvements and potential impact on the UI.
  • Create new development branch.
  • Develop a testing environment to verify our components work under this new build.

Issues

  • List here the detected issues
  • Fix snapshots:src/core/public/chrome/ui/header/header_help_menu.test.tsx

Global menu

Introduction

This UX redesign tier 1 scope involves mostly a new general menu for the whole interface.

Now that we have control over the complete dashboard, we want to improve the user experience, making it easier to access Wazuh features. Our first step will be to create a new menu experience in line with what the platform is designed to work with: the left navigation drawer.

Our current menu is embedded into our main application in the top bar:

image

We want to incorporate this accesses into the global navigation drawer, transforming the current look (on the left) to something like:

image

Of these, we want to pursue the 1st one, as it allows us to implement the global navigation drawer in a simple and fast pace manner, and allows us to evolve the main plugin with time, iteratively, instead of a big bang devel approach, unlike option 2 and 3.

It is important that we leverage the built-in styles and looks so that our menu can evolve with the new upstream changes which are on their way (for example opensearch-project#4298).

We must customize the icons for each category. The UI library provides a set of icons we could use.

It's also important to study what would happen in the case of newer applications arriving from upstream that use the same categories as we propose here.

Functional requirements

  • Users must be able to navigate to the main page of each module by accessing it using the global navigation drawer.

Non-functional requirements

  • The health-check must not run on every navigation through the navigation drawer. It sould only run when neccesary.
  • Background requests and state sharing must be kept at a minimum.
  • We must use the i18n framework, allowing future translation.
  • We must use the accessibility options built in the platform.
  • We must support dark and light themes.
  • We must support testing with Cypress or other UI testing frameworks (use identifiable selectors, etc.)

Plan

  • #93
  • #94
  • Update the documentation after the new menu

Define the process to bring upstream changes

Description

To keep this repository up-to-date with the original OpenSearch Repository, we need to periodically sync the fork bringing here (fork) the new changes made in the original repository (upstream).

For that, we'll follow the strategy defined in this article. To minimize the conflicts between the repos, we'll use the rebase strategy, replaying our work on top of OpenSearch Dashboards features.

We want to sync the fork once a week at least, so we'll also need to automatize this process. For that, we'll use GitHub Actions, and this action in particular.

[Solved] Cant' login to dashboard behind a reverse Proxy

I setup wazuh behind an apache reverse proxy

apache conf

<VirtualHost *:443>

         ServerName hostname
        <Directory /var/www/html/>
         Options -Indexes +Multiviews +FollowSymlinks
         </Directory>

         SSLEngine on
         SSLCertificateFile /etc/apache2/CERT
         SSLCertificateKeyFile /etc/apache2/KEY
      

         ProxyRequests off
         ProxyPreserveHost On
         ProxyVia full

                 RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R,L]

         RewriteCond %{HTTPS} off
         RewriteRule ^(.*)$ https://%{HTTP_HOST}%/$1 [L,R=301]


         ProxyPass / http://192.168.13.110/
         ProxyPassReverse / http://192.168.13.110/



 Alias /robots.txt /var/www/robots.txt
 <Location "/robots.txt">
    ProxyPass "!"
 </Location>
 </VirtualHost>

opensearch.yml

server.port: 80
opensearch.ssl.verificationMode: certificate
# opensearch.username: kibanaserver
# opensearch.password: kibanaserver
opensearch.requestHeadersAllowlist: ["securitytenant","Authorization"]
opensearch_security.multitenancy.enabled: false
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
server.ssl.enabled: false
server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"
opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]
uiSettings.overrides.defaultRoute: /app/wazuh
opensearch_security.cookie.secure: true
server.host: 192.168.13.110
opensearch.hosts: https://192.168.13.110:9200

I was able to access the dashboard but I could not login with the admin user or the wazuh user

Compatibility with OpenSearch 2.8.0

Description

We need to ensure the UI compatibility with the next version of OpenSearch v2.8.0.
This update is still being discussed, but we need to be aware of potential issues.

For that, we need to:

  • Review opensearch and opensearch-dashboard latest stable changelog.
  • Identify improvements and potential impact on the UI.
  • Create new tracking and development branches.
  • Develop a testing environment to verify our components would work under this new build.

Issues

  • List here the detected issues

Integrate our menu into the platform global navigation drawer

Description

In this issue, we'll track the progress to implement the selected design (see #93) to integrate Wazuh's app menu into the platform's navigation drawer menu.

Design

See selected design in:

Requirements

See requirements in:

Tasks


Wazuh dashboard should use a GIF file as loading screen logo

Description

  const openSearchLogo = /*#__PURE__*/_react.default.createElement("svg", {
    width: "64",
    height: "64",
    viewBox: "0 0 64 64",
    fill: "none",
    xmlns: "http://www.w3.org/2000/svg"
  }, /*#__PURE__*/_react.default.createElement("path", {
    d: "M61.7374 23.5C60.4878 23.5 59.4748 24.513 59.4748 25.7626C59.4748 44.3813 44.3813 59.4748 25.7626 59.4748C24.513 59.4748 23.5 60.4878 23.5 61.7374C23.5 62.987 24.513 64 25.7626 64C46.8805 64 64 46.8805 64 25.7626C64 24.513 62.987 23.5 61.7374 23.5Z",
    fill: "#005EB8"
  }), /*#__PURE__*/_react.default.createElement("path", {
    d: "M48.0814 38C50.2572 34.4505 52.3615 29.7178 51.9475 23.0921C51.0899 9.36725 38.6589 -1.04463 26.9206 0.0837327C22.3253 0.525465 17.6068 4.2712 18.026 10.9805C18.2082 13.8961 19.6352 15.6169 21.9544 16.9399C24.1618 18.1992 26.9978 18.9969 30.2128 19.9011C34.0962 20.9934 38.6009 22.2203 42.063 24.7717C46.2125 27.8295 49.0491 31.3743 48.0814 38Z",
    fill: "#003B5C"
  }), /*#__PURE__*/_react.default.createElement("path", {
    d: "M3.91861 14C1.74276 17.5495 -0.361506 22.2822 0.0524931 28.9079C0.910072 42.6327 13.3411 53.0446 25.0794 51.9163C29.6747 51.4745 34.3932 47.7288 33.974 41.0195C33.7918 38.1039 32.3647 36.3831 30.0456 35.0601C27.8382 33.8008 25.0022 33.0031 21.7872 32.0989C17.9038 31.0066 13.3991 29.7797 9.93694 27.2283C5.78746 24.1704 2.95092 20.6257 3.91861 14Z",
    fill: "#005EB8"
  }));
  • It is necessary to modify it so that said image is not hardcoded in the file itself but is obtained from an external file, in this way it is possible to modify the logo in an easier way from the construction of the package.
  • Also, this new image must not be static, but must be replaced by a dynamic image in which the blue dot is jumping, like the one shown here:

Logo-Wazuh-3

Tasks

  • Modify the template.js file to use an external SVG image.
  • Make the necessary changes to use a GIF file and not an SVG file.
    • Use the GIF file shown in this issue, if not, ask @wazuh/marketing team.
  • Adjust the logo of the loading screen to a smaller size in reference to the title Loading Wazuh.
    • This must be validated by the team.
  • Validate changes.

Validation

  • The template.js file accepts a GIF file external to it.
  • The loading screen shows a moving logo.
  • The size of the logo is adequate with respect to the lower title.
  • The logo is displayed smoothly in both light mode and dark mode.
  • The light mode of the Wazuh dashboard uses a logo on the loading screen with dark letters.
  • If issue wazuh/wazuh-packages#1924 has been completed:
    • The dark mode of the Wazuh dashboard uses a logo on the loading screen with light letters.

Automate the packages generation

Description

We need to have a quick and efficient way to generate production packages when it's necessary.

Currently we can generate production packages manually. See #58

Add ability to manage the Wazuh app using the plugin manager (bin/opensearch-plugins)

Description

There is a very useful utility to install plugins in the app, however, these plugins are exclusively those from OpenSearch. We would like to extend this utility to allow the installation of our plugin.

function generatePluginUrl(version, plugin) {
const platform = process.platform === 'win32' ? 'windows' : process.platform;
const arch = process.arch === 'arm64' ? 'arm64' : 'x64';
return `${LATEST_PLUGIN_BASE_URL}/${version}/latest/${platform}/${arch}/tar/builds/opensearch-dashboards/plugins/${plugin}-${version}.zip`;
}

We'll need to extend the changes performed here:

function generatePluginUrl(version, plugin) {
const platform = process.platform === 'win32' ? 'windows' : process.platform;
const arch = process.arch === 'arm64' ? 'arm64' : 'x64';
// Ignore the installation of the Wazuh plugin as it isn't present in
// the OpenSearch Dashboards repository. Otherwise, proceed as usual.
// TODO replace with actual URL of the Wazuh plugin at current version
// https://packages.wazuh.com/pre-release/ui/dashboard/wazuh-4.4.0-1.zip
return plugin.includes('wazuh')
? plugin
: `${LATEST_PLUGIN_BASE_URL}/${version}/latest/${platform}/${arch}/tar/builds/opensearch-dashboards/plugins/${plugin}-${version}.zip`;
}

The same functionality must be added to remove the plugin.

To implement this, we'll need a stable URL from where to fetch the package of the Wazuh plugin. We can coordinate with the @wazuh/cicd team for this.

Tasks

  • Install Wazuh plugin
  • Remove Wazuh plugin
  • Tests

Skip/fix failing Cypress tests

Description

Related issue: #32

As we do not have a fork repository of [tests repo][tests-repo], we need to skip the Cypress tests that are failing due to our changes, at least until we find a better solution.

Tasks

  • Detect the tests that fail.
  • Detect tests that fail because of our changes. If so, skip them.
  • For the tests that fail for other reason, find a way to solve them.

We expected all the tests from the Cypress tests suite to pass.

Add branches from upstream

Description

We must keep-up with the big developments of OpenSearch Dashboards, taking into account the changes they will introduce even before they do so, to plan and prepare our changes in advance.

We’ll need to track several branches, that will be synced automatically by an action. But prior to that, the branches need to exist in our repository

[BUG] Wazuh dashboard server is not ready yet

Describe the bug

I recently upgraded wazuh following guide Upgrade for OVA https://documentation.wazuh.com/current/upgrade-guide/upgrading-central-components.html#upgrading-wazuh-server

The problem now is that when I try to access via browser it says "Wazuh dashboard server is not ready yet" and hasnt changed for a couple of days.

I have tried restarting services and still nothing.

systemctl restart wazuh-dashboard
systemctl restart wazuh-indexer
systemctl restart wazuh-manager
systemctl restart filebeat

Still nothing.

filebeat test output

[root@wazuh-server /]# filebeat test output
elasticsearch: https://127.0.0.1:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 127.0.0.1
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 7.10.2
[root@wazuh-server /]#

Is there anything that i could've done wrong in the upgrading process or is incompatibility somewhere?

Modify unit tests

Description

There are a few things that prevent the unit and functional tests from passing.

Modify the unit tests or their snapshots so the pull requests from #1 pass the tests.

Replace redirection to `/home` with `/app/wazuh`

Description

We would like to make the Wazuh app the main view of the platform. By default, the home app is shown when the platform is accessed, and all links to home lead to this view.

We can simply replace the redirections in the source code, however, this will leave the platform in an inconsistent state as the Wazuh app is not installed yet, as seen in the image below. For this reason, we'll probably prefer to make this change using the configuration option uiSettings.overrides.defaultRoute: /app/wazuh in the opensearch_dashboards.yml file.

image

Search results for /app/home:

11 results - 7 files

wazuh-dashboard/src/core/public/chrome/chrome_service.tsx:
  251            helpSupportUrl$={helpSupportUrl$.pipe(takeUntil(this.stop$))}
  252:           homeHref={http.basePath.prepend('/app/home')}
  253            isVisible$={this.isVisible$}

wazuh-dashboard/src/core/server/ui_settings/settings/navigation.ts:
  41        }),
  42:       value: '/app/home',
  43        schema: schema.string({

wazuh-dashboard/src/plugins/opensearch_dashboards_react/public/overview_page/overview_page_footer/overview_page_footer.tsx:
  112                  flush="both"
  113:                 href={addBasePath('/app/home#/feature_directory')}
  114                  iconType="apps"

wazuh-dashboard/src/plugins/opensearch_dashboards_react/public/overview_page/overview_page_header/overview_page_header.tsx:
  166                        flush="both"
  167:                       href={addBasePath('/app/home#/tutorial_directory')}
  168                        iconType="indexOpen"

wazuh-dashboard/test/functional/apps/home/_home.ts:
  46        const url = await browser.getCurrentUrl();
  47:       expect(url.includes('/app/home')).to.be(true);
  48      });

  54        const url = await browser.getCurrentUrl();
  55:       expect(url.includes('/app/home')).to.be(true);
  56      });

wazuh-dashboard/test/functional/apps/visualize/_custom_branding.ts:
  139            const url = await browser.getCurrentUrl();
  140:           expect(url.includes('/app/home')).to.be(true);
  141          });

  147            const url = await browser.getCurrentUrl();
  148:           expect(url.includes('/app/home')).to.be(true);
  149          });

  204            const url = await browser.getCurrentUrl();
  205:           expect(url.includes('/app/home')).to.be(true);
  206          });

  212            const url = await browser.getCurrentUrl();
  213:           expect(url.includes('/app/home')).to.be(true);
  214          });

wazuh-dashboard/test/new_visualize_flow/config.ts:
  90        home: {
  91:         pathname: '/app/home',
  92          hash: '/',

Search results for navigateToApp('home'):

18 results - 9 files

wazuh-dashboard/src/core/public/chrome/ui/header/header_logo.tsx:
  94    } else {
  95:     navigateToApp('home');
  96      event.preventDefault();

wazuh-dashboard/src/core/public/chrome/ui/header/home_loader.tsx:
  98    } else {
  99:     navigateToApp('home');
  100      event.preventDefault();

wazuh-dashboard/src/plugins/data/public/index_patterns/index_patterns/redirect_no_index_pattern.tsx:
  72    if (redirectTarget === '/home') {
  73:     navigateToApp('home');
  74    } else {

wazuh-dashboard/src/plugins/dev_tools/public/application.tsx:
  124    if (!application.capabilities.dev_tools.show) {
  125:     application.navigateToApp('home');
  126      return true;

wazuh-dashboard/src/plugins/saved_objects_management/public/management_section/mount_section.tsx:
  75      if (!allowed) {
  76:       coreStart.application.navigateToApp('home');
  77        return null;

wazuh-dashboard/test/accessibility/apps/home.ts:
  38      before(async () => {
  39:       await PageObjects.common.navigateToApp('home');
  40      });

wazuh-dashboard/test/functional/apps/home/_navigation.ts:
  49        // Navigate to home app
  50:       await PageObjects.common.navigateToApp('home');
  51        const homeUrl = await browser.getCurrentUrl();

wazuh-dashboard/test/functional/apps/visualize/_custom_branding.ts:
   34        before(async function () {
   35:         await PageObjects.common.navigateToApp('home');
   36          await PageObjects.common.navigateToApp('opensearch_dashboards_overview');

   68          await opensearchArchiver.unload('visualize');
   69:         await PageObjects.common.navigateToApp('home');
   70        });

  104          await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:darkMode');
  105:         await PageObjects.common.navigateToApp('home');
  106          await testSubjects.existOrFail('welcomeCustomLogo');

  118        before(async function () {
  119:         await PageObjects.common.navigateToApp('home');
  120        });

  122        after(async function () {
  123:         await PageObjects.common.navigateToApp('home');
  124        });

  183            await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:darkMode');
  184:           await PageObjects.common.navigateToApp('home');
  185          });

wazuh-dashboard/test/security_functional/insecure_cluster_warning.ts:
  41      before(async () => {
  42:       await pageObjects.common.navigateToApp('home');
  43        await browser.setLocalStorageItem('insecureClusterWarningVisibility', '');

  62          );
  63:         await pageObjects.common.navigateToApp('home');
  64          await testSubjects.missingOrFail('insecureClusterDefaultAlertText');

  69        before(async () => {
  70:         await pageObjects.common.navigateToApp('home');
  71          await browser.setLocalStorageItem('insecureClusterWarningVisibility', '');

  79        it('should warn about an insecure cluster, and hide when dismissed', async () => {
  80:         await pageObjects.common.navigateToApp('home');
  81          await testSubjects.existOrFail('insecureClusterDefaultAlertText');

  92          );
  93:         await pageObjects.common.navigateToApp('home');
  94          await testSubjects.missingOrFail('insecureClusterDefaultAlertText');

Wazuh Dashboard Ingress - 401 unauthorised

Describe the bug
Hey Team,

We've installed Wazuh on a Kubernetes cluster and have attached a domain for it. Wazuh was working without any issues.

We then introduced ingress and our idea was to have path based routing for Wazuh under a common domain.

We also changed the dashboard values like below and after implementing when we hit the server with /wazuh path, we are getting 401 un-authorised error.

Below are the logs,

{
    "type": "response",
    "@timestamp": "2023-03-02T14:40:47Z",
    "tags": [],
    "pid": 40,
    "method": "get",
    "statusCode": 401,
    "req": {
        "url": "/wazuh/app/wazuh/app/wazuh",
        "method": "get",
        "headers": {
            "host": "devops.justcall.dev",
            "sec-ch-ua": "\"Not_A Brand\";v=\"99\", \"Brave\";v=\"109\", \"Chromium\";v=\"109\"",
            "sec-ch-ua-mobile": "?0",
            "sec-ch-ua-platform": "\"macOS\"",
            "upgrade-insecure-requests": "1",
            "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36",
            "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8",
            "sec-gpc": "1",
            "accept-language": "en-GB,en;q=0.5",
            "sec-fetch-site": "none",
            "sec-fetch-mode": "navigate",
            "sec-fetch-user": "?1",
            "sec-fetch-dest": "document",
            "accept-encoding": "gzip, deflate, br",
            "x-cloud-trace-context": "ed365d0a4d5357728a1ee65f9bc91aa2/688693293495436800",
            "via": "1.1 google",
            "x-forwarded-for": "34.170.144.15, 34.120.67.126,35.191.17.219",
            "x-forwarded-proto": "http",
            "x-envoy-external-address": "35.191.17.219",
            "x-request-id": "029a7d75-56e8-46c0-b78f-5d1e4a54f479",
            "x-envoy-decorator-operation": "dashboard.wazuh.svc.cluster.local:80/wazuh*",
            "x-envoy-peer-metadata": "",
            "x-envoy-peer-metadata-id": "router~10.68.9.10~istio-ingressgateway-5d4f4fcfb7-mzcdc.istio-ingress~istio-ingress.svc.cluster.local",
            "x-envoy-attempt-count": "1",
            "x-envoy-original-path": "/wazuh/app/wazuh",
            "x-b3-traceid": "780c9c1ded01d42f4dcd8ec7c88ba47d",
            "x-b3-spanid": "4dcd8ec7c88ba47d",
            "x-b3-sampled": "0"
        },
        "remoteAddress": "10.68.9.10",
        "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
    },
    "res": {
        "statusCode": 401,
        "responseTime": 2,
        "contentLength": 9
    },
    "message": "GET /wazuh/app/wazuh 401 2ms - 9.0B"
}

Below is the dashboard values yaml.

opensearch_dashboards.yml: |2-

    server.host: 0.0.0.0
    server.port: 5601
    opensearch.hosts: https://indexer:9200
    opensearch.ssl.verificationMode: none
    opensearch.requestHeadersWhitelist: [ authorization,securitytenant ]
    opensearch_security.multitenancy.enabled: false
    opensearch_security.readonly_mode.roles: ["kibana_read_only"]
    server.ssl.enabled: false
    server.ssl.key: "/usr/share/wazuh-dashboard/config/certs/key.pem"
    server.ssl.certificate: "/usr/share/wazuh-dashboard/config/certs/cert.pem"
    opensearch.ssl.certificateAuthorities: ["/usr/share/wazuh-dashboard/config/certs/root-ca.pem"]
    uiSettings.overrides.defaultRoute: /wazuh/app/wazuh

Change CSS styles and images

Description

The objective of this issue is to introduce Wazuh changes to the repository. These changes are mainly aesthetic, in terms of CSS styles, replacement of images with Wazuh's and so on.

Propose and evaluate different designs

Description

The first step of #83 is to generate and evaluate different designs to integrate our modules into the platform menu.

Tasks

  • Generate at least 3 designs and comment its pros and cons
  • Propose one of them as candidate.

Loading bar present using custom branding

Description

Using a custom loading logo enables the loading bar in the UI, which is not present using the default branding. I think this is a great feature and should be enabled in the default mode too.
I'm aware that an animated loading logo was included in #77, so this feature request might be simply ignored. I'm only creating the issue, so you are aware of this.

opensearchDashboards.branding:
  loadingLogo:
    defaultUrl: "https://logowik.com/content/uploads/images/f1-formula-18381.jpg"

image

Create new plugin wazuh-check-updates

Part of Epic
#84

Description

We need to develop a new plugin responsible for querying an external service to retrieve information about the latest available updates along with their corresponding features. This dedicated plugin will then be utilized by the primary Wazuh plugin, enabling it to notify users whenever new updates become accessible.
The plugin will also have a component to notify the user when there is a new updates, a component to view the deployment status, a component to view the details and a component to allow the user to change their notification preferences. This component will be used by the main plugin.
What we are looking for with the new plugin is to have the functionality referred to the notification of new updates modularized.

Tasks

  • [Backend] Expose an endpoint to query the new updates and their details. The endpoint should consult an external service about new updates and their details. Initially the response from the external service will be mocked
  • [Backend] Expose an endpoint to query user preferences.
  • [Backend] Expose an endpoint to update user preferences.
  • [Backend] Manage saved objects to save settings and user configurations.
  • [Backend] Run a cron job to periodically check for available updates.
  • [Frontend] Expose a component to notify the user of new updates so that it can be consumed by other plugins.
    • It must have a dismiss button to dismiss all further notifications about the presented version.
    • It must have an option to reject all future notifications of new updates.
    • It must contain a dynamic link so that the user can go to a page and see the details of the update.
  • [Frontend] Expose a component to show the deployment status and a button to check available updates.
  • [Frontend] Expose a component to show the details of the current available update.
  • [Frontend] Expose a component to allow the user to change their notification preferences.
  • [Frontend] It must use i18n.
  • Unit tests for each development

Notification mockup

image

  • New update message: A text that indicates that there is a new release available. E.g.: ¡Wazuh 4.8.0 is available!
  • Link to release notes: When the user clicks the link, it should open a new tab with the release notes official page.
  • Dismiss future updates check: An option check to give the user the possibility to avoid seeing these types of notifications in the future. E.g.: I don't want to know about future releases. If the option is checked, when the user closes the notification throw the button the configuration will be saved.
  • Close button: A button to close the notification. When the user clicks on it, it must be saved so that the notification of this release no longer appears for the user.

Deployment status mockup

image

  • Deployment status: Shows if is up to date or if there are available updates.
  • Tooltip: Shows when the last time new updates were checked.
  • Check updates button: A button to check available updates.

Current update mockup

image

  • New update message: A text that indicates that there is a new release available. E.g.: ¡Wazuh 4.8.0 is available!
  • Link to release notes: When the user clicks the link, it should open a new tab with the release notes official page.
  • Link to upgrade guide: When the user clicks the link, it should open a new tab with the upgrade guide official page.
  • Show detail accordion: A section where user can expand and view the update description.

User preference mockup

image

  • Dismiss future updates check: An option check to give the user the possibility to avoid seeing these types of notifications.

Amazon Linux 2003 E2E Dashboard testing Log error in 4.6.0-Alpha-1

Describe the bug

Doing Dashboard testing in E2E Testing in 4.6.0-alpha1

A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Install in EC2 Amazon Linux 2023 T3.Large Wazuh indexer, manager and dashboard.
  2. Connect from EC2 Amazon Linux 2023 Agent
  3. Check in the dashboard Managment/Logs and the following error will be visible

10 agent logs details
In Settings/Api configuration
It is possible to check:
image

Additional context

E2E Dashboard testing: wazuh/wazuh#18828

Integrate wazuh-check-updates plugin

Part of Epic
#84

Description

Integrate the main plugin with the wazuh-check-updates plugin developed in issue #87.
This integration will allow us to consume from the backend and frontend of the main plugin the methods and components exposed respectively by the wazuh-check-updates plugin.

Backend integration

  • Method to return an array of the available updates

Frontend integration

  • Component to notify the user when there is a new update

Dark mode

Is your feature request related to a problem? Please describe.

I would really like it if the Wazuh Dashboard had a dark mode, as dark modes are very nice :p

Describe the solution you'd like

I would just like the option to enable a dark mode inside of the dashboard config.

Disable the addition of sample data

Description

There is a feature in OpenSearch Dashboards which allows the users and adds sample data in order to create a playground on which to create visualizations and explore the features of the platform.

In the future, we'll probably use this feature to add Wazuh's sample data, replacing this same functionality from the plugin, but until then, we need to disable this feature to avoid confusing the users.

There are several places in the app from which this feature can be accessed, so we'll need to study the best approach to disable this feature globally, being the least intrusive as possible in terms of code changes.

Context

Here's the view:

image

Route: app/home#/tutorial_directory

Places from which this view is reference and/or can be accessed:

  1. Home
    image
  2. Feature directory (link View app directory in Home)
    image
  3. Index pattern (on empty state --> no index patterns)

Additional context: search results for tutorial_directory

17 results - 12 files

wazuh-dashboard/src/plugins/home/public/plugin.ts:
  143        showOnHomePage: true,
  144:       path: `${HOME_APP_BASE_PATH}#/tutorial_directory`,
  145        category: 'data' as FeatureCatalogueCategory.DATA,

wazuh-dashboard/src/plugins/home/public/application/components/welcome.tsx:
  81    private redirecToAddData() {
  82:     const path = this.services.addBasePath('#/tutorial_directory');
  83      window.location.href = path;

wazuh-dashboard/src/plugins/index_pattern_management/public/components/index_pattern_table/empty_state/empty_state.tsx:
  157                  className="inpEmptyState__card"
  158:                 onClick={() => navigateToApp('home', { path: '#/tutorial_directory' })}
  159                  icon={<EuiIcon size="xl" type="database" color="subdued" />}

  177                  className="inpEmptyState__card"
  178:                 onClick={() => navigateToApp('home', { path: '#/tutorial_directory/sampleData' })}
  179                  icon={<EuiIcon size="xl" type="heatmap" color="subdued" />}

wazuh-dashboard/src/plugins/opensearch_dashboards_react/public/overview_page/overview_page_header/overview_page_header.tsx:
  166                        flush="both"
  167:                       href={addBasePath('/app/home#/tutorial_directory')}
  168                        iconType="indexOpen"

wazuh-dashboard/test/accessibility/apps/dashboard_panel.ts:
  40      before(async () => {
  41:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  42          useActualUrl: true,

wazuh-dashboard/test/accessibility/apps/dashboard.ts:
  44      before(async () => {
  45:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  46          useActualUrl: true,

wazuh-dashboard/test/accessibility/apps/filter_panel.ts:
  41      before(async () => {
  42:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  43          useActualUrl: true,

wazuh-dashboard/test/accessibility/apps/home.ts:
  46      it('Add OpenSearch Dashboards sample data page', async () => {
  47:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  48          useActualUrl: true,

wazuh-dashboard/test/accessibility/apps/opensearch_dashboards_overview.ts:
  45      after(async () => {
  46:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  47          useActualUrl: true,

  57      it('Overview view', async () => {
  58:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  59          useActualUrl: true,

wazuh-dashboard/test/functional/apps/home/_add_data.ts:
  39      it('directory should not display registered tutorials', async () => {
  40:       await PageObjects.common.navigateToUrl('home', 'tutorial_directory', { useActualUrl: true });
  41        await PageObjects.header.waitUntilLoadingHasFinished();

wazuh-dashboard/test/functional/apps/home/_sample_data.ts:
   50        ]);
   51:       await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
   52          useActualUrl: true,

  101        beforeEach(async () => {
  102:         await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  103            useActualUrl: true,

  166        beforeEach(async () => {
  167:         await PageObjects.common.navigateToUrl('home', '/tutorial_directory/sampleData', {
  168            useActualUrl: true,

wazuh-dashboard/test/functional/page_objects/common_page.ts:
  135       * @param appName As defined in the apps config, e.g. 'home'
  136:      * @param subUrl The route after the hash (#), e.g. '/tutorial_directory/sampleData'
  137       * @param args additional arguments

  173       * @param appName As defined in the apps config, e.g. 'home'
  174:      * @param subUrl The route after the appUrl, e.g. '/tutorial_directory/sampleData'
  175       * @param args additional arguments

Tasks

In particular, we'll need to:

  • Hide the component Add sample data, present in several views
    image
  • Adjust the parent views as necessary.
  • Disable some or all of the links listed above.

Update check service UI

Introduction

We want to inform our users a new version of Wazuh is available from the wazuh-dashboard UI.

  • A user must be able to dismiss a notification, so it won't appear again
  • A user must be able to disable the check for updates, so no check is made at all from the global configuration section
  • A user must be able to see with details about new version, clicking in the notification or navigating to the About menu

The Wazuh API will implement the necessary endpoints for the dashboard to get the relevant information.

Design

We can implement the notification logic by:

  • checking for updates on each log-in
  • checking for updates at a given period (from dashboard to the API)
  • checking for updates by clicking a button in the About page

We might implement them all at some point, but we need to evaluate the impact on the user workflow to ensure the feature is usable and don't get in the way.

We can design this feature as a new plugin for wazuh-dashboards, and render its contents inside the main plugin under the About page.

Plan

UX redesign (I)

Description

We want to redesign our application, to integrate it better with the rest of the platform's tools.

In this first phase, we want to make Wazuh UI sections more accessible by using the global left menu to access each part of the application.

Also, we want to update our dashboards to resemble our latest work in the integrations, introducing a new look & feel, and new queries.

Implementation restrictions

  • We must use built-in platform styles and look and feel, so we can adapt to the coming changes of the platform.
  • All new functionality must come with comprehensive suite of tests

Plan

Wazuh Dashboard first steps

Wazuh dashboard

This repository forks the OpenSearch Dashboards repository to introduce changes that will ease its usage by Wazuh users and integrate itself with the Wazuh development process.

We want to accommodate our UX changes within the upstream code, minimizing conflicts. We want to contribute bug fixes and any component not tied to Wazuh upstream.

Also, we need to check all standard (vanilla) plugins are compatible with our builds, or we will need to build the infrastructure to build them ourselves too.

To do

Our release branch will be based on OpenSearch Dashboards 2.4.1 and upwards.

Notify user when a new update is available

Part of Epic
#84

Description

We need to notify the user when a new Wazuh update is available. To do this, the "wazuh-check-updates" plugin exposes a notification component to be consumed by the main plugin. If new updates are available, the component provided by the plugin will be displayed to the user. The user has the option to close the notification and can also specify if they do not want to receive further notifications about new updates.

Tasks

  • Consume the notification component exposed by wazuh-check-updates in issue #87 and integrated in issue #88

Integrate wazuh-check-updates plugin and update the About page

Part of Epic
#84

Description

Integrate the wazuh-check-updates plugin developed in issue #87 with the main plugin.
This integration will allow us to consume the components exposed by the wazuh-check-updates plugin.
The "About" page should show whether the current version is up to date or not. If it is not up to date, it should show the latest available version and should give the user the ability to see the details in the release notes for each release.

Tasks

  • Integrate wazuh-check-updates plugin
  • Replace the Angular template for a React component
  • Consume the UpToDateStatus component from wazuh-check-updates plugin
  • Consume the CurrentUpdateDetails component from wazuh-check-updates plugin
  • Consume the DismissNotificationCheck component from wazuh-check-updates plugin
  • Unit tests

Page mockup

Up to date

image

New release available

image

`opensearch.hosts` values cannot be IP address when using TLS

Describe the bug

When we configure in opensearch_dashboards.yml the setting opensearch.hosts and the URL starts with https, the server complains that you cannot use it because:

Sep 04 19:37:01 debian10 opensearch-dashboards[30752]: Terminating process...
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at processTicksAndRejections (node:internal/process/task_queues:78:11)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at wrapper (/usr/share/wazuh-dashboard/node_modules/lodash/lodash.js:5255:19)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at Object.utils.applyArgs (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/utils.js:188:19)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at sendReqWithConnection (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/transport.js:263:35)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at HttpConnector.request (/usr/share/wazuh-dashboard/node_modules/elasticsearch/src/lib/connectors/http.js:182:23)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at Object.request (node:https:357:10)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at new ClientRequest (node:_http_client:335:16)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at HttpsAgent.addRequest (/usr/share/wazuh-dashboard/node_modules/agentkeepalive/lib/_http_agent.js:239:10)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at HttpsAgent.createSocket (/usr/share/wazuh-dashboard/node_modules/agentkeepalive/lib/agent.js:77:11)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at HttpsAgent.createSocket (/usr/share/wazuh-dashboard/node_modules/agentkeepalive/lib/_http_agent.js:265:26)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at HttpsAgent.createConnection (node:https:147:22)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]:     at Object.connect (node:_tls_wrap:1678:15)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]: DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]: Node.js process-warning detected:
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]: (Use `node --trace-deprecation ...` to show where the warning was created)
Sep 04 19:37:01 debian10 opensearch-dashboards[30752]: (node:30752) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version

This deprecation happened in multiple Node.js versions:

This last version is the one used by OpenSearch 2.8.0 and 2.9.0, and will impact how users configure their deployments.

As the error message states, setting the TLS ServerName to an IP address is not permitted by RFC 6066

Tasks

We want to investigate a workaround to minimize the impact of an update from wazuh-indexer 4.5.x to wazuh-indexer 4.6.0 by enabling this deprecated functionality until next releases.

Customize URL route

The default URL route for the dashboard is /app/wazuh. Add a feature for customizing it.
eg. http://127.0.0.1/app/wazuh#/overview to 127.0.0.1/app/<custom_name>#/overview

Accommodate tests to pass

Description

Due to the changes applied, some tests no longer pass.

We need to modify the tests to adapt them to our changes.

Tasks

Hide `overview` app and its links

Description

We have been asked to hide the overview app.

Initially, this change was applied in #15, but this change as enough context to be treated as an independent work unit, hence this issue.

Port the changes from #22 to a new pull request.

Generate production packages with Wazuh changes and config files

Description

We need to generate production packages of the app with our changes and default configuration in it.

These packages will contain our security and wazuh plugins, and also some plugins from OpenSearch Dashboards.

The list of plugins is the following:

alertingDashboards
customImportMapDashboards
ganttChartDashboards
indexManagementDashboards
notificationsDashboards
reportsDashboards
securityDashboards
wazuh

Tasks

  • Build Wazuh dashboards 4.3 prototype production package, based on OSD 2.4.1.
  • Build Wazuh dashboards 4.4 prototype production package, based on OSD 2.6.0.
  • Build Wazuh dashboards 4.5 prototype production package, based on OSD 2.6.0.

Fix desing implementation

Part of Epic
#84

Description

Implement the following changes to improve the solution.

Tasks

  • [Frontend Main Plugin] In the About page delete the API table and leave a React component the same as previous Angular template.
  • [Frontend Check Updates Plugin] Delete unused components related with About page.
  • [Frontend Check Updates Plugin] In the UpdatesNotification component only ask for available updates if user doesn't check "Disable update notifications".
  • [Frontend Main Plugin] In API Table handle check updates button errors and show toast.
  • [Frontend Main Plugin] In API Table show tooltip with the error message when status is "error".
  • [Frontend Main Plugin] Unit tests for new Flyout with updates details.
  • [Docker] Update WZ_HOME in README file.

Import issue templates

Description

Import issue templates from wazuh-kibana-app.

  • Release: to track the effort and steps need for a new release of Wazuh.
  • Compatibility request: to track the effort required to bump our fork to a newer version of OpenSearch.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.