Change of webserver identification strings

I would like to ask for a possibility to easily change the Indigo (web)server strings used/send outwards in any HTTP identification.
I just tried a search for 'Indigo' at the website Shodan and found my instance listed there. Although I have a good password and changed the username it's quite unlikely someone can log in the normal way to my IndigoServer but if someday there is a known exploit or zero day attack it would be very easy to find all the users (including me) and abuse the system.

Therefore I would like to change these strings into something else so that it is at least not so easy to find my IndigoServer with a simple query. My installation is currently found there and displayed with these informations:
Www-Authenticate: Digest realm="Indigo Control Server", nonce="..deleted...", algorithm="MD5", qop="auth" Server: IndigoWebServer/5.0

Of cause I can change these settings myself in the indigoutil.py file but a nice settings option in the GUI would be great as this could survive updates of Indigo and would be easier for most users.
Or is there already an easy way to change these settings I haven't found yet?

[jay (support)]

Just for clarification: you have port forwarding set up on your home router and that's how the server is getting identified by Shodan?

Sure. My Indigo should be accessible from the outside as I use this for remote control. There is nothing wrong with Indigo.

Up till now there was never anyone abusing my IndigoServer. I've logged several (>1000) attempts to guess a password in the last 2 years but never any problem or insecurity. So with a strong password anything is fine.
This was just an idea to make the Indigo installation even more secure by sending random (whatever the user like) information in these headers to make identification of a server/version much more difficult. So if someday in the future there is a known bug your server can't be found with a simple query. This will give you 1-2 days time until your installation is found in the net to apply a patch in such a case.

[jay (support)]

You do realize that by poking holes in your router and allowing direct HTTP connections to your Indigo Server that your authentication credentials are being sent in the clear (HTTP Digest authentication is somewhat more secure than Basic but is still somewhat vulnerable)? For many, it's an acceptable risk, but it sounds as if you are somewhat concerned about security. This is why we created the Indigo Reflector Service - to allow more secure remote access (through HTTPS and secure tunnels) to their Indigo install without opening up holes in your router firewall and enabling potential exploits.

Security through obscurity is rarely an effective security improvement technique...

Therefore I would like to change these strings into something else so that it is at least not so easy to find my IndigoServer with a simple query. My installation is currently found there and displayed with these informations:
Www-Authenticate: Digest realm="Indigo Control Server", nonce="..deleted...", algorithm="MD5", qop="auth" Server: IndigoWebServer/5.0

A web server must respond with valid headers and information for it to function effectively -- the WWW-Authenticate header looks like the standard header that clients are going to require in order to properly authenticate (or at least clients that properly follow the standard, some may attempt different authentication methods if presented with missing information).

The Server header is not required, that is true, but really doesn't do anything for security. The automated security scanners always want to flag that as a low priority "defect" or "vulnerability", but the reality is that 99% of hack attempts are scripts that will attempt an exploit against ALL web servers, they very rarely or never will customize their payload based on a Server header.

Jay alluded to this but you are picking the wrong battle there -- using an SSL connection would increase your security 1000x more than eliminating the headers! SSL isn't foolproof either, of course, but at least offers a real, solid, proven increase in security. If you don't want to use the Prism Reflector service for some reason, search the forums for "Apache Reverse Proxy" on how you can still use an open port (without the Reflector service) and implement SSL. The reflector is far easier, though...

Adam

For my setup, I went with using a reverse proxy via Apache.

Beyond the ability to add SSL support, one of the cool "features" for my use case is that I added additional authentication logic -- for instance, no authentication is required when accessing the Indigo web server if you're on my Wifi & accessing from any of a few IP addresses (i.e. my laptop, cell phone, iPad -- each of which have MAC address based, router-assigned static IPs on my network).

You can also further add additional & more advanced authentication logic (multiple users, per-user restrictions by URL, etc. all become possible) customize headers, and plenty of other cool custom stuff like that. It's also pretty easy to setup...