ロコモコ堂通信社はWordPressサイトの改修・修理屋もややらせていただいておりますが、あちこちのサイトを拝見させていただいていて、常々思う事が有ります。
それは、WordPressのサイトに危ない状態のものが多いと言う事。
ビジネスに使っていらっしゃるサイトでも、何かのきっかけで崩れそうな危険なサイトがとても多いと言う事です。
どんな状態になっているかと言うと、こんな感じです。
Index
- 1 WordPressサイトの危ない状態
- 1.1 1. 完成時のサイトのコピーを残していない。
- 1.2 2. 定期的なバックアップをしていない。
- 1.3 3. WordPressのバージョンアップもプラグインのバージョンアップもしていない。
- 1.4 4. 修正・変更・追加が制作時のルールとは違う独自のやり方でされていて、内部はカオス状態。
- 1.5 5. プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceするのでなく、直接プラグインファイルに修正・削除を加えている。
- 1.6 6. Akismetプラグインが有効化されていない。
- 1.7 7. WordPressのバージョン情報がheader内に書き出されている。
- 1.8 8. ログインユーザー名がサイトのタイトルなどから容易に連想される。
- 1.9 9. パスワードが英文字4文字で、数字も記号も使っていない。又は数字のみの4文字。
- 1.10 10. wp-config.phpなどの重要なphpファイルのパーミッションが、400になっていない。
- 2 円滑にメンテナンスと適時システムの修正・変更が行える 仕組みとルールを作りましょう
WordPressサイトの危ない状態
- 完成時のサイトのコピーを残していない。
- 定期的なバックアップをしていない。
- WordPressのバージョンアップもプラグインのバージョンアップもしていない。
- 修正・変更・追加が制作時のルールとは違う独自のやり方でされていて、内部はカオス状態。
- プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceするのでなく、直接プラグインファイルに修正・削除を加えている。
- Akismetプラグインが有効化されていない。
- WordPressのバージョン情報がheader内に書き出されている。
- ログインユーザー名がサイトのタイトルなどから容易に連想される。
- パスワードが英文字4文字で、数字も記号も使っていない。又は数字のみの4文字。
- wp-config.phpなどの重要なphpファイルのパーミッションが、400になっていない。
これがなぜ危ないのか?というと。
1. 完成時のサイトのコピーを残していない。
これ、結構有ります。Webサイトを最初の状態に戻してたくても戻せなくなります。
作成した業者に聞いても、「データは残していないので、サイトが壊れたら、もう一度制作する事になる。」と言わたりします。
サイトのキャプチャー画像も無ければ、修理屋も元の状態に再現出来ないので、かなり困った事になります。
これは定期的なバックアップを取る事で、解決できるんですが。
2. 定期的なバックアップをしていない。
WordPressは情報をデータベースで管理しています。このデータベースがまれに壊れる事が有ります。このデータベースが壊れた場合、修理し手元の状態に戻すのが難しい。確実なのはバックアップから復旧させるのが確実です。
またサイトがウイルスやトロイの木馬などに侵されたしまった場合、感染前のバックアプデータが有れば、全消去し、ウイルスを駆除し、その後感染前のバックアップをサイトにコピーすれば、感染前の状態に戻せますが、無ければどうしようもない状態になってしまいます。
さらに間違ってファイルを削除してしまったり、上書きしてしまった場合にもバックアップからコピーすれば元の状態に戻せます。
バックアップ作業はサーバに負担をかけるので、バックアップ中のサイトへのアクセスはレスポンスが下がります。あまり頻繁には行わない方が良いとは思いま。ですが最後のバックアップを行ってから後のデータはバックアップに残されていないので復旧できません。出来るだけそれを減らす為に、適度にバックアップの間隔を短くして、こまめにバックアップを残しておいた方が良いでしょう。
3. WordPressのバージョンアップもプラグインのバージョンアップもしていない。
WordPressはセキュリティーホールを潰したり、内部で使っているコードにある古い関数などのPHP非推奨の箇所を新しい推奨のものに変えるため為、常にバージョンアップしています。
WordPressのバージョンが古いとハッキングによってサイトに侵入されたり、プログラムコードに使えない古い関数が入っている事でエラーを起こし、最悪サイトが動かなくなってしまいます。
プラグインのバージョンアップも同様です。バージョンアップしていないとセキュリティホールが残ったままになったり、使用できなくなったコードやタグの為、動作がおかしくなったりします。
4. 修正・変更・追加が制作時のルールとは違う独自のやり方でされていて、内部はカオス状態。
htmlやcss、phpの記述の仕方についての事なので、通常サイトを見る時は判らない部分ですが、てんでバラバラのいろんなルールで書かれていると、コードの内容が判りにくく、コードの修正・変更・追加時に間違いを起こし易くなります。
例えばこんなのがあります。
- 1つのhtmlタグのスタイルをhtmlのstyle属性とcssの両方で設定している。
- cssに同じ内容のものが複数有る。
- cssでサイズの単位がpx、en、rem、%などがバラバラに使われている。
- htmlで空行を作る為に<p style=”margin-top: 20px;”></p>や<div style=”heignt: 10px;”></div>がはめ込まれている。
- floatプロパティーの解除に2重・3重にclearfixがかけられている。
- かと思いきや、floatプロパティーの解除がされていない。
- htmlで閉じタグを使っていない。
あ、ルール以前の事も入ってるな。
違うクラスだから影響無いだろうと思ってcssを変更したら、あちこちの表示がおかしくなるなんて事もざらにあります。
解析に時間がかかるし、トラブルの原因になるし、ルールに一貫性を持たせないと危ないです。
5. プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceするのでなく、直接プラグインファイルに修正・削除を加えている。
これは何が怖いって、プラグインをバージョンアップすると、変更部分が跡形もなく全て消えてしまって変更前のディフォルト状態になる事です。
バックアップが残っていれば、それから復元できるんですが、バックアップも無い場合、時間とお金をかけて一から変更部分を開発し直さないといけなくなります。
血が凍りそうな程恐ろしい話です。
6. Akismetプラグインが有効化されていない。
Akismetプラグインは、記事に投稿されたコメントを自動的に分類し、スパムコメントをスパムフォルダに移し、決められた時間が過ぎるとそのスパムコメントを削除するプラグインです。
スパムコメントには悪意のこもったものも多く、ワームやトロイの木馬入りのものも有ります。Akismetプラグインを有効化して、サイトの入り口で排除する様にしておかないと危ないです。
以前、管理していたWordPressサイトでAkismetを無効化した時、1日に1000件近いスパムコメントが送られてきた事が有りました。あの時程Akismetプラグインの有り難みを感じた事は有りません。
7. WordPressのバージョン情報がheader内に書き出されている。
現在WordPressサイトは最も多く使われているCMSなんじゃないでしょうか?
多く使われていると言う事は、そのセキュリティーホール情報などを手に入れれば効率良く多くのサイトをハッキングできるわけで、実際WordPressサイトをターゲットにした攻撃が多いです。
サイトのheader情報などGoogleのでベロッパーツールやSafariのインスペクターで簡単に見られたりするわけで、情報は簡単に集められます。WordPressのバージョン情報がheader内に書き出されていると、そのバージョン特有のセキュリティーホールを突いて攻撃される心配が出てくるのです。
表示させない様にするには、使っているテーマのfunctions.phpに
1 |
remove_action('wp_head', 'wp_generator'); |
を書き込むだけで良いので、やるべきです。
8. ログインユーザー名がサイトのタイトルなどから容易に連想される。
一番驚くのがこれで、ユーザー名がサイト名をアルファベットにしただけとか、サイト名を数字などの語呂合わせにしたものなど、簡単に推測できるものが多いんです。
9. パスワードが英文字4文字で、数字も記号も使っていない。又は数字のみの4文字。
パスワードは4桁程度だと1秒程度で解析されてしまうと言う話も有ります。10桁になればそれが数時間かかるとも言われています。
WordPressのログインパスワードは、英数文字だけでなく何種類もの記号も使えるので、出来るだけ複雑で、長いパスワードを使うべきです。
10. wp-config.phpなどの重要なphpファイルのパーミッションが、400になっていない。
wp-config.phpはWordPressの基本設定ファイルみたいなもので、データベースのホスト名やデータベース名、パスワード迄書かれています。悪意の第三者がこのファイルから情報を得れば、とても危険な事になります。
WordPressが置かれているサーバでは、ファイルやディレクトリをパーミッションというアクセス権を設定する事で、ファイルを不正に使用されたり、改竄されたりできない様にしています。読み取り・書き込み・実行出来る権利を、アクセスする者を管理者・グループ・一般に分け、設定するのです。
設定は数字又はr・w・xのアルファベットを使って行いますが、400と言うのはグループ、一般とも全くアクセスできず、管理者も読み取りだけで書き換えも実行も出来ないと言うという、改竄防止にはかなり強力な設定です。
WordPress Codexでも推奨されている事なのですが、一般も読み取りできる644と言う設定になっているところが多いんです。
400に設定すべきです。
WordPress の安全性を高める – WordPress Codex
円滑にメンテナンスと適時システムの修正・変更が行える
仕組みとルールを作りましょう
内部は継ぎはぎだらけのパッチワーク状態で整合性が取れていず、さらに重要なセキュリティー対策もほとんど取られていないところが予想以上に多いです。
サイトを製作した業者は制作のみの請け負だと、予算と時間との兼ね合いから、運営時のセキュリティーとメンテナンス性の確保にあまり手間をかけられないのですよね。
また修正・変更・追加を請け負う業者やフリーランスのWebデザイナー・エンジニアも、請け負う費用の為にあまり作業に時間をかけられないし、時間をかけてサイトの構造を調べられない分、他人の作った未知のサイトをいじると何が起るか判らない恐怖心から、書き込まれているコードには出来るだけ手を加えない様にしてしまうんですよね。
その為にパッチワークはどんどん増え、セキュリティーの確保からも取り残されていくんですね。
サイトは大事なビジネスの道具なのですし、情報漏洩にもつながりかねません。きちんとしたメンテナンスで、堅牢なサイトにしていくべきだと思うんですが。
それにはサイトの作成時から、メンテナンスと適時システムの修正・変更が行える仕組みとルールを作り、サイトを作成した業者か、サイトの仕様を理解している業者に管理をる様にしないといけないですね。
Webサイトは道具ですが、壊れたら元に戻せない道具です。
くれぐれもメンテナンスは怠らない様、ご注意下さい。
WordPressサイトの危ない状態
興味深いサイトを提供していただきありがとうございます。
現在 HTMLサイトと WP を組み合わせたサイトで 運用を考えております
WPは便利だが 壊れると直せないもの ダミーサイトを いっぱい作って
iFlameでHTMLないに表示
調子が悪くなったら _002に切り替え
なんていう事を考えています。
そもそも WPは突然動かなくなるも 無料だからしかたがない
直せないから バックアップサイトを作っておく
記事更新がめんどうだ >>> 始末がつかなくなる を繰り返していました
”Webサイトは道具ですが、壊れたら元に戻せない道具です。
くれぐれもメンテナンスは怠らない様、ご注意下さい。”
興味深く拝読させていただきました
”プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceする ”
どのようにすればよいのでしょうか 方法が記載されている記事をご紹介いただけますとありがたいです
コメントありがとうございます。
メインのサイトにサブサイトをiframeで表示させる。サブサイトが壊れた場合に切り替えて表示させる予備のサブタイトを複数作成しておくやり方をお考えなんですね。
メインのサイトをWordPressでない従来型で、サブサイトをWordPressで作成する感じでしょうか?
このやり方なら、複数のサブサイトもサブドメインなどで常にインターネット上に公開され、さらにメインのサイトでもネット上で同じ内容が表示される様になりますね。
となると、ネット上に同じ内容のものが複数有り、メインのサイトではそれを流用している事になってしまうので、SEO的にまずいことになります。
Googleがネット上のサイトの情報を集め、検索出来る様に情報を整理する時、同じ内容のサイトはコピーサイトと見なされ、価値が低いものと評価されます。
それはiframeなどで呼び込ませる時も同じで、場合によってはスパム扱いになって、評価のランクをさらに下げられてしまいます。
ですからサイトは1つにした方が良いです。サイトは定期的に自動バックアップさせて、異常が出たらバックアップデータを入れ直せば良いですし。
技術的な管理が難しい場合は、管理業者に任せた方が良いかと思われます。管理にかかる手間と大きなトラブルが起きた時の出費を考えると、コスト的にも有利だと思いますし。
”プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceする”
これはプラグイン自体に修正部分を書き込んでいると、プラグインのアップデートで書き換えられてしまう事への対処で、自己流でやっている方法です。
プラグインのディレクトリ外に修正部分のファイルを置いておき、アップデートされたプラグインファイルにrequire_once(‘修正ファイルへのパス’);を書き込むやり方です。
アップデートでプラグイン自体が大きく変更された場合、以前の修正ファイルは使えなくなるので、カスタマイズする箇所を探し出して修正ファイルを作り直してやる事になります。