Quantcast
Channel: さくらのナレッジ is_page
Viewing all 325 articles
Browse latest View live

ポートスキャンツール「Nmap」を使ったセキュリティチェック

$
0
0

サーバーの基本的なセキュリティ対策の1つとして重要なのが、ネットワーク内のどのマシンがどのポートでサービスを提供しているのかを把握することだ。このために有用なのが、ポートスキャナと呼ばれるツールだ。本記事ではポートスキャナとして有名な「Nmap」というソフトウェアを使用し、ポートスキャンを行う方法について解説する。

定番のポートスキャナ「Nmap」とは

対象として指定したホストに対してポート番号を変えながらIPパケットを送信し、その反応を調べることでどのポートが外部からアクセス可能なのかを調査する行為をポートスキャンと呼ぶ。Nmap(Network Mapperの略)は、オープンソース(GPLv2ライセンス)で開発・提供されているポートスキャンツール(ポートスキャナ)だ。NmapではOSが提供するソケット機能を利用するだけでなく、ポートスキャンに使用するパケットを独自に生成することで、高速なポートスキャンやファイアウォール/IPS(侵入検知システム)で保護されたサーバーに対するポートスキャンを可能にしているのが特徴だ。また、対象とするホストの挙動からそのOSやバージョンと行った情報を推測したり、稼働しているサーバーソフトウェアの種類やバージョンを取得する、いった機能も備えている。

なお、Nmapには多くのスキャンオプションが用意されており、この中には特殊なパケットを送信して対象ホストの情報を取得するオプションや、発信元を隠してポートスキャンを実行することを可能にするオプション、侵入検知システムを回避することを可能にするオプションなどが用意されている。そのため、悪意のあるハッカーが攻撃対象のホストを調査する、といった用途にも利用できてしまう。他者が管理しているサーバーに対しポートスキャンを行うことは不正アクセスに該当する可能性もあるため、Nmapを利用する際は十分に注意してほしい。

Nmapのダウンロードとインストール

Nmapはマルチプラットフォーム対応が行われており、LinuxだけでなくWindowsやMac OS X、FreeBSDなど各種BSD、Solaris、HP-UXなどの各種UNIXでも動作する。ソースコードだけでなく、WindowsやMac OS X向けバイナリも提供されている。

Linux環境の場合、多くのLinuxディストリビューションで公式パッケージが提供されているので、それを利用するのが簡単だ。たとえばRed Hat Enterprise Linux(RHEL)やその互換OSであるCentOSなどでは「nmap」というパッケージでNmapのバイナリが提供されており、yumコマンドでインストールできる。

# yum install nmap

また、Gtk+で実装されたGUIフロントエンド(Zenmap)もnmap-frontendというパッケージで提供されている。GUIフロントエンドを利用したい場合はこちらもインストールしておこう。

# yum install nmap-frontend

なお、ディストリビューションの公式パッケージとして提供されているNmapは、そのバージョンがやや古いことがある。最新版のNmapを利用したいという場合やLinux以外のプラットフォームでNmapを利用したいという場合、NmapのWebサイト内のダウンロードページで公開されているバイナリやソースコード、ソースRPMを利用してインストールすれば良い。

たとえばWindows環境の場合、ダウンロードページの中頃に「Microsoft Windows binaries」という項目があり、そこにインストーラおよびZIPアーカイブのダウンロードリンクが用意されている。インストーラにはNmapが使用するWinPcap(オープンソースのパケットキャプチャライブラリ)も含まれているので、通常はインストーラを使ったインストールをおすすめする(図1)。また、このインストーラにはNmap本体に加え、GUIフロントエンドの「Zenmap」や各種ツールも同梱されている。

図1 NmapのWindows向けインストーラ
図1 NmapのWindows向けインストーラ

 そのほか、ダウンロードページではMac OS X(x86版)向けのバイナリも提供されている。Mac OS Xユーザーはこちらを利用すると良いだろう。

>>次ページ:Nmapを使ったポートスキャンを行う

おしらせ

banner_vps


脆弱性スキャナ「OpenVAS」でのセキュリティチェック

$
0
0

昨今ではソフトウェアに脆弱性が発見されることは珍しくない。そのため、既知の脆弱性についていかに迅速に対処を行うかが重要となっている。本記事では既知の脆弱性を発見するためのツールである脆弱性スキャナ「OpenVAS」を使ったサーバーのセキュリティチェック方法について解説する。

オープンソースの脆弱性スキャナ「OpenVAS」とは

昨今ではWebブラウザやWebサービスの深刻な脆弱性がニュースとなることも多い。しかしソフトウェアに脆弱性が発見されること自体は珍しいことではなく、深刻なものから軽微なものまでさまざまな脆弱性が毎月のように発見されている。しかし、「バグのないプログラムを作成することは不可能である」と言われているように、ソフトウェアに含まれる脆弱性を事前に見つけ出して取り去ることは非常に困難である。そのため、発見された脆弱性に対していかに迅速に対処を行うかがセキュリティ対策の鍵となる。

脆弱性に関する情報はJPCERT/CCUS-CERTといったWebサイトで公開されている。また、各OSベンダーやソフトウェア開発者らは脆弱性の発見されたコンポーネントに対する対策パッチやセキュリティアップデートなどをリリースしている。これらを定期的に確認して対応することが好ましいのだが、独自にカスタマイズしたソフトウェアを利用している場合や多数のサーバーを管理している場合など、利用しているソフトウェアに関する脆弱性情報の確認が困難な場合もある。このような場合に有用なのが、「脆弱性スキャナ」と呼ばれるソフトウェアだ。

脆弱性スキャナは、対象のマシンに導入されているソフトウェアのバージョンや設定、構成などを確認してそれらに脆弱性がないかどうかをチェックするツールだ。脆弱性スキャナの多くは簡単な操作でスキャンを実行でき、その結果をレポートとして出力する機能を備えている。既知の脆弱性に関する情報を格納したデータベースを用いて脆弱性のチェックを行うという仕組み上、未知の脆弱性については検出できない可能性はあるものの、定期的にスキャンを実行することでセキュリティ対策の不備を発見しやすくなり、セキュリティをより強固にできる。

脆弱性スキャナにはさまざまなものがあるが、今回はオープンソースで開発されている「OpenVAS(Open Vulnerability Assessment System )」を紹介する。OpenVASはかつてオープンソースソフトウェアとして開発・リリースされていたセキュリティスキャナ「Nessus」から派生したセキュリティスキャナだ。Nessusは2005年にリリースされたバージョン3以降、非オープンソースライセンスで提供される商用ソフトウェアとなったが、オープンソースで公開されていたバージョン2系をベースに拡張を続けたものがOpenVASとなる。コミュニティベースで開発され無償で利用できるだけでなく、脆弱性データベースは日々更新が続けられており、開発を支援する独Greenbone Networksによる商用サポートも提供されている。

OpenVASのアーキテクチャと動作環境

OpenVASはユーザーが操作を行うためのクライアントや、実際にスキャン操作を実行するスキャナ、スキャンのための各種設定やデータを管理するマネージャ、サービスやユーザーの管理を行うアドミニストレータといった複数のコンポーネントから構成されている(表1)。

表1 OpenVASのコンポーネント
種別 コンポーネント名 コマンド名 説明
クライアント OpenVAS CLI openvas-cli OpenVASをコマンドラインで操作するインターフェイスを提供する
Greenbone Security Desktop(GSD) gsd OpenVASをGUIで操作するインターフェイスを提供する
Greebone Security Assistant(GSA) gsad OpenVASをWebブラウザベースのGUIで操作するインターフェイスを提供する
スキャナ OpenVAS Scanner openvassd スキャン処理を行う
マネージャ OpenVAS Manager openvasmd スキャナやそのデータなどを一元管理する
アドミニストレータ OpenVAS Administrator openvasad サービスの起動/停止やユーザー管理などを行う

これらはそれぞれ同一のマシンで実行させることもできるし、異なるマシンで実行させることも可能だ。なお、Greenbone Security DesktopおよびOpenVAS CLIについてはLinuxおよびWindows向けのバイナリがリリースされているが、それ以外のコンポーネントについては基本的にはLinux向けとなっている。ダウンロードページではソースコードのほか、CentOS 6およびFedora 15~18、Red Hat Enterprise 6向けバイナリパッケージの入手方法が案内されている。なお、Debian GNU/LinuxやFedoraなどはその公式リポジトリでOpenVASのバイナリパッケージが提供されている。ただし、必ずしも最新のバージョンが提供されているわけではないので、それらを利用する際は注意してほしい。

今回は、CentOS 6.3をインストールした1台のサーバーにOpenVAS ScannerおよびOpenVAS Manager、OpenVAS Administrator、Greebone Security Assistantをインストールし、WebブラウザでそのサーバーにアクセスしてOpenVASの各種操作を実行するという構成で解説を行っていく。

OpenVASのインストールと設定

OpenVASのバイナリパッケージはCentOSの標準リポジトリでは提供されていないため、ソースコードからコンパイルしてインストールするか、もしくはサードパーティのリポジトリを利用してバイナリパッケージをインストールすることになる。バイナリパッケージの入手先やサードパーティリポジトリの利用法はOpenVASのWebサイトで説明されているが、CentOS 6の場合は以下のようになる。

Atomicorpのリポジトリを登録する

OpenVASのCentOS向けバイナリパッケージはAtomicorpというセキュリティ企業の提供するリポジトリ(atomicリポジトリ)から入手できる。atomicリポジトリを利用できるようにするには、http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/(x86_64向け)もしくはhttp://www6.atomicorp.com/channels/atomic/centos/6/i386/RPMS/(i386向け)で提供されている「atomic-release-<バージョン番号>.el6.art.noarch.rpm」という、atomicリポジトリの設定情報が含まれるRPMパッケージをインストールすれば良い。たとえば64ビット(x86_64)環境でatomic-release-1.0-14.el6.art.noarch.rpmをインストールする場合、以下のようにする。

# rpm -ivh http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/atomic-release-1.0-14.el6.art.noarch.rpm

atomic-releaseパッケージをインストールすると自動的にatomicリポジトリが有効になり、yumコマンドでこのリポジトリからパッケージをインストールできるようになる。

OpenVASのインストール

atomicリポジトリでは「openvas」という名称のパッケージでOpenVASが提供されている。このパッケージをインストールすることでOpenVASの利用に必要な一通りのコンポーネントがインストールされる。

# yum install openvas

OpenVASの設定

OpenVASでは、脆弱性情報やそれをテストするための設定情報を「NVT(Network Vulnerability Tests)」と呼ぶ。NVTは日々更新されており、NVT Feedと呼ばれる形式でその更新情報が配信されている。NVT FeedはOpenVASによって無料で配信されており、OpenVASの利用前には更新されたNVTをダウンロードしておく必要がある。また、OpenVASはNVTだけでなくSCAP(Security Content Automation Protocol)という仕様に基づいて記述された脆弱性情報も利用しており、これらのダウンロードやOpenVASを利用するためのユーザー情報の登録なども必要だ。これらは個別に行うこともできるが、openvasパッケージに含まれる「openvas-setup」というコマンドでまとめて実行できる。

# openvas-setup

openvas-setupコマンドを実行すると、まずNVTやSCAPベースの脆弱性情報のダウンロードとアップデートが実行される。この処理には数十分ほどの時間がかかるが、気長に待って欲しい。なお、ここでOpenVASプラグインのアップデートに失敗したという旨が表示されることがある。この場合、openvas-setupコマンドの実行後に後述するプラグインのアップデート処理を実行する必要がある。

# openvas-setup

Openvas Setup, Version: 0.3

Step 1: Update NVT’s and SCAP data
Please note this step could take some time.
Once completed, NVT’s and SCAP data will be updated automatically every 24 hours

Updating NVTs….
Error updating OpenVAS plugins. Please run openvas-nvt-sync manually.
Updating SCAP data…


Updating OpenVAS Manager database….

続いて、WebベースのGUI管理コンソールであるGreenbone Security Assistant(GSAD)の設定が行われる。デフォルトでは任意のIPアドレスからGSADに接続できるようになっているが、特定のアドレスからのみ接続できるように変更することも可能だ。

Step 2: Configure GSAD
The Greenbone Security Assistant is a Web Based front end
for managing scans. By default it is configured to only allow
connections from localhost.

Allow connections from any IP? [Default: yes] ←ここでEnterキーを押す
Stopping greenbone-security-assistant: [ OK ]
Starting greenbone-security-assistant: [ OK ]

次に、GSADの管理用ユーザーアカウントの作成を求められる。ここで作成したアカウントでGSADの設定変更といった管理操作を行うことになる。

Step 3: Choose the GSAD admin users password.
The admin user is used to configure accounts,
Update NVT’s manually, and manage roles.

Enter administrator username: sfjp ←作成するユーザー名を入力
Enter Administrator Password: ←パスワードを入力
Verify Administrator Password: ←同じパスワードを再入力

ad main:MESSAGE:29817:2012-12-27 20h27.09 JST: No rules file provided, the new user will have no restrictions.
ad main:MESSAGE:29817:2012-12-27 20h27.09 JST: User hylom has been successfully created.

続いて、通常の作業に利用するGSADの一般ユーザーアカウントを作成する。認証方法としてはパスワードもしくは証明書が利用できるが、通常はパスワードで問題ないだろう。また、ここでユーザーの権限を変更して実行できる処理を制限することも可能だが、これはGSADの起動後にGUIで設定できるので、ここでは設定していない。

Step 4: Create a user

Using /var/tmp as a temporary file holder.

Add a new openvassd user
———————————

Login : hylom ←作成するユーザー名を入力
Authentication (pass/cert) [pass] : ←「pass」を選択
Login password : ←パスワードを入力
Login password (again) : ←パスワードを入力

User rules
—————
openvassd has a rules system which allows you to restrict the hosts that sfjp has the right to test.
For instance, you may want him to be able to scan his own host only.

Please see the openvas-adduser(8) man page for the rules syntax.

Enter the rules for this user, and hit ctrl-D once you are done: ←Ctrl-Dを入力
(the user can have an empty rules set)

Login : hylom
Password : ***********

Rules :

Is that ok? (y/n) [y]
user added.

以上でopenvas-setupでの初期設定は完了だ。

Starting openvas-administrator…
Starting openvas-administrator:
[ OK ]

Setup complete, you can now access GSAD at:

https://<IP>:9392

この状態でopenvas-administratorおよびgsadは起動した状態になっているので、続いてopenvas-scannerおよびopenvas-managerを起動しておく。

# service openvas-scanner start
# service openvas-manager start

また、OpenVASプラグインのアップデートに失敗していた場合はここでopenvas-nvt-syncコマンドを実行し、プラグインのアップデートを行っておく必要がある。

# openvas-nvt-sync

プラグインのアップデート実行後は、アップデートしたプラグインをロードするためにopenvas-scannerを再起動しておく。プラグインのロードのため再起動には時間がかかる場合があるが、ここでも気長に待って欲しい。

# service openvas-scanner restart

最後に、openvas-managerをいったん停止させた上でデータベースのリビルドを実行し、完了したらopenvas-managerを再起動させておく。

# service openvas-manager stop
# openvasmd –rebuild
# service openvas-manager start

これでNVTのアップデートは完了だ。

Greebone Security AssistantによるOpenVASの操作

OpenVASではコマンドラインクライアント(OpenVAS CLI)で各種設定やスキャン操作を実行できる。また、GUI版クライアントを利用すると各種設定などをより容易に実行できる。ここでは、OpenVASの各種コンポーネントとともにインストールされるWebベースのクライアントであるGreebone Security Assistant(GSA)を使ったOpenVASの操作について説明していこう。

GSAへのログインとローカルホストのスキャン

GSAを稼働させているサーバーの9392番ポートにHTTPSでアクセスすると、GSAのログイン画面が表示される(図1)。

図1 GSAへのログイン画面
図1 GSAへのログイン画面

 ここでopenvas-setupコマンドで設定したユーザー名およびパスワードを入力してログインすると、「Tasks」画面が表示される(図2)。OpenVASではスキャン設定を「Task(タスク)」と呼び、この画面では登録されているタスク一覧が表示される。

図2 GSAの「Tasks」画面
図2 GSAの「Tasks」画面

 初期状態ではタスクは登録されていないので、まずローカルホストをスキャンするタスクを登録してみよう。タスクを登録するには、「Scan Management」メニューの「New Task」を選択する(図3)。

図3 タスクを登録するには「Scan Management」メニューの「New Task」を選択する
図3 タスクを登録するには「Scan Management」メニューの「New Task」を選択する

 「New Task」画面が表示されるので、ここでタスクに関する情報を登録していく(図4)。

図4 「New Task」画面
図4 「New Task」画面

 「Name」および「Comment」には任意のタスク名およびコメントを入力する。「Scan Config」ではスキャン方法を選択できるが、通常はデフォルトの「Full and fast」で良いだろう。「Scan Targets」ではスキャン対象を指定する。初期状態ではLocalhostのみが用意されているはずなので、これを選択する。これ以外についてはデフォルトのままでOKだ。最後に「Create Task」ボタンをクリックするとタスクが作成され、Tasks画面に作成されたタスクが表示される(図5)。

図5 Tasks画面に作成されたタスクが表示される
図5 Tasks画面に作成されたタスクが表示される

 登録したタスクを実行するには、ここで「Actions」列にある三角(Start)ボタンをクリックする。すると「Status」が「Requested」や進捗表示に変わり、スキャン処理が実行される(図6)。

図6 スキャン実行中は「Status」部分に進捗が表示される
図6 スキャン実行中は「Status」部分に進捗が表示される

 スキャンが完了すると「Status」が「Done」となり、また脆弱性が発見された場合は「Threat」の部分にその重大さが表示される(図7)。

図7 脆弱性が発見されるとその重大さに応じて「Threat」項目が変化する
図7 脆弱性が発見されるとその重大さに応じて「Threat」項目が変化する

 ここで「Reports」の「Last」欄にはスキャンを実行した日付が表示されており、これをクリックするとスキャンレポートが表示される(図8)。

図8 スキャンの実行日をクリックするとスキャンレポートが表示される
図8 スキャンの実行日をクリックするとスキャンレポートが表示される

 スキャンレポートには発見された脆弱性がその重大性ごとに表示され、それぞれの説明や対策などの情報も確認できるようになっている(図9)。

図9 スキャンレポートでは検出された脆弱性の情報を確認できる
図9 スキャンレポートでは検出された脆弱性の情報を確認できる

スキャン対象ホストの追加と認証情報を使った脆弱性スキャン

localhost以外のホストをスキャンしたい場合、「Configuration」メニューの「Targets」でスキャン対象となるTarget(ターゲット)を登録しておく必要がある(図10)。

図10 「New Target」画面
図10 「New Target」画面

 ここで「Name」にはターゲット名を、「Hosts」には対象ホストのホスト名を、「Port List」にはスキャン対象とするポートを指定できる。「Hosts」で「From file」を選択し、ホスト名が列挙されたテキストファイルを指定することで複数のホストを登録することも可能だ。必要な情報を入力し、最後に「Create Target」をクリックするとターゲットが追加される。

また、一部のテストでは対象のホストにログインしてセキュリティテストを実行する。このようなテストの実行にはログインに使用するためのアカウント情報(Credential)が必要だが、これについては「Configuration」メニューの「Credentials」から登録できる(図11)。

図11 「New Credential for Local Security Checks」画面
図11 「New Credential for Local Security Checks」画面

 ここで「Name」にはアカウント情報名を、「Login」にはログインに使用するユーザー名を入力する。また、認証にはパスワードもしくはSSHを利用できる。SSHを利用する場合「Autogenerate credential」を選択するとSSH鍵が自動的に生成されて登録されるほか、「Key pair」を選択して公開鍵および暗号鍵、パスフレーズを入力することもできる。これらの情報を入力して「Create Credential」をクリックするとアカウント情報が保存される。作成/登録された公開鍵は、「Credentials for Local Security Checks」の「Actions」列に表示されている鍵(「Download Public Key」)アイコンをクリックすることでダウンロードが可能だ(図12)。

図12 「Actions」列に表示されている鍵アイコンをクリックすると公開鍵をダウンロードできる
図12 「Actions」列に表示されている鍵アイコンをクリックすると公開鍵をダウンロードできる

 また、ここで作成したアカウント情報を使用するはターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定すれば良い(図13)。

図13 ターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定できる
図13 ターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定できる

放置されている脆弱性は意外に多い、ぜひ定期的なチェックを

OpenVASによる脆弱性のチェックを実行することで、気付いていなかった脆弱性を簡単に発見できる。多くのLinuxディストリビューションではデフォルトでセキュリティに配慮した設定が取られていることが多いが、それでも見過ごされていた脆弱性やセキュリティ的に問題のある設定というのは意外に存在する。コマンドラインでOpenVASを操作できるOpenVAS CLIを併用すれば、cronコマンドで定期的に脆弱性スキャンを実行する、といったことも可能だ。ぜひ一度、OpenVASを使って自分の管理しているサーバーのセキュリティを確認してみてはいかがだろうか。

おしらせ

banner_vps

Windowsでも使える脆弱性スキャナ「Nessus」を使う

$
0
0

 管理しているサーバーなどに脆弱性がないかを調べるツールを「脆弱性スキャナ」と呼ぶ。脆弱性スキャナにはさまざまなものがあるが、古くからよく知られているものの1つに「Nessus」がある。今回はこのNessusを使った脆弱性の調査について紹介する。

マルチプラットフォーム対応の脆弱性スキャナ「Nessus」

 Nessusは指定したサーバーに対しポートスキャンや擬似的なアクセスなどを行うことで、サーバーに存在する脆弱性を調査するツールだ。対象とするサーバーが使用しているソフトウェアに既知の脆弱性がないかどうかを調査できるほか、設定ミスや脆弱なパスワードの存在なども確認できる。また、さまざまな形式で詳細なレポートを生成できるのも特徴だ。WindowsおよびMac OS X、Linux、FreeBSD、Solarisというマルチプラットフォームで動作する。

 Nessusはかつてはオープンソースで開発されていたが、バージョン3.0以降は非オープンソースのプロプライエタリソフトウェアとして開発されている。企業などでの一般的な利用には有償のライセンス契約が必要となっているが、非商用の個人利用であれば無料で利用でき、また15日間限定の無料体験ライセンスも提供されている。

 今回はNessusの最新版であるNessus 5(5.0.2)を使用し、Windows環境およびLinux環境から脆弱性スキャンを実行する方法について紹介する。

 なお、無償で利用できる個人向けライセンス(Nessus for Home)はホームネットワークでの利用のみが許可されており、最大で16IPアドレスまでのスキャンしか行えないといった制限があるものの、脆弱性スキャン機能については有償版と同じものが利用できる。また、企業内などで評価目的で利用する場合は15日間利用できる評価用ライセンスが用意されているので、こちらを利用してほしい。

Nessusを利用するためのライセンスを取得する

 Nessus本体は開発元であるTenable Network SecurityのWebサイトからダウンロードできる。ただし、インストール後の初期設定時に同社から取得したアクティベーションコードの入力が必要だ。そのため、事前にこちらを取得しておく必要がある。

 企業内での評価目的であれば、「Nessus Evaluation」ページから評価用ライセンスの申込みが行える(図1)。このとき氏名およびメールアドレス、企業名、電話番号などの登録が必要だ。

図1 Nessusの評価用ライセンス申込みページ
図1 Nessusの評価用ライセンス申込みページ

 いっぽう、家庭内での利用の場合は「Nessus HomeFeed」ページから無償ライセンスを取得できる(図2)。この場合は、氏名およびメールアドレスの入力のみが必須となっている。

図2 Nessusの個人向け無償ライセンス申込みページ
図2 Nessusの個人向け無償ライセンス申込みページ

 ライセンスの申込みを行うと、メールでアクティベーションコードが送られてくる。筆者が試した際は、どちらの場合も申込みを行ってすぐにメールが届いていた。

Nessusのダウンロード

 Nessusのダウンロードは、Tenable Network SecurityのWebサイトから行える。WindowsおよびMac OS X、各種Linux、FreeBSD、Solaris向けのバイナリパッケージが用意されているので、使用したい環境に応じたものをダウンロードする(図3)。

図3 Nessusのダウンロードページ
図3 Nessusのダウンロードページ

Windows環境でのNessusのインストール

 Nessusはマルチプラットフォームに対応しており、WindowsおよびMac OS X、各種Linux、FreeBSDなどさまざまなプラットフォーム向けのバイナリが公開されている。たとえばWindowsの場合、Windows XP/2003/Vista/2008/7の32ビットおよび64ビット版に対応したインストーラが提供されている。利用したい環境に応じたインストーラをダウンロードして実行するだけでインストールが可能だ。

 Windows版Nessusのインストーラは、Windowsアプリケーションで一般的なウィザード形式のものだ(図4)。

図4 Windows版Nessusのインストーラ
図4 Windows版Nessusのインストーラ

 インストール作業は指示に従ってウィザードを進めていくだけで完了する。なお、Nessusはサービスとしてインストールされ、Webブラウザでアクセスしてその操作や設定を行う仕組みとなっている(図5)。

図5 Nessusはサービスとしてインストールされる
図5 Nessusはサービスとしてインストールされる

Linux環境でのNessusのインストール

 Linux環境向けには、各種ディストリビューション向けにrpmおよびdeb形式でバイナリパッケージが提供されている。対応しているディストリビューションはDebian 6.0、Red Hat Enterprise Linux(RHEL) 4/5/6およびその互換OS、Fedora 16~18、SUSE Linux Enterprise 10/11、Ubuntu 9.10~12.04などだ。たとえばRHEL 6互換のCentOS(64ビット)環境では、Nessus-5.2.1-es6.x86_64.rpmというパッケージが用意されている。このパッケージをダウンロードし、以下のようにrpmコマンドでインストールする。

# rpm -ivh Nessus-5.2.1-es6.x86_64.rpm

 このパッケージの場合、Nessusの各種機能は「nessusd」というサービスを通じて提供される。このサービスは自動的には起動しないので、インストール後に以下のようにして起動しておく。

# /sbin/service nessusd start

 なお、nessusdはTCPの8834番ポートで待ち受けを行うので、このポートにアクセスできるようファイアウォール設定の変更も行っておこう。

Nessusの初期設定

 Nessusのインストール後は、まずWebブラウザでNessusのGUI設定画面にアクセスして各種設定を行う必要がある。Windows版の場合、インストールの完了後に自動的にWebブラウザが立ち上がり「Welcome to Nessus!」と書かれたページが表示されるはずだ(図6)。

図6 「Welcome to Nessus!」ページ
図6 「Welcome to Nessus!」ページ

 Nessusの管理画面には通常SSL経由(HTTPS)で接続するのだが、使用する証明書は正式なものではないため、Webブラウザから警告が表示される旨がこのページでは記されている。これを確認したうえで、「here」部分のリンクをクリックすると初期設定を行うための画面が表示される(図7)。

図7 Nessusの初期設定ページ
図7 Nessusの初期設定ページ

 ここで「Get started」ボタンをクリックすると、まずNessusの管理画面にアクセスするためのユーザーアカウントを作成する画面が表示される(図8)。ここで「Login」にはログインに使用するログイン名を、「Password」および「Confirm Password」にそれぞれ同じパスワードを入力して「Next」をクリックする。

図8 アカウント作成画面
図8 アカウント作成画面

 続いてアクティベーションコードの入力画面が表示されるので、ここで先に入手しておいたコードを入力して「Next」をクリックする(図9)。

図9 アクティベーションコード入力画面
図9 アクティベーションコード入力画面

 なお、Nessusは開発元であるTenable Network Securityのサーバーにアクセスしてプラグイン更新を行うが、環境によってはプロクシを経由しないとインターネットにアクセスできない場合もあるだろう。その場合、アクティベーションコードの入力画面で「Optional Proxy Settings」をクリックすることで利用するプロクシの情報を入力できる。

 アクティベーションの完了後、プラグインの更新作業を行う(図10)。ここで「Next: Download plugins」をクリックすると、プラグインのダウンロードが実行される。この作業には数分程度の時間がかかるので注意したい。

図10 アクティベーションコードの登録完了画面
図10 アクティベーションコードの登録完了画面

 プラグインの更新が完了すると、Nessusの管理画面へのログイン画面が表示される(図11)。ここでは先ほど登録したユーザー名およびパスワードでログインが行える。

図11 Nessus管理画面へのログイン画面
図11 Nessus管理画面へのログイン画面

Nessusによる脆弱性スキャンを実行する

 Nessusの管理画面には表1のタブが用意されており、ログイン直後は「Scans」タブの内容が表示されている。

表1 Nessusの管理画面に用意されているタブ
タブ名 操作できる機能
Results スキャン結果の確認やレポートの作成
Scans 実行中/実行待ちスキャンの確認やスキャンの実行
Templates スキャン設定テンプレートの管理
Policies スキャン設定の管理
Users 管理画面のユーザー管理
Configuration 各種設定

 スキャンの実行や管理は「Scans」タブで行える(図12)。

図12 スキャンの実行や管理を行う「Scans」タブ
図12 スキャンの実行や管理を行う「Scans」タブ

 ここで「New Scan」をクリックすると、スキャンの設定を行うダイアログが表示される(図13)。

図13 「New Scan」ダイアログ
図13 「New Scan」ダイアログ

 ここで設定できる項目の意味は表2のとおりだ。

表2 「New Scan」ダイアログでの設定項目
設定項目 説明
Scan Title スキャン一覧画面で表示されるスキャン名
Scan Type 「Run Now」を指定するとすぐにスキャンが実行される。「Template」を選択すると設定をテンプレートとして保存できる
Scan Policy スキャン設定を指定する。スキャン設定は「Policies」タブで設定できる
Scan Targets スキャン対象とするホスト名もしくはIPアドレスを指定する
Upload Targets ホスト一覧が記載されたテキストファイルでスキャン対象を指定する

 Scan Typeで「Run Now」を指定した場合、「Create Scan」ボタンをクリックするとそのスキャンがScansタブのスキャン一覧に追加されると同時にすぐにスキャンが開始され、「Status」にその状況が表示される(図14)。

図14 「Create Scan」ボタンをクリックするとスキャンが実行される
図14 「Create Scan」ボタンをクリックするとスキャンが実行される

 スキャンが完了すると「Results」画面に完了したスキャンが追加され、そこからスキャン結果を確認できる(図15)。

図15 完了したスキャンは「Results」画面からその結果を確認できる
図15 完了したスキャンは「Results」画面からその結果を確認できる

 Results画面に表示されるスキャン結果をクリックすると、そこでまず発見された脆弱性や各種情報の概要が表示される(図16)。

図16 発見された脆弱性の概要(サマリ)ページ
図16 発見された脆弱性の概要(サマリ)ページ

 ここで、中央に表示された棒グラフでは発見された脆弱性や問題点の数を深刻度別に表したものだ。このグラフをクリックすると、発見された脆弱性や問題点の一覧が表示される。

図17 発見された脆弱性および各種情報一覧
図17 発見された脆弱性および各種情報一覧

 また、ここで個別の脆弱性情報をクリックすると、その脆弱性についての詳細が表示される(図18)。

図18 表示される脆弱性の詳細情報
図18 表示される脆弱性の詳細情報

 脆弱性一覧をファイルで出力することも可能だ。左サイドバーの「Export Results」をクリックし、出力形式と出力する情報を選択して「Export」ボタンをクリックすれば良い(図19)。

図19 「Export Scan Results」画面
図19 「Export Scan Results」画面

 たとえばPDF形式で出力されたレポートは図20のようになる。

図20 PDF形式で出力されたレポート
図20 PDF形式で出力されたレポート

スキャン方法の設定

 スキャン方法については「Policies」タブで設定が可能だ。デフォルトでは「External Network Scan」および「Internal Network Scan」、「Prepare for PCI-DSS audits (section 11.2.2)」、「Web App Tests」が用意されている(図21)。

図21 スキャン方法の一覧画面
図21 スキャン方法の一覧画面

 ここで「New Policy」をクリックして新たな設定を作成できるほか、既存のスキャンポリシーをクリックしてその設定を変更することもできる。スキャン設定の変更画面では4つのタブが用意されており、まず「General Settings」タブでは全体的なスキャン動作に関わる設定を行える(図22)。

図22 「General Settings」タブの設定項目
図22 「General Settings」タブの設定項目

 「Credentials」タブではスキャン時に使用する認証/アカウント識別情報などを指定できる(図23)。

図23 「Credentials」タブの設定項目
図23 「Credentials」タブの設定項目

 「Plugins」タブでは使用するプラグインの設定が行える(図24)。

図24 「Plugins」タブの設定項目
図24 「Plugins」タブの設定項目

企業内での利用は有償だが信頼性を重視するなら使う価値あり

 Nessusで検出された脆弱性には無害なものもあり、また誤検出の可能性もある。そのため最終的には人間の手で検出された問題点をそれぞれチェックして本当に問題となるものかどうかを確認する必要がある。あくまでNessusは問題の対象を絞り込んだり、問題となりそうな場所を見つけ出すためだけのもので、ただスキャンを行うだけではセキュリティの向上にはつながらないということを覚えておきたい。

 Nessusは商用利用は有償となるソフトウェアであるものの、その使い勝手はよく、信頼性に対する評価も高い。個人利用であれば無料で利用できるのもメリットだ。まずは自分が管理しているサーバーで試用してみて、そのセキュリティ状況をチェックしてみてはいかがだろうか。

おしらせ

banner_vps

「skipfish」でWebアプリの脆弱性をチェックする

$
0
0

 近年では多くの分野でWebアプリケーションが使われるようになり、大量の個人情報や重要な秘密情報を扱うようなアプリケーションも少なくない。そのため、Webアプリケーションも攻撃対象として狙われやすくなっている。今回はWebアプリケーションのセキュリティ対策として、Googleが公開しているセキュリティ調査ツール「skipfish」を使ったセキュリティスキャンを紹介する。

Webアプリケーションに特化したセキュリティ調査ツール「skipfish」

 今日では、Webブラウザ経由でさまざまな操作を行えるWebアプリケーションが広く浸透している。Webブラウザは最近のほぼすべてのPCにインストールされており、専用のクライアントを用意せずにアプリケーションを操作できるというのがその浸透の理由の1つだ。しかし、Webアプリケーションでは簡単にその一部(HTMLやJavaScript)のソースコードを閲覧することができ、また改ざんや細工を加えたリクエストを容易に送信できてしまう。そのため、設計・実装ミスによって簡単に脆弱性が生まれてしまう。Webアプリケーションに対する攻撃手法として有名なものにはSQLインジェクションやコマンドインジェクション、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)といったものがあり、これらが広く知られるようになった現在では攻撃を防ぐためのなんらかの仕組みが実装されていることが多いが、それが万全ではない場合や、ミスやバグなどによって特定の条件下で脆弱性が発生する場合などがある。

 今回紹介する「skipfish」は、このようなWebアプリケーションの脆弱性の検出に特化したセキュリティ調査ツールだ。Googleが開発・公開しており、実際にGoogle社内でも利用されているという。skipfishではWebサイトに対しクローリングを行ってアクセスできるURLを抽出し、それらに対しさまざまなパターンでのアクセスを行ったり、特定のキーワードや拡張子を組み合わせて問題の発生しそうなURLやリクエストを生成してアクセスすることで調査を行い、その結果をレポートとして出力する。対象とするWebサイトにHTTPでアクセスして調査を行うため、対象を特定のWebアプリケーションに限定せず、どのようなWebサイトに対してでも利用できる。

 調査結果はHTML形式のレポートとして出力され、発見された問題点は「潜在的リスク」ごとに色分けされて表示される。ここで検出された問題点のすべてがセキュリティリスクにつながる訳ではないが、問題を発見するための手がかりとしては非常に有用だ。

 skipfishの特徴としては、独自にカスタマイズされた高速なHTTPスタックによる高いパフォーマンスと使いやすさ、そして有意なセキュリティ調査を行える点が挙げられる。同社が公開しているプロクシ型の脆弱性検査ツール「ratproxy」など、同社が持つセキュリティ技術がskipfishに投入されており、CSRFやXSS、エンコード関連処理による脆弱性、SQL/XMLインジェクションなどさまざまな問題の検出が可能だ。動作環境はLinuxやFreeBSD、Mac OS X、Windows(Cygwin環境)となっている。

skipfishで検出できる問題点

 skipfishで検出できる脆弱性についてはskpifishのドキュメントにまとめられているが、たとえばリスクの高いものとしては次のものが挙げられている。

  • サーバーサイドSQL/PHPインジェクション
  • GET/POSTメソッドのパラメータにおけるSQL風命令の埋め込み
  • サーバーサイドシェルコマンドインジェクション
  • サーバーサイドXML/XPathインジェクション
  • フォーマット文字列に関する脆弱性
  • 整数オーバーフローに関する脆弱性
  • PUTメソッドでのLocations受け入れ

 これらは悪用されるとデータベースへの不適切なアクセスやサーバー上での想定外の処理実行などを許してしまう可能性があり、非常に危険な脆弱性であると言える。また、skipfishでは脆弱性だけでなく予期しないリクエスト結果の検出やSSL関連の不適切な設定、有効でないリンク、サーバーのエラーといった、脆弱性には直接つながらないがWebサイトの管理・運用には有用な情報も検出してくれる。

 なお、skipfishでは直接の脆弱性にはつながらないという理由で、以下の項目については調査を行わない。

  • 暗号化されずにやり取りされるCookie
  • JavaScriptからのCookie読み取り
  • 暗号化されずに送信されるフォーム
  • HTML内のコメント
  • エラーメッセージ内でのファイルシステムのパスや内部IPアドレスの表示
  • サーバーやフレームワークバージョンの表示
  • HTTPのTRACEやOPTIONSメソッドサポート
  • WebDAVなど一部でしか使われていない技術

 これらは通常直接問題になることは少ないが、別のセキュリティ調査ツールでの検出が可能なものもあるため、状況に応じて別のツールを併用することが望ましいだろう。

skipfishのダウンロードとビルド

 skipfishはGoogle Codeのプロジェクトページからダウンロードできる。動作環境はLinuxおよびFreeBSD、Mac OS X、Windows(Cygwin)だ。なお、バイナリパッケージは配布されていないため、各自の環境でコンパイルを行う必要がある。

 skipfishのコンパイルには、OpenSSLおよびPCRE、libidnが必要だ。たとえばCentOSの場合、openssl-develおよびpcre-devel、libidn-develパッケージをインストールしておけば良い。これらが利用できる環境で配布パッケージを展開し、展開先ディレクトリ内でmakeコマンドを実行すればコンパイルが完了する。

$ tar xvzf skipfish-2.10b.tgz
$ cd skipfish-2.10b
$ make

skipfishを使う

 skipfishはコマンドラインベースで操作するツールであり、GUIは用意されていない。skipfishのビルドが完了すると、makeを実行したディレクトリ内にskipfishというバイナリファイルが作成される。skipfishには多数のオプションが用意されているが、最低限必要なオプションは「-W」および「-o」オプションだ。これらを指定してskipfishを実行するには以下のようにすれば良い。

$ ./skipfish -W <キーワード辞書の保存先ファイル> -o <レポートの出力先ディレクトリ> <クロールを開始するURL> [<クロールを開始するURL2> ...]

 まず「-W」オプションだが、これは学習したキーワード辞書の保存先ファイルを指定するものだ。skipfishでは調査対象とするURLを収集するためにWebページをクローリングしていくとともに、キーワードが格納された辞書を利用して生成された未知のURLに対してもアクセスを試みる。

 skipfishにはあらかじめいくつかの辞書がdictionariesディレクトリ以下に同梱されているほか、クローリングに使用したURLやページ内に含まれるURL、文字列などからキーワードを抽出して独自の辞書を生成する機能も用意されている。

 ここで生成された辞書データは、-Wオプションで指定されたファイルに保存される。-Wオプションは必須のオプションであるが、もし辞書を保存したくない場合、「-W /dev/null」、もしくはそれと同じ挙動を行う「-W-」オプションを指定すれば良い。また、存在しないファイルを指定することはできないので、新たに辞書を作成したい場合は空のファイルをあらかじめ作成しておく必要がある。

 レポートの出力先ディレクトリを指定する「-o」オプションも必須である。そのほかのオプションについては、「–help」オプション付きでskipfishを実行することで確認できる(主要なものについては後述する)。

 なお、skipfishでは対象とするWebサーバーに連続してアクセスを行う関係上、サーバーに負荷をかける点には注意したい。フォームへの投稿なども行うため、実際に運用中のサーバーに対して実行することは避けることが望ましい。

使用する辞書を指定する

 skipfishのdictionariesディレクトリ以下には多くのサイトで利用できる汎用性の高いキーワード辞書が付属しており、これを使用することで意図せずに公開されているファイルや不適切な挙動を行うURLを検出できる。

 dictionariesディレクトリに用意されている辞書は、最小限のものに絞った「minimal.wl」および中程度のキーワードを含む「medium.wl」、多くのキーワードを網羅した「complete.wl」、そして拡張子に対するチェックのみを行う「extensions-only.wl」の4つだ。併用する辞書は、-Sオプションで指定できる。たとえばcomplete.wlを使用してスキャンを行うには以下のようにする。

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -o <出力ディレクトリ> <クロールを開始するURL>

skipfishによるスキャンを高速化する

 skipfishでは辞書やサイトから抽出したキーワードからURLを生成してスキャンを行うため、存在しない膨大なURLに対してのアクセスを行うことになる。そのため、辞書やキーワードの利用を制限してスキャンを高速化するためのオプションも用意されている(表1)。ただしスキャンが高速になるということは、そのぶん脆弱性の「発見漏れ」が生じる可能性も高くなる点に注意が必要だ。

表1 キーワードや辞書関連のオプション(抜粋)
オプション 説明
-L サイトコンテンツからのキーワードの抽出を行わない
-Y 辞書から「<ファイル名>.<拡張子>」というURLを生成する際、一部の組み合わせしか使用しない
-W- 抽出したキーワードを辞書へと書き込まない

 たとえば、skipfishのドキュメントでは「もっとも高速だが一般的な用途には推奨できないオプション」として、以下のような「-W-」および「-L」オプションの併用が挙げられている。

$ ./skipfish -W- -L -o <出力ディレクトリ> <クロールを開始するURL>

 このオプションを指定した場合、スキャン時間は短くなるものの、ディレクトリに対する総当たり攻撃が不十分になるという。短時間でスキャンを済ませたいのであればプリセット辞書「extensions-only.wl」もしくは「complete.wl」を使用し、-Yオプション付きでskipfishを実行するのがおすすめだ。

$ ./skipfish -S dictionaries/extensions-only.wl -W <作成する辞書ファイル> -Y -o <出力ディレクトリ> <クロールを開始するURL>

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -Y -o <出力ディレクトリ> <クロールを開始するURL>

 もちろん、-Yオプションを指定すると辞書中のキーワードの一部の組み合わせしか使用されないので、時間的な余裕があるのであれば-Yオプションを使わないほうが好ましい。たとえば以下の例は、指定したWebサイトに対して完全なスキャンを実行するものだ。

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -o <出力ディレクトリ> <クロールを開始するURL>

ログインが必要なサイトに対する調査を行う

 アクセスの際に何らかの認証が必要となるWebサイトに対して調査を行いたい場合、skipfishに認証情報を与えて実行させる必要がある。たとえばBASIC認証を利用している場合、-Aオプションで以下のようにそのユーザー名およびパスワードを指定できる。

-A <ユーザー名>:<パスワード>

 いっぽう、Cookieを使った認証を行っている場合は-Cオプションで以下のようにアクセスの際に送信するCookieを指定できる。

-C <Cookie名>=<値>

たとえば名前が「sid」、値が「foobar」というCookieを利用する場合、以下のように指定すれば良い。

-C sid=foobar

特定のディレクトリを無視する

 Cookieを使った認証を行っている場合、特定のURLにアクセスすると認証が解除されてしまう(ログアウトされる)場合がある。これを防ぐには、-XオプションでそのURLを指定しておけば良い。-Xオプションは指定されたURLを調査対象から外す働きをするオプションだ。たとえば「/logout/」というURLを対象外とするには、以下のオプションを追加すれば良い。

-X /logout/

skipfishのレポートを確認する

 skipfishを実行すると、図1のようにその進捗が表示される。なお、テストで使用したのはさくらの専用サーバ エクスプレスG2シリーズのXeon 4コア仕様(ストレージはSATA)で、ローカルで実行しているWordPressベースのWebサイト(記事数は約400)に対しスキャンを行ったが、スキャンの完了までに約12時間ほどの時間が必要だった。

図1 skipfishの進捗表示
図1 skipfishの進捗表示

 スキャンレポートは、-oオプションで指定したディレクトリ内にHTML形式で保存される(図2)。

図2 skipfishが出力するスキャンレポート
図2 skipfishが出力するスキャンレポート

 レポートには「Crawl results」および「Document type overview」、「Issue type overview」という3項目が用意されている。まずCrawl resultsだが、ここにはサイトに対してクローリングを行っている際に検出された問題点が表示される(図3)。

図3 Crawl resultsにはクロールの際に発見された問題点が表示される
図3 Crawl resultsにはクロールの際に発見された問題点が表示される

 アイコンの色は危険度の高さを表しており、赤が「高リスク」、オレンジが「中リスク」、青が「低リスク」、灰色が「内部的な警告」、緑が「(リスクとは直接関係ないと思われる)情報」となっている。また、「Memo」ではとして発見された問題に関する情報が表示される。

 たとえばこの例の場合、リスクの高い問題は発見されていないものの、XSRF対策がされていない可能性のあるフォームがあることが検出されている。

 次の「Document type overview」では、クロールや辞書によって生成されたURLに対するアクセスに対し、どのようなドキュメントタイプのコンテンツが返されたかが表示される(図4)。

図4 「Document type overview」ではWebサイトが返すドキュメントのタイプが表示される
図4 「Document type overview」ではWebサイトが返すドキュメントのタイプが表示される

 そして最後の「Issue type overview」では、発見された問題点がその種別ごとに表示される(図5)。

図5 「Issue type overview」では、発見された問題点がその種別ごとに表示される
図5 「Issue type overview」では、発見された問題点がその種別ごとに表示される

 たとえばこの例では、危険度高の「Query injection vector」が2件、危険度中の「Directory traversal / file inclusion possible」および「Interesting server message」がそれぞれ2件および4件、そのほか低リスクのものとしてXSRF対策がされていないフォームや外部コンテンツの埋め込みといったものが検出されている。

手軽にWebサイトの問題点を検出できるものの過信は禁物

 skipfishは手軽にWebサイトの問題点を検出できるのが利点である。いわゆる脆弱性の検出だけでなく、キーワード辞書を使ったテストではバックアップファイル(拡張子が「.bak」のファイルや末尾に「~」が付いたファイルなど)の検出、公開状態にあるディレクトリの検出など、よくありそうなうっかりミスによる情報漏洩対策などにも有用だ。Webサイトの問題点というとSQLインジェクションなどの高度なテクニックを利用するものだと思いがちではあるが、このような問題は単純なだけに気がつかないうちに発生している可能性も高いのである。定期的にスキャンを実行して問題がないかチェックすることで、セキュリティに対する意識を高めることができるのではないだろうか。

 ただし、skipfishで検出されたものはそのすべてが必ずしも脆弱性につながるものではなく、誤検出であるものもある。そのため、検出された問題点をそのまま鵜呑みにせず、必ず手作業でのチェックやソースコードなどの確認などを行って本当に脆弱性につながるものかどうかを判断してほしい。

統合監視ツール「Zabbix」によるサーバー監視

$
0
0

サーバーを監視するためのツールにはさまざまなものがあるが、その1つに「Zabbix」がある。Zabbixはオープンソースで開発されている多機能な監視ツールで、設定を容易に行えるテンプレート機能やWebブラウザ上で操作できるGUIが特徴だ。本記事ではZabbixの概要と、ZabbixによるLinuxサーバーの監視方法について紹介する。

テンプレート機能や豊富な監視設定が特徴のZabbix

サーバー運用において重要なのが、サーバーやそこで動作しているアプリケーションが正常に動作しているかを監視することだ。監視方法としてはさまざまなものがあるが、多くの場合専用の監視用ツールを利用するのが一般的である。監視用ツールとしては「Nagios」や「MRTG」などが有名であるが、今回は豊富な監視機能を持つ「Zabbix」という統合監視ツールを使ってLinuxサーバーを監視する方法について紹介しよう。

Zabbixは、ラトビアのZabbix SIAが開発するオープンソースの統合監視ツールである(ライセンスはGPL)。「Zabbixエージェント」と呼ばれるソフトウェアを監視対象にインストールすることで詳細な監視が行えるほか、SNMPを使った監視や監視対象サーバーの各種ポートにアクセスして監視を行うポーリング監視機能も備えている。

ZabbixではさまざまなOSや機器向けの設定項目がまとめられた「テンプレート」が多数用意されており、監視したいサーバーを登録してテンプレートを選択するだけですぐに一通りの監視が行える。監視や設定はWebブラウザを使ったGUIで行えるため、OSやデバイスを問わずに監視や設定作業が可能だ。

Zabbixの構成

Zabbixは「Zabbix Server(サーバー)」および「Zabbix Agent(エージェント)」、そしてWebフロントエンドというコンポーネントから構成されている。Zabbixサーバーは監視および監視データの収集、設定などの管理を行うコンポーネントだ。後述のZabbixエージェントからの情報収集などはこのZabbixサーバーが実行する。

Zabbixエージェントは監視対象とするサーバーにインストールするソフトウェアで、ZabbixサーバーはZabbixエージェントを通じて監視対象サーバーの状態を取得する。WebフロントエンドはPHPで実装されたWebアプリケーションで、Zabbixサーバーが収集したデータを表示したり、各種設定を行う機能を持つ。

今回は監視を行う構成として、図1のような環境を想定している。ここではZabbixサーバーとWebフロントエンドを同じサーバー上で動作させているが、これらを別のサーバーで動作させることも可能だ。

図1 Zabbixによるサーバー監視構成例
図1 Zabbixによるサーバー監視構成例

 なお、以下では監視対象サーバーおよびZabbixサーバーのOSにRed Hat Enterprise Linux(RHEL) 6.4互換のLinuxディストリビューション「CentOS 6.4」を使用して環境構築方法を紹介している。

>>次ページ:Zabbixのインストール

おしらせ

banner_writer

柔軟なログ収集を可能にする「fluentd」入門

$
0
0

複数台のサーバーやクラウド環境を組み合わせてのサービス運用においては、ログの収集方法に工夫が必要となる。こういった場合に有用なのが、さまざまなログの収集手段を提供するfluentdだ。今回はfluentdのアーキテクチャやそのインストール/設定方法、基礎的な設定例などを紹介する。

さまざまな方法でログを収集できるfluentd

今回紹介するfluentdは、Treasure Dataが開発するログ収集管理ツールだ(図1)。オープンソースで公開されており、Linuxや各種UNIXで動作する。

図1 fluentdのWebサイト
図1 fluentdのWebサイト

 ログ収集のためのソフトウェアとしてはsyslogdやsyslog-ngなどが有名だが、fluentdがこれらと異なる点としては、以下が挙げられる。

さまざまなソースからのイベントをさまざまな媒体に出力できる

fluentdの大きな特徴としては、ログの収集方法やログの記録先などを柔軟にカスタマイズできる点がある。

一般的にログ収集ソフトウェアは何らかの「イベント」を検知し、その内容を発生時刻などの情報とともにファイルやデータベースなどのストレージなどに出力する、という処理を行うが、fluentdではイベントの受け取り(input)およびストレージなどへの出力(output)がすべてプラグインとして実装されている(図2)。

図2 fluendのアーキテクチャ。ファイルやアプリケーションなどのイベントソースから受け取ったイベントが集約され、条件に応じてさまざまな出力先に出力される
図2 fluendのアーキテクチャ。ファイルやアプリケーションなどのイベントソースから受け取ったイベントが集約され、条件に応じてさまざまな出力先に出力される

 inputプラグインについてはsyslog互換プロトコルやMessagePackベースの独自プロトコル、HTTPのPOSTリクエスト、Unix Domain Socketなどを使うものや、任意のテキストファイルを監視してそこにテキストが書き込まれたらそれをイベントとして受け取る、といったものなどが用意されている。outputプラグインについては標準出力への出力やテキストファイルへの書き出し、MongoDBへの書き込み、任意のコマンドを実行してそこにログデータを渡す、といったものが用意されている。

また、サードパーティによって開発されたプラグインも多く公開されており、さらに自分でプラグインを作成することも可能だ。fluentdやそのプラグインはRubyで実装されており、Rubyの知識があれば比較的容易にfluentdの機能を拡張できる。

ログの種類はタグで管理される

fluentdでは、ログの管理を「タグ」と呼ばれる情報で管理する。タグはイベントを発生させる側やinputプラグイン側で任意の文字列を指定できるが、以下のように「.」を使った階層構造を取るのが一般的だ。

<親タグ名>.<子タグ名>

「foo.bar.hoge」のように3階層以上の構造を持つタグを指定することもできる。

ログの内容はJSON形式

fluentdではログの内容(レコード)がJSON形式になっている。そのため、アプリケーション側でのパースが容易であるというメリットがある。最近ではMongoDBなどのJSON形式をネイティブで扱えるデータベースも登場しており、これらと組み合わせることでデータの解析などがやりやすくなる。

さまざまな言語向けのモジュールが提供されている

fluentdでは、イベントを送信するためのモジュールがさまざまな言語で用意されている。公式のものとしてはRubyやJava、Python、PHP、Perl、Node.js、Scala向けのモジュールが提供されているほか、サードパーティによってこれ以外の言語向けのモジュールも開発されている。これらを利用することで、独自のアプリケーションのログをfluentd経由で簡単に記録させることができる。

fluentdが適している分野

fluentdはさまざまな環境で利用できるが、やはり多く使われているのはWeb関係の分野だろう。たとえば、一定以上の規模のWebサービスではロードバランサを使ってリクエストを複数台のWebサーバーに分散させる構成が一般的だ。このような構成の場合、fluentdを使ってWebサーバーのアクセスログを処理することで、ログを1つのデータベースに集約することが可能になる。

また、アクセスログに加えてWebアプリケーションから直接fluentdにログを記録させることで、より粒度の高いロギングが可能になる。

クラウド環境においてもfluentdは有用だ。クラウドサービスで提供される仮想マシンでは、ストレージの永続化がサポートされていない(サーバーを停止/再起動させた際にストレージがクリアされる)ことも多い。そのため、各種ログは仮想マシン外の永続的ストレージに記録する必要がある。fluentdを利用すれば、外部ストレージへのログ記録と複数サーバーのログ集約が容易に行える。

>>次ページ:fluentdの設定手順

おしらせ

banner_vps

あなたのサーバは大丈夫?Shellshock対策をしましょう

$
0
0

9月下旬に発覚したbashの脆弱性Shellshock。自分のサーバは関係ない、そのままでも大丈夫と思っていませんでしょうか。最近のサーバに対する攻撃はほぼ自動化されており、手当り次第に攻撃を仕掛けてきます。

もちろん大手のサービスは狙われやすいですが、そんなことのないごくごく小さなサービスを運営しているだけでも狙われる可能性は十分にあります。対策は難しくありませんので、以下の内容を参考に確認、対策をしてください。

対象

さくらインターネットの下記サービスを利用されているケースにおいて、対策が必要になる可能性があります。

  • さくらのVPS
  • さくらのクラウド
  • さくらの専用サーバ
  • 専用サーバ
  • 専用サーバPlatform Ad/St

bashがインストールされている場合は対象になりえるので、Windows Server以外はほぼほぼ全てのサーバが対象と言えます。

確認方法

全てのサーバが対策が必要という訳ではありません。その確認方法を紹介します。今回はさくらのVPSを使ってみます。

さくらのVPSトップページ
さくらのVPSトップページ

さくらのVPSトップページを表示します。左側にあるリモートコントロールをクリックします。

リモートコントロール
リモートコントロール

黒い部分をクリックして、エンターキーを押します。

ログイン
ログイン

ログインはそれぞれサーバインストール時に設定されていると思います。管理者権限(rootなど)があるユーザでログインします。ログインできると、

[root@www9999 ~]#

といったような文字が一番下に出るかと思います。

ログイン完了です
ログイン完了です

ログインしたら、次のコマンドを入力してエンターキーを押します。

env x='() { :;}; echo this bash is vulnerable' bash -c :

via Bash – shellshockのテストスクリプトがUnix的でないので改善してみた。 – Qiita

もし、

this bash is vulnerable

と出たら脆弱性があります。何も出なければ問題ありません。

もし脆弱性が確認されたら

そのまま放置しておくと危険ですので、OS(Linuxディストリビューション)ごとに対応を行います。

Redhat Linux/CentOSの場合

管理者権限(rootなど)において次のコマンドを実行します。

yum update bash

Debian/Ubuntuの場合

管理者権限(rootなど)において次のコマンドを実行します。

apt-get update
apt-get upgrade bash

その他のLinux/Unixの場合

パッケージ管理されていない場合は、bug-bash (thread) などを参考にbashにパッチを当ててください。

確認

対応が終わったら先ほどの

env x='() { :;}; echo this bash is vulnerable' bash -c :

を実行して何も文字が出ないことを確認してください。


サーバのセキュリティ問題は、自分たちのサーバが乗っ取られたり、データを削除される怖さもありますが、それ以上に乗っ取られることで他者のサーバを攻撃する踏み台にされる可能性があると言うことです。

万一データが消えても惜しくないから放っておくというのは危険で、加害者にならないためにも早めの対応を行わなければなりません。こちらの記事を参考にぜひ早めの対応をお願いします。

【重要】GNU bash の脆弱性に関する注意喚起 | さくらインターネット

サーバー監視、セキュリティのトレンドなど最新の話題がいっぱい! 「第23回さくらの夕べin大阪」レポート

$
0
0

2015年2月27日に、大阪で開催された「第23回 さくらの夕べin大阪」に参加してきました。
大阪では半年ぶりの開催で、100人近い方々が参加されました。
今回は、株式会社はてな(以下、はてな)のサーバー管理サービス「Mackerel(マカレル)」や、ウェブペイ株式会社の決済サービス「WebPay」についてご紹介します。

はてなCTO 田中慎司

「Mackerelによる簡単サーバー管理入門」

はてなのCTO、田中慎司さんに「Mackerel」を紹介していただきました。Mackerelは、はてなが2014年9月にリリースしたクラウド型(SaaS)のサーバー管理ツールです。

はてなCTO 田中慎司

サーバーを複数管理している個人や会社にとって、サーバーの管理や運用などの手間は面倒だし煩わしいものです。できれば、サーバーの保守にはあまり手間をかけたくないでしょう。
そんなニーズにマッチするサービスがMackerelです。
Mackerelはクラウド型のサービスなので、インストールの手間がパッケージソフトに比べて少なく、比較的簡単に始めることが可能です。サーバー群を一括で監視できるので、運用や保守にかかる人件費を削減できます。

いままでにも「Zabbix」や「Nagios」といったオープンソース型のサーバー監視ツールはありました。しかしインストールや設定が複雑で、それなりに運用の知識が必要であり、導入に時間がかかったり、あまりインターフェースが洗練されていなかったりという課題がありました。
また、「サーバー監視をするためのサーバー」が必要という問題点もあります。
クラウド型サービスのMackerelは監視サーバーを自前で用意する必要がなく、ユーザーが所有する、監視したい対象の各サーバーにAgentをインストールすることで、サーバーを監視できます。

現在のところ、Mackerelが対応している監視対象のサーバーOSは以下のとおりです。
・CentOS 5/6
・Debian 6/7
・Windows(アルファ版)
・Mac
・ARM版

監視できるリソースは、CPUメモリ使用率ロードアベレージなどです。それに加えてJVMAWS RDSELBの状況も監視できます。サーバーの資源だけではなく、例えばWebサーバーのアクセスごとのステータスコード(404 not foundの数)などもカウントしてグラフ化できます。
サーバー異常時にアラートを送る宛先は、メール、Slack、HipChat、Webhook、Chatworkを指定できます。
監視対象のサーバーが複数になる場合、それぞれのリソースは積み重ねグラフとして表示できます。
ある日、監視対象のサーバー群の1つを廃止しても、そのサーバーのリソースグラフが全部消えてしまうことはなく、履歴として残るので、サーバー全体としてどれだけのリソースが減ったかの差分を視覚的に確認することができます(オートスケール対応)。

おもしろいと思ったのは、埋め込みグラフ機能です。
Mackerelの管理画面では、もちろん監視対象のすべてのリソースグラフを見ることができますが、特に注意して見たいグラフを別のページに埋込表示させることができます。
例えば特定のサーバーのリソースだけをチェックしたいとか、あまりサーバーのことがわからない上司にロードアベレージだけを見せるといったプレゼンをするときに便利ですね!

Mackerel 埋め込みグラフ機能

Mackerelは毎週のように新しい機能をリリースしており、どんどん進化していますので、今後のパワーアップが楽しみです。

Mackerelについては去年のさくらの夕べでも、はてなの田中さんに登壇していただいています。こちらも合わせてご覧ください。
はてなの田中CTOがMackerelを語る!第18回さくらの夕べ 開催レポート

「クレジットカードのためのセキュリティ標準入門」

次はウェブ決済、アプリ決済サービスの「WebPay」を運営するウェブペイ株式会社(以下、ウェブペイ)CEOの久保渓さんのお話です。

ウェブペイ株式会社 久保渓

WebPayの最近のニュースと言えば、2014年2月に「LINE Pay」がウェブペイを100%子会社化したことが話題になりました。

[参考]LINE、決済サービスを提供するウェブペイを買収

巨大なユーザー数を抱えるLINE PayにWebPayの技術が使われることで、今後、WebPayプラットフォームが大きく飛躍することが予想されます。

最近では、サービスが稼働しているシステムが外部から攻撃されたり、セキュリティの不備を突かれたりすることによる個人情報の漏えい事件が世間でたびたび発生しています。
特にクレジットカード番号は、守られるべき情報として厳重に管理されなければなりませんが、カード番号の漏えいも実際に起こり、賠償問題に発展しています。しかしネットショップやアプリなどのサービスを提供する立場としては、顧客の個人情報を厳密に管理することは工数もコストもかかる問題です。セキュリティを高めることだけに腐心していれば競争力のあるサービスが作れなくなり、経営の体力がどんどん失われていきます。
そこで、セキュアでコストパフォーマンスの良い決済サービス事業者とうまく連携して、自社では顧客のクレジットカード番号を保管しないソリューションが登場しています。
WebPayは2013年にサービスを開始して以来、高度なセキュリティの確保とサービス開発者にとって実装しやすいAPIを提供することで、人気上昇中の決済サービスです。

今回初めて耳にしたのですが、クレジットカードを扱う業者に対して、PCI DSSというセキュリティ基準があります。
PCI DSSは300以上ものチェック項目があり、例えば「データセンターに監視カメラを設置すること」「ネットワークは適切にセグメント化されること」「通信を暗号化すること」など、項目の一つひとつはかなり具体的です。

本来ならば、決済事業者だけでなく、ネットショップなどのクレジットカードを取り扱う会社もこのPCI DSSに準拠していることが望ましいのですが、現実的にはこの膨大な数の基準項目に一般の企業が対応するのは困難です。
それならば、逆に「決済にクレジットカードを使うWebサービスやアプリは、生のクレジットカード番号を扱わずに決済すればよい」という発想で、生のカード番号はサービス提供者では取り扱わず、WebPayがカード番号を管理するという仕組みを構築しています。
ネットショップなどサービス提供者は、カード番号の代わりにランダムな文字列を並べたトークンで決済をやり取りします。

WebPayのトークン決済

実際にカード番号漏えい事件が発生しているのは、ほとんどのケースがPCI DSSに準拠していない通信経路上やサーバーからの漏えいであり、その危険な部分をトークンに置き換えられるというのは安全な取引をする上で大きな意味を持ちます。

余談ですが、久保さんが語ってくれたクイズは興味深いものでした。
ユーザーのクレジットカードを表示する場合は、マスクするべきなのは上位12桁で、実番号は下4桁を表示するのがクレジットカードのレギュレーションだそうです。
もし、あなたが開発にかかわっているサービス内で、顧客のカード番号を隠して表示していても、それが下4桁以外であれば、カード情報が漏えいしてしまう可能性があるのでご注意ください!
逆に、あなたのサービスがレギュレーションに準拠して、カードの下4桁のみ表示していても、上位12桁を明らかにしている別のサービスを同じユーザーが使っていれば、組み合わせで16桁すべての番号が漏えいしてしまいます。

クレジットカードの一部を隠す表示方法1クレジットカードの一部を隠す表示方法1

WebPayについては、ウェブペイCTOの曾川さんが、さくらのナレッジに寄稿されているので、興味がある方はそちらもご覧ください。
2014/7/24 決済にまつわるセキュリティの話 第1回 クレジットカードセキュリティ入門
2014/11/11 決済にまつわるセキュリティの話 第2回 PCIDSS取得のためのクラウド選定

「さくらのクラウドのサービス紹介」

さくらインターネット研究所 所長の鷲北 賢さんに、さくらのクラウドのサービス概要を紹介していただきました。

さくらインターネット研究所 所長 鷲北

さくらのクラウドは、さくらのVPSをさらに進化させたサービスで、2011年から運用が開始されており、さくらのVPSと同様に開発者志向でシンプルなものになっています。
さくらのクラウドではVPSと違って、たくさんのサーバーを追加したり削除したりすることが容易にでき、サーバーのCPU数、メモリ、ストレージのサイズをあとから変更することもできます。
将来的にスケールアウトするかもしれないサービスならば、VPSよりも、さくらのクラウドを選んでおけばサーバーの性能をあとから強化できるので安心です。
クラウドのサーバーは北海道・石狩のデータセンターで運用されており、「インスタンス」という言葉よりもサーバーという概念を大切にしたいという考えだそうです。実際に物理的なサーバーを操作するイメージのサービスにしたかったからとのことです。
さくらのクラウドでは、スペックに応じていろいろな料金プランがありますが、一番安い1コアでメモリ1GBのプランが月額1,954円です。さくらインターネットが主催するイベントでは、よく2万円分のクーポンがもらえるので、10カ月くらいは無料で使うことができ、おすすめです。

サーバー自体のサービスのほかに、別のサービスとの連携ができるのも興味深いところです。
さくらのクラウドのサービス内だけでなく、石狩データセンターに存在する専用サーバーやリモートハウジングのサーバーとレイヤー2レベルの接続ができるので、セキュアなネットワーク環境を構築できます。
サーバーの起動や停止、プラン変更などの基本的な操作は、さくらのクラウドコントロールパネルから行うことができます。APIも提供されているので、コマンドラインからサーバーを起動・停止したり、プランを変更したり、コントロールパネルでできることと同様の操作が可能です。
Sandbox機能があるので、試しにサーバーを作ったり消したりすることができます。また自作のスタートアップスクリプトをサーバー作成時に動かすことで、自分に必要なアプリケーションがインストールされたサーバーを作ることもできます。
VPCルータ機能では、VPN接続などのセキュアな方法で遠隔地からさくらのクラウドのサーバーに接続することができます。

ネットワークの構成は以下の写真のようにグラフ表示でき、マウスのドラッグ&ドロップで線をつないだり付けかえたりできるのは便利ですね。直感的でわかりやすいサーバー管理ができそうです。

さくらのクラウド 直感的で分かりやすいネットワークグラフ

最近では、さくらのクラウドの1つのアカウントについて、複数のユーザーを登録して運用できる仕組みを導入したそうです。

さらに、2015年3月1日から、オブジェクトストレージのサービスをリリースしています
AmazonのS3互換サービスになっており、さくら内のサービスから利用する限りは転送量課金が無料となっています。

サーバーのデータバックアップによさそうですね。

さくらのオブジェクトストレージ

懇親会

1時間半で3名の方にお話しいただいたあとは隣りの部屋で懇親会が開催されました。
懇親会は1時間ちょっとの短い時間でしたが、多くの参加者で賑わい、参加者のライトニングトークもあり盛況でした。
参加者の方に感想を聞いたところ、「本日登壇された、その道の有名な方と直接お話ができ、名刺交換させていただけたのでうれしかった」という声をいただきました。
私自身も多くの方と名刺交換や交流ができて、とても有意義でした。

さくらの夕べin大阪 懇親会

「さくらの夕べ」は大阪だけでなく、東京やその他の地域でも開催されています。今後のイベント予定はさくらインターネット広報のtwitterアカウント@sakura_prをフォローしてチェックしましょう!


決済プラットフォームでイノベーションを起こす!急成長中のサービス「WebPay」とは

$
0
0

2015年2月27日に行われた、「さくらの夕べin大阪」で登壇いただいた、ウェブペイ株式会社(以下、ウェブペイ)CEOの久保渓さんに別途時間を作っていただき、「WebPay」やさくらインターネットとのかかわりについてインタビューしました。
聞き手はさくらインターネット広報宣伝室の林さんです。

ウェブペイ株式会社の久保さんと曾川さん

ウェブペイ株式会社の久保さんと曾川さん

ウェブペイって、何をしている会社なのですか?事業をおこしたきっかけは?

ウェブペイは2013年に「WebPay」という決済サービスを始めたばかりの、比較的新しい会社です。その前は、米国のシリコンバレーでサーバーのホスティング会社を3年ほどやっていました。当時は日本向けのクレジットカードの課金ロジックを実装するときに、既存の決済サービスの難しい仕様やAPIを理解しなければならず、開発に多くの時間を要していました。決済サービスはもっと簡単に実装できるようになるはず、そのためのサービスを作って、開発者がもっと簡単に決済サービスを組み込めるようなプラットフォームを提供したいと思ったのがウェブペイという会社を作ったきっかけです。

ウェブペイ株式会社 久保渓さん

ウェブペイ株式会社 久保渓さん

WebPayは主にWebサービスの提供者モバイルアプリの開発者に向けて、簡単に決済サービスを実装できるようにシンプルなAPISDK(開発キット)を提供し、従来よりも高速かつ簡単に決済サービスを組み込めるようにしたものです。
すでにクラウド会計ソフトの「freee」や、スマホの写真を簡単に郵送できるサービス「レター」などのサービスの決済ツールとして利用されており、現在もWebPayを採用する企業やサービスがどんどん増えている状況です。

最近は個人情報などに対するセキュリティ意識が高まる一方、それらを扱う企業では外部からの攻撃や社内での運用ミスによる情報漏えいが少なからず発生しています。決済サービスを担う者は単に開発しやすいプラットフォームを提供するだけでなく、安全に取引・決済できるよう、重要なデータを適切にやりとりしたり保管したりしているという保証や安心をユーザーに与えなければなりません。クレジットカードで物を買うとき、生のクレジットカードのデータを通信経路上で何回も無駄にやりとりしないようにしたり、Webサービス提供者やアプリのサーバー上など必要のない場所にカード情報を残したりすることがないように、サービス提供者とWebPayサービスの間の橋渡しをするAPIをうまく設計しています。これにより従来の決済サービスより安全な取引ができるようになっています。

参考:2/27に大阪で開催されたさくらの夕べのレポートにも関連記事があります。
サーバー監視、セキュリティのトレンドなど最新の話題がいっぱい! 「第23回さくらの夕べin大阪」レポート

以前、私たちが取引をしている会社から、「自社の個人情報が漏えいした」と一報を受けたことがありました。調べてみたところ、住所や氏名などの情報は残念ながら漏れていましたが、クレジットカードの生データは漏れていませんでした。これはWebPayを通した決済において、直接クレジットカード情報をやりとりするのではなく、その代わりとなるトークンで決済のAPIを使う仕様になっているため、顧客のサーバーに生のカードデータが保管されていなかったからです。

先日、LINEによるウェブペイの完全子会社化が発表されましたが、そのことについて詳しく教えてください

参考: LINE、決済サービスを提供するウェブペイを買収

以前から、LINE社への個人的なつながりはあって、「一緒に何かやれたらいいね」という感じで話はしていました。
協業について具体的な話があったのは数ヵ月前からで、2015年2月10日に正式発表させてもらいました。
ウェブペイはまだ始めたばかりの会社で、人数もあまり多くないので、しっかりとした経営基盤を持つLINE社のバックアップを受けることはとても大きな意味を持ちます。
また、巨大なユーザーを持つLINEの決済プラットフォームにウェブペイの技術が組み込まれれば、私たちが設計した決済フローをより多くの人に使ってもらえることになるので、それが世間一般の標準仕様に発展できればうれしく思います。

パソコンでコミュニケーションしたり物を買ったりする時代が過ぎて、人はより多くのことをスマートフォンだけで済ませてしまう時代になってきています。しかしクレジットカードで物を買うとき、スマートフォンの小さい画面でカード番号を入力したり自分の名前を入力したりするのは面倒に感じる人も多いでしょう。そんな煩わしい手順ではなく、もっと簡単に決済できる仕組みをWebPayは追求していきたいし、LINEとの協業で、もっと決済が身近に感じられる仕組みを作っていけたらいいなと思っています。

WebPayはさくらのサーバーを使っているそうですが、どういったところにメリットを感じていますか?

ウェブペイを立ち上げる前から、さくらのサーバーを利用していたので、WebPay事業を始めるにあたって、引き続きさくらのサーバーを使うことは自然な流れでした。
現在は「さくらのVPS」、「さくらのクラウド」、「さくらの専用サーバ」を使っていますが、他社と比べてコストパフォーマンスの良いのが魅力です。
私たちが手がける決済サービスはもちろんコスト競争力がないといけません。経費としてかかるサーバーの費用を抑えることは、私たちのサービスを低価格で提供するためにも非常に重要なことです。

とはいえ、AWSなど他社のサーバーも併用しています。ストレージの暗号化やキーマネジメントシステムなど、AWSの方が便利に使える部分についてはAWSを使用していますが、それ以外の部分ではコストパフォーマンス的に有利なさくらのサーバーを使っています。用途によって最適なサーバーを使い分けているわけです。

さくらインターネット広報宣伝室 林

さくらインターネット広報宣伝室 林さん

逆に、さくらに関して「もっとこうなってほしい」と思う点はありますか?

PCI DSS(Payment Card Industry Data Security Standard)というクレジットカード業界のセキュリティ基準があります。これは、VISAやマスターカードなどクレジットカード会社5社が合同して作ったセキュリティ基準で、例えば以下のような300以上のチェック項目が記載されています。

・機密情報を扱う施設には監視カメラをつけること
・ネットワークをセグメントで分けるなど適切に区画すること
・オフィスへ出入りする人の入退室記録をつけること

この基準に準拠していれば、そのサービスはクレジットカード情報などを適切に保全できるサービスとして認められます。米国では、この基準に準拠することが州法で義務化されている地域もあります。
また、この基準はクレジットカードに限らず、一般的なセキュリティ基準として、さまざまな施設やサービスに対して適用できるので、サーバーホスティング会社などでも準拠の動きが広がっています。
さくらインターネットもこの基準に準拠していただければ、その上で展開している私達のサービスもよりセキュアで安全なものになりますので、ぜひ準拠することを検討していただきたいです。

参考:PCI DSSに関する、ウェブペイCTO曾川さんの記事を以前に掲載しているのでこちらもあわせて御覧ください。
決済にまつわるセキュリティの話 第1回 クレジットカードセキュリティ入門

日本特有の法規制とか、手続きについて煩わしいと思ったことはありませんか?

守るべき日本特有の法律や規制はあると思います。一般的には規制緩和が叫ばれている風潮ですが、私たちが親しくしている社外のエキスパートに助けられて、法基準や課題を1つひとつクリアしています。私たちの立場としては、サービスとして厳密な個人情報を扱うわけですから、なんでも規制緩和すればいいというわけではなく、法整備すべきところはちゃんと法整備して、安心に取引できる仕組みを作った方がメリットは大きいと考えています。規制が煩わしいというよりは、むしろもっと厳しくするべきところは厳しくするべきだと思います。

今後、WebPayはどうなっていきますか?どういう未来を描いていますか?

決済サービス事業は、金銭を渡したり受け取ったりするという意味では、まさに資本主義の根幹をなす事業です。そんな事業を手がけていることに責任ややりがいを感じていますし、社会に貢献できる部分も多く、今後できることの可能性が大きい領域だと思います。
小さく始めたWebPayですが、LINEとの協業を通じて、日本だけでなく世界も見すえた巨大な事業になると確信しています。
また、WebPayと同様なサービスもいくつも出てきていますが、単にライバル視するのではなく、そのような事業者の方とともに、この業界を大きく盛り上げていきたいと思っています。
ということで、人材も募集中です!私たちと一緒に未来ある事業を作っていきませんか?
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
1時間ほどお時間をいただき行ったインタビューでしたが、いかがでしたでしょうか。
若さに満ちあふれた久保さんを見ていると、今後のWebPayという決済サービスがどのようになっていくか、非常に楽しみです。
すぐ始められるそうなので、興味がある方はぜひ一度使ってみてはいかがでしょうか?

WebPay: 開発者向けクレジットカード決済サービス
https://webpay.jp/

SNIで1台のサーバ上に複数のSSLサイトを運用 – 後編

$
0
0
前回は、SNI(Server Name Indication)の技術的な概要と、その特徴について説明を行いました。

後編である今回は、新たにSNIに対応したさくらのレンタルサーバー スタンダードプランを利用して、実際にSNIを利用した独自ドメインのSSLの設定を行ってみたいと思います。

従来のさくらのレンタルサーバでは、独自SSL(IPアドレスベース)は、ビジネスプロプラン以上でのみ対応しており、1契約で1つのSSLサイトを運用できました。

それが、[今回のSNI SSL対応](http://www.sakura.ad.jp/function/security/original-ssl.html)により、スタンダードプラン1つで複数のSSLサイトを運用できるようになりました。

最安で月額515円から始められサーバプラン料金が抑えられることに加え、1サーバプランで複数のSSLサイトを運用できるので、サーバの運用コストを大幅に抑えられるようになりました。

この記事を通じて、「高コスト・面倒」だったSSLの設定・運用が、「低コスト・簡単」なものになってきたことを実感して頂ければと思います。

サイト構築の概要と前提

構築サイトの概要

ここでは、さくらのレンタルサーバスタンダードプラン1台で、2つのサイトを運用することを想定してみます。1つはブログ、もう1つはECサイトです。

以下はSNIの設定が完了したサイトのイメージです。SNIの設定が完了すると、このようにURLがhttpからhttpsと表示されます。

サンプルページ
サンプルページ

なお、複数のSSLサイトを設定するための全体フローは下図のようになりますが、本記事の解説範囲は、「SNIの設定」以降の範囲となります。

SNI設定のフロー

CSRの作成から始まるSSL証明書の発行、および、ドメインの取得から始まるマルチドメインの設定に関する作業は終わっていることを前提としています。
これらの作業について、参考になるページをそれぞれ挙げておきます。

作業内容

1. ドメイン設定画面を開く

レンタルサーバの管理画面にログインしたら、ドメイン設定メニューから「ドメイン設定」をクリックします。

ドメイン設定

2. example1.jp のSSL証明書を設定

このようなドメイン一覧画面が表示されるはずです。
まずはexample1.jpのSSL証明書を設定するために、「登録」をクリックします。

ドメイン一覧でSSL登録開始

続いて、「証明書のインストール」リンクをクリックします。

証明書のインストールを開始

3. example1.jp のSSL証明書を送信

事前に発行されたSSL証明書の内容を入力(①)し、送信ボタン(②)を押します。

中間証明書の送信

4. example1.jp のSSL中間証明書を登録

続いて中間証明書の設定を行うために、「中間証明書のインストール」をクリックします。

中間証明書のインストール開始

なお、発行されたSSL証明書の種類によっては、中間証明書の登録が不要なものもあります。
詳細は、SSL証明書発行元のドキュメントを参照して下さい。

5. example1.jp のSSL中間証明書を送信

SSL証明書の発行元から指定された中間証明書の内容を入力(①)し、送信ボタン(②)を押します。

中間証明書の送信

以上でSSL証明書の設定は完了です。

6. example1.jp のSNI SSLを設定

続けて、SNI SSLの設定を行うために、「ドメイン設定」をクリックします。

ドメインの設定

ドメイン設定の画面で、「SNI SSLを利用する」を選択(①)し、送信ボタン(②)を押します。

SNI SSLの設定
以上で、example1.jpドメインに対するSNI SSLの設定が完了しました。

ドメイン設定完了

7. example2.jpの設定も同様に行う

example2.jp の設定も、以上の流れと同様に行います。
最終的に、ドメイン一覧は以下のようになります。

SNI設定完了後のドメイン一覧

エンジニアとして感じたこと

筆者はエンジニアとして、数々のWEBサーバの設定を経験してきました。
エンジニアによって作業スタイルは異なると思いますが、私はコンソール、いわゆる「黒い画面」で設定ファイルを編集しながら設定作業を行うことが多いです。

一方で、本記事のようにWEBの管理画面から設定作業を行うのは久しぶりの経験で、コンソールを利用した設定作業には無いメリットも感じることが出来ました。

作業項目の比較に見る属人性の低さ

最も大きなメリットとして、運用作業に対する属人性が低くなる点が挙げられます。

SNIで複数サイトの構築を行うための作業項目を、コンソール経由での作業項目と比較する形で列挙してみました。

  管理画面経由での作業 コンソール経由での作業
サブドメインの追加
  • 管理画面からサブドメインを追加
  • 設定ファイルにVirtualHostの定義を追加
  • 各VirtualHostに対応するディレクトリのパーミッションを確認
SNIに対応させる
  • 自動で対応済み
  • 設定ファイルでSNIを有効化
SSL証明書の配置
  • 管理画面からSSL証明書をアップロード
  • 秘密鍵を適切なパーミッションで配置する
  • SSL証明書を適切なパーミッションで配置する
  • 設定ファイルのVirtualHostの定義に、秘密鍵とSSL証明書のパスを追記する
中間証明書の配置
  • 管理画面から中間証明書をアップロード
  • 中間証明書を適切なパーミッションで配置する
  • 設定ファイルのVirtualHostの定義に、中間証明書のパスを追記する

管理画面経由での作業に比べ、コンソール経由での作業項目が多いことが分かると思います。
特に、パーミッション設定やファイル設置などの作業は、運用ルールを決めておかないと人によって内容がまちまちで、担当者が変わると混乱、、という状況になりがちです。

近年は、DevOpsと呼ばれる領域で、サーバ設定をコード化(プログラミング)して、属人性の少ない自動化されたプロセスを構築することも可能にはなっていますが、仕組みの構築・維持にも、それなりに高いスキルと時間が求められるのが現状です。

管理画面から証明書をアップロードするだけで設定が終わるというのは、設定作業の属人性が低くなるという点で、レンタルサーバの大きなメリットであると思います。

最後に

前編・後編の2回にわたって、SNIの解説記事をお送りしてきました。
SNIによってマルチドメインのSSL運用が楽になること、また、SNIのメリット・デメリットがご理解頂ければ幸いです。

さくらのレンタルサーバ スタンダードプランのように、低コストでSNI SSLを導入できるサービスも登場してきました。サーバ運用担当の方は、積極的にSNI SSLの導入を検討してみてはいかがでしょうか。

最後までお読み頂き、ありがとうございました。

常時SSL化とは?Webサイトの常時SSL化の効果と注意点

$
0
0
SSL
Googleが常時SSL化をランキングシグナルに使用することを発表してから、一般サイトにおける常時SSL化が話題になっています。今回は、この常時SSL化について詳しくご説明します。ECサイトや金融機関などの重要な個人情報を管理するサイトだけではなく、一般的なコーポレートサイトや個人運用の情報サイトにおいても常時SSL化は必要あるのでしょうか。Webサイトの常時SSL化の効果と注意点を確認しましょう。

常時SSL化とは?

https

「常時SSL化」とは、金融機関などのWebサイトのように、自サイトのWebページをすべて暗号化することです。

常時SSL化を行うことにより、Webサイトのトップページから、暗号化されたプロトコルを使用した安全なコンテンツであることを示す「HTTPS」が表示されます。

さまざまな効果が見込める常時SSL化

盗聴、パケット改ざんの防止

Webサイト内でのユーザーの行動を保護し、Cookieを含めたすべての情報を暗号化します。暗号化されたデータは盗むことが困難になり、パケットの改ざんもされにくくなります。

Webサイトが本物であることを証明できる

アクセスしているWebサイトが本物であることを証明し、なりすましサイトへの誘導にユーザーが気付きやすくなります。

一時期、ユーザーを大手金融機関に酷似した偽サイトに誘導し、キャッシュカードの情報を入力させることで金融情報を盗む「フィッシング」が問題となりました。現在ではほぼすべての金融機関が全WebページをHTTPS化しています。常時SSL化したなりすましサイトを作成することは事実上不可能に近いため、HTTPSのサイトであることが本物の証明となり、ユーザーが安心して使用できる環境が整っています。

サイトの信頼性が上がる

今後、Google Chromeをはじめとする各社のブラウザは、よりわかりやすいセキュリティ情報を配信するために、HTTPSのWebサイトを「安全」、HTTPのサイトを「危険」と表示するシステムに変化していく見通しです。

現時点でもHTTPSサイトのアドレスはグリーンで表示され、安全であることが示されていますが、今後さらに明確にHTTPとHTTPSのサイトが区別されるようになったとき、少なくともコーポレートサイトが「危険」と表示されていることは望ましくありません。

検索エンジンからの評価が上がる

Webサイトを常時SSL化することにより、Googleなどの検索エンジンから「ユーザーが安心して利用できる優良なコンテンツである」と評価されます。

同時に、インターネットのヘビーユーズ層でもあるセキュリティ意識の高いユーザーからの評価が上がり、安心してアクセスしてもらうことで、ユニークなアクセスや有効な滞在実績を集めることができます。その実績によって、さらに検索エンジンからの評価を上げることが可能※です。一般サイトにおける常時SSL化が話題になったのは、このSEOの観点からでした。

ウェブマスター向け公式ブログ

覚えておきたい常時SSL化の注意点

常時SSL化のSEO効果は限定的

現時点で検索エンジンは、常時SSL化が「強力な」SEOになるような評価システムを採用していません。「競合サイトがあって、すべてが同レベルならHTTPSのほうが評価は上がる」という程度であることが、GoogleのGary Illyesによって公式に語られています。数百におよぶその他の要素と比べて、格段に重要視されてはいないとのことです。

信頼性の低い認証は逆効果

SSL認証の信頼性は3段階に分かれ、信頼性が高いほど導入価格も上がります。なるべく安価に導入したいところですが、安価でセキュリティ強度の低い証明書を使用したHTTPSサイトや、期限切れの証明書を使用したままになっているようなWebサイトは、コンテンツの安全性を確認できないと判断される恐れもあります。
なお、SSLの認証レベルについては、改めて知ろう、SSLサーバー証明書とは?(第二回)をご確認ください。

Webサイト内の取り込みコンテンツにも注意

Webサイト内で外部スクリプトの読み込みやコンテンツの取り込みを行う場合、それらもすべて安全であることが必要です。取り込みたい外部コンテンツの発信元が安全なサイトであるかは慎重に確認してください。

ソーシャルシェアのカウントがリセットされる

サイトアドレスが変わるため、TwitterやFacebook、Google+といったソーシャルシェアのカウントがすべてゼロになります。これは情報サイトにとっては手痛い点かもしれません。

タイトルに惹かれてクリック流入してきたユーザーは、その情報が有用であるかを、ソーシャルのシェア数、つまり過去の「バズり」実績で確認することがあります。そこでシェア数がゼロになっている記事は「誰も良いと思っていない」と判断され、読んでもらえないことも考えられます。サイトの滞在時間が縮み、直帰率が上がるため、苦しい運用をすることになるかもしれません。

アクセス解析ツールへの再登録が必要な場合も

上記同様、HTTPS化によってサイトアドレスが変わるため、アクセス解析ツールへの再登録が必要な場合があります。情報の引き継ぎができない場合は、常時SSL化によるアクセスの変化を解析することが困難になります。

おわりに

常時SSL化は、いずれセキュリティに繊細な企業サイトだけではなく、個人が運用する情報サイトにも求められていくと考えられます。しかし、SEOのためにとりあえず常時SSL化しよう、なるべく安い証明書で形だけセキュリティレベルを高く見せかけよう……という方法では、逆効果になる可能性が高いため、注意が必要です。

あくまでもメインはユーザーにとって有用なコンテンツを安全に、便利に届けること、常時SSL化はそのための一手段であり、検索結果への反映はその結果にすぎないことを心に留めておきましょう。

ファイアウォールiptablesを簡単解説~初心者でもよくわかる!VPSによるWebサーバー運用講座(4)

$
0
0
VPSによるWebサーバー運用講座の連載4回目です。
今回は、iptablesを使ってサーバーのファイアウォールの設定を行います。
サーバーOSはCentOS 6.7です。(CentOS 7系ではファイアウォールの仕組みが違うのでこの設定は使えませんので注意してください。)

まず、ファイアウォールの基本を学ぼう

VPSをセットアップしてWebサーバーを公開したら、Webコンテンツを全世界に発信できるようになりますが、同時に悪意ある第三者の攻撃にさらされる宿命を負います。
ファイアウォールは和訳すると「防火壁」です。サーバーが提供するサービス以外の不要な侵入口を塞ぐことで、最低限のセキュリティを確保します。
Webサーバーを公開するならばぜひともファイアウォールは設定しておきたいところです。

ファイアウォールを設定するにあたって、基本的な考え方は、
使っているサービスの口はオープンにして、使ってないサービスの口は閉じる」ということです。
あなたが管理しているサーバーでは、どんなサービスを使っているでしょうか? 使っているサービスの通信は許可して、使っていないサービスの通信は遮断するのがファイアウォールです。

HTTPサーバーなどのサービスはそれぞれ固有の「ポート番号」を使用しています。
また、使用する通信プロトコルとしてTCPUDPがあり、それぞれにポート番号の概念があります。「TCPのポート番号80」と「UDPのポート番号80」は別物ですので注意してください。
代表的なサービスのプロトコルとポート番号は以下のようになっています。

サービス名 プロトコルとポート番号
httpサーバー(HTTP) TCP 80
httpサーバー(SSL) TCP 443
メールサーバー(POP3) TCP 110
メールサーバー(IMAP) TCP 143
メールサーバー(SMTP) TCP 25
メールサーバー(submission port) TCP 587
FTP TCP 20, 21
SSH、SFTP TCP 22

Webサーバーだけの機能を持つサーバーの場合、以下のようにSSH(SFTP)、HTTP、HTTPSのポートを許可して、他の通信は拒否する設定にします。

ファイアウォール

よく使われるサービスのポート番号は、ウェルノウンポート番号(WELL KNOWN PORT NUMBERS)といって 0〜1023までのポート番号のどこかに割り当てられています。
詳しくは、以下のページをご覧ください。
TCPやUDPにおけるポート番号の一覧 – Wikipedia

あなたのサーバーについて、どのポートを許可すべきかをあらかじめ調べておきましょう。

ファイアウォールiptablesの設定を行う

それでは実際にiptablesの設定を行います。
はじめに、iptablesがインストールされていることを確認しましょう。

# which iptables
/sbin/iptables

whichコマンドで、iptablesがインストールされているパス /sbin/iptables が返ってくる場合は、すでにiptablesはインストールされています。

逆に、以下のようなメッセージが表示された場合はiptablesがインストールされていません。

/usr/bin/which: no iptables in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

この場合は、yumコマンドでインストールしてください。

# yum install iptables

iptablesの基本的な考え方

iptablesには、INPUTOUTPUTFORWORDという3つのポリシーがあります。それぞれの通信の基本ポリシーを”DROP”(拒否)、”ACCEPT”(許可)のどちらかに設定できます。
INPUTは、サーバーに入ってくる通信のポリシーです。ここでは基本ポリシーを”DROP”にして、あとで個別のポートに対して許可する設定にします。
OUTPUTは、サーバーから出て行く通信のポリシーです。基本ポリシーは”ACCEPT“にします。
FORWARDは、受信したデータを他のサーバーへ転送する際に適用される設定です。ここでは、特に転送するサーバーは無いので”DROP”にします。

iptablesのポリシー

実際の設定事例と解説

ポリシーを決めたあとに、個別のポートを許可する設定を行います。
事例を見てもらった方が早いと思いますので、実際のiptablesの設定ファイル内容を以下に紹介します。(2行以上に渡っている行は、実際には1行です)

# (1) ポリシーの設定 OUTPUTのみACCEPTにする
*filter
:INPUT   DROP   [0:0]
:FORWARD DROP   [0:0]
:OUTPUT  ACCEPT [0:0]

# (2) ループバック(自分自身からの通信)を許可する
-A INPUT -i lo -j ACCEPT

# (3) データを持たないパケットの接続を破棄する
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# (4) SYNflood攻撃と思われる接続を破棄する
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# (5) ステルススキャンと思われる接続を破棄する
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# (6) icmp(ping)の設定
# hashlimitを使う
# -m hashlimit                   hashlimitモジュールを使用する
# —hashlimit-name t_icmp  記録するファイル名
# —hashlimit 1/m               リミット時には1分間に1パケットを上限とする
# —hashlimit-burst 10        規定時間内に10パケット受信すればリミットを有効にする
# —hashlimit-mode srcip    ソースIPを元にアクセスを制限する
# —hashlimit-htable-expire 120000   リミットの有効期間。単位はms
-A INPUT -p icmp --icmp-type echo-request -m hashlimit --hashlimit-name t_icmp --hashlimit 1/m --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-htable-expire 120000 -j ACCEPT

# (7) 確立済みの通信は、ポート番号に関係なく許可する
-A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

# (8) 任意へのDNSアクセスの戻りパケットを受け付ける
-A INPUT -p udp --sport 53 -j ACCEPT

# (9) SSHを許可する設定
# hashlimitを使う
# -m hashlimit                   hashlimitモジュールを使用する
# —hashlimit-name t_sshd 記録するファイル名
# —hashlimit 1/m              リミット時には1分間に1パケットを上限とする
# —hashlimit-burst 10       規定時間内に10パケット受信すればリミットを有効にする
# —hashlimit-mode srcip   ソースIPを元にアクセスを制限する
# —hashlimit-htable-expire 120000   リミットの有効期間。単位はms
-A INPUT -p tcp -m state --syn --state NEW --dport 22 -m hashlimit --hashlimit-name t_sshd --hashlimit 1/m --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-htable-expire 120000 -j ACCEPT

# (10) 個別に許可するプロトコルとポートをここに書き込む。
# この例では、HTTP(TCP 80)とHTTPS(TCP 443)を許可している。
-A INPUT -p tcp --dport 80   -j ACCEPT
-A INPUT -p tcp --dport 443  -j ACCEPT

COMMIT

この設定内容を/etc/sysconfig/ の下にiptables というファイル名で保存します。
具体的には以下のコマンドになります。rootユーザーで作業してください。
vimコマンドでエディタを起動し、上記設定内容を貼り付けたあと、:wqで保存終了してください。

# cd /etc/sysconfig
# vim iptables

上記の設定内容について詳しく解説します。
(1) はポリシーの設定です。INPUT、OUTPUT、FORWARDそれぞれについてDROPまたはACCEPTの設定を指定します。

(2) 〜 (5) については、不正な接続の禁止などをする共通の設定です。このまま設定しておけば良いです。

(6) はpingの設定です。pingの応答を許可していますが、同一IPアドレスから繰り返しやってくるpingリクエストについては、外部からの攻撃とみなし拒否するようにしています。hashlimitオプションを使うことで、120秒の間に10回パケットを受信すれば、それ以降のリクエストには応答をしないように設定しています。

(7) は、確立済みの接続について通信を許可する設定です。これもよく使われる一般的な設定ですのでそのまま設定しておけば良いです。

(8) は、サーバーからのDNS問い合わせに対しての戻りパケット(UDP ポート53)を許可する設定です。これを許可しておくと、パソコンからサーバーへのSSH接続などで無駄に待たされることが無くなります。

(9) は、SSHを許可する設定です。ping設定のときと同じく、hashlimitオプションで接続回数による制限をかけています。
2分間の間に同一IPアドレスから10回接続要求があると不正な接続とみなし、それ以降の新しい接続要求を2分間拒否します。

(10) は、サービスごとに通信を許可する設定です。ここでは、TCPポート80のHTTPと、TCPポート443のHTTPS(SSL)を許可する設定をしています。
もし、他にも通信を許可したいサービスがある場合は、行を追加してください。以下の赤色の部分を通信許可したいサービスにあわせてカスタマイズすれば良いです。

-A INPUT -p tcp --dport 443    -j ACCEPT

もし、許可したいサービスのプロトコルがTCPなのかUDPなのか分からない場合は、いったんTCPとUDPのそれぞれの許可設定をしておいて(つまり2行の設定を書いておいて)、片方ずつ設定を無効にして本当に通信ができるかどうか試してみるなどして確認すれば良いと思います。または、本当に分からない場合はTCP、UDPともに通信許可をしておいても良いと思います。

設定が完了したあとは、iptablesを再起動します。
気をつけなればならないのは、SSHの設定です。SSHの通信を許可しておかないと、iptablesを有効にしたときに、新しくSSHの接続ができなくなります。
万が一、iptablesの設定に失敗してSSH通信ができなくなってしまった場合は、SSHターミナルからではなく、さくらVPSのコンソールパネルからVNCコンソール機能を使ってサーバーにログインし、iptablesの設定を正しく設定しなおしてください。

# service iptables restart

コマンド実行後[FAILD]と表示される場合は、設定ファイルに不備がありiptablesが有効になっていません。いま一度設定内容を確認してください。

設定が正しく行われたら、次のコマンドで設定状況を確認してみましょう。

# iptables -nL
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: up to 1/min burst 10 mode srcip htable-expire 120000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 flags:0x17/0x02 limit: up to 1/min burst 5 mode srcip htable-expire 120000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain INPUTの項で、2280443のポートがACCEPTされていることが分かります。
以上でiptablesによるファイアウォールの設定ができました。

 

最後に、iptablesについて詳しく書かれたサイトを紹介します。
iptablesについて、より細かい設定を行いたい場合に参照してください。
CentOS iptablesによるパケットフィルタ
ファイアウォール(iptables)の設定

少しやり方は異なりますが、さくらインターネットの公式サポートサイトにもiptablesの設定方法について解説がありますので、こちらも合わせてご覧ください。
iptablesの設定方法|さくらインターネット公式サポートサイト

 

Webサーバー運用講座の第4回目は以上です。
次回はWebコンテンツのバックアップ/リストアの方法や、OSのセキュリティアップデートについて解説します。

あわせて読みたい

>>「サーバーってなに?」~初心者でもよくわかる!VPSによるWebサーバー構築講座(1)
>>あなたのサーバは大丈夫?Shellshock対策をしましょう
>>さくらのVPSからディスクイメージを移行してみよう – 「楽しいさくらのクラウド」
>>Movable Type をさくらのVPSにインストールしてみよう
>>DrupalをVPSにインストールしてみよう

おしらせ

banner_vps

 

WAFの基礎から、SiteGuard Liteのセットアップまで ~SiteGuardシリーズでセキュリティ強化(その1)~

$
0
0

はじめに

はじめまして。株式会社ジェイピー・セキュアの齊藤です。

皆様、「さくらの専用サーバさくらのクラウド」では、ウェブアプリケーションファイアウォール(Web Application Firewall。以下、WAF)が標準で利用できることをご存知でしょうか?

「さくらの専用サーバ/さくらのクラウド」をご利用の場合、対応OSのイメージに、弊社のWAF製品「SiteGuard Lite」が組み込まれているため、セキュアなWebサイトの構築が可能です。

この連載では、急速に普及が進んでいるWAFの基本について紹介するほか、「さくらの専用サーバ/さくらのクラウド」をご利用の皆様向けに、「SiteGuard Lite」の設定・運用イメージを紹介していきたいと思います。
連載は、全3回を予定しており、第3回では、CMS(Content Management System。以下、CMS)のセキュリティ対策についても紹介します。

第1回

WAFの概要と「SiteGuard Lite」について紹介します。また、「SiteGuard Lite」のセットアップと動作確認の方法を紹介していきます。

第2回

検査機能のコアとなるシグネチャ検査・シグネチャ更新設定のほか、通知設定など、「SiteGuard Lite」の詳細設定について紹介します。

第3回

CMSのセキュリティ対策について説明したのち、人気のWordPressについて、SiteGuardシリーズを活用したセキュリティ対策を紹介します。

WAFとは、どのような製品なのだろうか?Webサイトのセキュリティ対策に有効なのか?設定が難しいのではないか?
そのような疑問を解決できるよう、連載を通して、できるだけ分かりやすく紹介していきますので、どうぞ宜しくお願いいたします。

WAFとは

ご存知のことと思いますが、個人情報の窃取やサイト改ざんなど、Webサイトを狙った攻撃による事件・事故が後を絶たず、Webサイトのセキュリティ対策が求められています。
これらの事件・事故の原因は、SQLインジェクションやクロスサイトスクリプティングといったウェヴアプリケーションの脆弱性を悪用した攻撃によるものが代表的であり、その脅威は、Webサイトの規模や企業・個人に関係なく、身近なこととして意識する必要があります。
攻撃による被害を受けないようにするだけでなく、改ざんによるマルウェア配布サイトへの悪用など、加害者とならないように努めることも重要です。

安全なWebサイト・アプリケーションの構築は、セキュア設計・セキュアプログラミングが基本であり、それを完璧に行うことができれば何の心配もありません。
しかしながら、間違った対策や対策漏れが生じるケースもあり、現実問題として、脆弱性をゼロにするのは簡単なことではありません。
脆弱性診断によって、脆弱性が見つかった場合には、修正が不可欠ですが、運用上の理由(サイトを停止できない、バージョンアップできないなど)により修正が困難であったり、修正までに長い時間が必要になることもあります。

そこで、効果的にWebサイトのセキュリティを強化する一つの方法として、WAFを紹介させていただきます。
WAFは、ウェブアプリケーションの脆弱性を悪用した攻撃からWebサイトを保護するための有力なソリューションとして注目を集めています。

WAF

WAFを導入することで、SQLインジェクションやクロスサイトスクリプティングなど、ウェブアプリケーションの脆弱性を悪用する攻撃を効率良く防御することができます。
それだけでなく、不完全な対策や対策漏れに備えるセーフティネットとしての活用、2014年に大きく取り上げられたApache Strutsやbashの深刻な脆弱性への対策などにも、WAFが有効活用されています。
前述の運用上の理由に該当しますが、Apache Strutsやbashの深刻な脆弱性が発見されたときは、すぐに対策を実施することができないWebサイトを救済するために、WAFが大きな役割を果たしました。
2015年には、WordPressやJoomla!といったCMSの脆弱性を狙った攻撃も大きな話題になるなど、WAFの必要性は益々高まっています。

「さくらの専用サーバ/さくらのクラウド」では、標準でWAFを利用することができます。
この機会に、”ワンランク上のWebセキュリティ“を実現する一つの手段として、WAFの利用を検討してみてはいかがでしょうか。

ホスト型WAF「SiteGuard Lite」

WAFには、ゲートウェイ型やホスト型、サービス型のようにいくつかの形態があります。
「さくらの専用サーバ/さくらのクラウド」で標準利用できるWAFは、ホスト型WAF「SiteGuard Lite」です。
ホスト型のWAFは、ウェブサーバー上にインストールして利用しますので、各サーバー毎にインストールする必要がありますが、最もシンプルな構成で、ネットワークの変更が不要であるという利点があります。
そして、「SiteGuard Lite」は、ウェブサーバーApacheのモジュールとして動作するWAFです。
攻撃パターンを定義したシグネチャをもとに、HTTP/HTTPSのリクエストを検査するシグネチャ検査機能を主としています。

SiteGuard Lite

製品の主な特長は、

  • 高品質なシグネチャによる防御性能
  • シンプルで直観的なGUIで、かんたん設定

です。
業態を問わず、導入実績が豊富なWAF製品で、特にホスティング環境での実績と安定稼働には定評があります。

通常、製品のインストールは、RPMパッケージによるインストールとセットアップスクリプト実行の2ステップとなりますが、「さくらの専用サーバ/さくらのクラウド」をご利用の場合、対応OSのイメージに「SiteGuard Lite」が組み込まれた状態で提供されていますので、セットアップスクリプトを実行するだけで、「SiteGuard Lite」の利用を開始することができます。※

※すでにご利用中のサーバーに追加導入することはできません。
「専用サーバ:新規、OS再インストール」「クラウド:インストール済みアーカイブからのサーバ作成」でご利用いただくことができます。

セットアップスクリプトの実行

それでは、「さくらの専用サーバ/さくらのクラウド」の環境で、「SiteGuard Lite」のセットアップスクリプトを実行してみましょう。
ターミナルで、「SiteGuard Lite」のインストールディレクトリにあるsetup.shを実行します。
setup.shは、root権限で実行してください。

# cd /opt/jp-secure/siteguardlite/
# ./setup.sh

セットアップでは、Apacheの設定ファイルや実行コマンドの指定、「SiteGuard Lite」のウェブ管理画面で使用するポート番号の指定、ウェブ管理画面のアクセス制限などを行います。
難しそうに思われるかもしれませんが、ご安心ください。対話形式のスクリプトで簡単に設定できるようになっています。
Apacheの設定ファイルや実行コマンドなども自動的に検出しますので、基本的には[Enter]を押していくだけです。
あっと言う間にセットアップが完了するのですが、一つだけ、ウェブ管理画面のアクセス制限に関する項目については、適切に設定していただくことを推奨しています。

please enter the addresses allowed to access the web console for https.
ex:192.168.1. 10.0.0.0/24
please enter allowed addresses. [ALL] -->192.168.1.100(例)

デフォルト値は[ALL]で、ウェブ管理画面について、全ての接続元からのアクセスを許可します。
一般的な管理ページへのアクセス制限と同様、アクセスを許可する接続元を登録しておきましょう。

セットアップスクリプトの最後の処理で、Apacheの再起動を行い、セットアップ完了です。

Apache restart. Are you sure? [yes]|no -->Enter押下
stopping apache ...
starting apache ...
apache restart done.
-----------------------------------------------------
+ finished SiteGuard Lite setup +
-----------------------------------------------------
Please access following URL for starting service.
https://hostname:9443/
(default user:admin, default password:admin)

SELinuxを有効にした環境でご利用いただく場合は、「SELinux 環境での事前設定」が必要です。
設定方法につきましては、製品マニュアル(管理者用ガイド)を参照してください。
(専用サーバの場合は、技術ドキュメントのページで、クラウドの場合は、さくらのクラウド ニュースのSiteGuard Lite(WAF)のページで、製品マニュアルをダウンロードすることができます。)

基本動作の確認

初期設定

セットアップ完了後は、ウェブ管理画面を使用して「SiteGuard Lite」の設定を行います。
ブラウザを起動して、ウェブ管理画面に接続してみましょう。

https://[サーバーホスト名(またはIPアドレス)]:9443 にアクセスすると、「SiteGuard Lite」のログイン画面が表示されます。

SiteGuard Lite 画面-1

ログイン画面が表示されたら、初期ID・パスワードで、ウェブ管理画面にログインします。
ログイン画面が表示されない場合は、ポート9443への接続が許可されているかiptablesなどの設定を確認してみてください。

SiteGuard Lite 画面-2

初回ログイン時に、管理パスワードの変更画面が表示されますので、新しいパスワードを設定してからご利用ください。
管理ユーザ名の変更も同じ画面で行うことができます。
(初期パスワードの変更は必須です。変更するまで他の操作を行うことはできません。)

初期パスワードの変更が完了したら、検査機能を有効にしてみましょう。(初期値:無効)
稼働中のWebサイトにWAFを導入するときは、設定内容や手順を検討してから検査機能を有効にしますが、ここでは「さくらの専用サーバ/さくらのクラウド」での「SiteGuard Lite」の提供形態に合わせて、新規構築のイメージで、順に設定と確認方法を紹介していきます。

モジュール設定の[ウェブ攻撃検査]で有効を選択し、画面下の[適用]ボタンを押します。

SiteGuard Lite 画面-3緑色のチェックと「設定を保存しました。」のメッセージを確認してください。

SiteGuard Lite 画面-4これで、初期設定は完了です。

動作確認

初期設定が完了しましたので、動作確認を行います。
ブラウザを起動して、Webページを表示してみましょう。

http://[サーバーホスト名(またはIPアドレス)]

まずは、Webサイトのページが正しく表示されることを確認してください。

次に、「SiteGuard Lite」の検査機能が有効になっていることを確認します。
URLのパスに、”WAF-TEST-SIGNATURE”という文字列が含まれている場合に検出するテスト用のシグネチャが用意されていますので、検出テストパスにアクセスしてみましょう。

http://[サーバーホスト名(またはIPアドレス)]/WAF-TEST-SIGNATURE/

今度は、検査機能によって検出したことを示す[検出メッセージ]が表示されます。

SiteGuard Lite 検出メッセージ該当のリクエストは拒否(BLOCK)となり、HTTPの応答コードは「403 Forbidden」です。

表示される検出メッセージの内容は、[検出メッセージの編集]画面で変更することができます。
(9000バイトまで)
なお、Apacheの設定で、”ErrorDocument 403″を指定している場合は、ErrorDocumentで指定したメッセージが表示されます。
オリジナルエラーページの表示をご希望の場合は、必要に応じてErrorDocumentの使用を検討してみてください。

検出ログの確認

検出内容の詳細は、動作ログの[検出ログ]で確認します。

SiteGuard Lite 画面-5

ログの表示アイコンにカーソルをあてると、ポップアップが表示され、検出した日時や動作・接続元・メソッド・URL・検出したシグネチャなどの情報を見やすいかたちで確認することができます。SiteGuard Lite 画面-6以上で、初期設定と基本的な動作確認は完了です。

おわりに

今回は、WAFの概要と「さくらの専用サーバ/さくらのクラウド」で、ホスト型WAF「SiteGuard Lite」の利用を開始するまでの手順を紹介しました。
基本的な内容が中心となりましたが、まずは、ウェブ管理画面の操作方法を含めて、簡単な手順でスタートできるというイメージが伝われば幸いです。
次回は、「SiteGuard Lite」のシグネチャ検査やシグネチャの更新設定、管理者への通知設定、統計グラフの見方など、詳細設定や運用について紹介させていただく予定です。

SiteGuard Liteの詳細設定 ~SiteGuardシリーズでセキュリティ強化(その2)~

$
0
0

はじめに

前回は、WAFの概要と「さくらの専用サーバさくらのクラウド」の環境で、ホスト型WAF「SiteGuard Lite」を動作させるまでの手順を紹介しました。
今回は、「SiteGuard Lite」の防御機能の主となるシグネチャ検査機能のほか、通知設定や統計グラフの活用方法など、詳細設定について紹介していきます。

  • シグネチャ検査機能
  • 管理者への通知設定
  • 統計
  • syslogへの出力
  • 設定のバックアップ・リストア
  • 動作確認

紹介する内容は、製品マニュアル(管理者用ガイド)に記載されている内容ですが、今回の記事により、一通りの機能と設定を把握できるように構成しており、連載を通して「SiteGuard」シリーズの設定ができるようになっています。
テスト時・運用開始後の設定変更などについても、イメージできるように配慮していますので、宜しくお願いいたします。

シグネチャ検査機能

「SiteGuard Lite」は、標準搭載のトラステッド・シグネチャによる防御(シグネチャ検査機能)を主としています。
トラステッド・シグネチャによる検査を行うことで、ウェブアプリケーションの脆弱性を悪用する様々な攻撃から、Webサイトを保護することができます。

トラステッド・シグネチャ

トラステッド・シグネチャは、ジェイピー・セキュアが提供する「SiteGuard」シリーズに搭載されている高品質なシグネチャの名称です。
Apacheのモジュールとして動作する「SiteGuard Lite」は、HTTP/HTTPSのリクエストを検査し、

  • SQLインジェクション
  • クロスサイトスクリプティング
  • ディレクトリトラバーサル
  • OSコマンドインジェクション
  • HTTPヘッダインジェクション など

ウェブアプリケーションの脆弱性を悪用する攻撃を検出します。
また、Apache KillerやApache Struts、ShellShockと呼ばれたbashの脆弱性など、ウェブサーバーやフレームワークの脆弱性を悪用する攻撃を検出するシグネチャも用意されており、迅速なシグネチャリリースに定評があります。

シグネチャ検査によって、大規模な個人情報の流出といった甚大な被害を受けるSQLインジェクション攻撃を防御したり、CMS本体やプラグインの脆弱性にも多いクロスサイトスクリプティングなどを防御することができます。
「小規模なWebサイトだから」、「個人のブログサイトだから」のように、あまり気にされていない方もいるのですが、改ざん被害の結果として、マルウェアの配信サイトや迷惑メール配信などに悪用されるケースもありますので、Webサイトの規模や企業・個人に関係なく、加害者とならないように努める必要があります。

トラステッド・シグネチャの設定は、ウェブ管理画面の[モジュール設定]-[トラステッド・シグネチャの設定]で確認することができます。

siteguardlite-trusted_signature

シグネチャは、防御性能と運用性のバランスに配慮した”推奨設定”で、標準搭載しています。
基本的には、”推奨設定”でご利用いただいていますが、使用していないフレームワークに関するシグネチャは無効にするなど、個別に設定を変更することも可能です。
設定を変更した場合は、[適用]ボタンを押して、設定を反映してください。

シグネチャ更新設定

トラステッド・シグネチャの更新は、ウェブ管理画面の[シグネチャ更新設定]の画面で行います。
更新方法は、[今すぐ更新]ボタンによる手動更新とスケジュールによる自動更新があり、シグネチャ更新サイトにHTTPS(443)で接続します。
インターネットへの接続にプロキシサーバを経由する必要がある場合は、プロキシサーバの指定ができます。

まずは、最新のシグネチャに更新するため、[今すぐ更新]ボタンを押してみましょう。

siteguardlite-signature_update_01

シグネチャの更新に成功すると、「更新に成功しました!」のメッセージが表示されます。

siteguardlite-signature_update_02

シグネチャの更新に失敗した場合は、更新失敗のメッセージとエラーの内容が画面に出力されますので、原因の調査に役立ちます。

自動更新では、

  • 毎日 00:00
  • 毎週水曜日 01:00
  • 毎月1日 05:00

のように、更新間隔を指定することができます。(初期値:自動更新無効)

[保存]ボタンを押すと、rootのcrontabに更新スケジュールが登録されます。

siteguardlite-signature_update_03

スケジュールによる更新、メンテナンスや運用作業のタイミングに合わせた手動更新など、Webサイトの運用方針に合わせてご利用ください。
自動更新を設定していても、緊急性の高いシグネチャがリリースされたときの即時更新(手動更新との併用)が可能です。

シグネチャの更新ログは、[ログ]-[シグネチャ更新ログ]で確認することができます。

siteguardlite-signature_update_04

 カスタム・シグネチャ

「SiteGuard Lite」では、標準搭載されているトラステッド・シグネチャのほかに、お客様独自のルールを作成できるカスタム・シグネチャによる検査が可能です。(1000個までの条件を登録することができます。)
カスタム・シグネチャは、ウェブ管理画面の[モジュール設定]-[カスタム・シグネチャの編集]画面で、作成します。

siteguardlite-custom_signature_01

以下、予め用意されているサンプルをもとに、カスタム・シグネチャの作成例を紹介します。
いずれも、無効の状態で登録されていますので、必要に応じて、有効にしてご利用ください。

sample-01:検出の除外設定

カスタム・シグネチャでは、条件を指定した検出の除外設定を作成することができます。
sample-01は、”field1″というパラメータについて、signature-1~4とsignature-11のシグネチャによる検出を除外する設定です。
(ここでは、実際のトラステッド・シグネチャ名ではなく、仮のシグネチャ名を使用しています。)

siteguardlite-custom_signature_02

条件に、URLを加えた複数条件を登録することもできますので、柔軟な設定が可能です。
一部の検出を除外する場合などに、有効活用してください。

sample-02:ブルートフォース対策

カスタム・シグネチャには、「頻度判定」の機能があります。
作成した条件に対して、何秒間に何回一致したかを接続元IPアドレスでカウントしますので、ログインページへのブルートフォース攻撃といった高頻度の接続を検出することができます。

siteguardlite-custom_signature_03

sample-02では、login.phpへの接続が”1秒間に3回以上”発生した場合に検出します。

siteguardlite-custom_signature_04

機械的な不正ログイン試行などに有効なシグネチャで、こちらも要求メソッドなどを加えた複数条件を登録することができます。

sample-03:管理者アクセスの検査除外

接続元IPアドレスの指定で、条件に一致する接続を安全とみなす(検査を除外する)設定です。
CMSなどの管理ページの操作で、ページやコードの編集といった管理者操作がトラステッド・シグネチャの検出対象になってしまうことがあるため、管理者アクセスを安全とみなす設定として、作成しておくことを推奨しています。
sample-03では、/admin/というパスについて、192.168.1のネットワークからの接続を安全とみなします。

siteguardlite-custom_signature_05

一例となりますが、有名なCMSであるWordPressの場合、ブルートフォース対策のシグネチャであれば、sample-02の検査文字列で、

/wp-login\.php

のように、WordPressのログインページを指定します。
検査文字列を変更する場合は、[条件の編集]ボタンを押してください。
また、せっかくですので、シグネチャ名とコメントも分かりやすい内容に変更しておきましょう。

siteguardlite-custom_signature_06

管理者アクセスの検査除外については、sample-03の最初の条件になっている検査対象”パス”の検査文字列で、

/wp-admin/

のように、WordPressの管理アクセスのパスを指定します。
同じように、検査文字列の変更は[条件の編集]で行い、シグネチャ名とコメントも分かりやすい内容に変更しておきましょう。

siteguardlite-custom_signature_07

sample-03は、”パス”と”接続元IPアドレス”の組み合わせが条件になっていますが、条件を1つにして、接続元IPアドレスの指定だけで安全とみなす設定も可能です。
作成・編集したカスタム・シグネチャは、[適用]ボタンを押すことで、反映されます。

ここで、除外するトラステッド・シグネチャ名検査文字列に関する補足となりますが、それぞれ正規表現で指定します。

■設定例
^signature-1$                  signature-1が対象
^signature-[1-4]$             signature-1~4が対象
^192\.168\.1\.               192.168.1.xが対象
^192\.168\.1\.1(5|6)$    192.168.1.15と192.168.1.16が対象

^:      文字列の最初
$:      文字列の最後
\X:     記号Xのエスケープ表記
[X-Y]:  文字範囲指定
A|B:    AまたはB
():      グループ化

設定するときは、文字列の最初と最後を示す”^”と”$”や範囲指定について、気を付けてください。
記述にコツが必要となるケースもありますが、柔軟にシグネチャを作成できるという正規表現だからこそのメリットがあり、このカスタマイズ性も「SiteGuard」シリーズの魅力の1つです。

 管理者への通知設定

続いて、管理者への通知設定です。
「SiteGuard Lite」には、検査機能によって検出した内容のほか、製品に発生したエラー情報を管理者宛に通知する機能があります。
基本的な設定方法は同じですので、ここでは、検出通知をもとに説明していきます。
通知の設定は、[モジュール設定][管理者への通知設定]で行います。(初期値:無効)

検出通知を有効にして、通知間隔を指定します。(初期値:10分)
初期値の場合、検出情報を要約したメールが10分間隔で送信されます。
通知メッセージの内容は、[サマリ検出通知メッセージの編集]で編集することができます。
通知の間隔は、分単位による指定のほか、毎日00:00のような設定も可能です。

siteguardlite-notify_admin_01

メールを送信する宛先の指定も、同じ画面上で行います。

siteguardlite-notify_admin_02

宛先のメールアドレスのほか、差出人(From)を指定します。
宛先は、改行区切りで、複数のアドレスを指定することができます。
差出人の指定は任意で、差出人の指定がない場合は、宛先に指定された先頭のメールアドレスが差出人に設定されます。

このほか、SMTPサーバのホスト名(または、IPアドレス)とポート番号、SMTP認証が必要な場合は、認証のユーザ名とパスワードを指定します。
必要な情報を入力したら、[適用]ボタンを押して設定を反映してます。

外部からのWebサイトへのアクセスで発生した検出情報の要約が、メールで送信される有用な機能となっていますので、是非、利用してみてください。

siteguardlite-notify_admin_03

通知間隔の指定は、いずれか1つとなります。
検出した情報を早いタイミングで確認したい場合は、分単位での設定。デイリーレポートとして通知を受けたい場合は、毎日を設定のように、運用方針に合わせてご利用ください。
どちらも、検出がなかった場合、メールは送信されません。

統計

ウェブ管理画面のホームには、検出結果を集計した統計グラフが表示されます。
検出全体の種類別統計のほか、検出したシグネチャのTOP10を確認することができます。

siteguardlite-statistics_01
siteguardlite-statistics_02

ここまでの紹介では、前回の検出テスト用パス(WAF-TEST-SIGNATRE)へのアクセスだけしか試していませんが、実際に運用を開始していただくと、上図のような統計が確認できると思います。

統計の更新は、60分間隔(毎時0分)で行っていて、更新スケジュールは、rootのcrontabに登録されています。

0 * * * * cd /opt/jp-secure/siteguardlite;./siteguardlite_statistics.sh

統計は、現在の統計(最新)と前回の2世代を表示可能です。
[統計をクリア]ボタンを押すことで、統計のクリアと前回分としてのコピーが行われます。

統計のクリアは自動化することもできます。

0 0 1 * * cd /opt/jp-secure/siteguardlite; make statistics-clear

というスケジュールをrootのcrontabに登録しておくと、毎月1日の00:00に、過去1ヶ月分の統計を前回分としてバックアップし、新たに統計の作成を開始しますので、月次統計として活用することができます。

syslogへの出力

「SiteGuard Lite」のログは、インストールディレクトリにあるlogsに、ログファイルとして出力されます。
特に必要な場合、出力先をsyslogに変更することができます。

ログ出力の設定変更は、[アドバンスト設定]で行います。
デフォルト値は、ファイルになっていますので、これをsyslogに変更し、タグファシリティプライオリティを設定してください。

siteguardlite-syslog_01
siteguardlite-syslog_02

設定変更後は、忘れずに[適用]ボタンを押してください。
なお、syslogに出力したログファイルは、ウェブ管理画面の[ログ]-[動作ログ]には表示されませんので、ウェブ管理画面からのログ閲覧も行う場合は、ログの出力先でファイルとsyslogを選択してください。

設定のバックアップ・リストア

必要に応じて、設定変更を検討する場合はありますが、ここまでの内容で、基本的に「SiteGuard Lite」の設定は完了です。
「SiteGuard Lite」には、[バックアップ・リストア]の機能がありますので、万一の操作ミスや障害時に備えて、設定のバックアップを取得しておきましょう。

siteguardlite-backup_resotre

バックアップを取得するときは、[バックアップ]を押します。
リストア時は、取得したバックアップファイルを選択して、[リストア]を押すだけです。

バックアップ・リストアのもう1つの活用方法ですが、複数台の「SiteGuard Lite」に同じ設定を適用したい場合にも有効です。
2台のウェブサーバーを構築し、今回の連載をもとに、「SiteGuard Lite」を同じ設定で動作させる場合、1台目で設定した情報を[バックアップ]して、2台目に[リストア]することができます。
複数台の「SiteGuard Lite」を同じ設定で構築する場合には、是非、有効活用してください。

※[バックアップ]により、ウェブ管理画面で設定した各種設定のバックアップができますが、cronへの追加登録となる下記の設定は、バックアップの対象外となるため、リストア後の再設定をお願いします。

  • シグネチャの自動更新スケジュール
  • 統計クリアの自動化(前述の月次統計の例)

動作確認

ここまでの準備が整ったら、コンテンツ作成のほか、Webサイトの公開に向けたテストを実施し、通常アクセスやアプリケーションの動作に問題がないことを確認しましょう。
トラステッド・シグネチャの推奨設定は、防御性能と運用性のバランスを図っていますが、通常アクセスが検出されてしまった場合には、前述のカスタム・シグネチャの作成例を参考に、サンプルの編集または、新規カスタム・シグネチャを作成してください。

今回の連載では、「さくらの専用サーバ/さくらのクラウド」での「SiteGuard Lite」提供形態に合わせて、新規構築をイメージしていますが、「SiteGuard Lite」をあとからセットアップ(将来的に、稼働中のWebサイトへ導入)する場合は、「監視運用(モニタリング)」を推奨しています。
監視運用については、製品マニュアル(管理者用ガイド)を参照してください。
(専用サーバは、技術ドキュメントから、クラウドは、SiteGuard Lite(WAF)からダウンロードすることができます。)

おわりに

今回は、防御機能に関する説明だけでなく、シグネチャ更新や通知設定、統計といった運用開始後にも役立つ設定、仕様について紹介しました。
「ワンランク上のWebセキュリティ」の一手段として、シンプル・高性能なホスト型WAF「SiteGuard Lite」の有効活用を是非、ご検討ください。
次回は、CMSのセキュリティを中心に紹介していく予定です。
WAFによる対策のほか、人気のWordPressについて、セキュリティプラグイン「SiteGuard WP Plugin」を活用した対策を紹介します。

CMSのセキュリティ対策 ~SiteGuardシリーズでセキュリティ強化(その3)~

$
0
0

はじめに

この連載では、「さくらの専用サーバさくらのクラウド」で、ホスト型WAF「SiteGuard Lite」を利用するための手順や設定を紹介してきました。
連載の最終回となる今回は、WordPressを中心にCMSのセキュリティについて紹介していきます。
以下のポイントについて、「SiteGuard」シリーズによる対策を含めて、設定方法などを分かりやすく紹介していきたいと思いますので、宜しくお願いいたします。

  • 狙われるCMSの脆弱性
  • WAFによる対策
  • WordPress用セキュリティプラグイン「SiteGuard WP Plugin」

セキュリティプラグインについては、ジェイピー・セキュアが提供する「SiteGuard WP Plugin」(無償プラグイン)をもとに、説明させていただきます。

狙われるCMSの脆弱性

CMSは、簡単にブログを作成できるだけでなく、さまざまな機能拡張など、ユーザーにとって大きな魅力があり、今では多くの企業もCMSを活用して、Webサイトの構築・運用をしています。
しかしながら、不正ログインや改ざんなど、CMSで構築されたウェブサイトへの攻撃は増加の一途を辿っているのも事実であり、CMSのセキュリティ対策は重要な課題となっています。

国内のシェアは、WordPressが圧倒的ですが、

  • WordPress
  • Drupal
  • Joomla!

これらのCMSが、三大CMSと呼ばれることも多いため、ここ数年のセキュリティ事情について、少しずつ紹介します。

まず、WordPressですが、プラグインが豊富で、その拡張機能が大きな魅力である一方で、プラグインの脆弱性を悪用した攻撃が後を絶ちません。
2015年にかぎった話ではありませんが、人気プラグインの脆弱性発見が相次ぎ、多くのWebサイトが改ざんされるなど、深刻な状況が続きました。このほか、WordPress本体でも深刻なクロスサイトスクリプティングの脆弱性が見つかり、攻撃の実証コードや実演が公開されたことから、大きな話題になりました。

次に、Drupalですが、2014年の10月に深刻なSQLインジェクションの脆弱性が発見されたことが大きな話題となり、Joomla!については、2015年10月に発見されたSQLインジェクションの脆弱性に対する攻撃の増加と、12月のゼロデイによるリモートコード実行(原因は、PHPの既知の脆弱性)が記憶に新しいところです。
WordPress同様に、拡張機能の脆弱性が数多く報告されているのも実情であり、CMSが狙われる要因の一つとなっています。

プラグインやテーマなどの拡張機能は、不特定多数のユーザーや有志によって、自由に開発・提供されています。CMSの利用において、様々なメリットをもたらす反面、開発者ごとの安全性の配慮にばらつきがあるという実情から、深刻な脆弱性・攻撃へとつながってしまうことがあります。
CMS本体だけでなく、プラグインなどの拡張機能についても、運用中のサイトで利用している拡張機能のバージョンやメンテナンス状況、脆弱性の有無に注意するよう心がけてください。

 WAFによる対策

先に述べましたように、CMSにおいても、SQLインジェクションやクロスサイトスクリプティングなどによる攻撃、被害が多発しています。
2015年 WordPressに関しては、日に数件というペースで、プラグインの脆弱性が報告された時期もあり、クロスサイトスクリプティングとSQLインジェクションだけで脆弱性の6~7割を占めるという状況でした。
CMSの運用では、拡張機能を含めて、最新バージョンを利用することが重要ですが、「すぐにバージョンアップすることができない。」「利用しているプラグインが、最新の本体での動作をサポートしていない」など、バージョンアップが難しいことも多いのではないでしょうか。
このようなケースで、WAFを導入していると、WAFがセーフティネットとして大きな役割を果たします。

cms-waf

WordPress用セキュリティプラグイン「SiteGuard WP Plugin」

ここからは、人気のWordPressのセキュリテイ対策について、考えていきたいと思います。
SQLインジェクションやクロスサイトスクリプティングなどの対策はもちろんですが、WordPressの運用では、

  • 不正ログイン対策
  • コメントスパム対策
  • 管理画面(管理ページ)のアクセス制限

に悩むことも多いのではないでしょうか?

ジェイピー・セキュアでは、WordPressのセキュリティ対策と発展に貢献するために、「SiteGuard WP Plugin」を開発・提供しています。

siteguard-wp-plugin_image

「SiteGuard WP Plugin」は、シンプル且つ簡単に利用できるという「SiteGuard」シリーズのコンセプトを踏襲しており、難しい知識を必要とせず、インストールするだけでWordPressのセキュリティを向上させることができる日本語対応のセキュリティプラグインです。

「SiteGuard WP Plugin」を利用することで、外部からの不正ログインを防御するほか、管理ページへの不正アクセスやコメントスパムの脅威からウェブサイトを守ることができます。
なお、「SiteGuard WP Plugin」は、WordPressの公式ディレクトリへの登録、リリースとなっていますので、どなたでも無償でご利用いただくことができます。

siteguard-wp-plugin_dashboard

この記事では、先ほど課題として挙げた不正ログイン対策コメントスパム対策管理画面(管理ページ)のアクセス制限に役立つ機能を中心に紹介していきます。

ログインページ変更

WordPressのログインページである”wp-login.php“を変更し、機械的な不正ログインを回避するための機能です。
新しいログインページ名は、”login_(5桁の乱数)“で設定されますが、任意の名称を使用することもできます。

siteguard-wp-plugin_rename_loginpage
WordPressのスマートフォン用のアプリから接続するXML-RPC経由のアクセスは、ログインページ変更の対象外となりますが、簡単にログインページを変更することができる便利な機能です。
“wp-login.php”宛の機械的なアクセスが非常に多くなっていますので、不正ログイン対策に活用してみてください。(初期値:ON

変更後のログインページは、管理者宛にメールで通知されますので、メールを保存しておくか、忘れずにブックマークしましょう。
任意のログインページ名を設定する場合は、自分自身にとって分かりやすく、推測されにくいものを設定するようにしてください。

画像認証

ログインページとコメントページに画像認証(CAPTCHA)を追加する機能です。

siteguard-wp-plugin_captcha_01

画像認証(CAPTCHA)は、パスワード確認ページとユーザー登録ページにも表示させることができます。
また、表示する画像は、ひらがな英数字を選択することができ、各項目ごとに、有効・無効を設定することができるように配慮しています。
初期値:全ての項目でON・ひらがな

ログインページに画像認証(CAPTCHA)を設けることで、不正ログイン対策はより強固になり、

siteguard-wp-plugin_captcha_02

コメント欄の画像認証(CAPTCHA)により、コメントスパムへの対策も可能になります。

siteguard-wp-plugin_captcha_03

ひらがなの画像認証(CAPTCHA)が使用でき、読みやすいという点が好評です。

ログインロック

ログインに繰り返し失敗する接続元からのアクセスを禁止する機能です。

siteguard-wp-plugin_login_lock

デフォルト値では、5秒間に3回のログイン失敗があった場合に、その接続元からのアクセスを1分間禁止するという動作をします。
これにより、機械的な不正ログインの試行を効率良く防ぐことができます。(初期値:ON

「SiteGuard WP Plugin」は、ログインページ変更画像認証ログインロックの組み合わせにより、WordPressのログインページを強力に保護しています!

管理ページアクセス制限

管理ページ(/wp-admin/以下)への不正アクセスを防ぐための機能です。

siteguard-wp-plugin_adminpage_filter_01
WordPressの運用において、管理ページのアクセス制限は、重要な位置付けにありますが、接続元IPアドレスを固定することができない環境のアクセス制限は、困難であるという課題がありました。

管理ページアクセス制限の機能を使用することで、ログインに成功した接続元IPアドレスのみ、管理ページ(/wp-admin/)へのアクセスが許可されるようになりますので、簡単に管理ページのアクセス制限を適用できます。

siteguard-wp-plugin_adminpage_filter_0224時間以上、ログインしていない接続元IPアドレスは、順次削除されていきます。

なお、この管理ページアクセス制限の機能は、初期値がOFFになっています。
これは、変更後のログインページ忘れによる初心者の方のログイン不可など、管理ページへのアクセスを「/wp-admin/宛でも行えるようにして欲しい。」というリクエストが多かったためです。

WordPressの仕様上、ログインしていない状態で”/wp-admin/”にアクセスすると、ログインページにリダイレクトしますので、「SiteGuard WP Plugin」を利用する際は、管理ページアクセス制限を有効化(ON)し、リダイレクトによるログインページの表示を禁止することを推奨しています。

その他の機能

ログイン失敗時に詳細エラーを表示させないようにする機能やログインがあった場合のメール通知、WordPress本体やプラグイン、テーマに更新があった場合のメール通知、ピンバックの悪用を防ぐためのピンバック無効化の機能、ホスト型WAF「SiteGuard Lite」と連携したチューニングの補助機能があります。

  • ログイン詳細エラーメッセージの無効化
  • ログインアラート
  • ピンバック無効化
  • 更新通知
  • WAFチューニングサポート

更新通知の機能は、基本となる「最新バージョンの利用」を補助するための機能となっています。
運用中のサイトのバージョンや更新の有無を把握するための機能として、役立ててください。

 

いかがでしたか?
セキュリティ対策に役立つ機能や補助機能を一つのプラグインにまとめて提供していますが、機能毎にON/OFFを設定できるようになっています。
気に入った機能や使ってみたい機能がありましたら、是非お試しください。

プラグインのインストールは、他のプラグインと同様に、WordPressのダッシュボードから行うことができます。
ダッシュボードで、[プラグイン]-[新規追加]の順に選択し、”SiteGuard“を検索します。

siteguard-wp-plugin_install_01

“SiteGuard”が表示されたら、[今すぐインストール]を選択して、インストールを進めてください。

siteguard-wp-plugin_install_02

各機能の説明や使用方法については、「SiteGuard WP Plugin」の使用方法のページで確認することができます。

おわりに

この連載では、WAFの有効性とジェイピー・セキュア「SiteGuard」シリーズの活用方法、CMSのセキュリティについて紹介してきました。
セキュリティということから、少し難しい印象の話が続いてしまったかもしれませんが、できるだけ分かりやすく、役に立つ情報を紹介するように努めました。
連載の内容を「さくらの専用サーバ/さくらのクラウド」で構築するWebサイトのセキュリティ対策に、お役立ていただければ幸いです。


簡単!! レンタルサーバのセキュリティ対策!

$
0
0

「知らない」ではすまされない時代になってきた

2015年12月28日(月)に、経済産業省から「サイバーセキュリティ経営ガイドライン」が発表されました。
これは何かというと、IT に関するシステムやサービス等を供給する企業や、 IT を利用する企業の経営者と幹部に向けて、サイバーセキュリティリスクの対策をするようにと書いたガイドラインになります。
今の所、法的な罰則はありませんが、このガイドラインの中では対策を怠った場合の想定として下記のような事が想定されると警告しています。

・企業イメージの失墜
・信用の喪失
・損害賠償請求

このように行政機関から公式に警告が出ている以上、情報管理者はもう、何かあった時に「知らなかった」では済まされません。

そのため、個人情報をはじめ重要なデータがいっぱい詰まったサーバを扱う管理者は、ますます頭を悩ませる事になる時代になってきたというわけです。

さくらのレンタルサーバならセキュリティ対策も簡単!

でも、そこまで心配する事はありません。
さくらのレンタルサーバはそのほとんどの部分がさくらインターネットで保守、運用されているので、サーバ管理者様にはたった2つの部分を管理していただければいいようになっています。

・パスワードの管理
・ウェブコンテンツ(ホームページのデータ)の管理。

たったこれだけです。

パスワードについて

096846

さくらのレンタルサーバを運用するにあたって、3種類のパスワードがあります。
契約内容変更や新規契約の際などに使われる会員メニューログインのためのIDとパスワード。
サーバのマスターキーとなるサーバパスワード。
そしてメールアドレスなどに紐付いたユーザーのパスワードです。

パスワードは英数混合、記号も混ぜよう

パスワードを強度の高いものにするだけで、だいたいのサイバー犯罪は防げると専門家は言います。
パスワードの漏洩は文字列の総当り(ブルートフォース攻撃)で解析される事が多いといわれていますが、組み合わせる文字や文字数が多ければ多いほど、パスワードが強固になります。

例えば同じ8桁のパスワードを設定しようとした場合とくらべ、これを英数混合、大文字との組み合わせ、さらに記号文字も使った場合、単純計算で60万倍の強度になります。
もし、桁を8桁から9桁に増やせばさらに約100倍の強度です。

スーツケースについている数字3桁の鍵であれば総当りで30分くらいで開いてしまいますが、数字8桁の組み合わせよりも60万倍も複雑なパスワードだったら、コンピュータを使っても膨大な時間がかかってしまいます。これでは不正アクセス者もあきらめてしまいますよね。

パスワードを複雑なものにするのは利用者にとって面倒くさいものですが、米スプラッシュデータ社によると、「12345678」とか「iloveyou」とか「password」などにしてしまうと簡単に推測、悪用されてしまうそうですので注意が必要です。

パスワード個別に設定しよう(使いまわしはダメ!!)

いくらパスワードを強固なものにしていても、パスワードの使い回しをしていると意味がありません。
他の脆弱なサイトがハッキングされてしまった場合、攻撃者はまず、その情報を使って別のサイトにログインできるか試します(パスワードリスト攻撃)

「使い回しがよくないのはわかるけど、管理が大変だ」っていう人は、セキュリティソフトメーカーなどが出しているパスワードマネージャーを使うのも方法のひとつでしょう。

ウェブコンテンツについて

さくらのレンタルサーバでは、クイックインストールからWordPressやEC-CUBEなどのウェブアプリケーション(CMS)をインストールできます。

sakura_cms

WordPressやEC-CUBE、Joomla!といったウェブアプリケーションはとても便利です。
ウェブアプリケーションを使えば、あんまりサーバの知識がない人でも手軽にホームページの更新ができるし、プラグインで手軽に機能を拡張する事だってできます。
特に世界のホームページの25%はWordPressでできている、なんて事まで言われています。

cms_w3techs_november_2015_graph

venturebeat.comより引用
しかし、たくさんの人が使うソフトには、必ずそれを狙う輩が居ます。
特にWordPressの脆弱性はちょっと調べればたくさん出てくるので、古いバージョンを使っていると、それがそのまま誰にでもわかる不正アクセスの手段になってしまうんです。

WordPressのセキュリティを強化する

WordPressの本体やテーマ、プラグインは更新があるたびに管理画面で通知されます。
どれも管理画面に入ってしまえばワンクリックでバージョンアップできますので、こまめにチェックさえしていればいつだって安全な状態に保てるというわけです。

また、セキュリティ系のプラグインの中には何か更新があるたびに指定されたメールアドレス宛に通知してくれるものもありますので、毎日確認するのが面倒だという人は活用してみてください。
プラグインはWordPressの管理画面から追加できますが、信頼性の高い、そして頻繁に更新があるものを選ぶと外れがないと思います。

クイックインストールのWordPressの特徴

さくらのレンタルサーバのクイックインストールからインストールできるWordPressには、最初から厳選されたWordPressプラグインが用意されていますが、中でも『All In One WP Security & Firewall』はセキュリティに特化したプラグインとなっています。

ASP All In One WP Security & Firewallのダッシュボード画面

【マニュアル】WordPressのセキュリティを強化する

初期状態では有効になっていないので、是非、プラグインメニューから有効にして使ってみてください。

コントロールパネルでできるセキュリティ対策

さくらのレンタルサーバには、「国外IPアドレスフィルタ」が搭載されています。

これは何かというと、この国外IPアドレスフィルタを有効にする事で、海外からのFTPやSSH、WebDAV、それにWordPressの管理画面へのアクセスができなくなるという機能です。

ipfilter-img-010

現在、さくらのレンタルサーバで見られるパスワード漏洩や、ウェブ改ざんによる被害は、九割以上が海外からのアクセスによるものだったりします。そのため、国外IPアドレスフィルタを有効にしているアカウントでは、パスワードなどが漏れていたとしても、かなりの数の不正アクセスが未遂に終わっています。
国外IPアドレスフィルタと言ってもAWSやGoogleなどからは接続できますので、ぜひ活用してください。

最後に

不正アクセスというとニュースなどでは無駄に恐怖心を煽るような言い方をしますが、そんなのは世にある不正アクセスのほんの一部です。

確かにコンピュータを使う全ての人にとって不正アクセスは重要な問題となっています。
しかし、ちゃんとした対策をしたら、そのリスクは限りなく0に近づきます。不正アクセスで得られる利益よりも、時間や手間といったコストの方が高くつくなら、攻撃者もわざわざやる価値がありません。

ちょっとずつでも手間をかける事で未然に防げる被害の方が多いので、しっかり対策していきたいものです。

ポートスキャンツール「Nmap」を使ったセキュリティチェック

$
0
0

サーバーの基本的なセキュリティ対策の1つとして重要なのが、ネットワーク内のどのマシンがどのポートでサービスを提供しているのかを把握することだ。このために有用なのが、ポートスキャナと呼ばれるツールだ。本記事ではポートスキャナとして有名な「Nmap」というソフトウェアを使用し、ポートスキャンを行う方法について解説する。

定番のポートスキャナ「Nmap」とは

対象として指定したホストに対してポート番号を変えながらIPパケットを送信し、その反応を調べることでどのポートが外部からアクセス可能なのかを調査する行為をポートスキャンと呼ぶ。Nmap(Network Mapperの略)は、オープンソース(GPLv2ライセンス)で開発・提供されているポートスキャンツール(ポートスキャナ)だ。NmapではOSが提供するソケット機能を利用するだけでなく、ポートスキャンに使用するパケットを独自に生成することで、高速なポートスキャンやファイアウォール/IPS(侵入検知システム)で保護されたサーバーに対するポートスキャンを可能にしているのが特徴だ。また、対象とするホストの挙動からそのOSやバージョンと行った情報を推測したり、稼働しているサーバーソフトウェアの種類やバージョンを取得する、いった機能も備えている。

なお、Nmapには多くのスキャンオプションが用意されており、この中には特殊なパケットを送信して対象ホストの情報を取得するオプションや、発信元を隠してポートスキャンを実行することを可能にするオプション、侵入検知システムを回避することを可能にするオプションなどが用意されている。そのため、悪意のあるハッカーが攻撃対象のホストを調査する、といった用途にも利用できてしまう。他者が管理しているサーバーに対しポートスキャンを行うことは不正アクセスに該当する可能性もあるため、Nmapを利用する際は十分に注意してほしい。

Nmapのダウンロードとインストール

Nmapはマルチプラットフォーム対応が行われており、LinuxだけでなくWindowsやMac OS X、FreeBSDなど各種BSD、Solaris、HP-UXなどの各種UNIXでも動作する。ソースコードだけでなく、WindowsやMac OS X向けバイナリも提供されている。

Linux環境の場合、多くのLinuxディストリビューションで公式パッケージが提供されているので、それを利用するのが簡単だ。たとえばRed Hat Enterprise Linux(RHEL)やその互換OSであるCentOSなどでは「nmap」というパッケージでNmapのバイナリが提供されており、yumコマンドでインストールできる。

# yum install nmap

また、Gtk+で実装されたGUIフロントエンド(Zenmap)もnmap-frontendというパッケージで提供されている。GUIフロントエンドを利用したい場合はこちらもインストールしておこう。

# yum install nmap-frontend

なお、ディストリビューションの公式パッケージとして提供されているNmapは、そのバージョンがやや古いことがある。最新版のNmapを利用したいという場合やLinux以外のプラットフォームでNmapを利用したいという場合、NmapのWebサイト内のダウンロードページで公開されているバイナリやソースコード、ソースRPMを利用してインストールすれば良い。

たとえばWindows環境の場合、ダウンロードページの中頃に「Microsoft Windows binaries」という項目があり、そこにインストーラおよびZIPアーカイブのダウンロードリンクが用意されている。インストーラにはNmapが使用するWinPcap(オープンソースのパケットキャプチャライブラリ)も含まれているので、通常はインストーラを使ったインストールをおすすめする(図1)。また、このインストーラにはNmap本体に加え、GUIフロントエンドの「Zenmap」や各種ツールも同梱されている。

図1 NmapのWindows向けインストーラ
図1 NmapのWindows向けインストーラ

 そのほか、ダウンロードページではMac OS X(x86版)向けのバイナリも提供されている。Mac OS Xユーザーはこちらを利用すると良いだろう。

>>次ページ:Nmapを使ったポートスキャンを行う

おしらせ

banner_vps

脆弱性スキャナ「OpenVAS」でのセキュリティチェック

$
0
0

昨今ではソフトウェアに脆弱性が発見されることは珍しくない。そのため、既知の脆弱性についていかに迅速に対処を行うかが重要となっている。本記事では既知の脆弱性を発見するためのツールである脆弱性スキャナ「OpenVAS」を使ったサーバーのセキュリティチェック方法について解説する。

オープンソースの脆弱性スキャナ「OpenVAS」とは

昨今ではWebブラウザやWebサービスの深刻な脆弱性がニュースとなることも多い。しかしソフトウェアに脆弱性が発見されること自体は珍しいことではなく、深刻なものから軽微なものまでさまざまな脆弱性が毎月のように発見されている。しかし、「バグのないプログラムを作成することは不可能である」と言われているように、ソフトウェアに含まれる脆弱性を事前に見つけ出して取り去ることは非常に困難である。そのため、発見された脆弱性に対していかに迅速に対処を行うかがセキュリティ対策の鍵となる。

脆弱性に関する情報はJPCERT/CCUS-CERTといったWebサイトで公開されている。また、各OSベンダーやソフトウェア開発者らは脆弱性の発見されたコンポーネントに対する対策パッチやセキュリティアップデートなどをリリースしている。これらを定期的に確認して対応することが好ましいのだが、独自にカスタマイズしたソフトウェアを利用している場合や多数のサーバーを管理している場合など、利用しているソフトウェアに関する脆弱性情報の確認が困難な場合もある。このような場合に有用なのが、「脆弱性スキャナ」と呼ばれるソフトウェアだ。

脆弱性スキャナは、対象のマシンに導入されているソフトウェアのバージョンや設定、構成などを確認してそれらに脆弱性がないかどうかをチェックするツールだ。脆弱性スキャナの多くは簡単な操作でスキャンを実行でき、その結果をレポートとして出力する機能を備えている。既知の脆弱性に関する情報を格納したデータベースを用いて脆弱性のチェックを行うという仕組み上、未知の脆弱性については検出できない可能性はあるものの、定期的にスキャンを実行することでセキュリティ対策の不備を発見しやすくなり、セキュリティをより強固にできる。

脆弱性スキャナにはさまざまなものがあるが、今回はオープンソースで開発されている「OpenVAS(Open Vulnerability Assessment System )」を紹介する。OpenVASはかつてオープンソースソフトウェアとして開発・リリースされていたセキュリティスキャナ「Nessus」から派生したセキュリティスキャナだ。Nessusは2005年にリリースされたバージョン3以降、非オープンソースライセンスで提供される商用ソフトウェアとなったが、オープンソースで公開されていたバージョン2系をベースに拡張を続けたものがOpenVASとなる。コミュニティベースで開発され無償で利用できるだけでなく、脆弱性データベースは日々更新が続けられており、開発を支援する独Greenbone Networksによる商用サポートも提供されている。

OpenVASのアーキテクチャと動作環境

OpenVASはユーザーが操作を行うためのクライアントや、実際にスキャン操作を実行するスキャナ、スキャンのための各種設定やデータを管理するマネージャ、サービスやユーザーの管理を行うアドミニストレータといった複数のコンポーネントから構成されている(表1)。

表1 OpenVASのコンポーネント
種別 コンポーネント名 コマンド名 説明
クライアント OpenVAS CLI openvas-cli OpenVASをコマンドラインで操作するインターフェイスを提供する
Greenbone Security Desktop(GSD) gsd OpenVASをGUIで操作するインターフェイスを提供する
Greebone Security Assistant(GSA) gsad OpenVASをWebブラウザベースのGUIで操作するインターフェイスを提供する
スキャナ OpenVAS Scanner openvassd スキャン処理を行う
マネージャ OpenVAS Manager openvasmd スキャナやそのデータなどを一元管理する
アドミニストレータ OpenVAS Administrator openvasad サービスの起動/停止やユーザー管理などを行う

これらはそれぞれ同一のマシンで実行させることもできるし、異なるマシンで実行させることも可能だ。なお、Greenbone Security DesktopおよびOpenVAS CLIについてはLinuxおよびWindows向けのバイナリがリリースされているが、それ以外のコンポーネントについては基本的にはLinux向けとなっている。ダウンロードページではソースコードのほか、CentOS 6およびFedora 15~18、Red Hat Enterprise 6向けバイナリパッケージの入手方法が案内されている。なお、Debian GNU/LinuxやFedoraなどはその公式リポジトリでOpenVASのバイナリパッケージが提供されている。ただし、必ずしも最新のバージョンが提供されているわけではないので、それらを利用する際は注意してほしい。

今回は、CentOS 6.3をインストールした1台のサーバーにOpenVAS ScannerおよびOpenVAS Manager、OpenVAS Administrator、Greebone Security Assistantをインストールし、WebブラウザでそのサーバーにアクセスしてOpenVASの各種操作を実行するという構成で解説を行っていく。

OpenVASのインストールと設定

OpenVASのバイナリパッケージはCentOSの標準リポジトリでは提供されていないため、ソースコードからコンパイルしてインストールするか、もしくはサードパーティのリポジトリを利用してバイナリパッケージをインストールすることになる。バイナリパッケージの入手先やサードパーティリポジトリの利用法はOpenVASのWebサイトで説明されているが、CentOS 6の場合は以下のようになる。

Atomicorpのリポジトリを登録する

OpenVASのCentOS向けバイナリパッケージはAtomicorpというセキュリティ企業の提供するリポジトリ(atomicリポジトリ)から入手できる。atomicリポジトリを利用できるようにするには、http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/(x86_64向け)もしくはhttp://www6.atomicorp.com/channels/atomic/centos/6/i386/RPMS/(i386向け)で提供されている「atomic-release-<バージョン番号>.el6.art.noarch.rpm」という、atomicリポジトリの設定情報が含まれるRPMパッケージをインストールすれば良い。たとえば64ビット(x86_64)環境でatomic-release-1.0-14.el6.art.noarch.rpmをインストールする場合、以下のようにする。

# rpm -ivh http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/atomic-release-1.0-14.el6.art.noarch.rpm

atomic-releaseパッケージをインストールすると自動的にatomicリポジトリが有効になり、yumコマンドでこのリポジトリからパッケージをインストールできるようになる。

OpenVASのインストール

atomicリポジトリでは「openvas」という名称のパッケージでOpenVASが提供されている。このパッケージをインストールすることでOpenVASの利用に必要な一通りのコンポーネントがインストールされる。

# yum install openvas

OpenVASの設定

OpenVASでは、脆弱性情報やそれをテストするための設定情報を「NVT(Network Vulnerability Tests)」と呼ぶ。NVTは日々更新されており、NVT Feedと呼ばれる形式でその更新情報が配信されている。NVT FeedはOpenVASによって無料で配信されており、OpenVASの利用前には更新されたNVTをダウンロードしておく必要がある。また、OpenVASはNVTだけでなくSCAP(Security Content Automation Protocol)という仕様に基づいて記述された脆弱性情報も利用しており、これらのダウンロードやOpenVASを利用するためのユーザー情報の登録なども必要だ。これらは個別に行うこともできるが、openvasパッケージに含まれる「openvas-setup」というコマンドでまとめて実行できる。

# openvas-setup

openvas-setupコマンドを実行すると、まずNVTやSCAPベースの脆弱性情報のダウンロードとアップデートが実行される。この処理には数十分ほどの時間がかかるが、気長に待って欲しい。なお、ここでOpenVASプラグインのアップデートに失敗したという旨が表示されることがある。この場合、openvas-setupコマンドの実行後に後述するプラグインのアップデート処理を実行する必要がある。

# openvas-setup

Openvas Setup, Version: 0.3

Step 1: Update NVT’s and SCAP data
Please note this step could take some time.
Once completed, NVT’s and SCAP data will be updated automatically every 24 hours

Updating NVTs….
Error updating OpenVAS plugins. Please run openvas-nvt-sync manually.
Updating SCAP data…


Updating OpenVAS Manager database….

続いて、WebベースのGUI管理コンソールであるGreenbone Security Assistant(GSAD)の設定が行われる。デフォルトでは任意のIPアドレスからGSADに接続できるようになっているが、特定のアドレスからのみ接続できるように変更することも可能だ。

Step 2: Configure GSAD
The Greenbone Security Assistant is a Web Based front end
for managing scans. By default it is configured to only allow
connections from localhost.

Allow connections from any IP? [Default: yes] ←ここでEnterキーを押す
Stopping greenbone-security-assistant: [ OK ]
Starting greenbone-security-assistant: [ OK ]

次に、GSADの管理用ユーザーアカウントの作成を求められる。ここで作成したアカウントでGSADの設定変更といった管理操作を行うことになる。

Step 3: Choose the GSAD admin users password.
The admin user is used to configure accounts,
Update NVT’s manually, and manage roles.

Enter administrator username: sfjp ←作成するユーザー名を入力
Enter Administrator Password: ←パスワードを入力
Verify Administrator Password: ←同じパスワードを再入力

ad main:MESSAGE:29817:2012-12-27 20h27.09 JST: No rules file provided, the new user will have no restrictions.
ad main:MESSAGE:29817:2012-12-27 20h27.09 JST: User hylom has been successfully created.

続いて、通常の作業に利用するGSADの一般ユーザーアカウントを作成する。認証方法としてはパスワードもしくは証明書が利用できるが、通常はパスワードで問題ないだろう。また、ここでユーザーの権限を変更して実行できる処理を制限することも可能だが、これはGSADの起動後にGUIで設定できるので、ここでは設定していない。

Step 4: Create a user

Using /var/tmp as a temporary file holder.

Add a new openvassd user
———————————

Login : hylom ←作成するユーザー名を入力
Authentication (pass/cert) [pass] : ←「pass」を選択
Login password : ←パスワードを入力
Login password (again) : ←パスワードを入力

User rules
—————
openvassd has a rules system which allows you to restrict the hosts that sfjp has the right to test.
For instance, you may want him to be able to scan his own host only.

Please see the openvas-adduser(8) man page for the rules syntax.

Enter the rules for this user, and hit ctrl-D once you are done: ←Ctrl-Dを入力
(the user can have an empty rules set)

Login : hylom
Password : ***********

Rules :

Is that ok? (y/n) [y]
user added.

以上でopenvas-setupでの初期設定は完了だ。

Starting openvas-administrator…
Starting openvas-administrator:
[ OK ]

Setup complete, you can now access GSAD at:
https://<IP>:9392

この状態でopenvas-administratorおよびgsadは起動した状態になっているので、続いてopenvas-scannerおよびopenvas-managerを起動しておく。

# service openvas-scanner start
# service openvas-manager start

また、OpenVASプラグインのアップデートに失敗していた場合はここでopenvas-nvt-syncコマンドを実行し、プラグインのアップデートを行っておく必要がある。

# openvas-nvt-sync

プラグインのアップデート実行後は、アップデートしたプラグインをロードするためにopenvas-scannerを再起動しておく。プラグインのロードのため再起動には時間がかかる場合があるが、ここでも気長に待って欲しい。

# service openvas-scanner restart

最後に、openvas-managerをいったん停止させた上でデータベースのリビルドを実行し、完了したらopenvas-managerを再起動させておく。

# service openvas-manager stop
# openvasmd –rebuild
# service openvas-manager start

これでNVTのアップデートは完了だ。

Greebone Security AssistantによるOpenVASの操作

OpenVASではコマンドラインクライアント(OpenVAS CLI)で各種設定やスキャン操作を実行できる。また、GUI版クライアントを利用すると各種設定などをより容易に実行できる。ここでは、OpenVASの各種コンポーネントとともにインストールされるWebベースのクライアントであるGreebone Security Assistant(GSA)を使ったOpenVASの操作について説明していこう。

GSAへのログインとローカルホストのスキャン

GSAを稼働させているサーバーの9392番ポートにHTTPSでアクセスすると、GSAのログイン画面が表示される(図1)。

図1 GSAへのログイン画面
図1 GSAへのログイン画面

 ここでopenvas-setupコマンドで設定したユーザー名およびパスワードを入力してログインすると、「Tasks」画面が表示される(図2)。OpenVASではスキャン設定を「Task(タスク)」と呼び、この画面では登録されているタスク一覧が表示される。

図2 GSAの「Tasks」画面
図2 GSAの「Tasks」画面

 初期状態ではタスクは登録されていないので、まずローカルホストをスキャンするタスクを登録してみよう。タスクを登録するには、「Scan Management」メニューの「New Task」を選択する(図3)。

図3 タスクを登録するには「Scan Management」メニューの「New Task」を選択する
図3 タスクを登録するには「Scan Management」メニューの「New Task」を選択する

 「New Task」画面が表示されるので、ここでタスクに関する情報を登録していく(図4)。

図4 「New Task」画面
図4 「New Task」画面

 「Name」および「Comment」には任意のタスク名およびコメントを入力する。「Scan Config」ではスキャン方法を選択できるが、通常はデフォルトの「Full and fast」で良いだろう。「Scan Targets」ではスキャン対象を指定する。初期状態ではLocalhostのみが用意されているはずなので、これを選択する。これ以外についてはデフォルトのままでOKだ。最後に「Create Task」ボタンをクリックするとタスクが作成され、Tasks画面に作成されたタスクが表示される(図5)。

図5 Tasks画面に作成されたタスクが表示される
図5 Tasks画面に作成されたタスクが表示される

 登録したタスクを実行するには、ここで「Actions」列にある三角(Start)ボタンをクリックする。すると「Status」が「Requested」や進捗表示に変わり、スキャン処理が実行される(図6)。

図6 スキャン実行中は「Status」部分に進捗が表示される
図6 スキャン実行中は「Status」部分に進捗が表示される

 スキャンが完了すると「Status」が「Done」となり、また脆弱性が発見された場合は「Threat」の部分にその重大さが表示される(図7)。

図7 脆弱性が発見されるとその重大さに応じて「Threat」項目が変化する
図7 脆弱性が発見されるとその重大さに応じて「Threat」項目が変化する

 ここで「Reports」の「Last」欄にはスキャンを実行した日付が表示されており、これをクリックするとスキャンレポートが表示される(図8)。

図8 スキャンの実行日をクリックするとスキャンレポートが表示される
図8 スキャンの実行日をクリックするとスキャンレポートが表示される

 スキャンレポートには発見された脆弱性がその重大性ごとに表示され、それぞれの説明や対策などの情報も確認できるようになっている(図9)。

図9 スキャンレポートでは検出された脆弱性の情報を確認できる
図9 スキャンレポートでは検出された脆弱性の情報を確認できる

スキャン対象ホストの追加と認証情報を使った脆弱性スキャン

localhost以外のホストをスキャンしたい場合、「Configuration」メニューの「Targets」でスキャン対象となるTarget(ターゲット)を登録しておく必要がある(図10)。

図10 「New Target」画面
図10 「New Target」画面

 ここで「Name」にはターゲット名を、「Hosts」には対象ホストのホスト名を、「Port List」にはスキャン対象とするポートを指定できる。「Hosts」で「From file」を選択し、ホスト名が列挙されたテキストファイルを指定することで複数のホストを登録することも可能だ。必要な情報を入力し、最後に「Create Target」をクリックするとターゲットが追加される。

また、一部のテストでは対象のホストにログインしてセキュリティテストを実行する。このようなテストの実行にはログインに使用するためのアカウント情報(Credential)が必要だが、これについては「Configuration」メニューの「Credentials」から登録できる(図11)。

図11 「New Credential for Local Security Checks」画面
図11 「New Credential for Local Security Checks」画面

 ここで「Name」にはアカウント情報名を、「Login」にはログインに使用するユーザー名を入力する。また、認証にはパスワードもしくはSSHを利用できる。SSHを利用する場合「Autogenerate credential」を選択するとSSH鍵が自動的に生成されて登録されるほか、「Key pair」を選択して公開鍵および暗号鍵、パスフレーズを入力することもできる。これらの情報を入力して「Create Credential」をクリックするとアカウント情報が保存される。作成/登録された公開鍵は、「Credentials for Local Security Checks」の「Actions」列に表示されている鍵(「Download Public Key」)アイコンをクリックすることでダウンロードが可能だ(図12)。

図12 「Actions」列に表示されている鍵アイコンをクリックすると公開鍵をダウンロードできる
図12 「Actions」列に表示されている鍵アイコンをクリックすると公開鍵をダウンロードできる

 また、ここで作成したアカウント情報を使用するはターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定すれば良い(図13)。

図13 ターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定できる
図13 ターゲットの設定時に「SSH Credential」項目で作成したアカウント情報を指定できる

放置されている脆弱性は意外に多い、ぜひ定期的なチェックを

OpenVASによる脆弱性のチェックを実行することで、気付いていなかった脆弱性を簡単に発見できる。多くのLinuxディストリビューションではデフォルトでセキュリティに配慮した設定が取られていることが多いが、それでも見過ごされていた脆弱性やセキュリティ的に問題のある設定というのは意外に存在する。コマンドラインでOpenVASを操作できるOpenVAS CLIを併用すれば、cronコマンドで定期的に脆弱性スキャンを実行する、といったことも可能だ。ぜひ一度、OpenVASを使って自分の管理しているサーバーのセキュリティを確認してみてはいかがだろうか。

おしらせ

banner_vps

Windowsでも使える脆弱性スキャナ「Nessus」を使う

$
0
0

 管理しているサーバーなどに脆弱性がないかを調べるツールを「脆弱性スキャナ」と呼ぶ。脆弱性スキャナにはさまざまなものがあるが、古くからよく知られているものの1つに「Nessus」がある。今回はこのNessusを使った脆弱性の調査について紹介する。

マルチプラットフォーム対応の脆弱性スキャナ「Nessus」

 Nessusは指定したサーバーに対しポートスキャンや擬似的なアクセスなどを行うことで、サーバーに存在する脆弱性を調査するツールだ。対象とするサーバーが使用しているソフトウェアに既知の脆弱性がないかどうかを調査できるほか、設定ミスや脆弱なパスワードの存在なども確認できる。また、さまざまな形式で詳細なレポートを生成できるのも特徴だ。WindowsおよびMac OS X、Linux、FreeBSD、Solarisというマルチプラットフォームで動作する。

 Nessusはかつてはオープンソースで開発されていたが、バージョン3.0以降は非オープンソースのプロプライエタリソフトウェアとして開発されている。企業などでの一般的な利用には有償のライセンス契約が必要となっているが、非商用の個人利用であれば無料で利用でき、また15日間限定の無料体験ライセンスも提供されている。

 今回はNessusの最新版であるNessus 5(5.0.2)を使用し、Windows環境およびLinux環境から脆弱性スキャンを実行する方法について紹介する。

 なお、無償で利用できる個人向けライセンス(Nessus for Home)はホームネットワークでの利用のみが許可されており、最大で16IPアドレスまでのスキャンしか行えないといった制限があるものの、脆弱性スキャン機能については有償版と同じものが利用できる。また、企業内などで評価目的で利用する場合は15日間利用できる評価用ライセンスが用意されているので、こちらを利用してほしい。

Nessusを利用するためのライセンスを取得する

 Nessus本体は開発元であるTenable Network SecurityのWebサイトからダウンロードできる。ただし、インストール後の初期設定時に同社から取得したアクティベーションコードの入力が必要だ。そのため、事前にこちらを取得しておく必要がある。

 企業内での評価目的であれば、「Nessus Evaluation」ページから評価用ライセンスの申込みが行える(図1)。このとき氏名およびメールアドレス、企業名、電話番号などの登録が必要だ。

図1 Nessusの評価用ライセンス申込みページ
図1 Nessusの評価用ライセンス申込みページ

 いっぽう、家庭内での利用の場合は「Nessus HomeFeed」ページから無償ライセンスを取得できる(図2)。この場合は、氏名およびメールアドレスの入力のみが必須となっている。

図2 Nessusの個人向け無償ライセンス申込みページ
図2 Nessusの個人向け無償ライセンス申込みページ

 ライセンスの申込みを行うと、メールでアクティベーションコードが送られてくる。筆者が試した際は、どちらの場合も申込みを行ってすぐにメールが届いていた。

Nessusのダウンロード

 Nessusのダウンロードは、Tenable Network SecurityのWebサイトから行える。WindowsおよびMac OS X、各種Linux、FreeBSD、Solaris向けのバイナリパッケージが用意されているので、使用したい環境に応じたものをダウンロードする(図3)。

図3 Nessusのダウンロードページ
図3 Nessusのダウンロードページ

Windows環境でのNessusのインストール

 Nessusはマルチプラットフォームに対応しており、WindowsおよびMac OS X、各種Linux、FreeBSDなどさまざまなプラットフォーム向けのバイナリが公開されている。たとえばWindowsの場合、Windows XP/2003/Vista/2008/7の32ビットおよび64ビット版に対応したインストーラが提供されている。利用したい環境に応じたインストーラをダウンロードして実行するだけでインストールが可能だ。

 Windows版Nessusのインストーラは、Windowsアプリケーションで一般的なウィザード形式のものだ(図4)。

図4 Windows版Nessusのインストーラ
図4 Windows版Nessusのインストーラ

 インストール作業は指示に従ってウィザードを進めていくだけで完了する。なお、Nessusはサービスとしてインストールされ、Webブラウザでアクセスしてその操作や設定を行う仕組みとなっている(図5)。

図5 Nessusはサービスとしてインストールされる
図5 Nessusはサービスとしてインストールされる

Linux環境でのNessusのインストール

 Linux環境向けには、各種ディストリビューション向けにrpmおよびdeb形式でバイナリパッケージが提供されている。対応しているディストリビューションはDebian 6.0、Red Hat Enterprise Linux(RHEL) 4/5/6およびその互換OS、Fedora 16~18、SUSE Linux Enterprise 10/11、Ubuntu 9.10~12.04などだ。たとえばRHEL 6互換のCentOS(64ビット)環境では、Nessus-5.2.1-es6.x86_64.rpmというパッケージが用意されている。このパッケージをダウンロードし、以下のようにrpmコマンドでインストールする。

# rpm -ivh Nessus-5.2.1-es6.x86_64.rpm

 このパッケージの場合、Nessusの各種機能は「nessusd」というサービスを通じて提供される。このサービスは自動的には起動しないので、インストール後に以下のようにして起動しておく。

# /sbin/service nessusd start

 なお、nessusdはTCPの8834番ポートで待ち受けを行うので、このポートにアクセスできるようファイアウォール設定の変更も行っておこう。

Nessusの初期設定

 Nessusのインストール後は、まずWebブラウザでNessusのGUI設定画面にアクセスして各種設定を行う必要がある。Windows版の場合、インストールの完了後に自動的にWebブラウザが立ち上がり「Welcome to Nessus!」と書かれたページが表示されるはずだ(図6)。

図6 「Welcome to Nessus!」ページ
図6 「Welcome to Nessus!」ページ

 Nessusの管理画面には通常SSL経由(HTTPS)で接続するのだが、使用する証明書は正式なものではないため、Webブラウザから警告が表示される旨がこのページでは記されている。これを確認したうえで、「here」部分のリンクをクリックすると初期設定を行うための画面が表示される(図7)。

図7 Nessusの初期設定ページ
図7 Nessusの初期設定ページ

 ここで「Get started」ボタンをクリックすると、まずNessusの管理画面にアクセスするためのユーザーアカウントを作成する画面が表示される(図8)。ここで「Login」にはログインに使用するログイン名を、「Password」および「Confirm Password」にそれぞれ同じパスワードを入力して「Next」をクリックする。

図8 アカウント作成画面
図8 アカウント作成画面

 続いてアクティベーションコードの入力画面が表示されるので、ここで先に入手しておいたコードを入力して「Next」をクリックする(図9)。

図9 アクティベーションコード入力画面
図9 アクティベーションコード入力画面

 なお、Nessusは開発元であるTenable Network Securityのサーバーにアクセスしてプラグイン更新を行うが、環境によってはプロクシを経由しないとインターネットにアクセスできない場合もあるだろう。その場合、アクティベーションコードの入力画面で「Optional Proxy Settings」をクリックすることで利用するプロクシの情報を入力できる。

 アクティベーションの完了後、プラグインの更新作業を行う(図10)。ここで「Next: Download plugins」をクリックすると、プラグインのダウンロードが実行される。この作業には数分程度の時間がかかるので注意したい。

図10 アクティベーションコードの登録完了画面
図10 アクティベーションコードの登録完了画面

 プラグインの更新が完了すると、Nessusの管理画面へのログイン画面が表示される(図11)。ここでは先ほど登録したユーザー名およびパスワードでログインが行える。

図11 Nessus管理画面へのログイン画面
図11 Nessus管理画面へのログイン画面

Nessusによる脆弱性スキャンを実行する

 Nessusの管理画面には表1のタブが用意されており、ログイン直後は「Scans」タブの内容が表示されている。

表1 Nessusの管理画面に用意されているタブ
タブ名 操作できる機能
Results スキャン結果の確認やレポートの作成
Scans 実行中/実行待ちスキャンの確認やスキャンの実行
Templates スキャン設定テンプレートの管理
Policies スキャン設定の管理
Users 管理画面のユーザー管理
Configuration 各種設定

 スキャンの実行や管理は「Scans」タブで行える(図12)。

図12 スキャンの実行や管理を行う「Scans」タブ
図12 スキャンの実行や管理を行う「Scans」タブ

 ここで「New Scan」をクリックすると、スキャンの設定を行うダイアログが表示される(図13)。

図13 「New Scan」ダイアログ
図13 「New Scan」ダイアログ

 ここで設定できる項目の意味は表2のとおりだ。

表2 「New Scan」ダイアログでの設定項目
設定項目 説明
Scan Title スキャン一覧画面で表示されるスキャン名
Scan Type 「Run Now」を指定するとすぐにスキャンが実行される。「Template」を選択すると設定をテンプレートとして保存できる
Scan Policy スキャン設定を指定する。スキャン設定は「Policies」タブで設定できる
Scan Targets スキャン対象とするホスト名もしくはIPアドレスを指定する
Upload Targets ホスト一覧が記載されたテキストファイルでスキャン対象を指定する

 Scan Typeで「Run Now」を指定した場合、「Create Scan」ボタンをクリックするとそのスキャンがScansタブのスキャン一覧に追加されると同時にすぐにスキャンが開始され、「Status」にその状況が表示される(図14)。

図14 「Create Scan」ボタンをクリックするとスキャンが実行される
図14 「Create Scan」ボタンをクリックするとスキャンが実行される

 スキャンが完了すると「Results」画面に完了したスキャンが追加され、そこからスキャン結果を確認できる(図15)。

図15 完了したスキャンは「Results」画面からその結果を確認できる
図15 完了したスキャンは「Results」画面からその結果を確認できる

 Results画面に表示されるスキャン結果をクリックすると、そこでまず発見された脆弱性や各種情報の概要が表示される(図16)。

図16 発見された脆弱性の概要(サマリ)ページ
図16 発見された脆弱性の概要(サマリ)ページ

 ここで、中央に表示された棒グラフでは発見された脆弱性や問題点の数を深刻度別に表したものだ。このグラフをクリックすると、発見された脆弱性や問題点の一覧が表示される。

図17 発見された脆弱性および各種情報一覧
図17 発見された脆弱性および各種情報一覧

 また、ここで個別の脆弱性情報をクリックすると、その脆弱性についての詳細が表示される(図18)。

図18 表示される脆弱性の詳細情報
図18 表示される脆弱性の詳細情報

 脆弱性一覧をファイルで出力することも可能だ。左サイドバーの「Export Results」をクリックし、出力形式と出力する情報を選択して「Export」ボタンをクリックすれば良い(図19)。

図19 「Export Scan Results」画面
図19 「Export Scan Results」画面

 たとえばPDF形式で出力されたレポートは図20のようになる。

図20 PDF形式で出力されたレポート
図20 PDF形式で出力されたレポート

スキャン方法の設定

 スキャン方法については「Policies」タブで設定が可能だ。デフォルトでは「External Network Scan」および「Internal Network Scan」、「Prepare for PCI-DSS audits (section 11.2.2)」、「Web App Tests」が用意されている(図21)。

図21 スキャン方法の一覧画面
図21 スキャン方法の一覧画面

 ここで「New Policy」をクリックして新たな設定を作成できるほか、既存のスキャンポリシーをクリックしてその設定を変更することもできる。スキャン設定の変更画面では4つのタブが用意されており、まず「General Settings」タブでは全体的なスキャン動作に関わる設定を行える(図22)。

図22 「General Settings」タブの設定項目
図22 「General Settings」タブの設定項目

 「Credentials」タブではスキャン時に使用する認証/アカウント識別情報などを指定できる(図23)。

図23 「Credentials」タブの設定項目
図23 「Credentials」タブの設定項目

 「Plugins」タブでは使用するプラグインの設定が行える(図24)。

図24 「Plugins」タブの設定項目
図24 「Plugins」タブの設定項目

企業内での利用は有償だが信頼性を重視するなら使う価値あり

 Nessusで検出された脆弱性には無害なものもあり、また誤検出の可能性もある。そのため最終的には人間の手で検出された問題点をそれぞれチェックして本当に問題となるものかどうかを確認する必要がある。あくまでNessusは問題の対象を絞り込んだり、問題となりそうな場所を見つけ出すためだけのもので、ただスキャンを行うだけではセキュリティの向上にはつながらないということを覚えておきたい。

 Nessusは商用利用は有償となるソフトウェアであるものの、その使い勝手はよく、信頼性に対する評価も高い。個人利用であれば無料で利用できるのもメリットだ。まずは自分が管理しているサーバーで試用してみて、そのセキュリティ状況をチェックしてみてはいかがだろうか。

おしらせ

banner_vps

「skipfish」でWebアプリの脆弱性をチェックする

$
0
0

 近年では多くの分野でWebアプリケーションが使われるようになり、大量の個人情報や重要な秘密情報を扱うようなアプリケーションも少なくない。そのため、Webアプリケーションも攻撃対象として狙われやすくなっている。今回はWebアプリケーションのセキュリティ対策として、Googleが公開しているセキュリティ調査ツール「skipfish」を使ったセキュリティスキャンを紹介する。

Webアプリケーションに特化したセキュリティ調査ツール「skipfish」

 今日では、Webブラウザ経由でさまざまな操作を行えるWebアプリケーションが広く浸透している。Webブラウザは最近のほぼすべてのPCにインストールされており、専用のクライアントを用意せずにアプリケーションを操作できるというのがその浸透の理由の1つだ。しかし、Webアプリケーションでは簡単にその一部(HTMLやJavaScript)のソースコードを閲覧することができ、また改ざんや細工を加えたリクエストを容易に送信できてしまう。そのため、設計・実装ミスによって簡単に脆弱性が生まれてしまう。Webアプリケーションに対する攻撃手法として有名なものにはSQLインジェクションやコマンドインジェクション、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)といったものがあり、これらが広く知られるようになった現在では攻撃を防ぐためのなんらかの仕組みが実装されていることが多いが、それが万全ではない場合や、ミスやバグなどによって特定の条件下で脆弱性が発生する場合などがある。

 今回紹介する「skipfish」は、このようなWebアプリケーションの脆弱性の検出に特化したセキュリティ調査ツールだ。Googleが開発・公開しており、実際にGoogle社内でも利用されているという。skipfishではWebサイトに対しクローリングを行ってアクセスできるURLを抽出し、それらに対しさまざまなパターンでのアクセスを行ったり、特定のキーワードや拡張子を組み合わせて問題の発生しそうなURLやリクエストを生成してアクセスすることで調査を行い、その結果をレポートとして出力する。対象とするWebサイトにHTTPでアクセスして調査を行うため、対象を特定のWebアプリケーションに限定せず、どのようなWebサイトに対してでも利用できる。

 調査結果はHTML形式のレポートとして出力され、発見された問題点は「潜在的リスク」ごとに色分けされて表示される。ここで検出された問題点のすべてがセキュリティリスクにつながる訳ではないが、問題を発見するための手がかりとしては非常に有用だ。

 skipfishの特徴としては、独自にカスタマイズされた高速なHTTPスタックによる高いパフォーマンスと使いやすさ、そして有意なセキュリティ調査を行える点が挙げられる。同社が公開しているプロクシ型の脆弱性検査ツール「ratproxy」など、同社が持つセキュリティ技術がskipfishに投入されており、CSRFやXSS、エンコード関連処理による脆弱性、SQL/XMLインジェクションなどさまざまな問題の検出が可能だ。動作環境はLinuxやFreeBSD、Mac OS X、Windows(Cygwin環境)となっている。

skipfishで検出できる問題点

 skipfishで検出できる脆弱性についてはskpifishのドキュメントにまとめられているが、たとえばリスクの高いものとしては次のものが挙げられている。

  • サーバーサイドSQL/PHPインジェクション
  • GET/POSTメソッドのパラメータにおけるSQL風命令の埋め込み
  • サーバーサイドシェルコマンドインジェクション
  • サーバーサイドXML/XPathインジェクション
  • フォーマット文字列に関する脆弱性
  • 整数オーバーフローに関する脆弱性
  • PUTメソッドでのLocations受け入れ

 これらは悪用されるとデータベースへの不適切なアクセスやサーバー上での想定外の処理実行などを許してしまう可能性があり、非常に危険な脆弱性であると言える。また、skipfishでは脆弱性だけでなく予期しないリクエスト結果の検出やSSL関連の不適切な設定、有効でないリンク、サーバーのエラーといった、脆弱性には直接つながらないがWebサイトの管理・運用には有用な情報も検出してくれる。

 なお、skipfishでは直接の脆弱性にはつながらないという理由で、以下の項目については調査を行わない。

  • 暗号化されずにやり取りされるCookie
  • JavaScriptからのCookie読み取り
  • 暗号化されずに送信されるフォーム
  • HTML内のコメント
  • エラーメッセージ内でのファイルシステムのパスや内部IPアドレスの表示
  • サーバーやフレームワークバージョンの表示
  • HTTPのTRACEやOPTIONSメソッドサポート
  • WebDAVなど一部でしか使われていない技術

 これらは通常直接問題になることは少ないが、別のセキュリティ調査ツールでの検出が可能なものもあるため、状況に応じて別のツールを併用することが望ましいだろう。

skipfishのダウンロードとビルド

 skipfishはGoogle Codeのプロジェクトページからダウンロードできる。動作環境はLinuxおよびFreeBSD、Mac OS X、Windows(Cygwin)だ。なお、バイナリパッケージは配布されていないため、各自の環境でコンパイルを行う必要がある。

 skipfishのコンパイルには、OpenSSLおよびPCRE、libidnが必要だ。たとえばCentOSの場合、openssl-develおよびpcre-devel、libidn-develパッケージをインストールしておけば良い。これらが利用できる環境で配布パッケージを展開し、展開先ディレクトリ内でmakeコマンドを実行すればコンパイルが完了する。

$ tar xvzf skipfish-2.10b.tgz
$ cd skipfish-2.10b
$ make

skipfishを使う

 skipfishはコマンドラインベースで操作するツールであり、GUIは用意されていない。skipfishのビルドが完了すると、makeを実行したディレクトリ内にskipfishというバイナリファイルが作成される。skipfishには多数のオプションが用意されているが、最低限必要なオプションは「-W」および「-o」オプションだ。これらを指定してskipfishを実行するには以下のようにすれば良い。

$ ./skipfish -W <キーワード辞書の保存先ファイル> -o <レポートの出力先ディレクトリ> <クロールを開始するURL> [<クロールを開始するURL2> …]

 まず「-W」オプションだが、これは学習したキーワード辞書の保存先ファイルを指定するものだ。skipfishでは調査対象とするURLを収集するためにWebページをクローリングしていくとともに、キーワードが格納された辞書を利用して生成された未知のURLに対してもアクセスを試みる。

 skipfishにはあらかじめいくつかの辞書がdictionariesディレクトリ以下に同梱されているほか、クローリングに使用したURLやページ内に含まれるURL、文字列などからキーワードを抽出して独自の辞書を生成する機能も用意されている。

 ここで生成された辞書データは、-Wオプションで指定されたファイルに保存される。-Wオプションは必須のオプションであるが、もし辞書を保存したくない場合、「-W /dev/null」、もしくはそれと同じ挙動を行う「-W-」オプションを指定すれば良い。また、存在しないファイルを指定することはできないので、新たに辞書を作成したい場合は空のファイルをあらかじめ作成しておく必要がある。

 レポートの出力先ディレクトリを指定する「-o」オプションも必須である。そのほかのオプションについては、「–help」オプション付きでskipfishを実行することで確認できる(主要なものについては後述する)。

 なお、skipfishでは対象とするWebサーバーに連続してアクセスを行う関係上、サーバーに負荷をかける点には注意したい。フォームへの投稿なども行うため、実際に運用中のサーバーに対して実行することは避けることが望ましい。

使用する辞書を指定する

 skipfishのdictionariesディレクトリ以下には多くのサイトで利用できる汎用性の高いキーワード辞書が付属しており、これを使用することで意図せずに公開されているファイルや不適切な挙動を行うURLを検出できる。

 dictionariesディレクトリに用意されている辞書は、最小限のものに絞った「minimal.wl」および中程度のキーワードを含む「medium.wl」、多くのキーワードを網羅した「complete.wl」、そして拡張子に対するチェックのみを行う「extensions-only.wl」の4つだ。併用する辞書は、-Sオプションで指定できる。たとえばcomplete.wlを使用してスキャンを行うには以下のようにする。

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -o <出力ディレクトリ> <クロールを開始するURL>

skipfishによるスキャンを高速化する

 skipfishでは辞書やサイトから抽出したキーワードからURLを生成してスキャンを行うため、存在しない膨大なURLに対してのアクセスを行うことになる。そのため、辞書やキーワードの利用を制限してスキャンを高速化するためのオプションも用意されている(表1)。ただしスキャンが高速になるということは、そのぶん脆弱性の「発見漏れ」が生じる可能性も高くなる点に注意が必要だ。

表1 キーワードや辞書関連のオプション(抜粋)
オプション 説明
-L サイトコンテンツからのキーワードの抽出を行わない
-Y 辞書から「<ファイル名>.<拡張子>」というURLを生成する際、一部の組み合わせしか使用しない
-W- 抽出したキーワードを辞書へと書き込まない

 たとえば、skipfishのドキュメントでは「もっとも高速だが一般的な用途には推奨できないオプション」として、以下のような「-W-」および「-L」オプションの併用が挙げられている。

$ ./skipfish -W- -L -o <出力ディレクトリ> <クロールを開始するURL>

 このオプションを指定した場合、スキャン時間は短くなるものの、ディレクトリに対する総当たり攻撃が不十分になるという。短時間でスキャンを済ませたいのであればプリセット辞書「extensions-only.wl」もしくは「complete.wl」を使用し、-Yオプション付きでskipfishを実行するのがおすすめだ。

$ ./skipfish -S dictionaries/extensions-only.wl -W <作成する辞書ファイル> -Y -o <出力ディレクトリ> <クロールを開始するURL>

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -Y -o <出力ディレクトリ> <クロールを開始するURL>

 もちろん、-Yオプションを指定すると辞書中のキーワードの一部の組み合わせしか使用されないので、時間的な余裕があるのであれば-Yオプションを使わないほうが好ましい。たとえば以下の例は、指定したWebサイトに対して完全なスキャンを実行するものだ。

$ ./skipfish -S dictionaries/complete.wl -W <作成する辞書ファイル> -o <出力ディレクトリ> <クロールを開始するURL>

ログインが必要なサイトに対する調査を行う

 アクセスの際に何らかの認証が必要となるWebサイトに対して調査を行いたい場合、skipfishに認証情報を与えて実行させる必要がある。たとえばBASIC認証を利用している場合、-Aオプションで以下のようにそのユーザー名およびパスワードを指定できる。

-A <ユーザー名>:<パスワード>

 いっぽう、Cookieを使った認証を行っている場合は-Cオプションで以下のようにアクセスの際に送信するCookieを指定できる。

-C <Cookie名>=<値>

たとえば名前が「sid」、値が「foobar」というCookieを利用する場合、以下のように指定すれば良い。

-C sid=foobar

特定のディレクトリを無視する

 Cookieを使った認証を行っている場合、特定のURLにアクセスすると認証が解除されてしまう(ログアウトされる)場合がある。これを防ぐには、-XオプションでそのURLを指定しておけば良い。-Xオプションは指定されたURLを調査対象から外す働きをするオプションだ。たとえば「/logout/」というURLを対象外とするには、以下のオプションを追加すれば良い。

-X /logout/

skipfishのレポートを確認する

 skipfishを実行すると、図1のようにその進捗が表示される。なお、テストで使用したのはさくらの専用サーバ エクスプレスG2シリーズのXeon 4コア仕様(ストレージはSATA)で、ローカルで実行しているWordPressベースのWebサイト(記事数は約400)に対しスキャンを行ったが、スキャンの完了までに約12時間ほどの時間が必要だった。

図1 skipfishの進捗表示
図1 skipfishの進捗表示

 スキャンレポートは、-oオプションで指定したディレクトリ内にHTML形式で保存される(図2)。

図2 skipfishが出力するスキャンレポート
図2 skipfishが出力するスキャンレポート

 レポートには「Crawl results」および「Document type overview」、「Issue type overview」という3項目が用意されている。まずCrawl resultsだが、ここにはサイトに対してクローリングを行っている際に検出された問題点が表示される(図3)。

図3 Crawl resultsにはクロールの際に発見された問題点が表示される
図3 Crawl resultsにはクロールの際に発見された問題点が表示される

 アイコンの色は危険度の高さを表しており、赤が「高リスク」、オレンジが「中リスク」、青が「低リスク」、灰色が「内部的な警告」、緑が「(リスクとは直接関係ないと思われる)情報」となっている。また、「Memo」ではとして発見された問題に関する情報が表示される。

 たとえばこの例の場合、リスクの高い問題は発見されていないものの、XSRF対策がされていない可能性のあるフォームがあることが検出されている。

 次の「Document type overview」では、クロールや辞書によって生成されたURLに対するアクセスに対し、どのようなドキュメントタイプのコンテンツが返されたかが表示される(図4)。

図4 「Document type overview」ではWebサイトが返すドキュメントのタイプが表示される
図4 「Document type overview」ではWebサイトが返すドキュメントのタイプが表示される

 そして最後の「Issue type overview」では、発見された問題点がその種別ごとに表示される(図5)。

図5 「Issue type overview」では、発見された問題点がその種別ごとに表示される
図5 「Issue type overview」では、発見された問題点がその種別ごとに表示される

 たとえばこの例では、危険度高の「Query injection vector」が2件、危険度中の「Directory traversal / file inclusion possible」および「Interesting server message」がそれぞれ2件および4件、そのほか低リスクのものとしてXSRF対策がされていないフォームや外部コンテンツの埋め込みといったものが検出されている。

手軽にWebサイトの問題点を検出できるものの過信は禁物

 skipfishは手軽にWebサイトの問題点を検出できるのが利点である。いわゆる脆弱性の検出だけでなく、キーワード辞書を使ったテストではバックアップファイル(拡張子が「.bak」のファイルや末尾に「~」が付いたファイルなど)の検出、公開状態にあるディレクトリの検出など、よくありそうなうっかりミスによる情報漏洩対策などにも有用だ。Webサイトの問題点というとSQLインジェクションなどの高度なテクニックを利用するものだと思いがちではあるが、このような問題は単純なだけに気がつかないうちに発生している可能性も高いのである。定期的にスキャンを実行して問題がないかチェックすることで、セキュリティに対する意識を高めることができるのではないだろうか。

 ただし、skipfishで検出されたものはそのすべてが必ずしも脆弱性につながるものではなく、誤検出であるものもある。そのため、検出された問題点をそのまま鵜呑みにせず、必ず手作業でのチェックやソースコードなどの確認などを行って本当に脆弱性につながるものかどうかを判断してほしい。

Viewing all 325 articles
Browse latest View live