WEBサイトがダウンした時の確認ポイント

サイトダウン時の確認ポイントWEBサイトが突然見られなくなった!ホームページがダウンした!挙動が不安定だ!お客様からホームページが見られないと連絡をいただいた!など、新規問合せをいただくことがあります。そのような時に、確認すべき事は以下です。

  1. 500番や400番などのエラーコード(HTTPステータスコード)確認
  2. .htaccess(apache)やphp.ini、httpd.conf(apache)やnginx.conf(nginx)などで(バーチャル)ホスト設定の確認。
  3. ドメインやサーバー(VPS、クラウド)の契約期限切れ
  4. 直近でマスコミ取材などの高負荷になる原因がないか?社内外の広報系業務全般を振り返る。
  5. ワードプレスなどのCMSやフレームワーク側のログ解析
  6. phpやデータベース(MySQLなど)のログ解析
  7. Linuxサーバー自体のログ解析
  8. DDOS攻撃やセキュリティ脆弱性を突かれた、ログイン突破されたクラッキングなどの可能性
  9. htmlのheadタグ前後にエクスプロイトを埋め込まれていないか?webshellやバックドアなどを仕掛けられていないか?セキュリティ脆弱性を突かれた可能性。

ログ解析は、英数字の超大量羅列を目視で追いながら調べる、機械に対して人手で行うアナログ作業です。有料のログ解析専用ツールなどを使ったり、日頃から監視を行なってデータ蓄積が無い場合、判断しにくい作業となる場合があります。

セキュリティ脆弱性を突かれる原因は、ワードプレス本体(コア)、テーマ、プラグインの更新放置、サーバー内でワードプレスを下から支えるアプリケーションたちの更新(yum update)の放置も原因の一つです。同じサーバーの中で運営している別のWEBサイトに脆弱性があり、別のWEBサイトが受けた攻撃によってサーバー全体で侵食される場合などもあります。その他admin/adminなどのハッカーが試す様な、使ってはいけない危険なログインアカウントを使っていたり、テキスト数が少ないパスワードで辞書攻撃により簡単にログイン突破されたケースなど多岐にわたります。ダッシュボードログインURLをデフォルト状態から変更しておく事は常識です。

HTTPステータスコードについて

パソコンやスマホなどの(クライアント)ブラウザのクリックイベント(動作)などによる命令(リクエスト)信号をサーバー(リモートホスト)が受け取り、ブラウザに命令の処理結果(レスポンス)をサーバー(リモートホスト)が返します。HTTPステータスコードは、レスポンス(サーバーが訪問者のパソコンやスマホに送り返すデータ)の健康チェックバロメーターの様なものだと考えてください。

HTTPステータスコードは、100番台から500番台まであり、基本的に400番と500番がエラーです。ステータスコード確認は、クロームのディベロッパーツール、OWASP ZAP、グーグルサーチコンソール、オンラインツールなど数多くあります。個人的にはクロームディベロッパーツールのNetworkでHeadersをよく使います。200番やgzip圧縮のファイル容量確認など、かなりいろいろな用途で使います。注目すべきはエラーの400番台と500番台です。

403

ブラウザで『403 Forbidden』などが表示される事が多いです。リクエストを受けたファイルなどについて、外部からのアクセス権限をサーバー管理者が認めていない。セキュリティ対策が施された部分などの場合です。サーバー管理者など、サーバー自体にログインできる人がサーバーにログインした後でないとそのファイルを見られない様にするなど、ファイルやディレクトリのパーミッションやファイヤーウォールの設定を疑ってください。パーミッションは、chmodコマンド(アクセス権変更)、chgrpコマンド(グループ変更)、chownコマンド(所有者変更)。ファイヤーウオールはiptablesやfirewalldです。

404

『404 Not Found』などがブラウザに表示されます。リクエストを受け取ったURLのページがサーバー内で探されたけど、見つからなかった場合に帰って来る返事です。SSL化を行う時などは、確実にhttpからhttpsに301リダイレクトを行ってください。

410

『410 Gone』などがブラウザに表示されます。リクエストを受け取ったURLのページはサーバー内で消去されたという返事です。見かける事は少ないです。

500

『500 Internal Server Error』などがブラウザに表示されます。サーバー内のプログラムのバグなどを意味します。

503

『503 Service Temporarily Unavailable』などがブラウザに表示されます。同時アクセスが多過ぎるなど、サーバーに対する負荷が、サーバースペック(処理能力)を越えている状態です。ビジネスの成長限界、見えない成長ボトルネックです。Monitoring Plusなどでネットワークの遅延監視なども行ってみてください。WEBサイトオーナーが知らない場所で知らない人に対して、サーバーが隠れてエラーを吐きます。どんなに素晴らしいコンテンツを書いてもWEBページを見せられなければ無駄になります。ネットワーク遅延の改善とPV向上は、深い関係があります。

契約しているサーバーのネットワーク回線の帯域制限(データ転送量)や月間ないしは1日あたりトラフィック量の確認と計算を行う必要が有ります。安いサーバーは特にトラフィック制限を無断でかけられている可能性も否めません。素人が知らない隠れた真実です。朝の通勤ラッシュで色々な会社へ通勤する人がいますが、御社だけこの道路でやたらと社員が多く渋滞の悪因になっているので、1秒間に通行できる御社の社員の人数を制限します!と言う感じ。最低でもサーバー1台に対して月3000円前後くらいは見越して予算を建ててください。そして、1台のサーバーにWEBサイトを詰めこみ過ぎて挙動が遅くならない様にしてください。

レンタル共有サーバーには、セキュリティ対策、負荷対策、表示速度対策、ネットワーク回線の同時アクセス数限界など、技術的な問題への対応限界があります。

サーバーにお得な買い物はありません。世の中のサーバーはすべて価格相応です。サーバー代をケチる限り、503を乗り越える事は出来ません。キャッシュ活用によるカバーも多少は出来ますが、記事投稿時に毎回キャッシュを削除する手間が増えるなど、キャッシュ活用は運用者側の手間や学習コストも増大します。キャッシュ運用のベストプラクティス模索なども必要になり、ITリテラシーが小さい運用者ほどキャッシュ活用や予算組み(コストへの理解)が難しいです。月3000円程度の費用すら出せない場合、月間20万PV以上などのインターネット集客活用を目指さす事は出来ません。月10万~月20万PVを越えてくると、WEBサイトによるビジネス貢献が顕著になってきます。

WEBサイトダウンの監視方法

サーバーの死活監視(生死監視)などと言われ、PCI DSSなども関連してきます。無料であればMonitoring Plusやアクセスアラームが設定も簡単でお勧めです。集客施策を台無しにしない為にも無料アラートは必ず使ってください。OSSのZabbixを別建てのサーバーにインストールして監視する本格的な方法もあります。最近は、ログ収集活用向けにfluentdなどもあります。

Monitoring Plusはネットワーク遅延系のエラーを見つけてくれるので、WEBサイトオーナーが気付けない致命的な機会損失をあぶりだしやすいです。このあたりのエラーはサーバー代をケチると発生します。日本のIT業界は何でも価格相応で、事業者によって非常によく考えられているのでお得な買い物はありえません。

アクセスアラームは、時間帯別流入数(TOP10)、参照元別流入数(TOP10)、ページ別流入数(TOP10)を毎日メールで決まった時間にお知らせしてくれるので、訪問が集まりやすい記事の傾向などをつかみやすくなります。2サイトまで無料登録出来ます。

サーバーが「踏み台」にされてしまった場合、他人(他者のサーバー)に攻撃を与え、全く見識の無い他人を巻き込むことになります。

ワードプレスのログ確認

FTPではなく、パソコン(クライアント)からSSHでサーバー(リモートホスト)にログインします。クライアント側(自分のパソコン)がWindowsの場合、TeraTerm、Cygwin、putty、git bash、Poderosaなどを使います。Power Shellについては、少しずつLinux向きにMicrosoftが動いており、今後、LinuxをWindowsで使いやすくなる可能性はあると思います。初心者の方は、ググった時の使い方の良質な説明記事がTeraTermには比較的に多いのでお勧めです。

他のCMSやフレームワークでも、ログ確認方法は必ず存在しますり方は個別に調べる必要が有ります)。SSHでサーバー接続した後にワードプレスのディレクトリ(windowsのフォルダは、Linuxではディレクトリと言います)までcdコマンドで進みます。DocumentRootの中のあたりまで進んでください。以下の様にwp-admin,wp-includes,wp-content が配置されているデイレクトリがワードプレスのディレクトリです。ディレクトリ名やファイル名の検索を行う場合、findコマンドを使ってください。

wp-config.php

1台のサーバーで複数のワードプレスを扱っている場合、同じ構成のディレクトリが複数ありますのでwp-content/themesやwp-content/pluginsなどの中身を見ながら、作業対象とするワードプレスWEBサイトのディレクトリであるかどうか確認する事を強くお勧めします。また、wp-config.phpで該当WEBサイトとデータベースアカウントが合致するかどうか確認を行うのもお勧めです。ただ、wp-config.phpは、セキュリティ対策でもう一つ上位のディレクトリ階層に移動してパーミッション(ファイルやディレクトリに対するアクセス権)を400や600に絞っている場合があります。1サーバー内で複数のワードプレスを動かしている場合、作業該当のワードプレスWEBサイトのwp-config.phpであるかどうか見極める事も非常に大切です。MySQLデータベースに接続して記事内容を見るなどの確認方法があります。DBのテーブル接頭辞なども確認の目安になります。

wp-config.phpをAtomやVisual Studio Codeやnotepad++などのutf-8 BOM無し対応エディタで編集

メモ帳でファイルを開くと、ファイルの文字コードの設定が変更され、wp-config.phpが文字化けを起こして、ワードプレスが真っ白画面になるなど、トラブルの原因になりやすいです。メモ帳でソースコードファイルを開いて保存しない様にしてください。文字コードによる文字化けが起きていること自体が「セキュリティ脆弱性」です。ファイル内のコメントは英語で記載して、文字化けが起こらない様にするのも立派なセキュリティ対策です。

wp-config.phpには以下を追記します。※日本語でコメントを入れていますが、文字コードによる文字化けが起こらない様に管理できるという認識のうえで行っています。

そして、ワードプレスによって生成されたdebug.logをcatコマンドやlessコマンドなどで見て各種エラー確認をしましょう。Win SCPやFileZillaなどでダウンロード確認してもいいのですが、量が多いのでダウンロード作業だけで結構な時間がかかります。

この設定をずっと継続すると、ログファイルがサーバー内で無限に増え続けます。

エラー確認が落ち着いたら、wp-config.phpファイルを元の設定に書き直したり、ログローテート設定してください。

サーバーログの確認方法

SSHでサーバー(ホスト)にログインします。cdコマンドを使って/var/logまで移動してください。

※Linux CentOSではなく、Linux UbuntuやLiteSpeedなどのLinuxディストリビューションやサーバー構築者によって配置場所が異なる場合があります。

sshでログインした際のlinuxの一般ユーザーから、rootユーザーにユーザー変更をしないと閲覧できないログファイルがあります。sudo su -などで予めルートに成っておいたほうが楽ですが、サーバーの最高権限者になり全削除のrm -rfコマンドなど何でも出来ますので気を付けてください。

root(ルート)パスワードがわからないと、サーバーの管理者ユーザーに変更できません。rootパスワード再発行には、サーバー再起動が必要など、使っているマシンやクラウド会社、サーバー会社に応じたrootパスワード再発行の作業を行う必要が有ります。Hyper-V、VMware、Xenなど仮想化基盤に採用している技術の種類によってrootパスワード再発行の手順や方法に差があるかもしれません。レンタル共有サーバーの場合、root権限が一般契約者に与えられることはありません、見る事ができるログの種類が制限されています。

catコマンドやlessコマンドなどを使って実際にログを確認し、サーバーに何が起こったのか追及します。色々なログがありますが、下記種類を知っておくといいです。

ログローテーションによって生成されたファイルも周辺に配置されている場合、日付で追う事ができます。基本的にやりたくないですが、生ログを目視で頑張る場合、ApacheLogViewerなどのOSS(Open Source Software)を使います。

問題が起きた際のログ解析は、セキュリティ脆弱性に起因する事もあり、解析も対策も求められる専門度が比較的に高いです。整形外科、消化器内科、精神科の違いの様に必要なスキル範囲の幅が広いため、WEB開発/運営の見積時に、問題が起きたときのログ解析は有料であることを必ず伝えておく必要があります。トラブル対応は解決までの作業量予測が困難なこともあるため、見積計算がわからない方は、税別1分100円などで着地できれば無難です。

金融系システムとログ管理

エンドポイント監視などのログ監視は、予兆をつかみ、侵入検知する等の重要な手掛かりとなります。ログの集中管理は非常に重要なセキュリティ対策の1つです。官庁査察などがある場合、インシデントの重要な証拠となります。SELinuxで防衛しながらlogstash ElasticSearch Kibanaなどを使う事もおすすめです。セキュリティとログは深い関連性があります。

作業や技術の請負範囲ルールや役割分担が非常に大事

作業や技術の請負範囲ルールを決めず、知人から安請け合いの実験台WEB制作を行うと、問題が起きたときに毎回電話がかかってきて、自信が無い受注者の気持ちの隙間にフィットしてしまうと、無料でログ解析まで大量の時間を使って行う破目に陥ります。アホくさい赤字で自分の首を絞める前に、ルール決めは最初に厳格に丁重に行う必要が有ります。契約書はとても大切です。さらに請負ルールが緩く、より安価な開発者に日本国内でプロジェクトの発注先が変わっても、そのプロジェクトはうまくいかないです。ルールが無い理由は、技術と経験の不足だからです。ルールがある=ノウハウや技術の経験がある!win-win-winへの確率が高まる!となります。

発注クライアント先と開発請負元の適当な馴れ合いはダメ

仲良くなって何でも聞いてくるようになり、答えてしまい開発側が無料でがっつり表層レベルの浅いノウハウや時間を奪われるパターンです。作業とナレッジによる商売は価格ラインがあやふやになりやすいため、win-win-winからもっとも遠くなり、プロジェクト破綻のリスクが上がります。最終的にプロジェクト全体で幸せになる人間がどこにも発生しません。WEB開発業界でキャリアを積んだ後の独立起業ではなく、ノウハウや積み重ねが無いWEB開発起業の場合、赤字を出しながら覚える、定番の誰もが通る道です。WEB開発会社の組織化や事業参入障壁の1つです。ログ解析が必要な時=『何かのトラブル』や『セキュリティ向け業務』や『集客マーケティング向け業務』などが多く、解析結果が出てきた後、対策で手間暇必要な新たな作業発生も考えられます。

顧客のITリテラシーが小さいほど、安請け合いの責任範囲と無料コミュニケーションが比例して無制限に大きくなり、赤字になりやすく、win-win-winが遠のく。何でも教えてくれるいい人ではダメです。プロダクトアウトでもマーケットインでも、コンテンツを自主的に読んでもらえる、コンテンツマーケティングによる顧客のITリテラシー育成や顧客絞り込みは、コスパや品質を上げるために非常に大切なことです。

PV上昇/データ(解析)活用/処理速度パフォーマンスなどを考慮したい事業者は、AWSやAzureやGCPやIBMなどのクラウドでIaas(root権限あり)やPaasを選びます。サーバー管理のわずらわしさから解放されたい、でもスケーラブル性やAIやBIによるデータ活用も行いたい、という場合、クラウドPaasを選びます。IT系の投資で失敗経験を持つ顧客や、世の中、何でも学習が必要などの考え方の顧客である場合、同じ失敗を繰り返さない様に、開発者の話をよく聞いて勉強するため、win-win-winになりやすいです。

サーバー選びとSSL選びは密接に結び付いている

ほとんどのレンタル共有サーバーでLet’s Encryptなど無料のドメイン認証SSL(梅)を使える様になってきました。証明書更新の手間や費用が少ないものを選ぶ事をお勧めします。ビジネス向けに有料の企業認証SSL(竹)や有料の最上位のEVSSL(松)を導入出来るレンタル共有サーバーもありますが、サーバーのプラン自体が安い場合、SSLプロバイダの選択肢を縛って料金を高く設定する戦略がサーバー会社の定石です。外注せずに自分の手でサーバー引越を出来る人であれば、コスパが良いVPSへの引越などをお勧めします。個人的には、攻撃遮断くん込のEX-CLOUDのWordpressホスティングがバランス良くてお勧めです。

レンタル共有サーバーで困る事

個人商店などの小規模ビジネスではない、100万PV/月が当たり前の様な、本格的にWEB集客を考えるビジネスには根本的に向いていません。

  • セキュリティ対策のSELinuxを導入出来ない。ワードプレスの場合、SELinux導入後はWP-CLIが必要です。
  • PV上昇に対して自由自在なオートスケーリング(『スケールアウト:サーバー台数増加』、『スケールイン:サーバー台数減少節約』、『スケールアップ:サーバースペックアップ』、『スケールダウン:サーバースペックダウン節約』)が出来ない。
  • ライターによる記事投稿/編集時の表示速度(運営利便性)について、記事やPVが増えてくると非常に挙動が遅くなり、運営障害になる。
  • 同じサーバー内に高負荷な他人のWEBサイトがあると、速度が遅くなる(被害を被る)。
  • SSL会社の選択肢が無い場合がある。企業認証とEV認証がやたらと高い場合がある。下手するとドメイン認証から有料の場合がある。

root権限のパスワードがわからなくなるパターン

前任の担当者が各種のアカウント関連を引き継がなかった。
前任者に責任を問いましょう。専門性云々ではなく、人として無責任です。
サーバーへのssh接続というものがあること自体を知らなかった。
WEB担当者として努力不足です。集客やセキュリティを本気で考える場合に絶対に通る道です。
sshによるサーバー接続の鍵認証方式やコマンドの黒い画面は苦手、いつもftpを使っている。
ネットショップや会員制サイトの様に個人情報や決済を取り扱うサイトの場合、セキュリテイとして最も行ってはいけない。サイト訪問者(顧客)に対する背任行為です。今すぐ、ssh/sftp等に変えてください。情報漏えい裁判で、わかりやすいマイナス要素となります。
外注業者に任せきりで、何かあるたびに全て発注している。
根本的な運用体制から、お金を使って見直しましょう。
レンタル共有サーバーを使っていて、根本的にroot権限の譲渡を受けることが不可能。
隠れたサーバーダウンが無いか?近い将来に大きなアクセス増の可能性は無いか?確認して、必要な場合はサーバーのスケールアップ(スペックアップ)やNginxへの変更、スケールアウト(サーバー台数増加、負荷分散の導入)、DBサーバー分離などを考える必要があります。負荷対策は、クラウドでトリガーを設定してオートスケール(自動スケール)なども可能です。

ログ解析結果に対する施策実施は、技術を持っている業者に任せるべきだと思いますが、WEB担当者ならサイトがダウンした時の原因を特定するためのログ確認手順は知っておくべきです。社内で唯一のWEB担当者が頼りにならない、というのは致命傷です。誰も問題に対応できる人が居なくなり、お金をかけて作った会社のWEBサイトが窮地に追い込まれます。役に立たないWEB担当者には、給与を支払う気が失せます(口には出しませんが)。

会社のホームページやブログサイトなどではなく、会員制サイトやネットショップなど、お金や個人情報を扱うWEBサイトの場合、レンタル共有サーバーではなく、root権限を取得できるVPSやクラウドを使い、SSL(https)の暗号化やクラウド型WAF(IDS/IPS含む)導入、PCI DSS順守範囲の最大化なども行いましょう。当然、普通のブログサイトよりも管理費用は上がります。楽天RMS、アマゾン、ヤフーストアクリエイターPro、カラーミー、MakeShop、BASEなどのモールへの土俵借り出店ではなく、OSS(Open Source Software)開発のオリジナルショップである場合、ネットショップや会員制サイトとしての参入障壁の高さが全く異なり、想像を越える大きな差があるという意識を持っていない方は結構多いです。セキュリティと集客力でモールに依存しない、初期開発費用と時間とシステム永続開発費もソースコード実装に求められる量と質が全く上がり、セキュリテイ責任も増大する為です。

オススメはクラウド活用

Microsoft Azureでは、Azure 診断(仮想マシン)やApplication Insights(Azure Web Service)、アマゾンAWSではCloud Watchなど、いろいろな監視サービスがあります。クラウドサービスを使ってWEB運営を行う場合は、クラウドサービス提供元がIaasやPaasに対して標準提供している監視ツールのクオリティも高く、オススメです。クラウドの場合、監視だけでなくオートスケール(急激な負荷増加に対してサーバーのスペックアップや台数増加を自動で行う)やフェールオーバー(サーバーデータセンターが地震などの災害で停止した場合に、事前に準備しておいた別地域データセンターのサブシステム環境に自動でシステムを引き継ぐ)などもできます。WEBシステムの信頼性確保はビジネスの根幹です。クラウド活用できない企業とクラウド活用できる企業で、ビジネス展開で今後も引き続き大きな差が開き続けます。

データベースやwebサーバーapacheやNginxなどのログ確認なども、追って記載していきます。

コメントを残す