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.
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.