This article is for people who run servers the way I used to: build once, and as long as responses look healthy, leave them alone.
In college, a professor I was close to said, "I'll give you the parts—build a server and try running it!" That is how I got started. I installed CentOS, installed Apache, and did not really understand what I was doing, but turning off iptables and getting it publicly reachable felt amazing.
Later, when I started building apps, rental hosting was not enough, so I rented a VPS from Onamae.com. When AWS appeared, I jumped to EC2 on momentum—"Wow, you can scale up the instance you built as-is!!" I wrote Ansible recipes for automated setup, deployed, and then left things alone as long as responses looked normal—operations in name only.
I wish I could tell my past self: do not do that.
In the end, I was lucky enough to avoid major incidents before moving to serverless, and I stopped and terminated every custom instance I had built. Still, I want to say this to anyone planning to do the same thing now—or already doing it. Never do this on client work.
Exposing a Server Comes with Risk
Put simply, making a server public means exposing a machine you manage so anyone on the internet can reach it. Of course you restrict ports, tighten permissions, and limit access to read-only under specific directories, but bots still hammer servers where those controls are weak.
This experiment article explains it clearly.
Within about two hours of opening a port, bots found the server, noticed SSH was open, and tried unauthorized logins repeatedly. It had clearly been discovered by a malicious bot, so I left the server alone for about two weeks to watch what happened.
https://business.ntt-east.co.jp/content/cloudsolution/column-try-04.html
You get unauthorized access even on servers with no domain attached and no published IP address. Tie it to a service and the volume is incomparably higher (it really is).
Even if you say, "I built it exactly by the book!" you cannot claim every OSS library you use is free of security holes. The Information-technology Promotion Agency site shows what vulnerabilities have been disclosed.
https://www.ipa.go.jp/security/vuln/documents/index.html
I am not saying "servers are scary, so never expose them." But if you build from a recipe and then leave things alone while responses look fine, things can go very wrong. How bad?
- If unauthorized access succeeds, website defacement is unpleasant but at least noticeable
- If your server becomes a stepping stone for crime, you may never notice
- If it is discovered, the police may well come to you
- On client work, a damages claim is absolutely possible
"Vendor Security Obligations in System Development—Using the Tokyo District Court January 23, 2013 Judgment as Material" covers SQL injection, but it explains developer responsibility very clearly, so I recommend reading it.
https://www.softic.or.jp/semi/2014/5_141113/rep2.pdf
Serverless Lets You Benefit from Specialist Security
Of course you can choose to face those risks and "do your best," but I moved to serverless. I will skip what serverless is here, but very simply: you upload the code you run to cloud storage beforehand—not onto the server itself.
With AWS Lambda, your code (the function) is uploaded to S3. It is not uploaded to Lambda itself. At runtime an instance is assigned, runs the function, and when it finishes the instance is released. Naturally, you cannot be turned into a foothold through unauthorized login or have malware embedded on the instance (except in the deployed function itself).
With AWS Elastic Beanstalk, like Lambda, code is uploaded to S3 and deployed into a package AWS builds. It is built from EC2 and ELB, so it is not as safe as Lambda, but if that worries you, periodic restarts can keep the architecture clean. (Combined with scheduled Lambda execution, daily restarts are possible: reference.)
You can also apply security patches to instances automatically. The Elastic Beanstalk release notes make this easy to see—there are roughly two to three updates per month.
https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/relnotes-2021.html
It is also worth reading the shared responsibility model:
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
Closing
To repeat, this article is for people who, like me, build a server once and leave it alone while responses look healthy. A generation ago, even if you wanted otherwise, small projects used rental hosting and anything bigger assumed "you build the server yourself" on a VPS. Today serverless gives you a way to spread responsibility, so I hope you will consider it.
See you next time.