Humans never visit but I have some websites with ancient cms's. When I got bored playing with them I download the html, change the extensions to php and replace the site with a static copy. People then tirelessly try to hack it since they have laundry lists of known vulnerabilities. (Now that I think about it I regret not making the admin area public for added nostalgia.)
Not that I follow my own advice, but a popped server can still be a liability for you. If you don't need it online I would take it down. Don't want to suddenly realise you've been an email spam node for several months.
It's fine, I am just being a nit, but static doesn't mean zero code. There is still a server and program turning a web request into a response. But in your case it's not your problem, it's cloudflare's.
I only mentioned it in the assumption they had a VM or shared hosting, in which case it's worth thinking about.
Before you can hack a static website you first have to realize it is one and you need the motivation to do so.
My "audience" is motivated by it being very outdated software. If non of the exploits work they will think I've patched everything.
There must be more interesting targets out there?
If you are capable enough to hack appache the choice of target makes no sense.
My best security layer is that one first has to even find my websites. If you do there are plenty of better targets among them. From the business end however the most secure look the least secure.
It's a shared hosting account, if I try to send bulk email they will immediately unplug it.
That leaves only the glory of pwning the last instance of some obscure cms?
It would probably make me laugh? Everything will be back up within a week. Nothing of value is lost.
It would be an automated scan and exploit across all services exposed, and the motivation is just to add a node to a botfarm/ddos network or spam node. Your website is already on a database if it has an SSL certificate and domain.
Like you said, shared hosting and low value server so you don't mind either way.
It's always worth thinking about, and the only true "protection" is logging, logging, logging. If you're not reading system logs, you'll never know your daemon was segfaulting for a while, nor will you see that SSH login. Or iptables egress traffic to weird places. Whatever. Point is, knowing what your box is up to, is the only way to meaningfully perform due diligence.
My point though, in my prior comment, was attack surface.
With PHP you have outdated code in the ORM/MVC/whatever. Then you have your code. At least with only a web server and static HTML, and entire litany, and the most likely part to get compromised, is not there any more.
In my 30+ years of experience dealing with people getting compromised, it's always been some asshat not doing security updates (eg, using a distro and updating daily). Or worse, just compiling stuff then not updating builds on a daily or weekly basis.
Outside of that, it's been bad PHP code. Or perl. Or whatever.
I think once out of all the times I've been called to clean up a mess, has it been the web server itself. Bearing in mind "I didn't update my OS/web server for a year, and now I got hacked!!" isn't "it was the web server", it's "dumbass didn't do security updates".
Anyhow.
You're not wrong, yes everything is vulnerable. But PHP + framework + PHP code bugs == 9999, web server == 1 of the time.
If it's a computer publicly visible on the internet then it has an attack surface, not having a scripting language enabled reduces it a lot but not entirely. There is still a web server involved in a static site being served, amongst other services that computers often have by default.
If it's shared hosting, still a problem, just not theirs.
When I stood up some sites last year, I used codenames for the subdomains thinking I was obfuscating a little. I didn't know about the transparency logs until months later.
Yeah... you have to remember to setup and fully secure the site before LE certs are issued or you're going to have a bad time. Learned that the hard way when I popped a couple dozen wordpress sites in one go.
On one hand yes, but on the other hand just configuring your server to refuse connections by IP address rather than server name seemed to drop roughly half the bots I ever see.
I always had a decent bit of background noise, I think hosting on AWS comes with that. But after someone linked to me on hackaday the bot traffic went through the roof. One link to you from a noteworthy website, and all bets are off forever.
Could be because of number of pages you have. At work we have several million public content pages, so a few badly behaving bots can already do a lot of damage.
For my personal website it’s 10x more bots but I barely notice because it’s a few pages.
I never had this issue really… until two years ago, new website new host… boom, hugged to death by thousands of bots per second. This is on an alicloud vps.
I recently brought up a website on a never-before-seen .com domain. Within about 10 mins of bringing it up with a SSL certificate, Anthropic came knocking on the door requesting the front page. (Almost certainty due to them watching the Public Certificate Transparency logs)
Had a bit setup a new Wordpress install before I could lock it down. I was very confused why a brand new install didn’t give me the setup page before seeing in the logs someone had automated it. Pure evil to be scraping new renewals and dns changes to look for this kinda stuff.
For the record I thought I had this site behind basic auth.
