「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目川口洋のセキュリティ・プライベート・アイズ(52)(1/2 ページ)

全国各地から寄せられるセキュリティインシデントに関する相談の中には「これさえ設定していれば軽い被害で済んだのに」「ここだけでも把握できていれば早く対応できたのに」というケースが数多くあります。そうした残念な状況に陥らないようにするための7つのポイントを紹介しましょう。

» 2015年01月26日 18時00分 公開
「川口洋のセキュリティ・プライベート・アイズ」のインデックス

連載目次

相変わらず絶えないセキュリティインシデントに関する相談

 皆さんこんにちは、川口です。大変ご無沙汰しています。久々に書くコラムが、年を越して2015年になってしまいました。今年もよろしくお願いします。

 相変わらず全国各地からセキュリティに関するお悩み相談を受けることが多く、世の中では今も多数のセキュリティインシデントが発生していることを痛感しています。その相談の中には「これさえ設定していればこのセキュリティインシデントでも軽い被害で済んだのに」「ここだけでも把握できていれば早く対応ができたのに」というケースが数多くあります。また、脆弱(ぜいじゃく)なシステムを構築した責任をソフトメーカーに問うような事件も発生し、話題になりました。

 今回のコラムでは、なるべく早くセキュリティインシデントに気付き、速やかに対応できるようにするために、今すぐ皆さんに確認していただきたいポイントを7つご紹介します。ぜひ他人事と思わず、自分や周りのシステムを確認してください。

関連リンク

個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例

http://blogos.com/article/103366/


1. タスクスケジューラーの確認

 タスクスケジューラーは、Windowsを使っている環境では必ず確認してほしいポイントです。最近発生している大規模なセキュリティインシデントでは、ほぼ100%タスクスケジューラーが悪用されています。以下の手順で確認することができます。

「スタート」→「コントロールパネル」→「管理ツール」→「タスクスケジューラ」

 ここでは攻撃の手順については省略しますが、このタスクスケジューラーの登録内容に「見慣れないもの」がないか確認してください。見慣れないものという表現自体があいまいですが、ここに攻撃者が残したおかしなタスクが登録されていることがあるのです。

 確認対象は「全てのWindowsパソコン」と言いたいところですが、台数が多い場合には「Active Directory(AD)サーバー」だけでも確認してください。攻撃者は攻撃対象のシステムを制圧するためにADサーバーを狙ってきます。ADサーバーを管理しているのはシステム管理者でしょうから、タスクスケジューラーの状況を確認することは容易でしょう。

 もし、タスクスケジューラーに見慣れないタスクがあればよく調査をしてください。ここにおかしなタスクがあれば「即・入院」と言ってもいいくらい重大なセキュリティインシデントが発生しています。緊急度を上げて対応してください。

2. 管理者パスワード変更手順の確認

 システムの全権を握る管理者パスワードを変更する際は「どのパソコンから変更作業を行っているか?」を確認してください。侵入した攻撃者が管理者の端末を盗聴して変更したパスワードを盗んでいるケースがあります。

 可能であれば、管理者パスワードはリモートから変更するのではなく、ローカルからコンソールログインして変更してほしいところです。コンソールからの変更が面倒な場合もあるでしょうが、せめて、セキュリティインシデントが発生した後に行う管理者パスワードの変更はコンソールから行ってください。

3. テンポラリフォルダーの中身の確認

 テンポラリに使用されるフォルダーやディレクトリの中におかしなプログラムがないかを確認してください。

%temp% C:\Users\ユーザー名\AppData\Local\Temp
%systemroot% C:\Windows\Temp
Windowsの場合
/tmp
/var/tmp
Linuxの場合

 システムを長期間使用していると、これらのフォルダーやディレクトリにはたくさんのファイルやディレクトリが作成されていきます。このため、確認が難しい可能性が高いのですが、もしシステムに異常を感じることがあれば、これらのディレクトリに見慣れないファイルなどがないか確認してみてください。攻撃者はまず/tmp にファイルをダウンロードして実行することが多いです。

 個人的にはLinuxの/tmpフォルダーは別パーティションにして、nodev、nosuid、noexecのオプションを付けてマウントしたいところです。特に、Webサーバーを公開している場合はお守りのように付けていたりします。

4. ログ保存期間の確認

 システムのログの保存期間がどのように設定されているかを確認してください。システムの特性や各業界の法律などの条件を無視すると、できれば1年分は残しておいてほしいと思っています。これは非常に感覚的な数値ですが、「何かあったときに調査ができるように、せめて1年は残しておいてほしい」という思いからです。それ以上残すことができれば言うことはありません。

 中でも、公開サーバーにLinuxを使用して、特にログ保存期間を考慮していない場合、デフォルトでは1カ月分しかログが残らないことに注意してください。

$ cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
Linuxのログローテーション設定

 上記の設定では、「1週間ごとに、過去のログファイルを4つ保存する」ようになっていますが、それより古いものは自動的に消去されてしまいます。

 セキュリティインシデントが発生してすぐ異常に気付き、調査することができればいいのですが、発見や調査が遅くなった場合、古いログが消えていると原因究明ができず困ってしまいます。システム特性やディスク容量を考慮しつつ、特に制限がないのであれば、上記の設定の「4」というところに「0」を足して、「40」とでもしておいてください。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。