No apologies needed!
My experience is that log files of any service exposed to the wilderness are chock full of all sorts of threatening and occasionally terrifying entries.
I know it’s not a “solution”, but I now do all of my outward-facing services on AWS EC2 instances behind AWS Security Groups, and I run the firewall with relatively sparse inbound ports open. I try very hard to make those outward-facing services and the systems they run on read-only.
The key thing about security is that it not possible to build a “secure” system. I’ve benefited from security training at companies like IBM and Experian, and that training emphasizes:
- Identify and enumerate the threats and threat actors you are most concerned about
- Identify and enumerate the assets that are most vulnerable
- Build multiple layers of protection
- Design and assemble security mechanisms and protocols that target those specific needs
- NEVER rely on DIY protection mechanisms
- Incorporate security from the earliest stages of any design – do NOT assume that it can added at the last minute just before deployment
In my experience, there is always a tension between the inconvenience and overhead imposed by security protocols and the benefits that accrue from those protocols. The further away from the wilderness you are, the less concerned you need to be. A configuration file for an isolated Raspberry PI system in your basement playroom does not require the same protection as the same file on a public-facing system with millions of users spread throughout the world.
Finally, physical security is always a crucial and often neglected aspect of all this. This is especially true for those of us who work remotely.