TECHNICAL

This version of the post will be a deep dive into the tech stack. I’ll do my best to explain the reasoning I had for various choices, and go into detail on some of the difficulties I came across getting it to work.

The Idea

Cybersecurity blogs have, at least in my mind, taken off recently. More and more I see Medium as a suggested result when looking things up. These results are, almost always, awful. Poorly written and containing a lot of false information, I decided very early on that I did not want to use Medium as my platform when I eventually got around to setting this blog up.

So, instead, I took it upon myself to host the blog on AWS instead. I chose AWS as I’m most familiar with it, having created a website before. Hosting a site on AWS is not as simple as I’m making it sound. Below you can see a not-so-great drawing of the AWS services I’m using.

S3 or Amplify

AWS offers two different options for creating a website hosted on their platform. S3 (essentially a plain storage space in the cloud that you can allow access to), and Amplify (a fancier method of hosting more complicated sites).

One of the most important things I wanted to do when starting with this project was to keep it simple. A common concept in Cybersecurity is that risk scales with attack surface, meaning that the more complicated you make something, the more risky it is.

So, with that in mind I opted for a static website with a simple tech stack. Rather than code an entire blog framework by hand, I chose to use a static-site generator. You can read a more detailed explanation here, but the gist of it is that a static-site-generator will generate a complete static html based website using templates and raw data (in this case markdown).

More on the static website in a moment. After deciding on the static site, it became clear that I should host the site on AWS S3.

Setting up the S3 Buckets

S3 is fairly simple on the surface, you create what Amazon refers to as “buckets”, these buckets can act much like a shared network directory you might have at work, except of course it’s hosted in the cloud. It becomes complicated when you open it up to the public Internet, something that is required to host a basic site on AWS.

Before getting into the security issues the above statement presents, I set up multiple buckets. Two for my root and subdomain, and one to store logs forwarded by another service I’ll mention shortly called CloudFront.

Now, hosting a cybersecurity blog and allowing public access to the website code (even if it is static), didn’t appeal to me. On top of that, I wanted to have my own domain name rather than using a link to the bucket (something like http://websitename.com.s3-website-us-east-1.amazonaws.com). Security-minded folks might have also noticed that the link is in plain old http, another concern I had with this method.

You are able to get around the above issues by tacking on two other AWS services: Route 53 and CloudFront.

Route 53

AWS Route 53 is Amazon’s domain registration and DNS service. It allows you to search for, purchase, and configure a domain. In addition, you can set up DNS records that will propagate around the world in seconds, allowing you to associate the long AWS links like the one above, with the shorter domain name that you purchase.

I purchased the domain name for $14/year, and configured DNS records for both my root and subdomains to route to my CloudFront configuration. Below is a screenshot of my Route 53 setup:

CloudFront

CloudFront is something known as a CDN (Content Delivery Network). Essentially, CDN’s host a copy of your website at various locations around the globe. Somebody in Europe will be able to access a cached copy of the site on a European server, significantly reducing latency, and providing a barrier between the user and the website itself.

I configured CloudFront to do just that, while also enforcing that users view the website using HTTPS, automatically upgrading anybody that attempted to view it in plain HTTP.

With the infrastructure set up, I was able to move on to actually setting up the site.

Astro

Astro is a static-site generator, it uses templates and simple raw data (e.g. Markdown) to` creates a simple HTML based website out of it. As somebody that doesn’t specialize in web development, this is a godsend for me. I’m able to make minor tweaks to the templates to improve and change the format of the site, but the majority of the work is already done for me.

As it’s basic HTML without any extra bloat caused by a novice webdev, it’s very secure on top of it being fairly easy to use and maintain.

Details

Each post and page on this site will use a template created using a .astro format as shown below:

Each of these astro files is made up of two main parts, a Component Script located at the top and surrounded on top and bottom by three dashes (---), and a Component Template located below the dashes.

The Component Script is composed entirely of javascript and is used via expressions and HTML down in the template. The readme documents for Astro do a much better job explaining this:

In Atro’s words, “The code fence (---) is designed to guarantee that the JavaScript you write in it is “fenced in”. It won’t escape into your frontend application, or fall into your user’s hands.” That’s really cool! You can write sensitive code here and the user will never be aware of it or be able to see it.

The template can then access the functions and variables you set up in the component script, allowing Astro to generate websites for you really easily.

You can do a ton more with Astro, but like I’ve said I am not an experienced web dev. To be honest I have no desire to pursue web development and so will only be making minimal changes to these templates.

Template Changes

Speaking of minimal changes, to fit with my theme of creating three different posts for each topic, I really wanted buttons that I could use to swap between the different post types. I did this using one of these templates! You can see the code I setup for the button below:

By including this in the template, I won’t have to write it out in every post. Instead I just have to make a simple HTML div block in the markdown file with an id of either “technical”, “fun”, or “simple” and have the block load in with the hidden attribute. As soon as one of the three buttons at the top are clicked, the hidden attribute is toggled allowing the reader to view the article they want to see.

This is probably a very simple task for most web dev focused people, but I was quite proud of getting it working properly with the templates.

Github

Once I was satisfied with the site, I uploaded it to Github. You can find the code for it here.

And now for one of my favorite parts, auto-updating and propagating the site via Github Actions! With Github, as long as your project is public, you can set up Actions that will allow you to do various things with your code.

In this case, I wanted the astro project to build the site, and upload ONLY the HTML to my AWS S3 bucket whenever I pushed a new commit. This takes away me having to manually move all of my files up to S3.

On top of this, the build process can automatically prompt CloudFront to delete the old cached versions of the site and pull new ones!

You can check out the Action YML file here. As you can see, it’s surprisingly simple. It’ll open up an Ubuntu VM, download all of the npm packages it needs, compile the website, push it to the S3 bucket using some special creds I set up for it, and then force CloudFront to pull the new site!

The End

I’m not really sure how to end this post, I had fun getting this setup and learned a ton. It was good to get a refresher on AWS and I enjoyed learning the surface level content of Astro. I’m really happy to have this done and running and I have a ton of cool projects I hope to post about in the future!

PLEASE reach out to me via the email link if you have any comments, corrections, or anything! I’ll happily fix anything I have wrong, my goal is to teach not misinform. Until next time!

New Blog Who Dis

In a lot of job applications I’ve been going through for the past…oh four years now or so, there’s usually a little field where you can put a personal website.

Well that’s a lot of work, who would do that? Me I guess!

I’ll be using this blog to post some of my personal projects, maybe some info about things I’m learning or testing that kinda thing.

Who Cares, How’d You Do It?

Well that was rude, but also thanks for asking.

I’ve messed around with self-hosting websites on AWS before, and thought it would demonstrate my abilities a little if I did again with this blog thing. I’ve seen other cyber people use Medium but was a little put off with the vibe of that whole thing so thought I’d just try this out.

AWS Route 53

So, I registered the domain name via AWS Route 53 which is also responsible for making sure DNS records are updated. I was a little concerned about whois lookups exposing some personal info, but AWS offers a privacy option which obfuscates all that.

Cost-wise it’s not too bad, $14 a year and it does what I needed.

Whoops

I got the domain name, kinda neglected to make the website. That’s where Astro comes in! I’ve built sites by hand in the past, barebones html/css/javascript/php without any sort of templates or anything, and saying I didn’t want to do that again was an understatement.

I’m definitely not a web dev type of guy, there’s a level of artistic ability involved that I’m just completely lacking. The thought of “how can I make this look like it wasn’t made by a color-blind geriatric monkey” went through my head a lot while researching.

TODO: Insert horrifying AI generated image of a geriatric color-blind monkey.

TODO: Figure out how to add comments in markdown.

It turns out that there’s been some developments in webdev since the late 80s, who could’ve guessed?

Knowing that I wanted something simple (for security and sanity’s sake), and something that looked nice (for the reader’s sake), I settled on using a static-site generator framework.

Static-Site What?

The long-standing idea that everything cool gets ruined by popularity is true 100-fold for the Internet.

I’ve got a background in cybersecurity, and an important concept to understand is how risk scales with attack surface. Having an overly bloated hand-jammed website filled with a bunch of features means vulnerabilities, and vulnerabilities mean your precious Bored Ape NFT collection is now public domain.

Static-site generators hide all of that bloated mess behind the scenes, allowing you to create and generate a simple html website using templates and markdown.

Astro is neat, you can do some cool stuff. I borrowed this template cause I thought it was also neat. A few hours later and I’ve got a basic site…on my computer. Can you all check out my site at localhost:4321?

Git Ye Gone and Cloud Woes

Cool so to recap:

• Domain Name
• Site
• Literally Everything Else

Well, I started with getting Github set up which was easy enough. The project can be found here. I did this for reasons I’ll explain later!

Now, setting up a static webpage is fairly easy, if you aren’t worried about security. It’s as simple as creating an AWS S3 bucket, tossing your site up there, and allowing public access!

The concern there is that this would list the site in plain ol’ HTTP, and seeing as this is supposed to be showing how proficient I am, I figured that would be a bad idea.

The solution to this is to use a combination of AWS CloudFront, Route53 DNS Alias records, and roughly 6 hours of troubleshooting. That last part is key.

CloudFront is what’s known as a CDN or Content Delivery Network. It essentially hosts cached versions of content on servers across the world, allowing for faster access to the resources instead of them having to wait for data to travel all the way to them.

Side note, you can tell I spent 6 hours troubleshooting cause my writing is getting lazy and bad!

CloudFront also happens to be able to take HTTP requests, and force them to be HTTPS requests AND it can stop you from having to make your S3 buckets publicly available, a couple extra nice security features that I really wanted to get setup.

The problem here starts when you follow three different guides provided by AWS, each one adding an additional layer of security in ways that completely invalidate the last guide you followed: 1, 2, 3.

On top of that, I swear that the AWS documentation was wrong in one spot, but I’m far too over it to try to figure out where. Anyways, I found the age-old single tiny thing that was causing problems and I was finally able to set up the website with HTTPS over the Internet! There’s a lot more boring detail in there, but who wants to read about all that.

Git Ye Gone Again?

Ok, so now the reason I pushed the site up to Github instead of just moving it to AWS by hand (aside from that being an insane thing to do). Github has “Actions” that allow you to automate some processes when a user-specified event occurs.

In this case, I setup an action that would deploy the Astro project, generate the HTML, and then deploy it out to my AWS S3 bucket! This means that any time I publich a new post, it will automatically get pushed out to the website which is, say it with me, pretty neat!

So that’s the end of my first post! I have a few projects I want to do that I’ll do some writeups for, hopefully that wasn’t too dull of a read. I’m gonna commit this change and push it up, fingers crossed it actually updates!

Simplified Explanation

Hey there! In this version of the post you can read a simplified version of the above two posts. Simple isn’t meant to be an insult, my mantra is that you can’t know what you don’t know and there’s no shame in that! I find that a lot of technical people have a very hard time communicating complicated ideas in ways that non-technical coworkers or managers can understand and find this to be great practice!

So let’s get started.

What is a blog and why are you doing this?

A blog, at least to me, is a place where you can post your thoughts online for others to see. There are many cybersecurity blogs out there, ran by smart people doing cool things. What you don’t see too often is people taking the time to explain what’s going on to non-technical individuals.

I actually had this idea after sending a draft version of this to my Dad! He’s been a hard-working police officer his whole life, and he understandably isn’t very technical. Of course, when I sent him the post, his response was “Ok. I did not understand much of what you said but it is cool.” A very Dad response to give but it got me thinking.

I feel, that one of the major problems in the cybersecurity industry, is the elitism involved. Most employees just try to do their jobs to the best of their abilities. Cyber folks come in and tend to make their jobs harder! Things like two-factor authentication, phishing email campaigns, and mandatory security training suck! I think one of the problems is that cyber people fail to truly communicate properly with other employees.

So, that’s a very long-winded explanation on why I’m doing this. Let’s get into some details!

What, why. Ok let’s get to the how!

When you navigate to a website online, you are actually connecting to resources that are located physically on a computer somewhere in the world. Typically, it is much more secure and cost-efficient to have a company share those resources for you when building your own website.

There are many different ways to host websites online, some significantly easier than others (companies like Squarespace, Wix, and GoDaddy all offer such services). I chose to go with a more complicated route to help me learn about some different technologies.

You’ve likely heard of the cloud. It’s a very ethereal word that isn’t properly explained. And really, the word cloud is a bad one. The cloud is not a magical floating space where you can upload data, it’s clusters of thousands of servers with huge amounts of computing resources located somewhere physically in the world. Companies own these servers, and allow you to host your business applications on them.

There are a number of these cloud service providers including Amazon, Microsoft, and Google. I have used Amazon’s cloud service, AWS, before and wanted to continue learning how to use it so I chose to host my site on AWS.

I could get more detailed on that explanation, but that would be escaping the purpose of this section! To sum it up, AWS provides hundreds of services that allow you to replicate business networks in the “cloud”. You are able to combine these services to let you do things like purchase a website name, store your website code, and provide your website to people all over the globe!

Hopefully that explains it in an easy to understand format, please feel free to reach out to me via email if you have any questions or comments!