　FileMaker って、、、あれかなぁ: SonicWALL

ラベル SonicWALL の投稿を表示しています。すべての投稿を表示

2020-09-04

テレワークのセキュリティ対策

　コロナウイルスの蔓延により、人々の働き方に変化が表れました。労働者のウイルス感染リスクを低減させるために、テレワーク（在宅勤務、モバイルワーク、サテライトオフィス）を導入する企業も増えてきました。

「出社3割以下」もテレワーク再強化の動きコロナ感染拡大で
 「リモートワークできず倒産」というニュースが流れる日

　テレワークを導入するにあたり、企業側として最も気がかりになることはセキュリティですね。つまりウイルス・マルウェア対策と重要データの取り扱いとなります。

安易なテレワーク導入は危険がいっぱい

　スタッフの身の安全を確保しつつ業務を遂行するために、社内で以下のようなテレワーク構成を行ったとします。

社内ルータをVPN対応のものに変更し、ファイアウォールで公開ポート制限
各スタッフのPCにはアンチウイルスソフトを導入済み
各スタッフは社内ネットワークにVPN接続し、リモートデスクトップで社内のコンピュータやサーバにアクセス
スタッフAは会社支給のPCを使い、リモートデスクトップ経由で社内業務の管理を担当
スタッフBはBYOD(自前)の自作PCを使って開発を行い、成果物をリモートデスクトップ経由で社内サーバ環境にコピーしたり、データベース管理を行ったりする
スタッフCはBYOD(自前)の mac PC を使っているが、社内で使っている経理ソフトが Windows 版のため、リモートデスクトップ経由で社内の Windows コンピュータにアクセスして経理ソフトウェアを操作

　一見、ひととおりテレワークで業務がこなせるようになってはいますが、これではまだセキュリティ的に問題のある構成となっています。この問題点は何だかわかりますか？

テレワーク環境に潜む問題

　在宅スタッフに起因する基本的なセキュリティ対策が不足しているのです。
　それでは問題を見ていきましょう。

各PCのセキュリティ状態が把握できない

　各 PC にはアンチウイルスソフトウェアがインストールされてはいますが、各人バラバラのメーカーのものを導入しています。これではウイルス感染した PC に関しての情報を会社側で把握することが難しく、問題の発生した PC から漏れたウイルスが社内ネットワークに広まってしまう可能性があります。

社内ネットワーク側にウイルス検知システムが導入されていない

　社内の VPN 機能付きルータ自身には基本的なファイアウォール機能が搭載されており、公開ポートを限定できるようになっていますが、リモートデスクトップ経由やその他の手段で到達したウイルスやマルウェアは、そのまま社内ネットワークに入り込んでしまうことになります。

　在宅スタッフが VPN 経由でウイルス付きのファイルを社内サーバーに配置してしまったり、ウイルスが添付されたメールを社内スタッフ向けに転送してしまったというトラブルが発生しています。

BYOD(自前)PC の用途が厳格化されていないため、セキュリティリスクが高まる

　上図の例を取ると、スタッフB とスタッフC は自前 PC を使用してテレワークを行っていますが、自前ということで業務以外の目的に PC を使うことが前提となります。つまり、業務目的以外に PC を使うというだけで、セキュリティリスクに晒されやすくなってしまうのです。会社はスタッフがどんな私用ソフトを自前の PC にインストールしているかも把握できませんし、業務時間外のネット利用を禁止するわけにもいきません。私用でインストールしたソフトウェアによって PC がウイルス感染したり、私用メールを開いた途端に PC がウイルス感染したというケースも多く発生しています。

　取り急ぎテレワーク環境を整えた企業は、上記のようなセキュリティの甘い構成になっていることが多いのではないでしょうか？

　最近では、テレワーク化が原因でデータ流出やウイルス感染が発生したことがニュースにもなっています。
　VPN 経由だからこそデータが流出しやすくなることがあることも忘れないようにしてください。

　参考ニュース記事：
　テレワークで情報流出　ＶＰＮの脆弱性を悪用
　在宅勤務時にＰＣウイルス感染　不正アクセス、従業員情報が流出―三菱重工
　

セキュリティの高いテレワーク構成には、セキュリティの一元管理が必要

　テレワークを安全に行うためには、企業ネットワーク側から各 PC の状態をある程度把握できる仕組みが必要となります。
　たとえば、クラウド管理型のアンチウイルスシステムを導入し、在宅スタッフの PC でウイルスが検出された場合にその通知が社内のスタッフに送信されるようにします。また、社内のルータを侵入検知機能付きのものに変更し、在宅スタッフ側で防げなかったウイルスやマルウェアを社内ネットワークの入り口で完全にシャットアウトします。

　以下のように構成します。

テレワーク環境の改善

クラウド型アンチウイルスシステム Panda Endpoint Security の導入

　弊社では、クラウド型アンチウイルスシステムとして、Panda Endpoint Security を導入しています。各クライアント PC に Panda Antivirus というソフトウェアをインストールすることにより、各PC のウイルス対策はもちろんのこと、感染や検疫が行われた記録はすべてクラウド上に通知され、担当者にその旨メールが送信されます。

　https://www.pandasecurity.com/en/business/solutions/ [英語]

SonicWall ルーターによるファイアウォール、アンチウイルス、サービス遮断

　SonicWall はルーター機能の他に、より柔軟性の高いファイアウォール機能が搭載さてれいます。不要ポートの遮断はもちろんのこと、各PC の IPアドレスやMACアドレス別に接続を許可したり、アクセス許可の範囲を決定したりできます。

　また、アンチウイルスおよび侵入検知機能も用意されているため、VPN 経由で侵入したウイルスやマルウェアも SonicWall ルータによって検疫の対象となり、社内ネットワーク上のウイルス蔓延を未然に防ぐことができます。

　さらに、特定のサービス（チャット、ゲーム、P2Pなど）を遮断したり、特定のサーバへのアクセスを遮断したりすることができるため、業務中にそれらのサービス使用によるトラブルを回避できます。

　https://www.sonicwall.com/ja-jp/

　弊社では Panda Cloud Security および Sonicwall によるネットワーク構築を支援するサービスを承っております。
　詳細はこちらをご覧ください。
　セキュリティとネットワーク構築

Amazon Workspaces の一部導入

　上図のスタッフC 経理は自前PC の OS 互換性の理由により、社内の Windows PC にリモートデスクトップ接続して経理ソフトウェアを操作しています。このため、経理一人のために本社の PC/仮想マシンを稼働させておく必要があります。
　将来的に経理担当を増やしたり、不要な稼働マシンの削減を考慮して、オンデマンドで起動できる Amazon Workspaces というクラウド型の Windows 仮想マシンを用意することによって、必要時にのみ Amazon Workspaces 上で経理ソフトを操作させる選択肢もあります。
　Amazon Workspaces はデスクトップ越しのファイル送信やコピー＆ペーストが許可されないため、操作ミスによる情報漏洩のリスクも低減できます。

　弊社では Amazon Workspaces の導入に関するコンサルティングから導入まで支援するサービスを承っております。
　詳細はこちらをご覧ください。
　AWS導入サービスについて

その他考慮すること

　企業によってテレワークのセキュリティポリシーをスタッフ別に考慮する必要も出てきます。たとえば、ネットワーク管理者であれば自宅から遠隔操作でほぼすべての社内リソースにアクセスできる必要があるでしょうし、社員の印刷やファイル交換の可否のセキュリティポリシーをグループまたは担当者別に設定する必要があるでしょう。
　また、外注スタッフに一部のシステム操作を許可する場合にも、アクセス可能時間を限定したり、IP/MAC アドレス別にアクセスを制御したり、機能が制限された Amazon Workspaces 上のみで操作を許可するようにしたりと、不正操作を未然に防止する必要もあるでしょう。

テレワークのセキュリティポリシー

　また、各スタッフの PC のドライブや外付けデータドライブ等も暗号化しておくことも重要です。これにより、万が一 PC や外付けデータドライブが盗難にあったとしても、データを復元できないため、データ自体は機密情報であっても、その中身を覗かれてしまうリスクを回避できます。
　ドライブの暗号化は、Windows 10 なら標準搭載の BitLocker、macOS も標準搭載の FileVault を使うことができます。

テレワークを成功させるには、各人の心がけありき

　上記のテレワーク構成は、それぞれのスタッフが万が一ネットワーク越しにうっかりミスをやらかしたときの基本的なセーフティネットを提供するにすぎません。

　いくらスタッフA 管理者が会社支給の PC を使用しているからといって、個人情報の取り扱いに問題のあるネット対戦ゲームソフトを勝手にインストールしたり、業務中や業務時間外に怪しいサイトを閲覧したりして、セキュリティリスクを高めてしまっているようでは元も子もありません。

スタッフB 開発者が、最強のPCを自作したとしても、その PC が故障してしまったら、業務はそこで停止しますし、VPN 経由で気を付けて本社サーバにアクセスしても、サーバの設定ミスでうっかり機密情報が外部に漏洩してしまうこともあります。

スタッフC の経理は自前PC の OS 互換性の理由により、社内の Windows PC にリモートデスクトップ接続して経理ソフトウェアを操作していますが、経理一人のために本社の PC/仮想マシンを稼働させておく必要があります。将来的に経理担当を増やしたり変更したりすることも考えて、オンデマンドで起動できる Amazon Workspacesというクラウド型の Windows 仮想マシンを用意し、必要時にのみ Amazon Workspaces 上で経理ソフトを操作するようにする選択肢もあります。

　企業の中には、きちんと成果さえ出せばいつ、どこで勤務しても良いという、労働条件の自由度が高いところもあるかもしれませんが、だからといって安易に喫茶店の無料 wi-fi を使って作業をすれば、個人情報や機密情報が外部に漏洩するリスクが発生しますし、赤の他人に横から情報を覗き見される危険性もあります。また、ワーケーションと称して観光地のホテルの一室で作業をしたりする際にも、機器の盗難リスク、紙の資料紛失、セキュリテイの甘い wi-fi 環境によるデータ漏洩のリスクも発生しやすくなります。働き方は自由でも、スタッフに課される責任として企業データや個人情報の保護を考慮すると、セキュリティ対策に自信のある人のみに許された自由ということになるのかもしれません。

土屋企画のテレワーク関連サービス
　弊社ではテレワークを検討されている企業様向けに検討から導入まで支援するサービスを提供しております。詳細は以下のリンクをご参照ください。
セキュリティとネットワーク構築
リモート開発/テレワークについて
AWSとテレワーク

2015-05-15

ポートスキャン、リモートコード実行、VoIP 攻撃

　先日、連続ネットワークアクセスのログが大量に記録されました。

　こんな感じです。

IP アドレス： 1.20.150.223 （タイ）
ポートスキャン後、連続アクセス。

IPS Prevention Alert: WEB-ATTACKS bash Access, SID: 8920, Priority: Medium - 1.20.150.223, 5313

bash Access とあるので、bash シェルの脆弱性（Shellshock）を狙った攻撃のようです。
　Unix、Linux、Mac OS X をお使いの方は注意が必要ですね。

参考：
bashに存在する「Shellshock」脆弱性についての注意喚起

　そして、この Shellshock 狙いどおり、リモートコード実行試行が10分間で 5700 回以上の連続アクセスが記録されていました。
　攻撃先のポートが 80 (http) だったので、Web サーバ狙いでしょうね。

WEB-ATTACKS Web Application Remote Code Execution 45, SID: 5617, Priority: Medium - 1.20.150.223

IP アドレス： 212.83.136.198 （フランス）

　ポートスキャン後、連続アクセス。
　過去のレポートを見ていると、先月末からもちょこちょこアクセスしている記録がありますし、この IP アドレスは以前から悪用が報告されているようです。

参考：
AbuseIPDB.com への報告

IPS Prevention Alert: VoIP-ATTACKS SIPVicious Activity 1, SID: 5616, Priority: Medium - 212.83.136.198, 5093

　VoIP で攻撃先のポートが SIP だったので、IP 通話関係の接続確立を試みたようです。

　みなさまもお気を付けください。

2013-08-30

SonicWALL の初期化（工場出荷時設定）方法

　SonicWall を工場出荷時設定に戻すには、以下の 2 とおりの方法があります。

【管理インタフェースからの起動】

1. 管理インタフェースにログインします。

2. 「システム」→「設定」の順に選択して設定ページに移り、ファームウェアイメージの一覧から「現在のファームウェア（工場出荷時の設定）」の起動ボタンをクリックします。

　これで工場出荷時の状態で SonicWall が起動されますが、設定情報はすべてリセットされますので、実行時にはくれぐれもご注意ください。

【本体のリセットボタンからの起動】

　SonicWALL に何らかの不具合が発生し、管理インタフェースが応答しなくなった場合は、本体のリセットボタンを押すことによって、セーフモードから工場出荷時の設定に戻すことができます。

1. SonicWALL に電源を入れたままの状態で、背面の電源ケーブルのすぐ左隣にある小さな穴に、つまようじのようなものを差し込み、10～20秒間軽く押したままにします。

2. SonicWALL がセーフモードで起動されますので、http://192.168.168.168 にアクセスすると、以下のようなセーフモードページが表示されます。

　ファームウェアイメージの一覧から、「現在のファームウェア（工場出荷時の設定）」の起動ボタンをクリックすると、工場出荷時の状態で SonicWall が起動されますが、設定情報はすべてリセットされますので、実行時にはくれぐれもご注意ください。

2013-08-29

HA 構成されている SonicWALL の切替ステータスの確認方法

SonicWALL で高可用性（High Availability, 以下HA）の切替が発生した場合は、切替状況がログに記録されます。

しかし、事前に HA のログを取るように設定をしておかなければ、ログが記録されませんので注意が必要です。

以下に設定方法と確認のしかたを示します。

【HA ログの設定方法】

1. 主格機側で管理インタフェースにログインします。

2. 「ログ」→「種別」の順に選択し、ログ種別設定ページに移動します。

　チェックボックスの見出しが消えてしまっていますが、上図のように、High Availability の行のチェックボックスに左から「ログ」、「警告」、「Syslog」にチェックを付け、“適用”ボタンをクリックします。

　これにより、HA のステータスがログに記録されるようになります。

【HA ログの確認方法】

　HA ログを記録させるには、主格機の電源を落とすのが手っ取り早いので、この方法でやってみることにします。

1. 主格機の電源を落とします。

2. 20秒～30秒待ち、副格機に処理が移るのを確認してから、副格機の管理インタフェースにログインします。

3. 「ログ」→「表示」の順に選択してログ監視ページに移り、表示の[種別]のプルダウンリストから [High Availability] を選択して“フィルタの適用”ボタンをクリックします。

　上図のように、Backup firewall transitioned to active という表記がログに出力されていれば、副格機に回線の制御が移ったことを示しています。

　また、主格機が復旧するまで、Backup missed heartbeats from primary （主格機からのハートビートが検出されません）というログも記録されますので、併せてチェックしてください。

4. 主格機に電源を投入します。

5. 20秒～30秒待ち、副格機に処理が移るのを確認してから、主格機の管理インタフェースにログインします。

6. 「ログ」→「表示」の順に選択してログ監視ページに移り、表示の[種別]のプルダウンリストから [High Availability] を選択して“フィルタの適用”ボタンをクリックします。

　上図のように、Primary firewall transitioned to active という表記がログに出力されていれば、副格機に回線の制御が移ったことを示しています。

　また、副各機とのリンクが復旧するまで、Primary missed heartbeats from backup （副格機からのハートビートが検出されません）というログが記録されることがありますが、Discovered HA backup firewall （HA 副格ファイアウォールが検出されました）が記録されれば副格機が検出されたことを意味しますので、併せてチェックしてください。

また、ログを自動メール送信設定している場合は、副格機に処理が切り替わった時には Backup firewall transitioned to active、処理が主格機に切り替わった時には Primary firewall transitioned to active という内容のメールが送信されますので、チェックしてください。

注意点：

1. 主格機 - 副格機の切替が発生したときの状態を機器の外観から知る方法はないようです。

　バックアップ状態（テストランプがオレンジ色で点滅）していた副格機のテストランプが、暗い青色に変化しますので、一応それで確認することは可能ですが、ビープ音が鳴ったりすることはないので、見落としてしまう可能性は高いといえるでしょう。

2. ログメールも、HA 切替発生時のメールタイトルを設定できないため、通常のログメールに紛れて見落としてしまう可能性が高いので、注意が必要です。

HA 構成されている SonicWALL のファームウェアの更新方法

　HA 構成済の SonicWALL でファームウェアをアップグレードする場合は、主格機側でアップデート操作するだけで、副格機のファームウェアも自動的にアップデートされるようになります。

　HA 構成の概要と設定方法については、以下の記事をご参照ください。

　SonicWALL で HA （高可用性）設定を行う

　それでは、ファームウェアのアップデート手順をご紹介します。

【ファームウェアのダウンロード】

1. MySonicWall にログインします。

https://www.mysonicwall.com/

2. 「ダウンロード」→「ダウンロードセンター」の順に選択すると、ダウンロードセンターページに移ります。

　上図のように、[言語設定]に「Japanese」、[ソフトウェア種別]にお使いの SonicWALL のモデルと同じものを指定してから、利用可能なファームウェアをクリックすると、ダウンロードが始まりますので、任意の場所に保存してください。

3. MySonicWALL からログアウトします。

【ファームウェアのアップロードと起動】

　SonicWALL からダウンロードしたファームウェアを、SonicWALL 主格機にアップロードして起動することによって、新しいファームウェアが主格機、および副格機に同時に反映されます。

1. SonicWall 主格機の管理インタフェースにログインします。

2. 「システム」→「設定」の順に選択すると、設定ページが開きます。
　現在起動中のファームウェアのバージョンを確認し、必要に応じてメモを取っておきます。

3. 下図のように、“ファームウェアのアップロード”ボタンをクリックし、先ほどダウンロードしたファームウェアを指定して“アップロード”ボタンをクリックすると、確認メッセージが表示されます。

　主格機、副格機ともに正常に動作していることを確認してから“OK”ボタンをクリックすると、ファームウェアのアップロードが始まります。

4. アップロードされたファームウェアがリストに表示されます。

　ページ下部に「ファームウェアが正常にアップロードされました。」という正常メッセージが表示されていることを確認してから、下図のように、新しいファームウェアの起動ボタンをクリックします。

5. この操作には 4 分ほど所要することと、主格機、副格機ともにファームウェアが反映されるため、社内でネットワーク利用のない時間帯に実行することを強くおすすめします。

　準備が整ったら、“OK” をクリックし、暫く待っていると主格機、副格機が再起動されます。

注意：
ファームウェアの更新に成功すると、古いファームウェアは起動リストには表示されなくなります。

以上です。

2013-08-26

SonicWALL で HA （高可用性）設定を行う

思ったより面倒だった SonicWALL の HA セットアップ

　SonicWALL の OS 5 では、比較的容易に冗長構成ができるようになっています。
　これは高可用性（High Availablity, 以降 HA）と呼ばれます。

　同モデルのメイン（主格）機とバックアップ（副格）機を用意して繋げておくことによって、主格機が電源障害やシステム障害などにより動作不能になった場合に、ネットワークの設定が自動的に副格機に移り、クライアントユーザはダウンタイムなしでネットワークを利用できるようになるといういうものです。

　意外に面倒なHA 構成、設定、確認方法をまとめてみました。

【用意するもの】

1. SonicWall 2 台

　OS 5 以上、同モデル機器、ファームウェアのバージョンが一致していることが条件です。
　当方は Sonic WALL TZ205W で操作を行いましたが、上位機でも、OS 5 であれば、ほとんどの操作で共通している部分も多いと思います。

2. クロスケーブル（カテゴリー6）：　1 本

　SonicWALL 同士を繋ぎ、一定の間隔で稼働状態をチェックする（ハートビート）ために使います。

3.　WAN スイッチ用のハブ： 1 台

　WAN 回線を分配するためのハブです。
　この他に、WAN ケーブル（ストレート） 1 本、LAN ケーブル（ストレート） 2本が必要になります。

4. LAN 用のハブ： 1 台

　二台の SonicWall、クライアント PC を繋ぐための LAN 用のハブです。
　台数分の LAN ケーブル（ストレート）が必要になります。

【設定用クライアントPCの準備】

　クライアント PC の NIC の設定で、IP 設定のゲートウェイを 192.168.168.168 （SonicWALL 管理インタフェースのデフォルト）にします。

　たとえば、以下のように設定します。

【副格機の設定】

　副格機側は、スイッチポートの設定のみを行います。

1. 副格機となる SonicWALL の　LAN ポート（X0）とクライアント PC の Ethernet ポートをストレートケーブルで繋ぎ、SonicWALL に電源を投入します。

2. http://192.168.168.168/ にアクセスし、ユーザ名を admin、パスワードを password でログインします（製品出荷時のデフォルト）。

3. 管理インタフェースより、「高可用性」 → 「設定」の順に選択します。

　下図のように、「高可用性を有効にする」のチェックボックスのチェックが外れていること、そして、「バックアップ SonicWALL」のシリアル番号が「000000000000」になっていることを確認します。

　上記のような状態になっていない場合は、工場出荷時の設定に戻し、最初からもう一度やり直してください。

　SonicWALL を工場出荷時の設定に戻す方法は、こちらをご覧ください。
　SonicWALL の初期化（工場出荷時設定）方法

4. PortShield グループより、X2～X4 ポートの設定を解除します。

　PortShield は、デフォルトでは、X2～X4 のスイッチポートにクライアント機器を接続してネットワーク利用できるようになっていますが、HA 構成をする場合は、X2～X4 ポートの PortShield 設定を解除（未定義）に変更する必要があります。

　管理インタフェースより、「ネットワーク」 → 「PortShield」グループの順に選択します。

　以下のように、 PortShield グループの設定ページが表示されますので、下図のように X2、 X3、X4 ポートをクリックして黄色に反転させ、選択状態にしてから、“設定”ボタンをクリックします。

注：
ポートを選択できない（黄色に反転しない）場合、「ネットワーク」→「インターフェイス」を選択し、目的のポートの「ゾーン」を「未定義」に指定します。

5. 複数のスイッチポートを編集するためのサブページが開きますので、その中から、「ポートシールドインタフェース」のプルダウンをクリックし、[未定義] を選択して“OK”をクリックします。

6. 元の PortShield グループ設定ページに戻りますので、ポートの X2、X3、X4 が黒抜きになっていることと、ポートシールドの状態が「未定義」になっていることを確認してください。

7. 管理インタフェースからログアウトし、副格機の電源を落とします。

以上で副格機側の設定は終了です。

【主格機の設定】

1. 副格機に接続していた LAN ケーブルを、主格機となる SonicWALL の LAN ポート (X0) に繋ぎ替え、アクティブな WAN ケーブルを WAN ポート (X1)に繋ぎ、電源を投入します。

2. 社内の WAN および LAN が正しく動作するように、ネットワーク設定を行います。
（ここではこの操作は省略）

3. PortShield グループより、X2～X4 ポートの設定を解除します。

　PortShield は、デフォルトでは、X2～X4 のスイッチポートにクライアント機器を接続してネットワーク利用できるようになっていますが、HA 構成をする場合は、X2～X4 ポートの PortShield 設定を解除（未定義）に変更する必要があります。

　この設定方法は、前述の副格機の設定と同様ですので、ここでは省略します。

4. 管理インタフェースより、「高可用性」 → 「設定」の順に選択します。

　下図のように、「高可用性を有効にする」のチェックボックスにチェックを入れ、「バックアップ SonicWALL」に副格機のシリアル番号を入力してから“適用”ボタンをクリックします。

注：
“適用”クリックで「HAでのインターフェースへのIP割り当ては、「静的」である必要があります」とエラーがでる場合、WANに接続するか、「ネットワーク」→「インターフェース」で「ネットワークモード」を「静的IP」に設定します。

5. 管理インタフェースからログアウトし、主格機の電源を落とします。

以上で、主格機側の設定は終了です。

【MySonicWALLに HA 構成を登録する】

　主格機のライセンス構成を副格機に引き継ぐには、MySonicWALL で主格機/副格機の関連付けを行う必要があります。

1. https://www.mysonicwall.com/ にログインし、主格機および副格機の SonicWALL の製品登録を行います（クイック登録でシリアル番号を入力するだけなので、ここでは省略）。

2. 「製品管理」より、主格機として登録した SonicWALL のリンクをクリックし、サービス管理ページを表示させ、ページ下部の「関連済み製品」より、「HA Secondary」をクリックします。

3. 関連付けが可能な SonicWALL のシリアル番号が表示されますので、副格機となる SonicWALL のシリアル番号を選択してから、“関連”ボタンをクリックします。

　以上でライセンスの関連付けは終了です。

　関連付けを確認する方法は、「製品管理」より、副格機として登録した SonicWALL のリンクをクリックし、サービス管理ページを表示させます。

　上記のように、「このセカンダリ装置はプライマリ装置により管理されています。いくつかのサービス有効化は、プライマリ装置にリダイレクトします。」という表記があれば、主格機と副格機でライセンスの共有がなされていることになります。

　また、「使用可能なサービス」欄で、目的のサービスが「購読済」になっていることも必ず確認してください。

【ケーブルを正しくつなぐ】

　主格機と副格機が正しく動作するように、ケーブルを繋ぎます。

　以下のような接続モデル図を考えた場合のケーブル接続をしてみます。

1. ハブを 2 台用意し、電源を投入します（WAN スイッチ用、LAN スイッチ用）。
　このとき、SonicWALL には電源をまだ入れないでください。

2. WAN スイッチ用のハブにケーブルを接続し、主格機および副格機の WAN ポート (X1) にそれぞれストレートケーブルを繋ぎます。

WAN スイッチ用ハブのイメージは以下の写真のとおりです。

3. LAN スイッチ用のハブにケーブルを接続し、主格機および副格機の LAN ポート（X0）にそれぞれストレートケーブルを繋ぎます。

LAN スイッチ用ハブのイメージは以下の写真のとおりです。

4. SonicWALL 主格機に電源を投入します。

5. 主格機と副格機の X4 ポートどうしをクロスケーブルを繋ぎます。
　SonicWALL では、 X4 ポートを HA 構成用に使います。

ここまで設定が終わると、SonicWALL のケーブル接続は次のようになります。

6. SonicWALL 副格機に電源を投入します。

【主格⇔副格の切替動作チェックを行う】

　主格、副格それぞれの SonicWALL にケーブルが正しく接続され、電源が投入されていることを確認したら、いよいよ切替動作チェックを行います。

1. 主格機 SonicWALL の管理インタフェース（企業の設定によって異なるが、たとえば http://192.168.1.1/ ）にログインします。

2. ログイン先が「プライマリ SonicWALL」になっていることを確認し、続いて「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「待機」になっていることを確認します。

　このとき、副格機 SonicWALL のテストランプ（工具マーク）が、青色→オレンジ色に交互に点滅していれば、主格機と副格機の通信が正しく行われていることを示します。

　このとき、バックアップ状況が「なし」になっている場合は、ケーブル接続、または PortShield の設定に誤りがある可能性がありますので、本記事の当該項目をご覧になりながらもう一度お試しください。

3. 管理インタフェースからログアウトし、主格機 SonicWALL の電源ケーブルを抜きます。
10 秒～ 15 秒ほど待ってから、主格機用の管理インタフェース（企業の設定によって異なるが、たとえば http://192.168.1.1/ ）にログインします。

4. ログイン先が「バックアップ SonicWALL」になっていることを確認し、「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「動作」になっていることを確認します。

　このとき、副格機 SonicWALL のテストランプ（工具マーク）が、青色になっていれば、副格機が動作状態になっていることを示します。

5. 主格機 SonicWALL と同じネットワーク状態になっていることを確認し、LAN、WAN アクセスの動作状態を確認してから、管理インタフェースからログアウトします。

　そして、再び主格機 SonicWALL の電源を投入します。

7. 15秒～20 秒ほど待ってから、主格機用の管理インタフェース（企業の設定によって異なるが、たとえば http://192.168.1.1/ ）にログインします。

8. ログイン先が「プライマリ SonicWALL」になっていることを確認し、続いて「高可用性」→「設定」の順に選択し、状況が、以下の赤囲みのように、バックアップ状況が「待機」になっていることを確認します。

　つまり、制御が元の主格に戻ったということになりますね。

　このとき、副格機 SonicWALL のテストランプ（工具マーク）が、青色→オレンジ色に交互に点滅していれば、主格機と副格機の通信が正しく行われていることを示します。

注：
主格機の復旧時に自動的に主格機が稼働するようにするには、「高可用性」→「詳細」で、「先制(プリエンプト)モードを有効にする」ボックスをチェックします。ここをチェックすると、主格機がアクティブな場合、主格機が稼働します。ここがオフになっていると、主格機が復旧しても、主格機は「待機」のままとなります。

【HA構成が動作しているときに、副格機の状態を調べる方法】

　SonicWALL で　HA 構成が確立されて、動作しはじめると、副格機の工場出荷時の設定は主格機の情報で上書きされてしまうため、http://192.168.168.168 で副格機の管理インタフェースに入ることはできなくなります。

この代わりに、主格機側で、管理インタフェース専用の仮想 IP を主格機および副格機に割り当てることによって、管理インタフェースにログインできるようになります。

　手順は以下のとおりです。

1. 主格機 SonicWALL の管理インタフェースにログインします。

2. 「高可用性」→「監視」の順に選択し、監視設定ページに移ります。
　ここで、下図のように X0 ポートの設定アイコンをクリックします。

3. インタフェース 'X0' の監視設定サブページが開きます。

　下図のように、[プライマリIPアドレス]（主格機に割当）、[バックアップIPアドレス]（副格機に割当）に同ネットワーク上で利用可能な IP アドレスを入力してから、[プライマリ/バックアップIP アドレスでの管理を許可する] チェックボックスにチェックを付け、“OK”ボタンをクリックします。

　上記の例では、http://192.168.1.101 で副格機の管理インタフェースにアクセスできるようになります。

以上です。

2011-04-21

SonicWall Global VPN Client のインストールが失敗したり、クラッシュしてしまうときのちょっとした改善案(Windows Vista, Windows 7 編)

　Sonic Wall Global VPN Client (以降 SWGVC) がインストール先の OS によって正しく動作しないという記事を過去に書きましたが、今回、Vista/Windows 7 環境でも不具合が発生することがあったため、裏技的な対応方法をご紹介します。

【現象】(テスト時の SWGVC のバージョンンは 4.2.6.0305)

　SWGVC を起動すると、「Failed to open the IPSec driver.」というエラーメッセージが表示され、接続できない。
　もしくは、SWGVC の起動まではできるが、Enable をクリックすると同様のエラーが表示されるか、接続が Enabled にならない。

【対応方法】

1. スタートメニューより、「コンピュータ」を右クリックしてから「プロパティ」の順に選択し、デバイスマネージャーを開きます。

2. デバイスマネージャーの「表示」メニューより、「非表示のデバイスの表示(W)」を選択します。

3. 左ペインに表示されるデバイスの一覧から、「SonicWall IPSec Driver」を右クリックし、「プロパティ」を選択します。

4. プロパティシートの「ドライバ」タブより、スタートアップの種類を「自動」に変更し、“開始”ボタンをクリックしてドライバを開始させ、コンピュータを再起動します。

5. SWGVC を起動し、接続を試みます。

　当方の場合は、最新版の SWGVC ではどうしても接続がうまくいかなかったため、旧版の SWGVC をインストールしなおし、上記の操作をしてみたところ、正常に接続されるようになりました。

　今までいろいろやってみて、どうしてもうまくいかなかった方は、ダメ元でお試しください。

参考：SonicWall Global VPN Client (GVC) Troubleshooting

2010-09-09

SonicWALLの新製品テクニカルセミナー 2010/08/26

　ブログ記述が遅れてしまいましたが、8月26日(木)に SonicWALL ネットワークセキュリティアプライアンステクニカルセミナーに参加してきました。

　セミナー内容はビジネスセッションとテクニカルセッションの基本的な部分は前回出席した SonicWALL セミナーとほぼ同様で特に真新しいと感じるところはなかったのですが、 SonicWALL が投資家グループ Thoma Bravo およびオンタリオ教師年金基金によって買収されたことにより SonicWALL 社が非上場企業になったことに触れていました。

　今回の買収は、プライベート・エクイティファインドである Thoma Bravo から安定した資金調達を確立することにより、製品ロードマップはそのままに製品開発に注力していくことを目的とした、前向きなものであるということでした。

参考：SonicWALL、7億1700万ドルで投資家グループが買収へ

　SonicWALL UTM 製品で前回のセミナーに追加されていた項目で目についたのは、消費電力の低さで、たとえば NSA 4500(製品情報はこちら)でも消費電力は 66W で、Fortinet の FG310B (製品情報はこちら)の 120W と比較しても約半分の消費電力となっています。

　テクニカルセッションも基本的には前回とほぼ同様の内容でしたが、SSL-VPN 機能について少々詳しい内容が盛り込まれていました。

SSL-VPN 機能の特徴
- Windows, Linux, Mac に対応(IPSec 機能では Windows のみ対応)
- 初回ログイン時に NetExtender モジュールをインストールし、NetExtender が SonicWall に対し SSL で暗号化されたトンネルを構築
- 1 要素認証のみサポート。高度な認証や同時接続ユーザ数が必要な場合は専用 SSL-VPN 装置を用意する必要あり。

参考：Introduction to the SonicWALL SSL VPN 200 (英語)

2010-03-03

SonicWALLの新製品テクニカルセミナー

先日、SonicWALLの新しいTotalSecure TZシリーズ（TZ100/TZ200/TZ210）のセミナーに行ってきた。

セミナーは2時間で最初の一時間がマーケ、後の一時間がテクニカルな内容であった。以下、その備忘録。

マーケ
2008年、UTM製品の国内の出荷台数シェアは、Juniper（NetScreen）、SonicWALL、Fortinet、Cisco、Checkpointの順。　同年の金額によるシェアは、Fortinet、Juniper、Cisco、SonicWALL、Checkpointの順。　Sonicは台数は出てるのに金額が低い、つまり、Sonicは中小向けの安いUTM製品に強みを持っている。

あと、営業さんが資料等で強調していたのは、「他社製品に比べ、コストパフォーマンスがいいですよ」ということ。

テクニカル---新製品の特徴

TZ180以前の機種で標準付属していたSonicOS Standardが無くなり、全機種がEnhanced（5.ｘ）に統合された
TZ180に比しUTMパフォーマンスが2.5～5倍Up（10Mbps→25Mbps～50Mbs）
GAVシグネチャーが上位機種(NSA？)と同等に。　TZ100も？
アプリケーションファイヤウォール（TZ210のみ）
SSL-VPN（ユーザ数：1～10、機種/オプションにより異なる）
冗長構成 --- 予備機(同機種)を一台用意し、障害発生時に切り替えて運用

アプリケーションファイヤウォールは近頃流行らしく、WinnyやSkypeといった企業にとって都合の悪いアプリの通信を遮断、またはユーザ毎に管理できる。　また、企業がブラウザをFirefoxに統一しようとする場合、IEによる通信を遮断してしまい、間接的にFirefoxのインストールを強制する、という使いかたもあるらしい。　社員が一杯いたらGoogle Chrome　をインストールしてシークレットモードで使おうとする不心得者もいる筈だが、どこまでのアプリケーションに対応可能なのか、アプリケーションのシグネチャはカスタマイズできるのかは、次回聞くことにしよう。　確か、カスタマイズはできると記憶している。

エンジニアは、TZより上位のシリーズはマルチコアCPUによりDPI（パケットのIPヘッダ部分だけではなく、データ部分を検査する機能）が高速化されていることを強調していた（が、今回のTZとは関係ないので、"マルチコアアーキテクチャ"と言いたかっただけと違うんかと）。
また、RFDPI(Reassembly Free Deep Packet Inspection)も強調。本機能は、他メーカー機と異なり、パケットをメモリ上に展開すること無く直接検査するため、非常に高速だとか。　こちらはTZシリーズでも採用している。
この2つの機能はSonicWALLの"売り"であるらしく、昨年のハイエンドのE-Class（ベンツかいな）のセミナーでも濃い説明があった。

尚、今回配布された「かんたんUTM導入ガイド」という小冊子(非売品)には、UTMのことがとてもよくまとめられている。　巻末の文言によるとこの小冊子は、アスキーの「NETWORK MAGAZINE」の08/9月～09/2月号でSonicWALLのエンジニアが書いた記事を再編集したもの、とのこと。

以上

見つけモノ
SonicWALLのYouTube動画サイト（英語）

2009-11-30

SonicWALL NSA E-Class セミナー（2009/11/27）

　SonicWALL NSA E-Class テクニカルセミナーに参加してきました。
　NSA E-Class は SonicWALL 製品でも上位クラスに属する製品群で、搭載されている CPU コア数が最大 16 というだけあって、ファイアウォールと UTM を同時に有効にしても平均 1 Gbps 以上のスピードを保持できるという優れものです（ちなみに CPU が 1 個の廉価版 TZ シリーズで出せるパフォーマンスはせいぜい 50Mbps なので、その差は歴然です）。

　NSA E-Class と TZ シリーズとの大きな違いといえば、上記で述べたマルチコア構成の他に　RFDPI (Reassembly Free Deep Packet Inspection) があります。
　SonicWALL に送られてきたパケットを SonicWALL 内部で一度開梱して、それをもう一度再構築して LAN に送るというのが従来の方式ですが、この再構築プロセスによって処理速度が低下してしまうのがネックとなっています。これを解決させたのが RFDPI で、パケットを開梱せずにスキャンを行う分、速度低下が発生しないようになっています。また、従来の方法では開梱したパケットを一時的にメモリに蓄えられるため、ファイルサイズが大きければそれだけメモリを消費することになり、大量のデータを一度に扱う場合はそれだけ処理速度の低下が発生したり、ファイルサイズが大きすぎるために処理不能と判断されドロップされる可能性がありますが、RFDPI なら開梱を行わずにスキャンを行うため、ファイルサイズによって処理速度が左右されることがありません。

参考：SonicWALL NSA E-Classシリーズ概要と構成例

SonicOS 5.0 以降の基本機能について

Layer 2 ブリッジモード
　ネットワーク構成を変えずに、ゲートウェイアンチウィルスやIPS機能を提供

アプリケーションファイアウォール
　アプリケーション別にアクセス制限をかける

Active-Passive ステートシンク　フェイルオーバー
　セッション情報の常時同期を行い、ハードウェア障害時にセッション情報を予備のハードウェアに引き継ぐ。

パケットキャプチャ
　パケットダンプ、HTML/CAP 形式でのパケット情報出力

シングルサインオン
　Microsoft Active Directory にログインするだけで SonicWALL 環境へのアクセスログインを可能に

参考：SonicWALL NSA E-Class シリーズ

SonicWALL による HA (High Availability 高可用性)構成
　現用系と予備系の SonicWALL ユニットを配置し、障害時に予備系の SonicWALL にパケット送信が切り替わるようにする構成方法です。E-Class では障害復旧時にどちらの機器に優先的にパケットを流すかも設定可能です。

構成例：Tokyo FM における HA 構成

Global Management System
　Global Management System をインストールすることにより、セキュリティポリシー一括適応、全ユニットの集中管理/監視、ライセンスの集中管理、リモート管理を可能にし、管理コスト削減を実現します。

参考リンク：
SonicWALL NSAシリーズ価格体系
Macnica Networks

SonicWALL E-Class シリーズ紹介ビデオ（英語）
（今回の東京での講習内容がほぼ網羅されています。）

04:34 Re-Assenbly Free Inspection 解説
05:06 マルチコアデザイン解説
06:15 Active-Passive ステートシンク　フェイルオーバー解説
07:10 Layer 2 ブリッジモード解説
07:19 Wireless スイッチモード解説

2008-12-09

【SonicWALL障害メモ】 IKE Responder: IPSec proposal does not match (Phase 2)

朝、メーラーを起動してみると、SonicWALL の警告の山。

IKE Responder: IPSec proposal does not match (Phase 2) -  221.189.***.***, ***.****.ne.jp -  219.163.***.**** -  192.168.0.66/32 -> 192.168.0.0/24

IKE Responder: No match for proposed remote network address - 221.189.***.***, ***.****.ne.jp - 219.163.***.*** - 192.168.0.66/32←なに、これ？　大体、66なんてアドレスは無いし…


こんなのが1時間に何通も届く。　2ヶ月位前にも同様の現象で、同じ警告メッセージが一杯届いているので、なんとか解決したような気がするけど、思い出せない。　年には勝てないので、ちゃんとメモしよう。

参考サイト
Stange errors on TZ170 with unknown LAN subnet
RE: Problem: Site-to-Site VPN ISA2004 and Sonicwall

◇現象解消 --- 08/12/19追記
あっさり解消した。　ネットワークはSite-to-Siteで、

　　こっちのTZ180（小社）　⇔　あっちのTZ180（客先）

となってて、「こっちのTZ-180」から上記のエラーログが送られてきてたので、こっちに障害があると思い込んだのがそもそも大間違い。　ただ、「あっちの」は客先の奴なので、滅多にいじることも無いわけで、原因となるのは「こっちの」だろうと、例によって思い込んだ。

結論としては、犯人は Panda MOP。　12月初め位からPandaが「アップデートしたのでPC(サーバを含む)を再起動しろ」とメッセージを表示していたが、うちは兎も角、客先のサーバをそう簡単に再起動できるわけもなくしばし放置。結局、この Panda のアップデートがSonicのエラーメッセージの原因だった。　12月某日12時(昼休)、客先に出向き2台のサーバを再起動。　12：00以降、あの警告メールがピッタリとまった。

クッソォ～、おぼえてろよぉ～、　パンダぁ！　ヽ(｀Д´)ﾉウワァァァン

◇メモ見つかる --- 08/12/19追記
上に「2ヶ月位前にも同様の現象で」と書いたが、メモが見つかった。それも堂々とテスクトップに置いてあった。　以下、そのメモ。

VPNの設定/詳細設定がこちらとあちらで全く同じことを確認する

0.254と1.252のSAをOFFにし、エラー継続を確認（0.1と1.253と競合していないことを確認）
0.1と1.253で、SonicOS Standard 3.8.0.3-36s.jpn の一致を確認
0.1と1.253で、MTUの一致確認

ネットワーク＞ルーティング　の誤ったルート設定が原因か？　削除したらエラー解消の模様（08/9/17）

◇今回12月のエラーログ発生時のメモ-- 08/12/19追記
12/13、170/180の2台と客先の180×２台が通信するときに、上記のエラーログを多数受信（但し、客先2台からはこのエラーログを受信していない) 。　亀がNPTの設定を弄ったとうので、4台のNTP設定を一致させるが、現象解消せず。

◇さらに-- 08/12/19追記
上記の英語サイトにもあるように、このエラーはさまざまな要因で起こるようで、発生前後で何か特別な事象が発生していないか、冷静に思い出すことが重要。

（終）

2008-10-09

拠点間VPNネットワークの構築 (1)

一昔前であれば、膨大な初期費用とランニングコストを要した拠点間の高速ネットワーク。　近年の光回線等のブロードバンドと、各種ネットワーク関連機器の普及と低価格化により、従来に比し非常に低価格で実現できるようになりました。今回は最近、小社で手がけた小規模な支店間VPNネットワークの構築について紹介します。

要件定義（お客様、ご要望）

4拠点間+α　VPNネットワーク構築
回線冗長性（ルータや回線障害時に回線を切り替え、業務を継続できること）
主なアプリはFileMaker Pro 5.5
Windows Server 2008 と Terminal Service を導入、支店でも社内LAN並みのパフォーマンスを出すこと
堅牢なセキュリティ環境と集中監視・管理
システム管理者が拠点のネットワークを遠隔保守
初期コストを最小化する
社内システム管理者の負担を最小化
拠点間の通信コスト限りなく０に、そしてスムーズな意思疎通

と、テンコ盛りの要件、しかも低予算...

1.　4拠点間+αのVPNネットワークを構築する

本社、工場、支店、土屋企画、出先ノートPC(緊急対応用)間のVPNネットワークを構築。　このうち、本社、工場、土屋企画間はSite-to-Site VPN（SonicWALL TZ180同士で暗号化）、支店と出先ノートPCはVPNクライアントにGVP(SonicWALL Global VPN Client)を使用。

4.　回線冗長性

万が一の回線やルータ障害の時にも、工場で生産や配送の指図書や送状が照会・印刷できますように。　大分前ですけど、OCNが大規模回線障害で何時間も不通になってる、って、NHKの夜のニュースでやってもやってましたね。　はい、うちも被害者です。

3.　主なアプリはFileMaker Pro 5.5

少しはクライアント/サーバっぽいFileMaker 8.5とか9を使うと、クライアント⇔サーバ間のパフォーマンスもよくなると思うんですけどね…　　お客様の暗黙の（しかも強力な）要請により、既存のFileMaker Pro 5.5/FileMaker Pro Server 5.5によるシステムを継続利用。　既存システムのできる限りの延命も重要なミッションでございます。

4.　Windows Server 2008 と Terminal Service を導入

「2008でFileMaker Pro 5.5が動くん？」　---　Ans：はい、立派に動いてますね。　しかもTerminal Server 上で。　

「印刷は？　ローカルディスク利用は？」　--- Ans：お客さんの環境では、問題なく動作しておりますです。　

「で、Vistaは？」　---　Ans:動くかも…

5.　堅牢なセキュリティ環境と集中監視・管理

SonicWALL　と Panda で、統合的、集中的な管理。企業の社会的信用にかかわるセキュリティ関連リスクの低減に、万全を期しましょう。

6.　システム管理者が拠点のクライアントPCを含むデバイスを保守

遠隔地よりシステム管理者（≒小社）が、サーバ、クライアントPC、ルータ(SonicWALL)、プリンタ等を管理・保守できるようにしています。　請け賜っているのは SonicWALLの保守と各PCのセキュリティ管理だけなのですが、「これ、セキュリティの問題ではありませんね」って言えるまでの調査過程で、大体は原因が判明してしまうんですけどね。

7.　初期コストを最小化する

Dell PowerEdge R300 (RAID 1)
Windows　Server　2008　+　Terminal Service Client ラインセンス
SonicWALL TotalSecure TZ-180 ×　4台
Panda WebAdmin クライアントライセンス（追加ユーザ分）

合計60万位。　既成のハード/ソフトだけでこれだけはどうしてもかかってしまいます（クライアントPCやプリンタは既存のモノで新規導入無し）。　ホントに大変なのは、これらの機器やソフト、PC、プリンタを最適に設定して、テスト、テスト、そしてテスト。この部分は小社の営業努力で･ﾟ･(ﾉД`)･ﾟ･

8. 社内システム管理者の負担を最小化する

経営者　　「システム、特にセキュリティなんかじゃ飯は食えんのよ」

小社　「ごもっともでございます（トホホ...）」

9.　拠点間の通信コストを抑える

IP電話より、Skypeとか、AOL IMの方が、使い勝手も、生産性が高いですね。

(続く)

2008-08-13

SonicWALL を使った Site-to-Site VPN　の構築

　VPN ルータ同士を接続して常時 VPN 接続を確立することを Site-to-Site VPN と言いますが、最近弊社では SonicWALL 同士の Site-to-Site VPN 接続の設定テストを行っています。

　VPN ルータが各終点に一つずつの場合は、比較的設定は容易です。
　基本的には VPN のポリシー設定で「主格 IPSec ゲートウェイ名またはアドレス」に対岸のルータアドレス（ゲートウェイアドレス）を入力し、「事前共有鍵」に任意の共有鍵コード（両方のルータに同じ共有鍵を設定）を指定し、そして「対象先のネットワーク」に対岸 LAN のネットワーク（たとえば 192.168.3.0）とサブネットマスクを指定するだけです。

　しかし、ネットワークが落ちたりすると業務に支障が出るような環境では、回線を複数用意しているところもあります。そのようなときに、現用回線と予備回線の両方に対して VPN トンネルを張っておき、現用回線がダウンしたときに予備回線の VPN トンネルを使うことがあります。これを冗長 VPN ゲートウェイと呼んでいるそうですが、この設定は、理屈では「主格 IPSec ゲートウェイ名またはアドレス」に現用回線のルータアドレス、「副格 IPSec ゲートウェイ名またはアドレス」に予備回線のルータアドレスを指定すれば動くということになっているのですが、何故か副格ゲートウェイの方だけが採用されている状態となりました。主格の方が無視されている状態なので、現在この原因について調査中です。

2008-07-08

SonicWall Total Securityによる回線速度低下

　SonicWall Total Security（以下、SonicWall）を導入し、セキュリティ関連の設定をした後に、回線速度のチェックをすると、導入前に比べて回線速度が低下していることに愕然とするかもしれません。しかし、外部から渡ってきたパケットの精査が SonicWall の機能であり、その精査に費やされる処理時間のことを考慮すれば、回線速度が低下するのは当然と言えば当然なのでしょう。

　以下、SonicWall のセキュリティ機能で、速度低下が著しいものとそうでないものを調べてみました。

導入すると極端に速度が落ちるもの
アンチスパイウェア
侵入防御（IPS）

若干速度が落ちるもの
電子メールフィルタ
ゲートウェイ　アンチウィルス

さほど速度が低下しないもの
コンテンツフィルタ

　もちろん、セキュリティ対策としてできるだけ多くのサービスを有効にしておくのが望ましいと思いますが、社内で利用しているネットワークサービスが使用に耐えられなくなるほど回線速度が落ちてしまうのでは、あまり実用的ではないでしょう。
　社内のネットワーク運用に最も適したサービス設定を行い、セキュリティをどうしても向上させる必要があるのなら、回線そのものの品質をアップグレードさせるのが現実的な運用方法と言えるかもしれません。

2008-07-04

SonicWall Global VPN Client のインストールが失敗したり、クラッシュしてしまうときのちょっとした改善案

　SonicWall には仮想プライベートネットワーク機能（VPN: Virtual Private Network, 以降 VPN）が搭載されているので、SonicWall を購入して VPN ライセンスを購入することによって、VPN 公開ができるようになります。
　この SonicWall VPN にアクセスするためには、クライアントとなるコンピュータに SonicWall Global VPN Client (以降 SWGVC)をインストールと接続設定を行う必要があります。

　インストーラを実行して指示に従えば終わりというパターンが通常で、アプリケーションを使うほとんどのユーザがそのような感覚でインストーラを実行していると思います。
　しかし、最近の FileMaker Server 9 のインストールトラブルのように、物によってはスムーズにインストールできないものもあるので、すぐできて当然という安易な姿勢で臨むと泣きを見る羽目になることもあったりします。

　SWGVC もなかなか癖のあるソフトウェアと言え、マシン環境によってはすんなりインストールできたり、インストール初っ端から躓いたり、設定の段階で躓いたりと結構トラブルに見舞われため、ここでその経験談をまとめてみることにします。

最初のインストールで躓くとき
　SWGVC をインストールした直後に起動しようとすると、SWGVC のレジストリ登録に失敗したというメッセージが出て失敗することがあります。こうなると、起動は絶対にできないので、一度 SWGVC をアンインストールし、さらにレジストリ情報を消去するプログラム SWVPNClientClean.exe を実行してから完全にインストール情報を消去した上で、SWGVC を再インストールする必要があります。

SonicWall にアクセスできないとき
　ピア IP アドレス（SonicWall の IP アドレス）を正しく設定し、接続ユーザ名とパスワードを正しく指定したにもかかわらず、ステータスが接続中だったり、IP アドレス取得中のままになってしまうことがあります。ログを見ると、"The peer is not responding to phase 1 ISAKMP requests." が残っていることがあります。
　この場合は、SWGVC の Peers タブより、LAN Settings にクライアントネットワーク側のルータ IP アドレスを入力したり、NAT Traversal を「Disabled」、Interface Selection を「LAN Only」に変更することによって改善することがあります。

参考リンク：
SonicWall VPN Client Doesn't Work Behind NAT Firewall(英文)
Sonicwall - The peer is not responding to phase 1 ISAKMP requests(英文)
NAT Firewall on router blocking sonicwall VPN?(英文)
NAT Firewall on router blocking sonicwall VPN...(英文)

接続が確立された直後に SWGVC がクラッシュするとき
　これが一番厄介だと思います。今のところ Windows XP Service Pack 2 で発生する可能性が高いことは経験からわかってきたのですが、すべての同様の環境で発生するとも言い切れず、このような現象が発生するコンピュータでは、SWGVC のインストール、アンインストールを繰り返したところで症状が改善することはまずないでしょう。
　しかし先日、客先でどうしてもこのような現象が発生する SWGVC を動かす必要があり、苦し紛れですが Windows 互換モードで実行することにより事なきを得ました。以下、方法を簡単に説明します。
　1) 今までどおり SWGVC を実行させてVPN 接続を行い、Connected が出た直後に SWGVC がクラッシュすることを確認します。
　2)　SWGVC のプログラムアイコンを右クリックして「プロパティ」を選択し、表示されるダイアログより「互換性」タブをクリックします。そこで「互換モードで実行する」にチェックを付けて、以前の OS のリストの中からできるだけ最新のものを選択して実行してみます。

　この方法で、今のところ Windows 98/Windows ME の互換モードで実行に成功しています。今までいろいろ試してみたが、クラッシュしてどうにもならないという方はダメ元で試してみる価値はあると思います。

2008-07-02

SonicWALL (4) --- IPS

前回「SonicWALL (2) --- IPS」で書いた警告メールの続きです。


IPS Detection Alert: IM Skype -- Application Activity, SID: 2800, 優先順位: 低 -  192.168.*.*, 4787, LAN -  204.9.163.158, 80, WAN, 163-158.static.quiettouch.com -
Skype を使用していると普通に送られてくる警告メール。　Skypeの利用を許可している環境では問題無い、Skypeに何らかの穴が見つからない限りですが。　ViewPointでは攻撃としては認識されていない。詳細解説


IPS Detection Alert: POLICY Google SSL Connections, SID: 3075, 優先順位: 低 -  209.85.171.97, 443, WAN, cg-in-f97.google.com -  192.168.*.*, 1774, LAN, **** -
Google Talkがクライアントと行うSSL通信をブロックしている。ViewPointでは攻撃として認識されない。　詳細解説


IPS Detection Alert: DNS BIND Version UDP Request, SID: 143, 優先順位: 低 -  149.20.52.206, 64457, WAN -  192.168.*.*, 53, LAN, **** -
DNSバージョンをチェックするクエリ。通常は無視していいが、自社のネットワーク情報を知られる可能性もある。　詳細解説


IPS Detection Alert: IM AIM -- Login, SID: 102, 優先順位: 低 -  192.168.*.*, 1253, LAN, **** -  64.12.161.185, 5190, WAN -
IPS Detection Alert: IM AIM -- Instant Message Sent, SID: 103, 優先順位: 低 -  192.168.*.*, 3749, LAN, **** -  205.188.12.130, 5190, WAN -   AIMを使用したログイン、またはメッセージ送信の発生を通知する。AIMの利用を許可している場合は無視。　詳細解説　詳細解説　


IPS Detection Alert: MULTIMEDIA Flash Video (FLV) Download 3, SID: 78, 優先順位: 低 -  *.*.*.*, 80, WAN -  192.168.*.*, 4752, LAN, **** -
Flash Video (FLV)はYouTube等で使用されるビデオフォーマット、これをダウンロードしたときに通知される。　詳細解説


IP spoof dropped -  192.168.*.*, 4388, LAN -  205.188.179.233, 5190, WAN -  MAC address: 00:90:cc:c3:06:49
以下、SonicWallのマニュアルから引用
「IP Spoof は、ハッカーが他のコンピュータのアドレスを使って、TCP/IP パケットを送ろうとする、侵入の企てです。保護されたネットワークに、そのネットワーク上のマシンの IP アドレスを使ってアクセスするために利用されます。SonicWALL では、これを侵入の企てとして認識し、それらのパケットを破棄します。SonicWALL の構成が間違っていると、IP Spoof の警告がログされることがよくあります。IP Spoof の警告
を見つけた場合には、LAN、WAN および DMZ 上の IP アドレスがすべて正しいことを確認してください。LAN 上の IP アドレスが LAN のサブネットに入らない場合にもIP Spoof の警告が出ることがあります。」


IPS Detection Alert: SMTP Reply-To Pipe Passthrough, SID: 1888, 優先順位: 低 -  194.150.164.130, 29174, WAN -  192.168.*.*, 25, LAN,  - 
旧Sendmailのバグを利用してコマンドを実行させる攻撃の可能性。SonicWallはこの攻撃を排除する。　詳細解説

以上

2008-06-20

SonicWALL (3) ---ログ分析ツールViewPointインストールで泣く

前回書いたようにSonicWALLには通信を監視し、「問題あり」とみなした通信内容を警告メールとしてネットワーク管理者に送付することができます。　ただ、この警告メールが大量に届くため、管理者がこれを逐一読むのはまず無理です。　そこでSonicWALL Total Security には、ViewPoint というログ分析ツールが無料で付属してきます。　この ViewPoint　ですが、ある一定の環境下は簡単にインストールできます。　しかし一定以外の環境では、多分、嵌ります。　一定以外の環境とは？　私が思うに SQL-Server インスタンスが複数動いている環境はマズイのではないかと。　

以前、 SQL-Server インスタンスが既に2つ存在するWindows　2003　に ViewPoint 4.0 をインストールしようとしたのですが、途中までいくとMSDE(Microsoft SQL-Server Desktop Engine、ViewPointのログ保存用データベース)へのログインの画面で認証に失敗し、続行できなくなりました。　表示されたエラーメッセージには、「後で\ViewPoint4\bin\postInstall.batを実行してインストールを続行できます」みたいなことが出ているので、インストールを一旦中断。　ただ、その後に postInstall.bat を実行しても、全く同じ状況でMSDEの認証で弾かれてしまいます。　で、サポートに電話したのですが、「そのような事例はあるのですが、解決方法は記されていません」の一言。　「おい、おい、　それで終わりかい？」（心の声）
その時は忙しかったので、既存のSQL-ServerインスタンスがないXP機に ViewPoint 4.0 を入れてしまいました。　こちらは全く問題無くインストール終了。

で、最近改めて件のWindows 2003機へ ViewPoint のインストールをトライしてみました。　前回失敗したときにアンインストールをしたみたいだったので、インストーラの VPS_JP.exe を再度実行。　「もしや今度はすんなりと完了するのでは…」という儚い望みはあっさり裏切らせ、前回と同じメッセージ。　しかたんくインストーラを終了して、上記の postInstall.bat を実行してもやっぱり駄目。　ここまでは前回と同様なので、トラブルシュートする腹を決めました。　まず「サービス」を起動してSQL-Serverインスタンス（サーバ名\SNWL）が存在することを確認。　また、インストール時に指定したディレクトリにMSDEが存在することも確認。では、ViewPoint4\MSDE\Data\MSSQL$SNWL\Data\　内に存在する筈のViewPoint 用の.mdfと.ldｆファイルは…と思って探しても無い。　あるのは、master/msdb/model/tempの4つのシステムファイルだけ。　SQL-Server Management Studio Express を起動して見ても、やはりこの4ファイル以外は無し。　先に成功したXP内のDataディレクトリには sgmsdb.mdf 他のViewPoint用ファイルがあるのに。
ここにきて、データベースのインストールに失敗していることが判明。　そこでググってみると、灯台下暗し「SonicWALL ViewPoint ユーザーズガイド」にたどり着く。　このガイドは ViewPoint 2.5 用でエラーのメッセージの出方も違うけど、第六感的にはぴったし。　P.157以降に解決策というのが書いてあります。　以下、上記マニュアルを引用。

********************　引用始　********************
ViewPoint が MSDE データベースの場所を見つけることができない
問題
SonicWALL ViewPoint 2.0 のインストールで、MSDE データベースが見つからない場合、次のようなアップグレード失敗を通知するメッセージが表示され、インストールはフェーズ 2 で失敗します。
[DBNETLIB]SQL Server does not exist or access denied. [DBNETLIB]ConnectionOpen (Connect()).
Java doesn't recognize the MSDE database using the URL "127.0.0.1\SNWL". This is an issue on some Windows 2000 servers.
解決策
次の手順を実行し、インストールを続行します。
1. 「キャンセル」を選択して、フェーズ 2 のインストールを終了します。
2. コマンドプロンプトから、「SQL Server Network Utility」（SVRNETCN.EXE）を実行します。一般的に、このプログラムは、C:\Program Files\Microsoft SQL Server\80\Tools\Binn フォルダ内にあります。
3. 複数の SQL サーバインスタンスがシステム上で稼動している場合は、「Instance(s) on this server」リストボックスに複数のインスタンスが表示されます。リストボックスから、サーバ名\SNWL の項目を選択します。
4. 「Protocols」リストから「TCP/IP」を選択し、「Properties」を選択します。
5. ポート番号を記録します。
6. メニューを終了します。
7. c:\sgmsConfig.xml ファイルと \Tomcat\webapps\sgms\WEB-INF\web.xml ファイルに以下の修正を行います。
dbURL の値を、"127.0.0.1/SNWL" から "localhost:ポート番号" へ変更。
dbhost の値を、 "127.0.0.1\SNWL" から "127.0.0.1" へ変更。
技術的ヒントとトラブルシューティング 157
8. \SQL\bldMSDB.bat に、以下の修正を行います。
User の値を sa に変更。
Password の値を <フェーズ 1で選択したデータベースのパスワード> に変更。
9. コマンドプロンプトで、\SQL フォルダへ移動し, bldMSDB.bat プログラムを実行して MSDE データベースをインストールします。
10. \Temp へ移動し、次のプログラムを実行して「SNWL ViewPoint Summarizer」サービスと「SNWL ViewPoint Syslogd」サービスをインストールします。
schedInstall.bat
vpInstall.bat
11. \Tomcat\bin へ移動し、次のプログラムを実行して「SNWL ViewPoint Web Server」サービスをインストールします。
tomcat.bat install
12. Windows システムを再起動

********************　引用終　********************

上記ステップの8までは問題なく実行できたんですが、ステップ9　bldMSDB.bat　が失敗してしまう。　SQL-Serverの認証方法がWindows認証になっているのが問題か？、と思い、認証を混合モードに変更してもやはり駄目。　仕方が無いので、bldMSDB.bat を開いてみると、その中で大量の.sqlファイル群を実行していて、しかも最初の行(sgmsdb.sqlの実行)から失敗している。　で、sgmsdb.sql　では何をしてるかというと、

　　　　　　USE master;

どうもここから失敗している。　コマンドプロンプトを開いて、

　　　　　　osql -U sa -P password -S 127.0.0.1\snwl

とやると失敗してしてしまう。　そこで、

　　　　　　osql -U sa -P password -S computer_name\snwl

とすると成功（computer_nameはWindows のコンピュータ名）。　そこで、どうやらこのループバックアドレス（127.0.0.1）がおかしいらしいと見当をつけて、以下を実行。

上記ステップ8にある「127.0.0.1」と「localhost」を「computer_name」に変更。
bldMSDB.bat をメモ帳で開き、すべての「127.0.0.1」を「computer_name」に置換。

上記を実行すると、上記マニュアルのステップ9～12はスムーズに終了し、Windows 2003起動してデスクトップに作成された SonicWALL ViewPoint 4.0 を実行すると、ブラウザに ViewPointの認証画面が表示されるようになり、デフォルトのID:admin、Password:password と入力することにより、ログインできました。　めでたし、めでたし。

2008-06-14

SonicWALL (2) --- IPS

SonicWall Total Security シリーズには、IPS(Intrusion Prevention System、不正侵入防御システム)が付属してきます。　これは SonicWALL 上の通信を監視し、悪意または不正な行為を検知・遮断する機能です。　通常のファイヤウォールは各ポートの通信を許可・不許可するだけですが、IPSはファイアウォールが許可したポートの通信の内容までも、シグネチャーデータベースに照らして監視します。ネットワーク管理者は SonicWALL の IPS が検知した不正または不正の可能性を含む通信の概要を警告メールとして送信するように設定することができます。　実際メール送信するように設定すると、やたら多くの警告メールが届き、困惑することになります。

よくある警告メール
警告メールの中を見ると、不正またはその可能性がある通信の内容の概要と、その危険度を低、中、高で示されています。　以下、ありがちな警告メールとその説明。

IPS Detection Alert: ICMP Destination Unreachable (Port Unreachable), SID: 310, 優先順位: 低 - 89.178.40.145, 17127, WAN, 89-178-40-145.broadband.corbina.ru - 192.168.*.*, 59367, LAN, ****** -
　外部からのＩＣＭＰパケットがＳｏｎｉｃＷａｌｌの内側のホストに届かなかった場合に発生。　危険度は「低」。あまり気にする必要はないが、ＤoS攻撃やネットワーク構成の探知が行なわれている可能性もある。頻発する場合は要注意。詳細解説


IPS Detection Alert: PROXY-ACCESS SOCKS 5 outbound proxy access, SID: 1775, 優先順位: 低 - 192.168.*.*, 38248, LAN, ***** -  219.160.253.130, 8558, WAN -
　SOCKS Protocol version 5のプロキシサーバへアクセス。攻撃ではないので無視。詳細解説

IPS Detection Alert: ICMP Time-To-Live Exceeded in Transit, SID: 352, 優先順位: 低 - 192.35.246.1, 53, WAN - 192.168.*.*, 1091, LAN -
IPデータグラムが断片化されて相手先ホストに送信されたため、一つ以上の断片化されたデータが未着となっているため、SonicWALLがデータ待ちをしない状態となる。　通常は無視してよいが、ＤoS攻撃やネットワーク構成探知行為の可能性もある。　詳細解説

Possible port scan detected -  210.248.168.20, 443, WAN, kanri.shopserve.jp -  *.*.*.*, 6887, WAN, ****** - TCP scanned port list, 6755, 6769, 6833, 6845, 6861

Possible port scan detected -  203.77.186.119, 80, WAN, cds32.tyo.llnw.net -  *.*.*.*, 1277, WAN, *.*.*.jp - TCP scanned port list, 1263, 1267, 1271, 1273, 1275
クラッカーが侵入準備のために行うポートスキャン、但し、管理目的のことが多い模様。
***.tyo.llnw.net からは非常に多くのアクセスがあるが、Microsoft Windows Update が使用しているミラーサイト(負荷分散サイト)との推定あり。



SonicALERTの全種別一覧http://software.sonicwall.com/applications/ips/index.asp?ev=cat

2008-05-30

SonicWALL (1)

UTM (統合脅威管理=Unified Threat Management)　という言葉ですが、日本ではいまひとつ馴染みが無いようです。　言葉としてもいまいちな感じ。　Integrated Secrurity Appliance とか、All-in-one Security Mnagement Device とか、Security という言葉を入れたほうがピンとくると思うのですが。　認知度が低いのはネーミングが悪いせいかどうかは兎も角、UTM製品名で検索をかけてもヒットするのは宣伝・広告ばかりで、日本のIT関連メディアやユーザサイドからの情報は、今のところ多くはありません。　したがって、運用に際してはには、英語のサイトに頼ることが多くなります。

さて、当方で使用しているのはSonicWALL Total Secure TZ-180というUTMです。　この製品はインターネットとLANの間に配置され、インターネットとLAN間の通信を監視し、設定した内容に従い、許容されていない通信パケットを破棄するとともに、VPNによりパケットの暗号化も行います。通信パケットの管理/暗号化は、ファイアウォール、VPN、ゲートウェイアンチウィルス、アンチスパイウェア、IPS、コンテンツフィルタリングにより行います。　また、ログ解析機能（ViewPoint）/警告メール送信機能も付属しています。

このうち、ゲートウェイアンチウィルス/アンチスパイウェアはhttp/ftp/smtp/POP3といったプロトコル（メーカーの謳い文句による50以上）を監視し、ウィルスやスパイウェアを発見すると除去します。　ただ、ゲートウェイアンチウィルスがあれば個々のPC/サーバにウィルス等のマルウェア対策が必要ないかというとそうではなく、個々のPC/サーバでもやはり対策が必要だと思います。　テロや外国人犯罪を防ぐのに飛行場や港湾といった水際の対策だけではなく、国内に侵入された場合にそなえ個人レベルの警戒も重要、というのと同義でしょう。厭な世の中ですが、破壊・犯罪を防ぐためには仕方がありません。

コンテンツフィルタリングは有害サイトへのアクセスを防ぎます。　一見すると子供向けの機能のようですが、有害サイトにはマルウェアが埋め込まれていることが多く、アクセスするだけで感染することもあります。　有害サイトへのアクセス遮断はマルウェアの侵入を防ぐ意味もあります。

ファイヤウォールとIPS（Intrusion-prevention system、侵入防止システム）の違いですが、一般のファイヤウォールはIPとポートへのアクセスを許可/拒否するように設定できますが、許可しているポートへの通信は、その通信パケットの中に悪意の命令が埋め込まれていても通してしまいます。　その結果、例えば、バッファオーバーフローを起こし、PCの動作異常や異常終了を引き起こしてしまったり、データベースのデータを改竄・消去されてしまったり（SQLインジェクション）ということも起こりえます。　これに対してIPSは、通常、IPやポートに依存せず、通信パケットのヘッダからデータをシグネチャ(攻撃パターン)データベースに照らして監視し、シグネチャに合致する通信パケットは侵入とみなし破棄します。　SonicWALLのシグネチャは24時間自動アップデートされ、新たな攻撃パターンをデータベースに記録します。

参考
Intrusion-prevention system（Wikipedia/英語版）
シグネチャを超えたプロアクティブな防御を――チェック・ポイントが戦略披露

土屋

登録: 投稿 (Atom)

メニューバー