Our Security Scanner noticed, that the Icinga2 Application is vulnerable on API port 5665 against the Nessus scanner fining “HSTS Missing From HTTPS Server” HSTS Missing From HTTPS Server (RFC 6797) | Tenable®
Affected URL is https://:5665/v1
For the Icinga-Webserver I could fix the finding by addding the following line to icingaweb2.conf:
Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”
But for the API port 5665 I have no WebServer config.
Is there any possibility to fix the HSTS Security Vulerability for Icinga API port 5665?
Hey there!
Thanks for letting us know, we’re looking into it!
We’re comfortable with leaving this public for now, but in case you ever happen upon a security issue that should be fixed before telling others about it, we do have a contact form on our website under Security Issues
calling this a security vulnerability is somewhat exaggerated. HSTS is primarily intended for services accessed from a browser which usually isn’t the case for the Icinga 2 API on port 5665. Also, that port only accepts TLS connections and there is no plaintext counterpart, so when Icinga 2 connects to another node, it will use TLS always and any custom API clients will also have to use HTTPS (as there’s no plaintext alternative).
There is no config option in Icinga 2 to add arbitrary HTTP headers and also nothing special for HSTS at the moment. Apart from that, HSTS affects all Ports on a host name, so if you serve a corresponding header on port 443, this will also affect port 5665.
HSTS is a mechanism to prevent browsers from accessing certain domain names (potentially including subdomains) over plaintext HTTP. Note that there’s no restriction on port numbers, so if its enables for a domain, it affects all ports. So if your web server hosting Icinga Web 2 in https://icinga.example.com/, you will no longer be able to access http://icinga.example.com/ or http://icinga.example.com:5665/ (http, not https) with a browser that has stored the HSTS header from that domain.
Depends on what you mean by securing the API. I don’t see a reason why a HSTS header should have any benefit for the Icinga 2 API served on port 5665, no matter if served on port 443, 5665, or both.
I don’t know their exact wording, but I would expect this kind of finding to be some notice to look into where you might or might not have a chance to improve security, and not a definite security issue.
Also the effect on all ports is why it would be a bad idea for Icinga to set such a header by default just to make some security scanner happy, it might affect other services that might intentionally be using HTTP.
You are right. Thank you for the information.
I see, if I access the Icinga host on port 5665 via Browser per HTTP, I am directly redirected to HTTPS.
So we are secure and I understand, that no further action is required.
We will evaluate the Nessus scanner finding as false positive.
