Project Name: openvas
Type of quota increase requested: floating ip
Amount to increase: 1 floating IP
Reason: Need to access GUI
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T356830 Floating IP request for project Openvas | |||
| Resolved | fnegri | T354192 Request creation of OpenVAS VPS project |
Event Timeline
Comment Actions
@KHurd-WMF if you can make OpenVAS listen to requests on port 80 (which seems it should be doing by default), setting up the web proxy to forward requests to it should be straightforward. What issues did you encounter?
I just want to make sure there is no easy way to set up the web proxy before allocating a floating IP, as they are a finite resource.
Comment Actions
The listening port should not matter at all, only that the protocol is HTTP and the project has opened that port on that instance via security groups. See https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_VPS_servers_from_the_internet for the basic help information. I would be happy to help answer specific questions if the documentation is not providing enough information yet.
Comment Actions
Per the diagram on https://hackertarget.com/openvas-tutorial-tips/ it looks like the web gui for OpenVAS runs on port 9392 by default. That port is active on openvasv1.openvas.eqiad1.wikimedia.cloud:
# netstat -lnp | grep 9392 tcp 0 0 127.0.0.1:9392 0.0.0.0:* LISTEN 24606/gsad # curl localhost:9392 <!doctype html><html><head><link rel="icon" href="/img/favicon.png" type="image/png"/><title>Greenbone Security Assistant</title><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><script type="text/javascript" src="/config.js"></script><script defer="defer" src="/static/js/main.d0502c33.js"></script><link href="/static/css/main.d6631c26.css" rel="stylesheet"></head><body><div id="app"></div><div id="portals"></div></body></html>
Port 9392 is open in your security group, so creating a web proxy with a backend port of 9392 should serve to expose it to the world.
Comment Actions
Ah ha! I see the problem in the netstat output I pasted in T356830#9526185. The gsad process that listens on port 9392 is currently bound to the 127.0.0.1 (localhost) interface. It would need to be bound to a public interface, or typically easier all interfaces (0.0.0.0) to be able to be contacted from outside the instance.
oot@openvasv1:~# ps ax | grep gsad 24606 ? SLsl 0:00 /usr/local/sbin/gsad --foreground --listen=127.0.0.1 --port=9392 --http-only 750539 pts/1 S+ 0:00 grep gsad
Possible fixes:
- Add an nginx or apache2 reverse proxy on the openvasv1.openvas.eqiad1.wikimedia.cloud instance to proxy from a public port and address to 127.0.0.1:9392 and then point the Horizon managed proxy to the ip:port of that reverse proxy.
- Configure gsad to bind to 0.0.0.0. The gsad process is managed by /etc/systemd/system/gsad.service where --listen=127.0.0.1 has been hard coded by the package maintainer. This may indicate that exposing gsad to the world is not seen as a best practice by the package maintainer(s).
- You could choose to manually edit /etc/systemd/system/gsad.service, which would likely be overridden again when you next upgrade the gsad package.
- Alternately you could create a local override for the service by doing sudo systemctl edit gsad to create a /etc/systemd/system/gsad.service/override.conf file that will persist across package upgrades.
- Don't worry about the public proxy at all and instead access the web GUI via an ssh tunnel to openvasv1.openvas.eqiad1.wikimedia.cloud. This could look something like:
- ssh -o ExitOnForwardFailure=yes -f -N -L 9392:127.0.0.1:9392 openvasv1.openvas.eqiad1.wikimedia.cloud
- Visit http://127.0.0.1:9392 with your browser of choice
Comment Actions
- Don't worry about the public proxy at all and instead access the web GUI via an ssh tunnel to openvasv1.openvas.eqiad1.wikimedia.cloud. This could look something like:
- ssh -o ExitOnForwardFailure=yes -f -N -L 9392:127.0.0.1:9392 openvasv1.openvas.eqiad1.wikimedia.cloud
- Visit http://127.0.0.1:9392 with your browser of choice
Thank you!
Comment Actions
Closing as invalid on the assumption that the ssh tunnel solution will work for now and that one of the other options from T356830#9526737 can be implemented when and if tunneling becomes undesirable.