Multi-part series on securing our internet presence: Taking Inventory & Responsibility

“Security is not the icing, it’s an ingredient.” – Ted Nass

A multi-part series by John Ball, Phillip Kuzma, and Ted Nass on web server security.

About 48 hours ago me and two of my friends decided that we were going to embark on a security race to harden at least a dozen domains that we manage in an effort to be a better contributor to the internet.

This first post will cover the technologies used while subsequent posts will take a deeper dive into the technology, reasoning behind its usage, and the ease at which it was implemented. Subsequent posts under tag “multi-part-security-series” will cover individual technologies and our usage. Look for future posts on this series daily around 0800 Eastern US time.

Let’s get started.

  1. We started with server test to get a baseline of our internet-facing servers prior to layering on any additional security services or making security changes on the back-end. If you aren’t familiar with Qualys SSL Labs, they summarize their service with this statement:
    “This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet.”
    SSL Labs gave us a fairly in-depth look at where we stood with our internet-facing servers and the communication protocols they are using.
  2. Next we turned to takes a different viewpoint and scratches the surface on DNS security, email security, and what they refer to as “WWW” security (looking at encrypted protocols, application security, and others). They summarize their service this statement:
      “Hardenize is developed by a small team who are passionate about improving the security of the Internet. Adapting the William Gibson quote, we believe that the future of security is already here, but it’s not evenly distributed yet. We made it our mission to help organizations and individuals gain visibility into the security of systems they care about.”
    Hardenize reminded us that there was more to our internet-facing presence than just encrypted protocols and told us that we needed to tighten up our DNS and email security. Honestly, I (John) forgot about the weaknesses around email and DNS security dealing with the daily grind of other INFOSEC issues.
  3. We bookmarked once we finished addressing the issues around our HSTS setup. allows you to submit your website(s) for inclusion in Google Chrome’s hard-coded HSTS lists. We used to verify we did not have HSTS enabled (yet).
  4. Jumping over to, we took a look at (obviously named) our security headers. filled in a few gaps that Hardenize didn’t report on and provided us some more insight on how to tighten up our security headers. This site was created by Scott Helme who does INFOSEC in the United Kingdom.
  5. Switching tables, we moved over to our mail security. We used Google’s GSuite Toolbox Check MX for MX record validation. We already knew we had some issues identified using Hardenize but again wanted to validate the results. GSuite Toolbox Check MX provided some deeper detail into our MX record setup.
  6. We also utilized DMARC Analyzer for some assistance in setting up our email security. We signed up for free accounts for our respective domains, generated the appropriate DMARC DNS TXT record for our domains, and then put the appropriate DNS entries in our Cloudflare DNS panel. It’s been interesting to see the number of failed/spoofed email domains trying to use our legitimate domain names for email spam.
    dmarc analyzer
  7. Once we had an idea of what needed to be fixed we turned to actually fixing the issues. We immediately stood up a Cloudflare instance for our domains, updated our DNS registrar name servers, and tweaked various firewall rules and items to ensure traffic was flowing through Cloudflare as opposed to coming to our web server directly. Leveraging Cloudflare immediately gave us a layer of protection from “the world” to our back-end servers.
    We didn’t use Cloudflare as the only protection for the issues identified above but Cloudflare became a necessary stop-gap and protection mechanism while we went and hardened our server-side security. This is an important item to note.
  8. Finally having fixed the identified issues and validated our results, we turned to some fun tools. provided us with a plethora of options available to taking a run at our systems. characterizes themselves on their About page as: is a service created by a group of experienced penetration testers for people (security professionals, system administrators, network auditors, etc) who need to test the security of websites and network infrastructures from a remote location.” comes off like a cloud-based Rapid7 Nexpose but more. Its integration with Cloudflare made scanning our back-end systems a lot easier. Detectify describes their services as:
    “Detectify continuously monitors your website’s security status and reports back with issues. The idea is to help developers deploy safer code and make companies work preventive with security, rather than reactive. “
    We did make some changes to our Cloudflare instance for testing purposes to ensure that these tools weren’t hitting Cloudflare’s protection only. Cloudflare also offers in-app installs (Detectify) so these services work through Cloudflare without issue.

Some additional tools that we used briefly but not something we will deep-dive in: DNS Visualization –, SRI Hash Generator –, and HTTP/2 test –

Key takeaways…

John Ball – This endeavor reminded me of issues I think about on a regular basis:

1) It is so ridiculously easy to “get your stuff straight” with the amount of free tools and services publicly available;
2) When a responsible party just shrugs off their weak security with a blasé attitude it should cause those with a security conscious to burn with anger;
3) It is embarrassing that more companies, business, non-profits, and internet consumers (those with blogs, etc.) aren’t required to take (more) responsibility for their actions when it comes to securing their presence and, for those that are required to take responsibility but don’t, circle back around to item number 1;
4) Far too often we see security amateurs and even security professionals using “another tool” to mitigate their inability to correct the root cause of a security weakness. Understand me clearly: these tools are nice to deploy and really easy to set up but it is no excuse for weak server-side security and good practice. I’ve seen this behavior so much at work and in general that I’ve dubbed it “Yet Another Tool” syndrome. Fix yourself properly.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.