If you try to bring it up there's always some inexperienced overseas contractor with 6 months of experience who will say "It' s a few clicks to install and a few plugins to protect the security 100% no problem, what's so difficult? why do you make a big deal out of it?".
What's my incentive to do things differently?
This is the catch. Depending on what was done to your site, there's no "getting rid of the malware" for $100.
Those cheap hosting providers don't provide automated backups of your database. You probably have a backup of your site's files -- that's probably not perfectly current, but close enough maybe -- but I bet you haven't got regular backups of your database.
Drupal is one of those many CMSs that stores tons and tons of code in the database, including executable PHP. So how do you go about ensuring that all of that is clean, and changing all the passwords that may've been compromised, and making sure there are no other backdoors or shells left behind, for $100?
This is horrifying. Why was this ever done?
Thankfully they removed this option in Drupal 8, the latest version. You could also restrict users from accessing the functionality so it wasn't that terrible. In practice few sites actually use the option, but when they do it can make troubleshooting a giant pain in the ass.
My projects had a patch to remove that entire module from core on each build.
Now which is easier—make a new module to serve this page or filter the output of that page, or just enable PHP code for this page, and write it directly in PHP on this page only?
Instead they just believe that they are 100% secure then when they get hacked they act all surprised and with great hypocrisy say "security is our number one priority at shitshow.com. we take security extremely seriously.".
Otherwise I'm not suggesting that there's some great incentive. As we've seen with huge hacks like Equifax and many more companies we know right now they just get a slap on the wrist and so they continue to try to use "we are sorry" PR statements after the fact as their strategy.
There's a spread between your life is ruined and nothing happens at all and it entirely depends on what you've done with the account/site.
Something like jekyll or something.
However, I see a couple of problems standing in the way of more widespread adoption of static site generators:
1) I've never seen a static site generator that non-technical users felt comfortable with. Programmers like terminal interfaces. Your average user in 2018 has probably never opened the terminal.
2) Possibly even more significant, I don't think the people making the choice to use a CMS for a simple business-info or blog site are aware of the trade-offs that they're making, or of the benefits that a static site will provide down the line. For a lot of small business owners I've spoken with, Wordpress is basically synonymous with "web presence."
I wonder if there's a market for a web-based GUI like what Wordpress provides, but which runs jekyll under the hood and uploads the files to s3 or something like that. Is this what companies like Squarespace and Wix do?
We also have a pretty neat solution for site generation/hosting (JekyllPro) which is rolling out next month.
Using these two, none of the contributors realize they're using Jekyll. It's not as user-friendly as Squarespace, but it's pretty darn good.
1: https://github.com/Wiredcraft/jekyllplus
2: https://wiredcraft.com/blog/the-new-starbucks-cn-website-bol...
(disclaimer: Netlify employee)
That said, it didn't help that you don't support Gitlab, which is where all my sites are, and which is the more important reason why I couldn't get it to work.
We (Graphia) took a similar approach for our document management system. Essentially it looks and acts like a regular CMS but it sits on top of a git repo instead of a database; and publishes via Hugo.
It's not intended to be a fully-fledged CMS but the API would support it without much work; the UI is definitely the time consuming portion.
http://www.graphia.co.uk for anyone who is interested, not quite ready for prime time just yet. Soon.
Feel free to ping me using the contact info in my profile or at @benaiah in our Gitter room (https://gitter.im/netlify/NetlifyCMS) if you're interested in discussing this elsewhere.
Forestry + Netlify + Bitbucket is a good combination.
That's not only the same gnarly problem as cache invalidation but with a metric ton of filesystem writes on top of it.
I spent a lot of years working in tech consulting and did a lot of CMS integrations. We desperately wanted to push clients to Contentful and away from ornery beasts like AEM, but Adobe can sell AEM by saying it's part of the "marketing cloud" and that it's magic power is in user engagement and analytics and whatever other marketingspeak lies. Contentful was the developer favorite, but it was hard to convince businesses it was in their best interests even though it totally was.
I would work on this if I wasn't already running another startup.
There's also Netlify CMS, but I haven't done much with it. I think the GitHub requirement puts people off, and work on the GitLab--which has free private repositories--support issue is slow.
What we need is something like Publii that's not packaged in a way that's obviously meant to make closing the source easy. That story is too old, and too common, to believe their intentions are good.
Imho if you are really wanting to write a blog and host it yourself, this should not be too hard to learn. Wordpress doesn't install itself automatically, either.
I remember having to purge front page extensions off many a server. Cathartic feeling that one.
That said, back on subject:
Look, this is the main reason you devs tend to hear disdain from us sysadmins when we hear you want to run some new webservice in whatever language fad of the day (node, python, perl, php, asp.net, ruby, scala, go, etc) instead of generating files with your app that can then be serviced to the user using the tried and true tools (apache, nginx, hiawatha, haproxy etc) that have had sometimes decades of public internet exposure to claw thier way through.
Ah, but what about $functionality. Most webdevs think they need a scripting language backend when they really don't. There are uses for it and it has it's place, but it's been way overdone.
Relevant discussion: https://groups.drupal.org/security/faq-2018-002
Sidenote: I think everyone should check out hiawatha webserver, over at (https://www.hiawatha-webserver.org/). Hugo wrote it with security in mind and it by default addresses many things that no other webserver does. It's also gplv2 (which is a big deal for me), and it's performance is second to none. I'm not a big php person, but if I were to be doing a webapp where a backend like that would be needed, I would probably try to go PHP-FPM with hiawatha(mbed TLS)/haproxy and a really nicely hardened boxen and edge firewall(you are using nftables now right?).
I'm on mobile but a quick ddg show: https://www.hiawatha-webserver.org/weblog/64
I used to work a LONG time ago for a company that built Yahoo Small Business ecommerce websites. They used a tool called RTML ("Robert T Morris Language"), which was essentially HAML, powered by Perl, and constructed using a GUI (no text editor interface). Select where you want a node > New node > select node type > Save...each action was a full page load. The process was excruciating, and I was in charge of developing tools to automate the upload of "template" files from the developer's machine to the client's Yahoo Small Business store.
At the end of the day, the customer would load up all their goods into the Yahoo database and hit "Publish", at which point a multi-hour job would kick off to run their RTML against the database. The result was a completely static ecommerce website. Only the cart/checkout pages were dynamic, and those were using shared code.
The development process was a nightmare. The client experience was really bad (want to fix a typo? You're going to wait a couple hours). But I'll be damned if it was possible for anyone to hack those things. There was nothing to hack.
Turning that CMS into a distributed publishing platform is tricky, but scaling static content is easy-mode from top to bottom.
Funnily enough, having worked on all kinds of websites for the past 15 years, i'm still at a loss when asked what the all-round good solution is.
To further complicate things, things change. A website that was a perfect fit for a Wordpress template easily grows beyond that. And a site that seemed ideal for a custom Django/Rails backend might eventually settle into the kind of functionality groove where you begin to wonder if an off the peg solution might not have been a better idea.
Is there significant overlap in their functionality?
You know it's all trivial garbage...except if you want to replace it you need to support it, train them to use these tools and at every point you're going to encounter this resistance about WHY you're doing it and you say well security and speed and they're like it's fast enough and we've never been hacked.
So until the site grinds to a halt and they get also get hacked they basically view you as a blocker.
Static site generators are simply a file-system caching layer. Drupal used to have one of those and it was a terrible idea as the number of page variants on a commercial site very quickly hits file-system limitations and performance is appalling. Better to use a proper CDN for a similar result but with massively reduced latency due to content being served from the edge.
Most websites are mainly read only anyway. No need to throw in a programming language and store the data in a database.
The thing is, non-tech savvy people should be able to use(and deploy) and understand the static-web generators.
This exploit was far more lenient in timing, there was an advance notice of a serious vulnerability, and the automated exploits were weeks later this time.
There are certainly many people running a CMS themselves that don't have the capabilities to keep them reasonably secure. But it's not that hard if you have a reasonably small attack surface, e.g. few plugins and no user-generated content/accounts. And of course you need to subscribe to the relevant security mailing list.
Currently they have to deal with at least 5 different CMS, 4 shopping systems, and some hand made sites with at least 4 different frameworks. 2 backend languages. And legacy code with self written frameworks in PHP 4 on at least 2 important sites.
It takes some expertise to do these correctly, but it's not rocket science. I taught myself and have self-hosted Wordpress and Drupal sites for 8+ years with very few security incidents.
That said, I'm moving my Wordpress and Drupal sites to platforms like WP Engine and Pantheon. But not because of security concerns--because the platforms will accelerate our development process by making it easier for developers to create staging instances and deploy to production.
I'd change that to "enterprise CMS". Experienced sole proprietor web devs have often moved to lightweight, non-enterprise, non-feature-packed CMSes, this being one reason.
No. The article is about a security holes from 2014. It does not need a team to keep your software updated. I have been running a bunch of CMS for many years now and keeping them updated takes me almost no time. If I accumulate all the time I spent on it, it's probably a day per year or so.
This... simply isn't true.
Sure, you can just set your system to update and reboot once a week, and then when an update is incompatible with some of your software, well, spend the time to clean up the mess.
This is going to break every few years, and that mess is going to take significant effort, especially if you haven't touched that software for a few years.
A more proactive approach is to watch the security mailing lists, updating when appropriate, but that's an hour or two a week of effort... remember, you have to keep your full stack updated; your cms, your webserver, your os, etc, etc... you need to watch for holes in each of these things, then when there is a hole, you need to figure out if applying the update will break your current configuration, and then apply said update
Either way, it's a significant amount of skilled labor.
Sysadmins don't get paid what SWEs get paid, but we ain't free.
To go deeper into what others will respond to this with, yes, distributions cover some of this. But consider that every few years your distro will go out of support.... and you will have to figure out how to upgrade that, which is often pretty painless, but it does require either a high tolerance for risk or a lot of reading.
Then consider that other bits under your stack; your webserver, your php, your cms, all those packages/versions are sometimes changed mid-release and often changed on those major releases.
Hosting a Drupal site on Pantheon or Acquia does NOT relieve the site owner of testing and applying patches, fixing the site when a patch breaks something, etc.
In terms of hosting, the LAMP stack itself is very stable; setting Linux, Apache, and MySQL to auto-apply stable updates is very unlikely to break Drupal. Even in PHP, going from 5.x to 7.x required some careful testing, but minor updates are generally fine.
The security advantage of open-source CMS software is that the community update process reminds site owners to do this stuff, and gives them the code to do it.
In contrast, a custom-developed CMS can sit there with security holes in it for months or years, and the owner will have no idea until their site is hacked.
Think about all the schools that paid someone once for this. The Solution is easy but the structure of responsibility is not there.
it's a bad idea to host and maintain
a presence with a CMS yourself
Talking about schools. I would say it depends. If the kids run the CMS I would say the learning outweights the downsides of having some VM hacked that only holds public information. So for a CMS with public information I would say: Let the kids have fun with it!
There might also be use cases where that's not a good idea. Really depends on what the CMS is used for.
It takes a relatively large team to reliable shield software as complex as modern CMS from abuse and the mitigations have to be employed so timely that one cannot wait until this is high enough on someone's to-do list that has to do this for 10 different CMS.