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!