Reverse Proxy

Introduction

The Reverse Proxy will be a Virtual Machines based on Nginx as it is a fairly light install and will be easily capable of forwarding all traffic to the Webservers in the Home Lab.

Redirecting Unknowns

It should have a default website that forwards anything that is unknown to the main website. Another redirect should be set up for anything that appears as an IP address because it should be possible to get the IP address, maybe, even though most of the DNS entries at Cloudflare are proxied. I think that there should be a redirect in place for the MySQL Server and the SFTP server although it is unlikely to be a problem.

Update The above has been changed and refined so that we do not expose MySQL to the internet and we do not any longer redirect default webserver requests to the main website see the notes below on the default server block.

SSL Certs

There are three types of SSL cert that we may use for our webservers. Self Signed, Cloudflare origin (maybe not an actual type but mor on them later) and public SSL certs, in this case Letsencrypt SSL certs, as they are free to use. both Cloudflare and self signed certs can have a very long duration but generally public certs life cycle is short, maybe a week for high security sites or 60 days for most others.

Letsencrypt SSL Certs

The main advantage of the Letsencrypt SSL Certs is that they are instantly recognised and trusted by virtually every devices that accesses the Internet. The downside is that they are usually only valid for a very short period so will need to be renewed frequently. To do the renewal there are bots that will download it within the required period so not too much of a problem once it is setup, we are using Certbot. Like most certs they can be either for a single domain name or be for a wildcard domain that is all subdomains of a single high level domain name eg *.seaoffate.net, the main stipulation of Letsencrypt wildcard certs is that it will only allow one level deep eg wiki.seaoffate.net is fine as it is only one dot but best.wiki.seaoffate.net would not be acceptable as it is two levels deep from the top (two dots). Incidentally, Cloudflare origin certs also only allow one ply deep. For setup details of the certificate and the bot see here.

Self Signed SSL Certs

we can setup Self Signed SSL Certs but they are of limited value now as Letsencrypt and Cloudflare origin Certs are so easy to acquire now and at zero cost. The good thing about them though is that they can be a stop gap solution that requires minimal time. further details can be found here

Default Webserver Configuration

There is no wildcard server on Cloudflare so anyrandomdomain.seaoffate.net will not get a response from Cloudflare. Also Pfsense will only accept and forward connections to 443 if the source address is one belonging to Cloudflare and this in itself should block 99.99 percent of bots from recognising the public facing IP address as hosting webservers. However, it should still be possible for a hostile actor to use their own Cloudflare domain to attempt a connection to webservices on the Home lab and as it comes from Cloudflare Pfsense would forward to Raisin, Raisin would then refuse the connection because there would be no matching SNI, the very action of refusing the SSL handshake would confirm the existence of services at the IP address. It would be better if any connection attempt to non existent SNI was quietly dropped without being refused.

Catchall Server Block

WE have set a server block that listens to server_name_ which in effect will catch anything that does not have an explicit match. Now to make sure that any SNI is refused we can have a directive to send 444.

return 444

However, the refusal would indeed confirm the existence of an active SSL at the IP address and that the domain does not exist there. So above that 444 response we need a directive that will quietly drop the connection without sending any SSL refused. The directive that will do just that is the ssl reject handshake so we switch that on with

ssl_reject_handshake on;

So now any unknown SNI passed from Cloudflare will be forwarded through the edge router(as it is 443) to Pfsense to Raisin(as it has a Cloudflare source) but it will not match the seaoffate.net SNI it will fall through to the default server name block and in turn will meet the reject ssl directive and therefore be dropped before the hello packet has been completed. Any direct connection attempt to our public facing IP address should be dropped by Pfsense as it does not come from Cloudflare but even if it does somehow get through to Raisin it should either be served by an actual named web service or meet the same default server block and be the SSL attempt would be dropped. It should be noted that the SSL reject handshake directive does not reply to the SSL handshake request at all, it will quietly drop the Hello packet immediately rather than sending a refused response and the handshake request will time out.