Rethink Security

Cleanup

website security development code

Estimated reading time: 6 minutes


Although it’s just September yet, it feels like the year is almost over with all the stuff there is to do. The CISSP with 90 days left until the exam is almost around the corner and a lot of other private stuff is still in the making.

Cleaning, Clearing, Erasing, Purging, Degaussing and Destruction

The thought for this blogpost originated when I put my old server racks in the car for destruction. Yes, physically shredding those old Fujitsu racks into tiny bits. The only problem here was, that it was not allowed by the service provider to trash storage (HDD, Tapes, USB etc.). I didn’t mind since the service was free, so I just removed all the old drives and just put the racks itself into the trash. During my way back home, I just remembered the protection of security assets which at that time, was the main section I was reading in the CISSP book. Since there are many ways on how to eliminate data remanence, mainly the once from the section title, I also chose to physically destroy them. Since then, I was going full circle an all the old things laying around; Old notebooks (T400+Latitude), USB sticks, and even some CDs (keeping the Zeta handbook and installer CD for nostalgia reasons). Took me some time to sort out what I truly wanted to keep and what not.

old stuff
Signed by RMS - but not usable anymore...

The time I spent to disassemble the notebooks and break all the other media and storage devices was also more than initially thought.

It felt good and bad to remove all those things. Especially trashing the notebooks which I got signed by Richard Stallman1, was a tough decision, but they where broken and not usable anymore :/ In the end, only a handful of stuff remained. Since I destroyed all the hardware, might as well tidy up some things on the software side.

O(n log n)

My old website/blog, onlogn [dot] net, started in 2017 as the successor of bloodrzr [dot] net. Bloodrzr in its early stages was too much of a hassle and too complex in terms of building (v1.0 Drupal, v1.2 .NET, v1.32 Django) because at that time I just wanted to use the latest technologies and trends (Docker, Kubernetes, etc.).So after spending countless of hours just to build a functioning (and secure) framework, I decided to cut every possible feature and just focus on the content itself. O(n log n) was born.

The “about” section of that time should speak for itself:

The original intention of this site was a) to share my code and b) to write some blogposts about IT (security) related topics. I found myself often rebuilding this site with new features and frameworks (+ other stuff) just to provide some spaghetti code and irrelevant information to the world. Since I got really tired of all those things, onlogn.net will just remain a static site, with just a few blogposts every few weeks/months/years. […]

Simplicity made complex

The initial goal, to make the site as simple as possible, worked out somehow. Although the design itself was pretty simple, the setup to produce pages/content was not.

In the early stages, I just wrote plain org files which I converted to HTML pages which then would be secure copied to the desired directory of my webserver. Good integrity was not given, which meant to adjust references and hyperlinks by hand if there were some major changes. Doesn’t that sound like a massive hassle? Yes, it was… but at least I used git from the very beginning.

Since I’m an Emacs enjoyer and the absence of it seems wrong on many different levels, I searched for another solution which integrates into my development environment. Luckily as the saying goes “There is an emacs package for everything”, so I used a nice package called org-static-blog3.

(setq org-static-blog-publish-title "My Static Org Blog")
(setq org-static-blog-publish-url "https://staticblog.org/")
(setq org-static-blog-publish-directory "~/projects/blog/")
(setq org-static-blog-posts-directory "~/projects/blog/posts/")
(setq org-static-blog-drafts-directory "~/projects/blog/drafts/")
(setq org-static-blog-enable-tags t)
(setq org-export-with-toc nil)
(setq org-export-with-section-numbers nil)

(setq org-static-blog-page-header
      "<meta name=\"author\" content=\"John Dow\">
<meta name=\"referrer\" content=\"no-referrer\">
<link href= \"static/style.css\" rel=\"stylesheet\" type=\"text/css\" />
<link rel=\"icon\" href=\"static/favicon.ico\">")

(setq org-static-blog-page-preamble
      "<div class=\"header\">
  <a href=\"https://staticblog.org\">My Static Org Blog</a>
</div>")

(setq org-static-blog-index-front-matter
      "<h1> Welcome to my blog </h1>\n")

The configuration itself is simple and does not bloat up the init.el to unknown extends. I changed my setup a little bit to get some better CI and somehow it worked out to produce content without massive overhead and hassle. If you’re also an org-mode enjoyer, I would definitely recommend this package. The author did a really great job.

Infrastucture can also give you nice headaches

A lot of technical people I know, tend to avoid third-party solutions or services and try to maintain their infrastructure by themselves. This can be a money safer and tinkering around has its own merit but comes at the cost of once time. And at that time, it seems to me I had wasted A LOT of time with just tinkering around. However, as time goes by, peoples priorities change and with those their personal goals.

The infrastructure I built around onlogn was massive. I had a lot of services running on my tiny VPS; From Nextcloud to e-mail to Gitea. Everything finetuned to my “needs” and integration worked seamlessly across all my devices. What gave me massive headaches: maintenance

So again, more time was spent on maintaining the infrastructure than on producing content, which was my original intent. What broke the camel’s back was the straw (aka blogpost) called “BloodHound” which I had planned to release on onlogn, but it just stayed there as a mere announcement.

last post
The last 'content' published

Migration to the current domain

Another migration to a new Domain had to happen. I was just tired of onlogn. The goal itself didn’t change; Something simple to post some content with low maintenance. This time I choose AWS. And it was the correct decision. No more hassle, no more excessive maintenance, no more focusing on infrastructure and other things. Just write stuff, push and publish. And onlogn? Deprecated. The whole infrastructure will go POOF! until the end of November 2022. Finally something gone which was long overdue. But cleaning up legacy stuff is important, otherwise you can’t focus on the things which are truly important.

As a final note - A special thanks to my friends who always give me good advice and critique on the stuff I post. I really appreciate you guys!


  1. https://en.wikipedia.org/wiki/Richard_Stallman ↩︎

  2. Until v1.3 the site was never published to the net, and it was some sort of playground for myself ↩︎

  3. https://github.com/bastibe/org-static-blog ↩︎