Nginx reverse proxy with Wazuh (MarketPlace) not working!

Hey guys,

I'm writing this with the hope someone can help me, since I'm feeling stuck by now (after 3 days trying to debug this).

I installed/deployed the Wazuh app from the Marketplace and everything was straight forward (I followed the https://www.linode.com/docs/products/tools/marketplace/guides/wazuh/#getting-started-after-deployment guide).
I was able to add some agents and start to play around with the app.

Then wanted to add some extra security (since the goal will be to run this in a production environment) and I tried to setup Nginx as a reverse proxy and adding a 2nd authentication layer.

In order to do so (I followed the part of the guidance of: https://www.linode.com/docs/guides/visualize-server-security-on-centos-7-with-an-elastic-stack-and-wazuh/).

I start to change the /etc/kibana/kibana.yml from

server.host: 0.0.0.0
server.port: 443

to:

server.host: localhost
server.port: 5601

And I updated the Nginx conf (/etc/nginx/sites-available/x-y-z-w.linodeusercontent.com) with the reverse proxy settings:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443;

    server_name x-y-z-w.ip.linodeusercontent.com;

    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/htpasswd.users;

    ssl_certificate /etc/letsencrypt/live/x-y-z-w.ip.linodeusercontent.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/x-y-z-w.ip.linodeusercontent.com/privkey.pem;

    location / {
        proxy_pass http://x-y-z-w.ip.linodeusercontent.com:5601;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

}

Then I restarted Kibana and Nginx.
(Note: the /etc/nginx/htpasswd.users was already generated)

When I try to access to my wazuh interface - https://x-y-z-w.ip.linodeusercontent.com - I promptly got ask for user and password - from the Nginx setup for 'restrict access' - and after enter the credentials I got a '502 bad gateway'.

From nginx error.log I got:

2022/10/06 13:16:24 [error] 20386#20386: *44 connect() failed (111: Connection refused) while connecting to upstream, client: 123.456.789.123, server: x-y-z-w.ip.linodeusercontent.com, request: "GET / HTTP/1.1", upstream: "http://x.y.z.w:5601/", host: "x-y-z-w.ip.linodeusercontent.com"
2022/10/06 13:16:24 [error] 20386#20386: *44 connect() failed (111: Connection refused) while connecting to upstream, client: 123.456.789.123 server: x-y-z-w.ip.linodeusercontent.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://x.y.z.w:5601/favicon.ico", host: "x-y-z-w.ip.linodeusercontent.com", referrer: "https://x-y-z-w.ip.linodeusercontent.com/"

The operating system shipped with thie image is: Ubuntu 20.04.5 LTS

I've have been trying to play around with some different confs but I always end on the exactly same point (maybe I'm starting to get burn out).

If anyone can help me/point me in the right direction I would be deeply appreciated!

Best regards!
JayS

2 Replies

Full disclosure, I took a peak behind the scenes so that I could troubleshoot with your actual IP address and domain names, but none of your personal information will be revealed below.


As I understand the provisioning process of the Marketplace Wazuh app, a proxy entry and SSL cert are generated when the Linode is deployed. I CURL'd the website associate with your Linode

http://$SUB.DOMAIN.TLD:
---
curl: (60) SSL: no alternative certificate subject name matches target host name '$SUB.DOMAIN.TLD'

HTTP/1.1 301 Moved Permanently
Location: https://$SUB.DOMAIN.TLD/
```

So in part, this is good - it shows that the proxy redirect is working, although the SSL certificate is not properly associated to your current domain name. You had mentioned that you had modified your config file; SSL certificates are normally very specific about naming and pathing. This means that if SSL location or domain naming/Linode hostnames have changed, the SSL cert may not work as it was originally created.

This shouldn't be too big of an issue since CertBot allows you to generate a new SSL cert pretty quickly. I know from experience that it may have issues if you have very recently created a new SSL cert since there is a creation limit within X amount of time.


Alternatively, the 502 error can occur if you are using CloudFlare to manage your domain and you have proxied your DNS A/AAAA record before establishing the SSL cert with CertBot. You would essentially need to temporarily drop the proxy, run CertBot to establish the SSL, and then re-enable the proxy to obfuscate your true IP address. You would also need to make sure that your Domain's SSL/TLS encryption mode is setup as "Full" since the SSL cert is hosted server-side. For more info:

Hi jhartman,

I just wanted to thank you so much for taking your time to check on my question. It was very helpful!

We ended up adopting a slightly different solution. Since this is running on a production environment and only a few on our team have access to it, we decide to limit the access through an IP whitelist.

Thanks once again!

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct