3 ms·

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 disc

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.
- laumars 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. Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall). I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time. > 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. Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product. Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly. Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage. Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP. > 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. Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so. > 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. This I agree with too.
- laumars 6y ago
  > 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. All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely! You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_with_the_bathwater https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...

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.

laumars 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. Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall). I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time. > 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. Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product. Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly. Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage. Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP. > 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. Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so. > 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. This I agree with too.
laumars 6y ago
> 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. All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely! You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_with_the_bathwater https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...