Icinga Web 2 publicly visible (on internet)


I have really simple question: is there anything against putting Icinga Web 2 (only GUI access for authenticated users) on the internet? I am not sure if this was ever considered, and how good the GUI is hardened against HTTP attacks.
Of course I should put some reverse proxy in front of it, but do you have any other ideas, how could I harden it? I don’t want to make IP white listing, VPN is also not an option for me.

I would like to give access to my Icinga Web 2 to some folks outside my organization (only authenticated), that’s it. If this is not a good idea at all, please let me know.


Only with tcp/443 and TLS certificates. In terms of security, the developers took measurements to prevent such attacks. @nilmerg certainly can tell you more about it.

Firewalls and things like webserver log scanning and blocking should be your Swiss army knife too.

As Michael already said, only ever over encrypted connections. Icinga Web 2 is pretty much susceptible to any form of attack (like any other network service) and an encrypted connection mitigates/prevents most issues.

If you only want to allow access for authenticated users, there’s only the login and error-page which is accessible for anonymous clients. The login is (as any other form in Icinga Web 2) secured against CSRF attacks. The error-page may show stacktraces (including local paths on your server) so you should make sure it’s disabled.

You also need to know/remember that Icinga Web 2 does nothing against automated access, such as bots or repeated requests. If I know your url I can easily run e.g. a brute-force attack with my mighty dictionary. :sweat_smile:

That’s what

are for. :sunglasses:

1 Like


so the “public” Icinga Web 2 is only for customers?
My consideration would be a separate Icinga Web 2 instance. Without commandtransport backend, Director and so on. Maybe only with Grafana Module without Links and direct access to the Grafana instance.
For the users, I would create a strict role / group concept. This is really only limited to reading needed things.

On the network side, dnsmichi is right, I would only take a reverse proxy too or I would place the “public” instance in the dmz and only allow the IDO database connection from the “public” instance to the “private” instance.

I would allow the command transport, and specific features based on roles and permissions, even if external. This comes in handy if you’re using Icinga Web 2 on a mobile and want to acknowledge a problem.

One thing you should always have - enforce a strong password policy for all your AD users. Nothing prevents exploitation with weak passwords where attackers just try combinations, and most recently, entire leaked password databases.

That being said, such attempts are visible in the webserver’s log and can be filtered and banned. AFAIK fail2ban can do that too.

And since I had such a question last week about our Discourse instance - responsible care with updates, don’t leave the instance on a specific version too long. There are no known exploits for Icinga Web 2, but still, once there is, a released fix should get your attention immediately from the release changelog.

In my consideration it was for customers only so “read-only”. So when you have to interact with icinga2 like ack or something like this you’re right.

1 Like

Hi Guys,

Many thanks for your replies. To summarize all ideas, when VPN or IP white-listing is not an option, here are the steps to be considered to protect Icinga2 Web:

  1. Force to use SSL

  2. Use reverse proxy

  3. Disable showing stack trace

  4. Create Read Only access users (group) and restrict access only to specific areas

  5. Configure fail2ban to check logs from web server

  6. Update the server as frequent as you can

  7. Ideally (not in my case unfortunately since I have only one server): move Icinga web2 to separate server.

Please update this list when something comes to your mind.



Maybe to harden its setup and don’t allow alterations, you might automate it with Puppet, Ansible, etc. if you have that in place.

  1. Configure fail2ban to check logs from web server

I can’t find Icinga Web 2 login failures anywhere in logs.
fail2ban would be really great. But it is not doable I believe.

Hi Majkeee,

Could you be able to make this work (i mean public icingaweb with grafana)?
Actually I need to do something similar to give external access to my icingaweb. What i have done is https via firewall/loadbalancer, external partners could login to see icinga checks but could not see grafana graphs. When I used inspect, it looks like, it is trying to connect from Internet directly to my grafana server. What i expect is my icingaweb server will connect to grafana server and display the graph instead of user having direct access to grafana server from Internet to retrieve graph.

Just want to ask if you could make this work with grafana graphs in a better way.