企業ホームページ運営の心得

もしハッキングされたとしたら、Web担当者に欠かせないリスク管理の心得

Web担当者としてのリスク管理の心得について
Web 2.0時代のド素人Web担当者におくる 企業ホームページ運営の心得

コンテンツは現場にあふれている。会議室で話し合うより職人を呼べ。営業マンと話をさせろ。Web 2.0だ、CGMだ、Ajaxだと騒いでいるのは「インターネット業界」だけ。中小企業の「商売用」ホームページにはそれ以前にもっともっと大切なものがある。企業ホームページの最初の一歩がわからずにボタンを掛け違えているWeb担当者に心得を授ける実践現場主義コラム。

宮脇 睦(有限会社アズモード)

心得其の330

ウイルスにハッキングされた

金曜日の昼下がり。週明け締め切りの原稿を書いていると携帯電話が鳴ります。

友人からで「ついているな」と独りごち、私が電話にでた幸運を誉めそやします。なぜなら私は携帯電話を携帯しないことが多く、スーツの内ポケットにいれたまま、3日間放置したことも一度や二度ではありません。会社員時代、営業職にあり、時間も曜日も問わず「着信アリ」だった反動かもしれません。などとわずかな想い出を脇に置き2つ折りのガラケーを開きます。

ウイルスにハッキングされたみたい

久しぶりの挨拶もなく単刀直入に要件が伝えられます。それが本当なら一大事。今回はこのハッキング事件から、すべての「プログラム(ソフト・アプリ)」に通じる心得を紹介します。

まずは範囲の特定から

友人は自社サイトで利用しているアンケートプログラムがハッキングされたといいます。時節柄「何語?(どの国から)」かと尋ねると「いや、文字化け」と回答。とにかくサイトを見てほしいというので、アクセスしてみると過去の設問が確かに文字化けしています。%や\マークに続き英数字が並ぶ様は、正体不明の何者かのアクセスを想起させます。

こうした不測の事態に着手するのは「被害範囲の特定」です。サイトを見回ってみると、改ざん(?)されたのはこのページだけ。するとプログラムの仕組みを読み解かれ、乗っ取られたクラッキングの可能性が高いと見るべき。犯人がサイトのアクセス権限をゲットしたなら、トップページの改ざんなど、もっとわかり易い嫌がらせやイタズラを仕掛けるものだからです。

被害拡大の防止が第一

アンケートはフリーで配布されているプログラムをそのまま設置したものでした。想定外のトラブル発生時、まずはサイトの機能をすべて停止し、原因を追及するのが最適解です。被害の拡大を防ぐことを第一目的とするのです。

とはいえ、サイトのすべてを停止することは困難であることも多く、次善の手としては当該プログラムのみを停止させます。しかし、友人はプログラムの稼働を望みます。ウイルスでないとわかって強気になったのでしょう。そこで手っ取り早い対策が「パスワードの変更」です。

一般論としてのクラッキングは、ユーザーIDやパスワードが特定されて発生します。可能な限り長く、英数字と記号を混在させたパスワードに変更することで、安全性を高めることができます。イタズラ程度のクラックなら、この変更だけで対応できますが、あくまで対症療法にすぎません。

一件落着と思いきや

パスワードを変更し安堵したものの、文字化けした過去の設問を消すことはできませんでした。このアンケートプログラムは、データフォルダ内のテキスト情報、あるいはそのファイル名を「設問」として表示するようになっており、友人の言うところの「ウイルス」によって、文字化けした名前のファイルが数百作成されていたのです。

技術的な話なので割愛しますが、Telnet(ネットワーク上のコンピュータを遠隔操作する仕組み)でアクセスできないレンサバとの契約では手の打ちようがありません。そこで「別ディレクトリ」へ移植する方法を指示し一件落着。

その翌日は土曜日。「あまちゃん」の最終回をBS、本放送、再びBSに戻り、当週の放送分をまとめてオンエアする「あまちゃん一週間」を見終え、ふと気になり友人のサイトにアクセスすると、また始めの「ハッキング」状態になっているのです。今度はこちらから彼の携帯電話を鳴らします。

意外な犯人

パスワードではなくプログラムの構造的な問題の可能性が高まります。パスワードを入力しなくても改ざんできる方法があるということです。そこですぐに停止させます。Perlなら権限の変更ですが、プログラムはPHPで、ここまでご覧いただいた様に、彼に特別な知識はありません。そこで「ファイル名の変更」で対応させます。アンケートプログラムを直撃したということは、その名前を変えるだけで一時的に攻撃を回避できるのです。そしてサーバーへのアクセス権などを提供させ、私が直接対策に乗り出します。

まず「生ログ」を確認します。驚いたことに犯人は「グーグル」の「ボット」でした。「ボット」とは検索エンジンの情報収集プログラムのことで、ボットがアクセスするごとに、文字化けファイルが量産されていたのです。ボットが連れてきた「引数」が犯人だったのです。意図したものではないでしょうが、とにかく発生要件はわかりました。次は原因です。

アンケートプログラムの配布元にアクセスします。グーグルボットが原因なら、どのサイトでも発生する可能性が高く、ならば対応策がでていると考えたからです。最新版に更新することでの解決は、うたかたの夢と消えます。2005年で開発が停止していたのです。

専門家の力

仕方がないのでプログラムを追いかけると典型的な「バグ」が見つかります。パスワードの有無を問わず、ファイル書き込みができるルートがあり、グーグルボットはこのルートをたどっていたのです。このルートを潰して解決です。

オープンソースなど、フリーのプログラムは多くのWeb担当者を助けてくれます。しかし、そこにはリスクがともないます。個人で開発するプログラムは十分なデバッグ(検証と対策)がなされていない場合もあり、個別のサポートも難しいものです。それを回避する簡単な手段は「開発中」「サポート継続中」のソフトを選択することです。利用者からのフィードバックがプログラムを育てます。

これは商用ソフトでも個人の趣味でも同じです。ビジネスとして利用する以上、サービスの継続性やサポートの有無は重要な検討事項です。そして開発停止を宣言すればこの限りではありません。これは本質として来春にサポートが終了となる「Windows XP」にも通じます。

もう1つの対策は「プロ」の手配です。制作会社など、プログラムソースを読め、手を加えることができる専門家を側に置いておくことです。もちろんサポートはタダではありませんから、更新・運用費などとして予算を組んでおく必要があります。タダより高いものはない……とならないようご注意ください。

今回のポイント

すべてのソフトにリスクはつきもの

可能な限り開発を継続している最新版を利用する

用語集
PHP / Perl / アクセス権 / ガラケー / セキュリティ / ディレクトリ / フィード / ボット / リスク / 検索エンジン
この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

TLS
「TLS」(Transport Layer Security)は、Webサイトを ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]