SC：対策技術 - 防御・侵入検知 のバックアップ(No.11)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• SC：対策技術 - 防御・侵入検知 へ行く。
  • 1 (2019-08-30 (金) 20:05:08)
  • 2 (2019-08-30 (金) 20:36:52)
  • 3 (2019-08-31 (土) 13:25:36)
  • 4 (2019-08-31 (土) 18:56:00)
  • 5 (2019-08-31 (土) 19:07:05)
  • 6 (2019-09-01 (日) 14:01:55)
  • 7 (2019-09-01 (日) 15:18:46)
  • 8 (2019-09-01 (日) 20:23:18)
  • 9 (2019-09-01 (日) 21:13:54)
  • 10 (2019-09-03 (火) 21:18:30)
  • 11 (2019-09-07 (土) 16:55:23)
  • 12 (2019-11-02 (土) 19:21:09)
  • 13 (2019-12-03 (火) 09:49:06)
  • 14 (2020-01-04 (土) 12:35:41)
  • 15 (2020-02-14 (金) 19:55:47)
  • 16 (2020-09-29 (火) 22:12:00)
  • 17 (2020-10-09 (金) 11:37:04)
  • 18 (2020-10-12 (月) 12:51:49)
  • 19 (2020-10-13 (火) 16:06:09)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

下記のように分類される。

防御 †

• ホスト要塞化
• 脆弱性検査
• トラステッドOS

侵入検知 †

• F/W、WAF

• IDS（不正侵入検知システム）
• IPS（不正侵入防止システム）

• サンドボックス

防御 †

ホスト要塞化 †

サーバーの脆弱性を塞ぐ。

実施項目 †

• パーティション分割
  • OS
  • プログラム
  • データ
  • ログ

• セキュアなファイルシステム
  • アクセス制御
  • 暗号化

• OSインストール
  • 最新版
  • パッチ適用

• アカウントと権限
  • コンピューターに必要なアカウントのみ追加
  • リソースに必要なアカウント / 権限のみ追加
  • 不要なアカウント / 権限の削除
  • 不要なリソースの削除

• デフォルト・ロックダウンからの、
  • 必要なサービスの有効化（最新版）
  • 必要なソフトウェアの追加（最新版）
  • サービス/ ソフトウェアのバージョンアップ
  • サービス/ ソフトウェアへパッチ適用

※ 必要に応じて不要なサービスを停止する。

• 各種ポリシ設定
  （グループポリシーなどで設定）

• 監査ログのポリシ

• パスワードポリシ
  「文字数 / 文字種、ロックダウン回数、パスワードの定期変更」の指定
  「初期値、ユーザIDと同じ、辞書とパスワード辞書、名前、生年月日」の拒否

• , etc.

脆弱性検査 †

ソフトウェア内部の脆弱性（パッチが未提供のもの）

• OS、ミドル
• Webアプリケーション

検査の手法 †

• ホワイト・ボックス
• ブラック・ボックス（通常コチラ）
  以下の様な呼称もある
  • セキュリティ・スキャン
  • セキュリティ・ホール検査
  • 侵入検査、ペネストレーション・テスト
  • ファジング（予測不可能な入力データを与える）

検査の手段 †

• 手動
  • ツールでは検出困難な検査が出来る。

• 自動（ツール）
  • 検出能力に限界がある。
  • 複数の脆弱性を組み合わせた攻撃などは検出できない。
  • 検査結果の分析とサイトに合った対策などは人手が必要。

比較 †

トラステッドOS †

トラステッドOS †

• 軍用システムで用いられる。
• 「TCSEC」の「B Division」に定義されている規約を満たす。
• Common Criteria（CC）内で規定されたセキュリティ機能要件を実装する。

• システムの設定方法や扱いが非常に難しく、大変に高価

セキュアOS †

• Trusted OSの高度なセキュリティ機能を実装しながら、
  民間にも導入しやすいようにいろいろな工夫を施したOS。
• Trusted OSの豊富なセキュリティ機能から、
  民間市場が要求する機能だけを実装するように開発。

• SELinux (Security-Enhanced Linux)
  • トラステッドOSではなく、セキュアOS
  • Linuxディストリビューションではない。
  • Linuxに強制アクセス制御 (MAC)機能を付加するモジュール
  • アメリカ国家安全保障局 (NSA) がGPL下で提供している。
  • Linux(UNIX)は、
    root が乗っ取られると、システム全体に致命的な被害を及ぼす。
    そのため、以下の仕組みを導入し、rootに権限が集中することを防いでいる。
    • Flaskアーキテクチャ（セキュリティーサーバーとアクセスベクターキャッシュ）
    • HTTP、FTPといったプロセスごとにアクセス制限をかける Type Enforcement(TE)
    • rootも含む全てのユーザに関して制限をかけるロールベースアクセス(RBAC)

規格 †

• ISO/IEC 15408
  TCSEC（Trusted Computer System Evaluation Criteria）など
  を元に策定されたCommon Criteria（CC）と呼ばれる評価基準を定めている。

• TCSEC（Trusted Computer System Evaluation Criteria）
  • 米国国防総省のNCSCによって1983年に策定されたセキュリティ評価基準
  • コンピュータシステムの信頼性を図るための指標として用いられている。
  • A1 - D の division、classに分類されたセキュリティ要求レベル
  • レインボーシリーズ : 技術的文書とポリシー文書のセット

• Common Criteria（CC）の主要な概念

• プロテクションプロファイル (PP, Protection Profile)
  セキュリティ要件（要求仕様）を特定する文書（利用者が書く）。

• セキュリティターゲット (ST, Security Target)
  • 製品のセキュリティ性能を特定する文書（利用者が書く）。
  • 製品を評価・認証するための基礎として使用する。

• 評価対象 (TOE, Target Of Evaluation)
  簡単に言えば、ST にセキュリティ主張が記述された製品。

• セキュリティ機能要件 (SFR, Security Functional Requirements)
  • 製品が提供する個々のセキュリティ機能を規定する条文。
  • 標準カタログとして PP や、ST を書くときに使用する。

• セキュリティ保証要件 (SAR, Security Assurance Requirements)
  セキュリティ機能性の主張に製品が準拠していることを保証するために、
  製品開発の間にとられる施策を規定する条文。

• 評価保証レベル (EAL, Evaluation Assurance Level)
  製品の開発過程全般をカバーする保証要件のパッケージ、7段階の厳格さに対応する。

ファイアウォール（F/W） †

種類 †

• パケット・フィルタリング型ファイアウォール
  TCP/IP以下のレイヤでパケット・フィルタリング

• その他、様々なファイアウォール
  • L4スイッチ的なもの、L7スイッチ的なもの。色々ある。
  • Arrayシリーズなどの統合アプライアンスに機能追加したようなタイプのものもある。

• 上記の2つの機能を持つハイブリッド型ファイアウォールもある。

構成例 †

• BBルータ的な構成

• ルータなのでNAPT機能を持つ。
  内部IPを晒さずセキュアになるので、
  F/Wのコンテキストで説明される。

• 非武装セグメント（DMZ）

• 「ノーガード」
  外部公開サーバが野晒

• 「三脚境界」
  DMZ上の外部公開サーバに必要な
  インバウンド・アウトバウンド通信をルーティング

• 「2台のF/Wに挟まれた」
  三脚境界はF/Wが1台だが、F/Wを2台にすることで、
  異なるベンダのF/Wにできるのでセキュリティが強化される。

• 「レベルによって分割された」
  言うなれば「4～脚境界」。
  レベルに応じた分割・設定が可能。

アクセス制御リスト（ACL） †

• ポジティブ・セキュリティ・モデル
  • 別名ホワイト・リスト
  • 基本的にすべての通信をdrop(deny)
  • 必要に応じて、高優先度のacceptを追加。
  • 特定クライアント＆通信のアクセス制御に利用される。

• ネガティブ・セキュリティ・モデル
  • 別名ブラック・リスト
  • 基本的にすべての通信をaccept
  • 必要に応じて、高優先度のdrop(deny)を追加。
  • コンテンツフィルタなど、不特定のクライアント＆通信のアクセス制御に利用される。

防御出来ない攻撃 †

• DoS系の攻撃
• マルウェア侵入後の攻撃
• ソフトウェア側の脆弱性を突いた攻撃

各種拡張機能 †

• ハイパフォーマンス、ギガビット対応
• マルチホーミング（複数のWAN接続経路）
• IPv6、VPN機能、QoS機能

• UTM（統合脅威管理）
  • IDPS機能
  • ゲートウェイ型AV
  • , etc.

• 負荷分散
  F/W型の負荷分散はArrayシリーズなどの
  統合アプライアンスに組み込まれている。

• HAクラスタ
  • ウォーム・スタンバイ、ホット・スタンバイ
  • F/Wの前後にスイッチやLBを配置してクラスタリング。

パケット・フィルタリング型ファイアウォール †

• もともとはインバウンドのパケット・フィルタリング機能
• 最近はアウトバウンドのパケット・フィルタリングも行う。
• ルータや、OS（パーソナル・ファイアウォール）などに付属している。

設定項目 †

以下は設定項目（ACL : アクセス制御リスト）

• No(優先順位)

• 方向 : in, out

• srcアドレス, srcポート
  srcポートにwell-knownを使うFTP(passive)などがある。

• dstアドレス, dstポート
  dstポートは、基本的にwell-knownになる。

• プロトコル : TCP, UDP, ICMP, etc.
  トランスポート層までのプロトコル

• Action : accept, drop(deny), reject

特徴 †

フィルタリング機能が原始的であるため、

• 結果的にACLの設定が難しい。
• ACLの設定ミスも発生し難い。

その他、様々なファイアウォール †

パケット・フィルタリング型ファイアウォールは、L3だが、こちらはL4

種類 †

• サーキットレベル・ゲートウェイ型
  L4スイッチ的に動作する。
  • クライアントを認証し、TCP/IPのコネクションを確立して転送する。
  • ペイロードをチェックしないが、UDPを対象にできる。
  • クライアント・プログラムが、SOCKS拡張に対応している必要がある。
    （SOCKS は、サーキットレベル・ゲートウェイのデファクトスタンダード）

• ダイナミック・パケットフィルタ型
  L4スイッチ的に動作する。
  • クライアントとTCP/IPのコネクションを識別して
  • 当該コネクションに対応するACLを自動登録する。
  • FTP(active)にも対応できる。

• ステートフルインスペクション型
  L4スイッチ的に動作する。
  • ダイナミック・パケットフィルタ型より更に高機能。
  • TCP/IPの通信フローまでをチェックできる。

• アプリケーション・ゲートウェイ、アプリケーション・プロキシ型
  L7スイッチ的に動作する。
  • クライアントとTCP/IPのコネクションを確立、
  • TCP/IPストリームのペイロードをチェックして、
  • 対象プロトコルのコマンドやメソッドなどをフィルタする。
  • TCP、UDP、または ICMP リクエストは処理対象ではないものが多い。

設定項目 †

以下は設定項目（ACL : アクセス制御リスト）

• No(優先順位)

• 方向 : in, out（ただし、下り設定は不要）

• srcアドレス, srcポート
  srcポートにwell-knownを使うFTP(passive)などがある。

• dstアドレス, dstポート
  dstポートは、基本的にwell-knownになる。

• プロトコル : HTTP, FTP, SMTP, etc.
  アプリケーション、セッション層のプロトコル

• ACK : ON or Active OpenのNo.2のみ通す。

• Action : accept, drop(deny), reject

特徴 †

フィルタリング機能が高機能であるため、

• 結果的にACLが設定し易い。
• ACLの設定ミスも発生し難い。

Webアプリケーション・ファイアウォール（WAF） †

こちらは、基本的にL7で、TCP/IPストリームのペイロードを詳細にチェックする。

種類 †

• プロキシサーバー型（≒インライン構成）
• ブリッジ型（≒ワン・アーム構成）
• エージェント型（ISAPやmod_isapiなど）

構成 †

IPSと同じ。

接続 †

• インライン構成 or ワン・アーム構成（後述のIPSと同じ）
• エージェント型はサーバー上なので接続は無し。

拡張 †

※ 後述のIDS、IPSと同じ。
※ 逆に見ると統合アプライアンスに当該機能が実装されている。

限界・課題 †

• 検知機能

• そもそも検知対象が複雑なので、
  検知精度は高くないと言って良さそう。

• Webアプリケーションの脆弱性対策は必要。

• 遮断機能
  • 誤検知による可用性の低下
  • 遮断機能の部分的適用の運用など。

• WAF自体の防御
  • アプリケーション・ゲートウェイ、アプリケーション・プロキシ型
  • 故に、プロミスキャス＆ステルス モードは使用できないので要防御。

• 処理能力、信頼性、可用性
  • 冗長化
  • SNMP監視
  • 無停電電源装置（UPS）
  • クラウド型WAF

侵入検知 †

IDS（不正侵入検知システム） †

• IDSは攻撃パターン（シグネチャ）のDB持っている。
• これを実際の事象と照合してF/Wで検知できなかった攻撃を検知できる。
  • マルウェアの活動
  • ソフトウェアの脆弱性を付いた攻撃

NIDS（ネットワーク不正侵入検知システム） †

• ネットワークを流れるパケットを監視する。

• 構成

• バリア・セグメントに接続
  • サイトに対する攻撃を検知できる。
  • 非武装セグメント（DMZ）に接続する場合、比較に利用できる。

• 非武装セグメント（DMZ）に接続
  • DMZ上のサーバに対する攻撃を検知できる。
  • 最も重要で、且つ、必要最小限の構成

• 内部セグメントに接続
  • 侵入後の攻撃を検知できる。
  • マルウェア、持込PC、内部犯行などが対象になる。

• 接続
  スイッチに横付けに配置するワン・アーム構成。

• パケット・キャプチャ・ツールを仕掛ける方法と≒。

• ポートミラーをサポートするスイッチを使用する。

• 上記をリピータHUB（ネットワークTAP）、
  スイッチ、統合アプライアンス等に接続。

• NICをプロミスキャス＆ステルス モードに設定する。

• 検知の仕組み
  ウィルス検出の仕組みと、だいたい同じ。

• シグネチャ型
  

• 検知の方法
  DBに登録されているシグネチャとのパターンマッチング

• 検知可能な事象
  ポートスキャン、脆弱性スキャン、
  ソフトウェア脆弱性に対する攻撃（BOF、コマンド）
  パスワード・クラッキング、DoS
  

• 特徴
  定義を最新化する必要があり、
  未知の攻撃を検知できない。

• 拡張
  独自シグネチャの追加登録機能

• アノマリ型
  

• 検知の方法
  プロトコルの仕様からの逸脱したものを異常と検知する。

• 検知可能な事象
  大量に発行されたコマンド
  プロトコル仕様に反したヘッダ、データ
  異常な数の応答パケット

• 特徴
  未知の攻撃を検知できるが、
  誤報が多くなる可能性に留意する。

• 拡張
  攻撃ではなく、脆弱性≒アウトバウンドのパケットに着目した検知
  前後のセッションを保存・分析した検知品質向上（×機械学習、深層学習）

• その他の拡張
  • ハイパフォーマンス、ギガビット対応
  • マルチ・インターフェイス・モニタリング
  • 暗号化パケットの復号化
  • IPv6、その他のプロトコルへの対応
  • 負荷分散、HAクラスタ

※ 逆に見ると統合アプライアンスに当該機能が実装されている。

HIDS（ホスト不正侵入検知システム） †

• ホストにインストールして使用する。

• 検知の仕組み
  常駐して監視して、OSレベルで検知可能なものを拾う。
  （それ以上の機能は、サーバー版のエンドポイント対策で行う）

• 検知可能な項目

• ログイン・ログオフの成功/失敗

• プログラム
  • 管理プログラム起動
  • 特権ユーザへの昇格
  • インストール

• ファイル・アクセス（変更・削除）
  • システム・ファイル
  • コンフィグ設定
  • Webコンテンツ

• NIC上で検知できるネットワーク攻撃

NIDSとHIDSの比較 †

• NIDSとHIDSの比較

  1	項目				NIDS	HIDS
  2	導入方法				監視対象セグメントへの接続	ホストへのインストール
  3	監視方法				パケットキャプチャと同じ	OS機能を利用して監視
  4	防御方法				接続制限・セッション切断	各種アクセス制限、リソース復元
  5	検知可能な攻撃
  	-1	ネットワーク		ポートスキャン	〇	〇
  	-2			DoS攻撃		△
  	-3	-a	インジェクション	BOF攻撃		△
  		-b		コマンド
  		-c		SQL
  	-4	ログイン			△	〇
  	-5	ローカル		リソース・アクセス	×
  	-6			プログラムのインストール
  	-7			ファイルの改ざん
  	-8			メール送信		×

• 検知の分類と対応するアクション

  #	検知の分類		対応するアクション	NIDS	HIDS
  1	-1	通知・記録	コンソールへのアラート	〇	〇
  	-2		メールでのアラート	〇	〇
  	-3		SNMPトラップ	〇	〇
  	-4		ログ（ローカル）	〇	〇
  	-5		ログ（サーバ）	〇	〇
  2	-1	接続制限・セッション切断	TCP/IPコネクションの切断（RST）	〇	－
  	-2		UDP, ICMP遮断（ICMP port unreachable）	〇	－
  	-3		F/WのACLの動的変更	〇	－
  	-4		アカウント制限（アカウントロック、権限昇格制限）	－	〇
  	-5		リソースへのアクセス制限	－	〇
  	-6		パケットの破棄	－	〇
  3		プログラムの実行・停止	プログラムの実行・停止	－	〇
  4		ファイル・レジストリの復元	ファイル・レジストリの復元	－	〇

限界・課題 †

• NIDS

• 誤検知への対応が必要

• フォールス・ポジティブ
  誤検知のケース（正常なアクセスを攻撃と認識）。

• フォールス・ネガティブ
  誤検知ではなく、攻撃を検知できないケース。

• 機能・性能的な問題
  • 暗号化されたパケットは解析できない。
  • 攻撃は検知できても、侵入は検知できない。
  • 処理能力不足によるパケット取りこぼし

• 検知できない事象
  • ホスト上の攻撃は検知できない。
  • ネットワーク攻撃は検知できても、侵入は検知できない。
  • アプリケーションに対するネットワーク経由の攻撃を検知し難い。
  • 正当な権限を持って行われる内部犯行は検知できない。

• HIDS

• 機能・性能的な問題
  • OSが検知できない攻撃は検知できない。
  • 攻撃の予兆を検知できない。
  • ホストの性能やパフォーマンスに悪影響を与える。

• 検知できない事象
  • ホスト経由の攻撃は検知できないケースがある。
  • 正当な権限を持って行われる内部犯行は検知できない。

IPS（不正侵入防止システム） †

基本的に、IDSに防止機能を実装したもの。

NIPS（ネットワーク不正侵入防止システム） †

NIDSとの違い。

• 遮断機能があるため、
  • F/Wと
    • ≒な、インライン構成が可能（主流）
    • 連携するタイプではワン・アーム構成が可能

• 誤検知が発生しないよう、検知制度を高めている。
• （検知後アクションなどの）ポリシ設定が可能。

• 構成と接続

• 構成
  • 非武装セグメント（DMZ）に接続 or 内部セグメントに接続
  • IDSと異なり、バリア・セグメントには配置しない。

• 接続
  IDSと異なり、インライン構成が主流。

• 機能上の限界と運用上の課題
  • 誤検知のインパクトが大きい
  • インライン構成は信頼性・可用性に影響する
    （NIPS障害時に素通しするフェイル・オープン機能がある）

• F/WやNIDSとの比較
  製品仕様に拠るので答えは一つではないが、
  • それぞれ、F/WやNIDSは専用機のため機能面で劣る。
  • F/Wと連携させたNIDSの方がスペック的には強い可能性がある。
  • ただ、F/WとNIDSを連携させるのが手間と思われる
    （１ベンダの製品でまとめれば対応容易かもしれない）。

HIPS（ホスト不正侵入防止システム） †

HIDSとの違い。

• 各種のエンドポイント対策機能
  • アンチウィルス
  • パーソナル・ファイアウォール(PFW)
  • EDR (Endpoint Detection and Response)
  • ファイル
    • 検査型サンドボックス
    • バックアップ・リストア

サンドボックス †

ダイナミック・ヒューリスティック法（ビヘイビア法）をするための放し飼い用サンドボックス。

機能 †

一般的なサンドボックスの機能、アプリケーション分離・仮想化を行うのではなく、
正規のアプリがデータを受信する前に、検査アプリで検証する見たいな話しッポイ。

• メール検査
  POPでのメール受信時。
  • 添付ファイルのチェック
  • URLのチェック

• ファイル検査 SMBでのファイル受信時。
  • ウィルス・チェック

• HTTP通信検査 HTTPでのデータ受信時。

• メール・HTTP通信検査連携

限界・課題 †

IDSの以下の限界・課題と同じ。

• 誤検知への対応が必要
• 機能・性能的な問題

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.099 sec.