KUMITATE HOSHU (\"kumitate-hoshu\" is Japanese for protection) closes the ways most WordPress sites get broken into, with as little to configure as possible. Activate it and the protections that cannot lock you out are already on. Everything else is one switch, explained in plain words.<\/p>\n\n
Login<\/strong><\/p>\n\n Fewer ways in<\/strong><\/p>\n\n Checks<\/strong><\/p>\n\n Keep<\/strong><\/p>\n\n Plugin Check notes a \"plugin updater\": that is the automatic-updates feature above, which installs updates from WordPress.org through the normal WordPress upgrader. The plugin never changes where updates come from.<\/p>\n\n What this plugin does not do: it cannot protect the web server or operating system, stop a denial-of-service attack, or help once an attacker can already run PHP on the server. Keep WordPress, plugins and themes updated and keep backups away from the server.<\/p>\n\n Nothing is downloaded or sent until you turn on \"Allow connections to WordPress.org and the vulnerability list\" under KUMITATE HOSHU > Settings.<\/p>\n\n Add Log in with one of your recovery codes, then on your profile turn two-factor login off and set it up again. An administrator can also turn it off for another user from that user's profile.<\/p><\/dd>\n It covers the login form, including custom login forms that use wp_signon(). XML-RPC and application passwords authenticate without the form and are not asked for a code, so keep \"Close unused doors\" on (it turns XML-RPC off) and give application passwords only to users who need them.<\/p><\/dd>\n They use XML-RPC. Turn off \"Close unused doors\" under KUMITATE HOSHU > Settings, or ask on the support forum for a finer switch.<\/p><\/dd>\n The file layout and database format follow that plugin's own archiver; backups made here were imported with its version 7.112 during development, with plugins and the theme re-activated by it afterwards. Save the permalink settings once after an import. Its free version limits the size of an import uploaded through the browser; large sites are restored with KUMITATE HOSHU itself, or imported with that plugin's paid extension.<\/p><\/dd>\n Under wp-content\/uploads\/kumitate-hoshu\/backups, with a random part in each file name and an .htaccess that denies web access on Apache. On nginx the folder is not denied automatically: add a location rule for \/wp-content\/uploads\/kumitate-hoshu\/ that returns 403. Download backups regularly and keep them away from the server; they contain your database, so treat them as confidential.<\/p><\/dd>\n Yes. The protections run on login and admin requests, which are not cached. Security headers on cached pages are sent only when the cache was filled with the plugin active.<\/p><\/dd>\n Login limits use the address the web server reports. If your host puts a proxy in front and every visitor appears to share one address, add a filter on \n
\n
\n
\n
External services<\/h3>\n\n
\n
\n
\n
I changed the login address and forgot it<\/h3><\/dt>\n
define( 'KUMITATE_HOSHU_LOGIN_URL_OFF', true );<\/code> to wp-config.php. The usual wp-login.php address then works again.<\/p><\/dd>\nI lost my authenticator device<\/h3><\/dt>\n
Does two-factor login cover every way in?<\/h3><\/dt>\n
Jetpack or the mobile app stopped working<\/h3><\/dt>\n
Can All-in-One WP Migration really read these backups?<\/h3><\/dt>\n
Where are backups stored, and are they safe?<\/h3><\/dt>\n
Does it work with a caching plugin or a CDN?<\/h3><\/dt>\n
What about the server behind a proxy or load balancer?<\/h3><\/dt>\n
kumitate_hoshu_client_ip<\/code> that returns the real address from the header your host documents, and only that header.<\/p><\/dd>\n\n<\/dl>\n\n\n0.2.0<\/h4>\n\n
\n
0.1.0<\/h4>\n\n
\n