9 ms·

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

by ehnto 1mo ago

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.

b112 1mo ago
Re-read the post. He converted the sites to static html.
- unclebucknasty 1mo ago
  To GP's point, any connected server can become a liability, even if it is intended to just host static HTML (or for some other purpose).
  - fragmede 1mo ago
    I'm serving static sites via Cloudflare pages. Pretty sure that's gonna be actually static.
    - unclebucknasty 1mo ago
      You're running Cloudflare Pages on a home server?
    - ehnto 1mo ago
      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.
      - b112 1mo ago
        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.
      - econ 1mo ago
        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.
        ehnto 1mo ago
        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.
- ehnto 1mo ago
  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.

by ehnto 1mo ago

b112 1mo ago

Re-read the post. He converted the sites to static html.

unclebucknasty 1mo ago
To GP's point, any connected server can become a liability, even if it is intended to just host static HTML (or for some other purpose).
- fragmede 1mo ago
  I'm serving static sites via Cloudflare pages. Pretty sure that's gonna be actually static.
  - unclebucknasty 1mo ago
    You're running Cloudflare Pages on a home server?
  - ehnto 1mo ago
    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.
    - b112 1mo ago
      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.
    - econ 1mo ago
      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.
      - ehnto 1mo ago
        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.
ehnto 1mo ago
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.