How can we afford to grow the pie?

Internet survival time

Written .

Note: This is an opinion piece. Discomfort or fury cannot be completely ruled out.

It seems like the internet is not the safest place on earth (queue shock and horror). This may stem from the fact that both human beings and most common computer systems are fragile instead of anti-fragile (queue more shock and more horror). It seems like servers have to be reachable from the internet. They cannot simply be kept away from the internet completely. Mitigations, therefore, seem warranted. This article focuses on servers.

Specific problem: Any computer attached to the internet becomes a target. For all practical intents and purposes this happens immediately. An excellent write-up is provided by Dr. Neil Krawetz.

One option seems to be to eliminate inbound traffic to a freshly installed operating system and to only permit outbound connections initiated by its update mechanism and, of course, their response traffic. This can be achieved or at least approximated by (1) a dedicated hardware firewall, (2) temporary AWS or GCP or Azure network configuration or (3) even the default $ qemu(1) network NAT configuration current at the time of writing this opinion piece. The details, of course, vary across the broad range of specific situations. Nevertheless, the concept seems worth exploring. Naturally, execution time, frequency and quality of security updates as well as hypothetical deployment time in case of a virtual machine (VM) must not fall too far behind evolution of the attacks.

A good next step seems to involve opening the perimiter up for test connections initiated by test clients. This is a server after all. Testing and validation are practically relevant tools to check against known counter-examples (queue even more shock and even more horror).

Finally, whitelisting all necessary TCP/IP and UDP/IP ports seems warranted if and only if the previous steps raised no red flags. Defense in depth seems to harmonize well with an anti-fragile approach.

Technical Appendix

While researching a bit on options for starting a VM in a more secured network environment for updates and deploying it to a cloud provider after updates and testing, multiple technically interesting details surfaced. They are documented here for future reference.

Firstly, qemu's default networking (SLiRP) seems to block inbound traffic by default. Secondly, searching for VM uploads to AWS, GCP and Azure yields results for uploading .ovf images, however, $ ovftool(1) seems to be some product by the company VMWare. There were no other easily discoverable implementations on the open virtualization format (OVF). Notably, the term "ovf" does not show up in the manual page for $ qemu-img(1) or OpenStack's article on conversion of VM images using qemu. The trick seems to be to search for qcow2 uploads to AWS and for VHD uploads to both GCP and Azure. All of this information pertains to the time of writing this text.