Iterations of this Site

In 2018 I applied for a position at Google, to start the day long series of interviews I got asked one simple question:

How would you create a secure web page?

I responded at first about securing the host, implementing SELinux, putting SSH on a high port with a certificate, sticking it behind a WAF. I had started to go into detail about the CI/CD pipeline when I was interrupted by the interviewer asking if I had heard of things such as HSTS and HKPI. I confessed that I hadn’t, and knew there must have been a whole world of things that I simply hadn’t had exposure to, so I took a mental note to go away, build myself a website and to try and experiment.

1st Generation

#

Initially I came up with a vague plan. A new venture desreves a new platform, and while I had experience with AWS and Azure in the past, I decided I’d try GCP as it was just launching their cloud platform in Australia. It’d be a simple static HTML page, running under Apache on a CentOS 7 host.

It was an interesting experience. The first hurdle to overcome was connecting to the VM I had created, GCP by default sensibly implies that repetitive/iterative development will be a better pathway. The platform doesn’t allow you to SSH to a host by default, instead heavily suggesting that you use some deployment system to configure and deploy the host without any interactive action.

As this was just a single host, I just wanted to establish it first and then examine the possibility of automation later on. This meant for me to connect I needed to implement the correct metadata tags on the host, so that I could remotely connect and configure it. I set up SSH on a high port with a certificate, installed Apache and then used SCP to copy across the files.

Leaving SELinux enabled in active more, I had to ensure the proper contexts were applied to the high port SSH, as well as the Apache directories with HTML.

The website itself was a simple single static HTML page. I had a quick blurb about myself, and links off to social media pages like LinkedIn and Github. I wanted to keep it small and simple, with a focus on some of the security elements around the page itself. I had included jQuery (a popular javascript library at the time), so that I could include an easter egg: entering in the konami code would trigger a blue screen of death.

This idea of easter eggs I’d later expand on with different elements I had been starting to learn.

While I didn’t necessarily have ideas for articles, I had written templates so that if I wanted to write it’d be simple to include (although I never did end up writing anything).

Then thanks to certbot, I served up a simple static HTML page with an SSL cert, a good baseline that would be expanded as I learned more.

2nd Generation

#

The next phase was one of refinement and improvements. Utilities like Mozilla Observatory helped make me aware of some of the possibilities, and after googling some of the acronyms that had made their way into the interview, I began reading quite a bit.

Implementations:

• HTTP Strict Transport Security (HSTS): Helps protect against man-in-the-middle attacks, such as downgrating protocol or hijacking cookies.
• Cross-Origin resource Sharing (CORS): Restricts the style sheets, and javascript on my webpage to just the domain and domains I approve (to prevent injection of iframes, videos, style sheets and more).
• Subresource Integrity (SRI): Included a hash of the resource, to ensure again that it hadn’t been tampered with.
• Response Headers: Including X-Content-Type-Options, X-Frame-Options and X-XSS-Protection helped to prevent content sniffing, iframe rendering and the like.

At the time I had looked at HTTP Public Key Pinning (KPKP) as well, which pinned the public key hash of a certificate to the website to resist impersonation and fradulent use of digital certificates. Due to it being a dynamic VM hosted in a cloud environment I had opted against it, as it’d be easy for issues to arise and take down the site. Now days, it’s been replaced entirely with Certificate Transparency, a public log of created certificates for quickly identifying malicious or deceptive certificates.

Sites like securityheaders.com helped to review and make further refinements. Allowing me to see other recommendations.

At this time I had rebuilt the system, upgrading to CentOS 8 in the process and transitioning from Apache to Nginx to make configuration a great deal easier. When controversy arose around CentOS I transitioned to Red Hat Enterprise Linux (RHEL) 8.

It was also at this time that I had started to review the Cryptographic Algorithms, ensuring things like ECDHE_RSA_WITH_256_GCM_SHA384 were preferred and removing old potentially vulnerable algorithms. I switched from Apache to Nginx which made configuring the host a great deal more easier, and installed a newer version of TLS on the host so I could get TLS 1.3 and move away from TLS 1.1.

As I learned more I added more easter eggs, including custom headers, custom responses based on user agent types and more.

I had also started to encounter a few issues during this time. The most interesting one was the SELinux database crashing and reverting to default. This meant that my website couldn’t load because the nginx contests that tell SELinux it’s HTML and approved to run from that location were removed. It got worse still, with the same happening to the SSH port I had allowed on a high port, meaning I couldn’t SSH to the host to resolve the issue.

This lead to a great deal of remote debugging through cloud startup scripts, and an interesting insight into an opportunity to hack the host.

3rd Generation

#

I’d classify the current version as the third generation. Before this the content of the pages themselves had been relatively simple - it was a single page, most of the changes I had made had been of a technical nature. I had written some brief proof of concept articles, and had presented at a conference in the past. I even had started to write the draft of a book. The reality was as I was reaching a decade in the cyber security industry I was looking at opportunities to contribute back, to present and share knowledge and mentor.

The problem with the 2nd generation was that it was difficult to make iterative changes and add new pages. I had manually written the HTML, which meant manually changing the homepage to add in new articles as they were written. A quick and simple solution that a lot of people turned to was using static page generators like Jekyll, stored in GitHub and then using Cloudflare pages and their own domain for hosting. This meant people could quickly turn ideas into articles that could be shared, without having to worry about the infrastructure behind it.

For me though, that would mean the loss of the customisations and easter eggs I had incorporated into the site. The site itself had also been a great endeavour that let me experiment and learn more, and so I sought out a compromise.

I devised a new solution, one using Hugo as the static site generator, pushing that to a private Github Project, then using that to trigger GCP’s Cloud Build to build a simple Alpine docker container with Nginx, that would be pushed into the Container Registry and then using GCP Cloud Run to run it behind a GCP hosted Load Balancer. A more detailed explaination can be found in Cloud Run Website with GCP

While the process is more complex, the automation behind the scenes makes it easier to make iterative improvements. Pushing a new article is as simple as writing markdown to a github repo.

Next Generation

#

How this site will grow, and what it’ll expand into I’m can only speculate, but it’s provided a great avenue for learning. So wherever it goes I’m sure I’ll learn a lot, and look forward to sharing the journey further.

Summary

#