Public website or internal only
How Tenvara tells a web server that hosts public websites from an internal box, a welcome page or a web server that serves nothing, and what each badge changes.
Plenty of machines have a web server installed without hosting anything for the internet: a file server with IIS switched on, nginx left on its welcome page, an intranet, or a web server that only fronts a device's management page. Tenvara checks what each web server really serves, and whether anyone on the internet can reach it, and shows the answer as a badge. Only the ones that really host websites count as web hosting, so the rest stay out of your hosting figures and raise no web alerts.
The badges
Every web server in Infrastructure > Web servers has a badge in its Serving column and beside its health on its page:
| Badge | What it means |
|---|---|
| Public website | It serves real content, and the check from the internet gets an answer. |
| Serving (public check pending) | It serves real content; the check from the internet has not run yet. |
| Internal only | It serves real content, but nothing answers from the internet. An intranet, for example. |
| Default page only | Only the stock IIS, nginx or Apache welcome page answers. |
| Installed but not serving | A management page (a sign-in form, a printer's or a router's own pages), errors, or nothing answers. The reason says which, naming a stopped service. |
| Not checked yet | The server's agent has not checked yet. |
Hover a badge for the reason in words. A server that served real content in the last 14 days keeps its badge while it does not answer: that is an outage, and its alerts are what you need.
How a server is checked
On the server
The agent asks every binding on the server itself, with each site's host names, and once with no host name for the default binding on ports 80 and 443. Each answer is judged as real content, the server's own welcome page, a management page, an HTTP error or no answer. A redirect is followed while it stays on the server; one that sends visitors elsewhere counts as serving them.
This runs with the agent's report, again once a day, and at once when a binding or site changes: a site added or removed, a host name changed, or the web service started or stopped.
From the internet
For every host name a server serves real content on, Tenvara checks from outside:
- Public DNS. The name is looked up with public resolvers, not the network's own, so split DNS inside the office does not count. A name that is not in public DNS, or points only at private addresses, is internal.
- The way in. The server's own public address, the site's public address (its internet lines) when what answers there is this site, or a proxy or CDN in front of it.
- The answer. The name is asked over HTTPS on 443, HTTP on 80 and any other port its binding uses, at the public address, and the certificate it presents is matched to the name.
The server is a Public website when any of its names answers. A site that answers with a certificate for another name is still public, marked Certificate mismatch, because it is exposed and its certificate needs fixing.
The outside check runs at least once a day per server, and again at once when the server's names, bindings or public addresses change, or when someone presses Refresh on the server page.
The Serving section
A server's page has a Serving section with:
- why the server has its badge, and when it was checked;
- each binding with its host name (or Any host name for the default binding), scheme and port, what it answered with, the status and the page title;
- for a public name, Behind a proxy when a proxy or CDN answers for it, and Certificate mismatch when the certificate does not cover the name.
A public website gets the offer to watch it: Choose sites to monitor for its site checks, with a reminder that its certificates are checked from Domains and its software from Vulnerabilities.
Telling Tenvara the way in
The outside check finds most routes by itself. Two settings help it:
- The server's public address. Open Settings on the server's page and give its Public IPv4 address and Public IPv6 address when the internet reaches it directly. Saving it runs the check again.
- Proxy address ranges. In Settings > Infrastructure, under Reachable from the internet, the Proxy address ranges are the addresses of proxies and CDNs that sit in front of your sites (Cloudflare's published ranges are filled in). A name that resolves into one of them counts as behind a proxy.
Check web servers from the internet in the same group switches the outside check on or off, for every customer or per customer.
What each badge changes
| Public website, pending or not checked | Internal only, default page or not serving | |
|---|---|---|
| Web alerts (services, disks, sites, certificates, backups) | Yes | No |
| Counted in the Infrastructure overview's web hosting figures | Yes | No, the overview says how many are not hosting |
| Counted as internet facing for vulnerabilities | Yes | No |
| Its names fed to domain and certificate checks | Yes | No |
An adopted server always counts as web hosting, whatever its badge: someone chose to run sites on it. A server you never want to see can be ignored instead; see Web servers.
Finding them
The Views picker on Infrastructure > Web servers has a view for each badge: Public websites, Public check pending, Internal only, Default page only and Not serving. Filter by Serving to combine them with a customer or a web server.
Tip: Run through Default page only and Not serving now and then. They are usually web servers someone switched on and forgot, and switching the service off removes something an attacker could probe.
Related
Was this page helpful?
Thanks for the feedback.