Securing Internal Applications

I recently made some changes to my intranet applications. Today, I talk about my adventures on securing these applications by authenticating users to see if they are authorized.

Cyber-security has become a hot topic in the last few years. Networks that we once thought were private are now becoming targets. Taking my personal network as an example, I have some internal applications I host on my Linux machine, such as a URL shortener (among others), whose configurations are unguarded on my intranet. If someone were to gain access to my network via a compromised device, then they would also be able to access those same applications without authentication. I have since secured these application, but thought it would be nice to touch upon some approaches I took to get there.

On externally facing sites, I employed the use of Cloudflare Access to secure my web applications. With Cloudflare sitting between a user and my application, any user trying to access a protected application is presented with an authentication challenge to prove their identity. If they successfully authenticate with an identity provider and are authorized, then they will be granted access to the protected application. This is what I did with my URL shortener. One of the things I liked is that the authentication flow is handled by Cloudflare, so my origin server doesn’t see traffic until the user has been authenticated and authorized.

On internally facing sites, this becomes a bit trickier because there are a few things at play. First, Cloudflare no longer sits between the user and the application. This is because DNS is handled internally for Active Directory, and will point directly at the internal server instead of towards Cloudflare. This was done intentionally to avoid having unnecessary traffic egressing the internal network and then subsequently ingressing back the same link because the user and server are in the same network. As such, Cloudflare Access cannot be used. Second, HTTPS needs to be configured internally in order to securely exchange session cookies. Previously, with Cloudflare as the external authoritative DNS, HTTPS between Cloudflare and the origin server was not a strict requirement since cloudflared resides on the same internal Docker network as the origin server. Fortunately, as part of my earlier infrastructure changes, I had already configured Let’s Encrypt certificates with certbot for things like my blog, so additional SSL certificates came pretty much “for free”.

With that out of the way, I still needed something to authenticate a user. Luckily, there exists an open-source apache2 module called mod_auth_openidc. It authenticates the user against an OpenID-compliant server, and if they’re authorized (defined by me), then they are granted access to the application. For my intents and purposes, I use Google as the authentication server, and allow only users that have an email address ending in domain (which is basically just myself) to access these applications.

The authentication screen on Google when visiting a protected application.

One thought that occurred after finding mod_auth_openidc was to use it on both external and internal facing sites. This is something worth considering in the future should I ever decide to move off of Cloudflare, but having the auth infrastructure managed by a third party is a nice convenience and saves my origin server from having to deal with these requests directly.

Anyways, that’s all I wanted to talk about today. Improving my security standpoint is a continual effort on identifying weaknesses and addressing them, all while threat actors continue to evolve, so it’s important to stay up-to-date with the latest trends.

Until next time!


Just some guy on the Internet that writes code for fun and for a living, and also collects anime figures.

Articles: 265

Feel free to leave a reply