5 ms·

Those independent servers haven’t gone away just because there are new toys in the box. They are still fast, cheap and ubiquitous. I’m no fan of PHP or Wordpre

by jspash 6y ago

Those independent servers haven’t gone away just because there are new toys in the box. They are still fast, cheap and ubiquitous. I’m no fan of PHP or Wordpress by any stretch. But I agree with the pragmatic choice in this case. It will probably only need one dev to maintain the site. But even that would be overkill. You just never want a bus factor of 1. Especially for such a high profile site. But I’m digressing... But cloud vs VPS aside, I do wonder is they are self hosting due to security reasons. Imagine a bad actor hacking into the WP installation! It does have a bad security record.

laumars 6y ago
Sorry, by “independent servers” I meant self hosting / on prem. And while that hasn’t gone away entirely it has diminished massively as companies deprecate on prem hardware as hardware ages and replaces those resources with cloud services. Stuff like NFS made sense for on prem but it’s a terrible solution for building services on AWS (for example). Security wise, any popular CMS will be a security nightmare. It’s not even a PHP thing. In an ideal world you’d stick your CMS behind a WAF and put some additional policies around your admin APIs (if at all possible). Wordpress, for all of its warts, actually made those parts easy to do.
- snowwrestler 6y ago
  > Security wise, any popular CMS will be a security nightmare. I disagree, and I think it comes from a different understanding of what web security is. Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that they could never afford themselves. Testing and patching is an extremely important component of web application security in the long run, and also very expensive to do well. Most custom CMS projects do not bother to do it at all, and yet fool themselves into thinking they are secure because they wrote their own code. No one can write secure software on the first try. The most well-funded and well-regarded software companies in the world spend tremendous effort on coding practices and testing, and still ship vulnerabilities. Continuous testing and patching is always required. If your website is the only one running your CMS software, your first hint of a vulnerability may be when it gets exploited in production.
  - laumars 6y ago
    You’re overlooking a key thing there though. You’re assuming every hack is a targeted one. And that simply isn’t the case. Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engines become tools for bots to hunt out these insecure platforms. I’m not someone who advocates security through obscurity however the vast majority of WP et al hacks are not targeted and thus a home grown CMS technically wouldn’t fall foul in the same way. HOWEVER please don’t twist my words into saying that home grown CMSs are “more” secure. I’m making no such claim what-so-ever (and nor did I in my previous post when you want off on a soliloquy about how I apparently suggested that — I did no such thing!). My statement is and was only that any popular CMS will be a security nightmare. That point is very much true. This is why I also brought up the point about WAF and additional policies on your admin path. The former buys you a little more time with updates (assuming you’re with a reputable WAF that supports the CMS platform you’re hiding against) because they can identify suspicious requests (ie ones that look like they’re triggering a known vulnerability) and simply block those requests from your site (technically the WAF is a reverse proxy with some firewalling, request heuristics, etc). As for the point about admin policies: if you can IP whitelist who gets access to /admin then that saves you a lot of pain early on. But that’s obviously not always practical. However there are plenty of other ways to harden access. Disclaimer: in a former life I used to repair and harden hacked CMSs, shops like Magento, etc.
    - snowwrestler 6y ago
      It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that. We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts. I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both. I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one. Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.

by jspash 6y ago

laumars 6y ago

Sorry, by “independent servers” I meant self hosting / on prem. And while that hasn’t gone away entirely it has diminished massively as companies deprecate on prem hardware as hardware ages and replaces those resources with cloud services. Stuff like NFS made sense for on prem but it’s a terrible solution for building services on AWS (for example). Security wise, any popular CMS will be a security nightmare. It’s not even a PHP thing. In an ideal world you’d stick your CMS behind a WAF and put some additional policies around your admin APIs (if at all possible). Wordpress, for all of its warts, actually made those parts easy to do.

snowwrestler 6y ago
> Security wise, any popular CMS will be a security nightmare. I disagree, and I think it comes from a different understanding of what web security is. Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that they could never afford themselves. Testing and patching is an extremely important component of web application security in the long run, and also very expensive to do well. Most custom CMS projects do not bother to do it at all, and yet fool themselves into thinking they are secure because they wrote their own code. No one can write secure software on the first try. The most well-funded and well-regarded software companies in the world spend tremendous effort on coding practices and testing, and still ship vulnerabilities. Continuous testing and patching is always required. If your website is the only one running your CMS software, your first hint of a vulnerability may be when it gets exploited in production.
- laumars 6y ago
  You’re overlooking a key thing there though. You’re assuming every hack is a targeted one. And that simply isn’t the case. Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engines become tools for bots to hunt out these insecure platforms. I’m not someone who advocates security through obscurity however the vast majority of WP et al hacks are not targeted and thus a home grown CMS technically wouldn’t fall foul in the same way. HOWEVER please don’t twist my words into saying that home grown CMSs are “more” secure. I’m making no such claim what-so-ever (and nor did I in my previous post when you want off on a soliloquy about how I apparently suggested that — I did no such thing!). My statement is and was only that any popular CMS will be a security nightmare. That point is very much true. This is why I also brought up the point about WAF and additional policies on your admin path. The former buys you a little more time with updates (assuming you’re with a reputable WAF that supports the CMS platform you’re hiding against) because they can identify suspicious requests (ie ones that look like they’re triggering a known vulnerability) and simply block those requests from your site (technically the WAF is a reverse proxy with some firewalling, request heuristics, etc). As for the point about admin policies: if you can IP whitelist who gets access to /admin then that saves you a lot of pain early on. But that’s obviously not always practical. However there are plenty of other ways to harden access. Disclaimer: in a former life I used to repair and harden hacked CMSs, shops like Magento, etc.
  - snowwrestler 6y ago
    It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that. We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts. I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both. I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one. Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.