sunhux
asked on
Is auto-update (or manual trigger) for Wordpress the best practice?
We just had an incident where Wordpress auto-updates failed (it was
looking for "“wp-config-sample.php” which was not there & thus failed.
It's on our public facing web server & it caused an outage
What's the best practice for Wordpress updates :
a) allow auto-updates for minor + security patches or disallow this?
b) disallow major feature update?
We are on version 5 of Wordpress : auto-update was Enabled & never
triggered such outage till we moved to Ver 5 (as I was told).
Senior management is against the idea of auto-update
got the following from some sites:
Automatic Background Updates
For WordPress 3.7+, you don’t have to lift a finger to apply minor and security updates. Most sites are now able to automatically apply these updates in the background. (You’ll still need to click “Update Now” for major feature releases.)
A site quoted:
“be careful disabling automatic security updates for WordPress as doing so could put you at risk for a brute force attack, hack, etc”
So what's the best practice? Allow minor+security auto-update (what's the risk of service disruptions if we allow)
& can Ver 5 of WP allow both auto (for minor+security) but disallow auto-update for major version updates ?
Does IPS signatures out there auto-deploy "Block" mode for Wordpress signatures or only "Detect"?
(I don't have access to an IPS anymore):
If senior managemt disallows auto-updates, what's the mitigations? Permit IPS to auto deploy "Block"
mode signatures for Wordpress?
looking for "“wp-config-sample.php” which was not there & thus failed.
It's on our public facing web server & it caused an outage
What's the best practice for Wordpress updates :
a) allow auto-updates for minor + security patches or disallow this?
b) disallow major feature update?
We are on version 5 of Wordpress : auto-update was Enabled & never
triggered such outage till we moved to Ver 5 (as I was told).
Senior management is against the idea of auto-update
got the following from some sites:
Automatic Background Updates
For WordPress 3.7+, you don’t have to lift a finger to apply minor and security updates. Most sites are now able to automatically apply these updates in the background. (You’ll still need to click “Update Now” for major feature releases.)
A site quoted:
“be careful disabling automatic security updates for WordPress as doing so could put you at risk for a brute force attack, hack, etc”
So what's the best practice? Allow minor+security auto-update (what's the risk of service disruptions if we allow)
& can Ver 5 of WP allow both auto (for minor+security) but disallow auto-update for major version updates ?
Does IPS signatures out there auto-deploy "Block" mode for Wordpress signatures or only "Detect"?
(I don't have access to an IPS anymore):
If senior managemt disallows auto-updates, what's the mitigations? Permit IPS to auto deploy "Block"
mode signatures for Wordpress?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I managed to dig out out Checkpont signatures list plus an old Trendmicro signature file n skim through various Wordpress signatures for vulnerabilities:
about two thirds of Wordpress signatures are deployed instantly/automatically in Block mode while one third in Detect mode.
As there is some form of mitigations already by IPS, if the team insists on disabling auto-updates completely (incl security patches), I can still get them to apply manually the patches weekly
about two thirds of Wordpress signatures are deployed instantly/automatically in Block mode while one third in Detect mode.
As there is some form of mitigations already by IPS, if the team insists on disabling auto-updates completely (incl security patches), I can still get them to apply manually the patches weekly
ASKER
My preference is to fix only the cause of the issue & not more than the cause of the issue:
a) if it's only the major upgrade that caused the disruption, then only disable major
upgrade but still permit minor + security updates
b) if minor+security updates was the cause of the disruption, then disable it as well
Alternative mitigations is to use IPS but was told by an IPS developer that IPS signature
runs a higher risk of causing disruption compared to patches from the products (ie
WPress in this case) principals
a) if it's only the major upgrade that caused the disruption, then only disable major
upgrade but still permit minor + security updates
b) if minor+security updates was the cause of the disruption, then disable it as well
Alternative mitigations is to use IPS but was told by an IPS developer that IPS signature
runs a higher risk of causing disruption compared to patches from the products (ie
WPress in this case) principals
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
https://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/
thanks heaps. I gave the 3 options to management n we have only 5 sites (I dont know if we hv custom codes):
Might want to establish when the issue occurred, which of the 3 modes of auto-updating was in effect at that time:
If Option 2 was in effect at the time of disruption, Option 3 may still be feasible
If Option 3 was in effect at the time of disruption, then we should disable all auto-updates ie go for Option 1
# Option 1: Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false ); ç Incident report’s suggestion
# Option 2: Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );
# Option 3: Enables core updates for minor releases (default):
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); ç this was my thought & Wordpress site suggests this
There are also some filters for even finer control, which override the above :
allow_dev_auto_core_update
allow_minor_auto_core_upda
allow_major_auto_core_upda