IOS デバイスの強化

はじめに

このドキュメントでは、Cisco IOS^®システムデバイスを保護し、ネットワーク全体のセキュリティを強化する方法について説明します。

前提条件

要　件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景

Cisco IOSシステムデバイスを保護すると、ネットワークの全体的なセキュリティが向上します。

ネットワークの全体的なセキュリティは、ネットワークデバイスの機能を分類できる3つのプレーンで構成されています。 ネットワークの3つの機能プレーンは、管理プレーン、コントロールプレーン、およびデータプレーンです。各プレーンは、保護する必要のある異なる機能を提供します。このドキュメントでは、各機能の概要と関連ドキュメントへの参照を示します。

• 管理プレーン：管理プレーンでは、Cisco IOSデバイスに送信されるトラフィックが管理されます。管理プレーンを構成するのは、アプリケーション、およびセキュアシェル(SSH)、Simple Network Management Protocol(SNMP)などのプロトコルです。
  
  
• コントロール プレーン：ネットワーク デバイスのコントロール プレーンでは、ネットワーク インフラストラクチャの機能性の維持に重要なトラフィックが処理されます。コントロールプレーンは、ボーダーゲートウェイプロトコル(BGP)や内部ゲートウェイプロトコル(IGP)などのネットワークデバイス間のアプリケーションおよびプロトコルで構成されます。 Enhanced Interior Gateway Routing Protocol(EIGRP)とOpen Shortest Path First(OSPF)も含まれています。
  
  
• データ プレーン：データ プレーンでは、データがネットワーク デバイス経由で転送されます。データプレーンには、ローカルCisco IOSデバイスに送信されるトラフィックは含まれません。

多くの場合、このドキュメントで説明するセキュリティ機能は、ここで説明する機能を設定するのに十分な詳細情報を提供します。ただし、詳細が不明な場合は、機能に対する追加の注意が必要かどうかを評価できるように説明します。このドキュメントでは、可能かつ適切な場合に、ネットワークの保護に役立つ推奨事項について説明します。

セキュアな運用

セキュアなネットワーク動作は、重要な課題です。このドキュメントの大半は、Cisco IOS デバイスの安全なコンフィギュレーションについて説明していますが、ネットワークを完全に保護するためにはコンフィギュレーションのみでは不十分です。基本となるデバイスのコンフィギュレーション同様に、ネットワークで使用される操作手順も、セキュリティにとって大きな役割を果たします。

下記のトピックに含まれる操作上の推奨事項を実装することを推奨いたします。下記のトピックでは、ネットワーク動作の重要領域に個別に焦点を当てていますが、すべてを網羅しているわけではありません。

Ciscoセキュリティアドバイザリとレスポンスの監視

Cisco Product Security Incident Response Team(PSIRT)は、シスコ製品のセキュリティ関連の問題に関する資料（一般にPSIRT Advisoriesと呼ばれる）を作成および保守します。あまり重大ではない問題の通知には、Cisco Security Response が使用されます。セキュリティアドバイザリとレスポンスは、Cisco Security Advisoriesから入手できます。

通知方法についての詳細は、『シスコセキュリティ脆弱性ポリシー』を参照してください。

セキュアなネットワークを維持するには、リリースされているシスコセキュリティアドバイザリとレスポンスを確認してください。ネットワークを危険にさらしかねない脅威を評価できるように、脆弱性に関して知っておく必要があります。この評価プロセスについては、『セキュリティ脆弱性のリスクトリアージに関するアナウンス』を参照してください。

認証、認可、アカウンティングの活用

ネットワーク デバイスをセキュリティで保護するには認証、認可、およびアカウンティング（AAA）フレームワークが重要です。AAA フレームワークでは、管理セッションの認証が行われると同時に、特定の管理者定義コマンドに対してユーザが制限され、すべてのユーザが入力したすべてのコマンドが記録されます。AAA の利用については、このドキュメントの「認証、認可、アカウンティングの使用」の項を参照してください。

ログ収集と監視プロセスの一元化

セキュリティインシデントに関連する現在、緊急、過去のイベントに関する知識を得るには、イベントログと関連付けの統合戦略が必要です。この統合戦略では、すべてのネットワークデバイスからのログを活用し、パッケージ化されたカスタマイズ可能な相関機能を使用する必要があります。

一元化されたログを実装した後は、ログ分析とインシデント追跡のための構造化されたアプローチを開発する必要があります。組織のニーズに応じて、ログ データを入念に見直すというシンプルなものから、高度なルールベースの分析までさまざまな方法をとることができます。

Cisco IOSネットワークデバイスにログを実装する方法についての詳細は、このドキュメントの「ロギングのベストプラクティス」セクションを参照してください。

セキュアなプロトコルの使用（可能な場合）

機密のネットワーク管理データを伝送するために、複数のプロトコルが使用されます。可能な限り、セキュアなプロトコルを使用してください。安全なプロトコルの選択には、Telnetの代わりにSSHを使用することが含まれるため、認証データと管理情報が暗号化されます。また、設定データをコピーする際には、セキュアなファイル転送プロトコルを使用します。たとえば、FTP や TFTP の代わりに、Secure Copy Protocol（SCP）を使用します。 

Cisco IOS デバイスの安全な管理についての詳細は、このドキュメントの「インタラクティブ管理セッションの保護」の項を参照してください。

NetFlow によるトラフィック情報の取得

NetFlowを使用すると、ネットワーク上のトラフィックフローを監視できます。NetFlowは本来、トラフィック情報をネットワーク管理アプリケーションにエクスポートすることを目的としているため、ルータのフロー情報を表示するためにも使用できます。この機能によって、ネットワークをどのようなトラフィックが通過しているかをリアルタイムで表示できます。フロー情報がリモートコレクタにエクスポートされているかどうかに関係なく、必要に応じてリアクティブに使用できるようにNetFlowのネットワークデバイスを設定することをお勧めします。

この機能についての詳細は、このドキュメントの「トラフィックの識別とトレースバック」セクションおよび「Cisco IOS NetFlow」を参照してください。

注：内部ツールと情報にアクセスできるのは、登録されたシスコユーザだけです。

構成管理

コンフィギュレーション管理は、コンフィギュレーションの変更を提案、検討、承認、および展開するプロセスです。Cisco IOSデバイスのコンフィギュレーションのコンテキストでは、コンフィギュレーション管理の2つの側面、つまりコンフィギュレーションアーカイブとセキュリティが重要です。

設定アーカイブを使用して、ネットワークデバイスに加えられた変更をロールバックします。セキュリティのコンテキストでは、コンフィギュレーションアーカイブを使用して、セキュリティに対する変更の内容と、それらの変更が行われた日時を確認することもできます。AAAログデータとともに、この情報はネットワークデバイスのセキュリティ監査に役立ちます。

Cisco IOS デバイスのコンフィギュレーションには、詳細な機密情報が多数含まれます。このような機密情報の例としては、ユーザ名、パスワード、アクセスコントロールリスト(ACL)の内容などがあります。Cisco IOSデバイスの設定のアーカイブに使用するリポジトリを保護する必要があります。この情報へのアクセスがセキュリティで保護されていない場合、ネットワーク全体のセキュリティが損なわれる可能性があります。

管理プレーン

管理プレーンは、ネットワークの管理目標を実現する機能で構成されます。SSH を使用するインタラクティブ管理セッションや、SNMP または NetFlow による統計情報収集がこれに含まれます。ネットワークデバイスのセキュリティを考慮する場合、管理プレーンを保護することが重要です。セキュリティインシデントが管理プレーンの機能を損なう可能性がある場合は、ネットワークを回復または安定させることはできません。

このセクションでは、管理プレーンの強化に役立つ Cisco IOS ソフトウェアのセキュリティ機能とコンフィギュレーションについて、詳しく説明します。

管理プレーン全般の強化

管理プレーンは、デバイスのアクセス、設定、および管理に使用され、デバイスの動作とデバイスが導入されているネットワークを監視します。管理プレーンでは、これらの機能の動作のためのトラフィックを送受信します。コントロールプレーンの動作は管理プレーンの動作に直接影響するため、デバイスの管理プレーンとコントロールプレーンの両方を保護します。管理プレーンで使用されるプロトコルには、次のものがあります。

• 簡易ネットワーク管理プロトコル
• Telnet
• Secure Shell Protocol（SSH）
• File Transfer Protocol（ファイル転送プロトコル）の略。
• ハイパーテキスト転送プロトコル/セキュアハイパーテキスト転送プロトコル

• トリビアル ファイル転送プロトコル（TFTP）（Trivial File Transfer Protocol）＃とりびあるふぁいるてんそうぷろとこるTFTP＃
• Secure Copy （SCP）プロトコル
• TACACS+
• RADIUS
• NetFlow
• ネットワーク タイム プロトコル
• Syslog

セキュリティ障害の発生時に管理プレーンとコントロール プレーンに影響が及ばないように、手段を講じる必要があります。これらのプレーンのいずれかが悪用されると、すべてのプレーンが侵害される可能性があります。

パスワード管理

パスワードにより、リソースやデバイスへのアクセスが制御されます。これは、要求の認証に使用されるパスワードによって実現されます。リソースまたはデバイスへのアクセス要求を受け取ると、その要求に対してパスワードとIDの検証を求めるチャレンジが行われ、その結果に基づいてアクセスを許可、拒否、または制限できます。セキュリティのベスト プラクティスとして、パスワードの管理には TACACS+ または RADIUS 認証サーバを使用する必要があります。ただし、TACACS+またはRADIUSサービスに障害が発生した場合でも、特権アクセス用にローカル設定されたパスワードが必要です。また、デバイスのコンフィギュレーション内には、NTP キー、SNMP コミュニティ ストリング、ルーティング プロトコル キーなど、他のパスワード情報が存在することもあります。

enable secretコマンドを使用すると、Cisco IOSシステムへの特権管理アクセスを許可するパスワードを設定できます。古い enable password コマンドではなく、enable secret を使用してください。enable password コマンドには、脆弱な暗号化アルゴリズムが使用されています。

イネーブルシークレットが設定されておらず、コンソールtty回線用にパスワードが設定されている場合、コンソールパスワードを使用して、リモート仮想tty(vty)セッションからでも特権アクセスを受信できます。しかしこれは望ましくないことであり、これも enable secret を設定する理由の一つです。

service password-encryption グローバル コンフィギュレーション コマンドは、Cisco IOS ソフトウェアに対して、パスワード、CHAP（Challenge Handshake Authentication Protocol）シークレット、およびコンフィギュレーション ファイルに保存されている同様のデータを暗号化するように指示します。このような暗号化は、管理者の肩越しに画面を見る場合など、第三者がパスワードを傍受しないようにするのに役立ちます。ただし、service password-encryption コマンドで使用されるアルゴリズムは、単純な Vigenere 暗号です。このアルゴリズムは、ある程度高度な知識を持つ攻撃者による本格的な分析からコンフィギュレーション ファイルを保護する設計にはなっていないため、このような目的では使用しないでください。暗号化されたパスワードを含む Cisco IOS コンフィギュレーション ファイルは、同じパスワードがクリアテキストでのリストになっている場合と同様に注意深く取り扱う必要があります。

この脆弱な暗号化アルゴリズムは、enable secret コマンドでは使用されていませんが、enable password グローバル コンフィギュレーション コマンドや password ライン コンフィギュレーション コマンドでは使用されています。この種類のパスワードは使用せず、enable secretコマンドか、拡張パスワードセキュリティ機能を使用してください。

enable secretコマンドと拡張パスワードセキュリティ機能は、パスワードのハッシュにMessage Digest 5(MD5)を使用します。このアルゴリズムは十分な公開審査を経ており、可逆的であるかどうかは不明である。ただし、このアルゴリズムも辞書攻撃の対象にはなります。辞書攻撃では、攻撃者は辞書やパスワード候補リスト内のすべての単語に対して、一致するものを探します。したがって、コンフィギュレーション ファイルは安全な場所に保管し、信頼できる相手とだけ共有するようにしてください。

高度パスワード セキュリティ

拡張パスワードセキュリティ機能はCisco IOSソフトウェアリリース12.2(8)Tで導入されました。この機能を使用すると、usernameコマンドでパスワードにMD5ハッシングを適用できます。この機能が登場する前は、クリアテキストのパスワードであるタイプ0と、Vigen re cipherのアルゴリズムを使用するタイプ7の2種類のパスワードがありました。拡張パスワード セキュリティ機能は、取得にクリアテキスト パスワードが必要なプロトコル（CHAP など）では使用しないでください。

ユーザパスワードをMD5ハッシングで暗号化するには、username secretグローバルコンフィギュレーションコマンドを発行します。

!

username <name> secret <password>

!

ログイン パスワードのリトライ ロックアウト

ログイン パスワード リトライ ロックアウト機能は Cisco IOS ソフトウェア リリース 12.3(14)T で導入されました。この機能を使用すると、指定した回数だけログインに失敗したローカル ユーザ アカウントをロックアウトできます。ロックアウトされたユーザのアカウントは、解除されるまでロックアウト状態になります。特権レベル15で設定された許可ユーザは、この機能を使用してロックアウトすることはできません。特権レベル15を持つユーザの数を最小限に抑えます。

認可ユーザは、ログインの失敗が既定回数に達した場合に、自身をデバイスからロックアウトできます。また、悪意のあるユーザが、有効なユーザ名を使用して何度も認証を試行することで、サービス拒絶（DoS）状態を作成する可能性があります。

次の例では、ログイン パスワード リトライ ロックアウト機能をイネーブルにする方法を示しています。

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

この機能は、CHAPやパスワード認証プロトコル(PAP)などの認証方式にも適用されます。

ノー サービス パスワード回復

Cisco IOS ソフトウェア リリース 12.3(14)T 以降では、パスワード回復のディセーブル化機能を使用すると、コンソールにアクセスした任意のユーザが、安全ではない状態でデバイスのコンフィギュレーションにアクセスしてパスワードを消去することはできなくなります。また、悪意のあるユーザがコンフィギュレーション レジスタの値を変更したり、NVRAM にアクセスしたりすることもできなくなります。

!

no service password-recovery

!

Cisco IOSソフトウェアでは、パスワード回復手順を提供しています。この手順は、システム起動時にBreakキーを使用するROMモニタモード(ROMMON)へのアクセスに依存しています。ROMMONでは、デバイスソフトウェアをリロードして、新しいパスワードを含む新しいシステムコンフィギュレーションの入力を求めることができます。

現在のパスワード回復手順では、コンソールにアクセスできる任意のユーザが、デバイスとそのネットワークにアクセスできます。パスワード回復のディセーブル化機能により、システム起動時に Break キー シーケンスが中断され ROMmon に入ることができなくなります。

デバイスに対してno service password-recoveryを有効にする場合は、そのデバイス設定のオフラインコピーを保存すること、および設定アーカイブソリューションを実装することを推奨いたします。この機能をイネーブルにした後で Cisco IOS デバイスのパスワードを回復する必要がある場合は、コンフィギュレーション全体が削除されます。

この機能についての詳細は、『ROMmon セキュリティの設定例』を参照してください。

使用していないサービスの無効化

セキュリティのベストプラクティスとして、不要なサービスを無効にします。不要なサービス(特にユーザデータグラムプロトコル(UDP)を使用するサービス)が正規の目的で使用されることはまれですが、通常はパケットフィルタリングで防御されるDoS攻撃やその他の攻撃の起動に使用される可能性があります。

TCPおよびUDPのスモールサービスを無効にします。提供されるサービスには次のものがあります。

• echo（ポート番号 7）
  
  
• discard（ポート番号 9）
  
  
• daytime（ポート番号 13）
  
  
• chargen（ポート番号 19）

スモールサービスの悪用は、アンチスプーフィングアクセスリストによって回避することも、危険性を軽減することもできますが、ネットワーク内でアクセス可能な任意のデバイスでサービスを無効にしてください。Cisco IOSソフトウェアリリース12.0以降では、スモールサービスはデフォルトで無効になっています。以前のソフトウェアでは、 no service tcp-small-serversとno service udp-small-serversグローバルコンフィギュレーションコマンドを発行してディセーブルにできます。

使用しない場合は、無効にする必要がある追加のサービスは次のとおりです。

• Fingerサービス：ディセーブルにするには、no ip fingerグローバルコンフィギュレーションコマンドを発行します。デフォルトでは、Cisco IOSソフトウェアリリース12.1(5)および12.1(5)T以降では、このサービスはディセーブルになっています。
• no ip bootpサーバ ブートストラッププロトコル(BOOTP)を無効にするグローバルコンフィギュレーションコマンド。
• Cisco IOSソフトウェアリリース12.2(8)T以降でBOOTPをディセーブルにするには、グローバルコンフィギュレーションモードでip dhcp bootp ignoreコマンドを発行します。これを実行しても、Dynamic Host Configuration Protocol（DHCP）サービスは引き続きイネーブルのままです。
• DHCP サービス（DHCP リレー サービスが不要な場合）：ディセーブルにするには、グローバル コンフィギュレーション モードで no service dhcp コマンドを発行します。
• Maintenance Operation Protocol（MOP；メンテナンスオペレーションプロトコル）サービス：ディセーブルにするには、インターフェイスコンフィギュレーションモードでno mop enabledコマンドを発行します。
• ドメインネームシステム(DNS)サービス：ディセーブルにするには、no ip domain-lookupグローバルコンフィギュレーションコマンドを発行します。
• パケットアセンブラ/ディスアセンブラ(PAD)サービス（X.25ネットワークで使用）：ディセーブルにするには、グローバルコンフィギュレーションモードでno service padコマンドを発行します。
  HTTP サーバおよびセキュア HTTP（HTTPS）サーバ：HTTP サーバをディセーブルにするには、グローバル コンフィギュレーション モードで no ip http server コマンドを発行します。HTTPS サーバをディセーブルにするには、no ip http secure-server グローバル コンフィギュレーション コマンドを発行します。
  Cisco IOS デバイスが起動時にネットワークからコンフィギュレーションを取得する場合を除いて、no service config グローバル コンフィギュレーション コマンドを使用してください。これにより、Cisco IOS デバイスでは、TFTP を使用してネットワーク上のコンフィギュレーション ファイルの場所が探索されなくなります。
  Cisco Discovery Protocol(CDP)は、ネイバー/アジャセンシー関係およびネットワークトポロジの他のCDP対応デバイスを検出するために使用されるネットワークプロトコルです。CDPは、Network Management System（NMS；ネットワーク管理システム）によって、または問題の切り分けが行われている間に使用できます。CDPは、信頼できないネットワークに接続されているすべてのインターフェイスで無効にする必要があります。これは、no cdp enable インターフェイス コマンドで実行できます。また、no cdp run グローバル コンフィギュレーション コマンドを使用する方法でも CDP をディセーブルにできます。悪意のあるユーザが偵察やネットワークのマッピングにCDPを使用する可能性があることに注意してください。
• Link Layer Discovery Protocol(LLDP)は、802.1ABで定義されたIEEEプロトコルであり、CDPに似ています。ただし、LLDP では、CDP に対応していないデバイス間の相互運用が可能になります。LLDP は CDP と同じ方法で扱う必要があります。非信頼ネットワークに接続しているすべてのインターフェイスでは、LLDP をディセーブルにしてください。これを行うには、no lldp transmitおよびno lldp receiveインターフェイスコンフィギュレーションコマンドを発行します。LLDPをグローバルでディセーブルにするには、no lldp runグローバルコンフィギュレーションコマンドを発行します。また、悪意のあるユーザが偵察やネットワークのマッピングにLLDPを使用する可能性もあります。

• SDFLASHからのブートをサポートするスイッチの場合は、セキュリティを強化してフラッシュからのブートを行い、「no sdflash」設定コマンドでSDFLASHを無効にできます。

EXEC タイムアウト

間隔を設定するために、EXECコマンドインタープリタは、セッションを終了する前にユーザ入力を待機し、exec-timeoutラインコンフィギュレーションコマンドを発行します。アイドル状態のvty回線またはtty回線のセッションをログアウトさせるには、exec-timeoutコマンドを使用します。デフォルトでは、非アクティブ状態が10分間続くとセッションが切断されます。

!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]
!

TCP セッションのキープアライブ

service tcp-keepalive-in と service tcp-keepalive-out グローバル コンフィギュレーション コマンドを使用すると、デバイスから TCP セッションのための TCP キープアライブを送信できます。この設定を使用して、デバイスへの着信接続とデバイスからの発信接続でTCPキープアライブをイネーブルにします。これにより、接続のリモートエンドにあるデバイスに引き続きアクセスでき、ハーフオープンまたは孤立した接続がローカルCisco IOSデバイスから削除されます。

!

service tcp-keepalives-in
service tcp-keepalives-out
!

管理インターフェイスの使用

デバイスの管理プレーンは、物理的または論理的管理インターフェイス上のインバンドまたはアウトオブバンドでアクセスできます。理想的には、インバンドとアウトオブバンドの両方の管理アクセスがネットワークデバイスごとに存在するため、ネットワークの停止中も管理プレーンにアクセスできます。

デバイスへのインバンドアクセスに使用される最も一般的なインターフェイスの1つが、論理ループバックインターフェイスです。ループバック インターフェイスは常にアップ状態ですが、物理インターフェイスの状態は変化することがあり、インターフェイスにアクセスできない可能性があります。ループバックインターフェイスを管理インターフェイスとして各デバイスに追加することを推奨します。このインターフェイスは管理プレーン専用として使用します。これにより、管理者は管理プレーンでネットワーク全体にポリシーを適用できます。デバイスに設定したループバックインターフェイスは、SSH、SNMP、syslogなどの管理プレーンプロトコルでトラフィックの送受信に使用できます。

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

メモリしきい値通知

メモリしきい値通知機能は、Cisco IOSソフトウェアリリース12.3(4)Tで追加されました。この機能を使用すると、デバイスのメモリ不足状態を緩和できます。これを実現するために、この機能ではメモリしきい値通知およびメモリ予約という 2 つの方法が使用されます。

メモリしきい値通知は、デバイスの空きメモリが設定されたしきい値を下回ったことを示すログメッセージを生成します。次の設定例では、memory free low-watermark グローバル コンフィギュレーション コマンドでこの機能をイネーブルにする方法を示しています。これにより、空きメモリ量がしきい値を下回ればデバイスで通知が生成され、しきい値を 5 % 上回ると再度通知が生成されます。

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

メモリ予約が使用されているため、重要な通知に十分なメモリを使用できます。次の設定例では、デバイスのメモリが使い果たされた場合に管理プロセスが機能し続けるようにするために、この機能を有効にする方法を示しています。

!

memory reserve critical <value>
!

この機能に関する詳細は、『メモリしきい値通知』を参照してください。

CPU しきい値の通知

Cisco IOSソフトウェアリリース12.3(4)Tで導入されたCPUしきい値通知機能を使用すると、デバイスのCPU負荷が設定されたしきい値を超えたときに通知を検出して受信できます。しきい値を超過した場合、デバイスでは SNMP トラップ メッセージが生成されて、送信されます。Cisco IOSソフトウェアでは、上昇しきい値と下降しきい値という2つのCPU使用しきい値方式がサポートされています。

次の設定例では、上昇しきい値と下降しきい値を有効にして、CPUしきい値通知メッセージをトリガーする方法を示しています。

!

snmp-server enable traps cpu threshold
!

snmp-server host <host-address> <community-string> cpu 
!

process cpu threshold type <type> rising <percentage> interval <seconds> 
     [falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!

この機能に関する詳細は、『CPU しきい値通知』を参照してください。

コンソール アクセス用のメモリ予約

Cisco IOSソフトウェアリリース12.4(15)T以降では、Reserve Memory for Console Access機能を使用して、管理や問題の切り分けの目的でCisco IOSデバイスへのコンソールアクセスを確保するために十分なメモリを予約できます。この機能は、デバイスのメモリが不足している場合に特に役立ちます。この機能をイネーブルにするには、memory reserve consoleグローバルコンフィギュレーションコマンドを発行します。次の設定例では、Cisco IOS デバイスでこの用途に 4096 KB を予約しています。

!
memory reserve console 4096
!

メモリ リーク検出機能

メモリリーク検出機能は、Cisco IOSソフトウェアリリース12.3(8)T1で導入されました。この機能を使用すると、デバイスのメモリリークを検出できます。メモリリーク検出は、すべてのメモリプール、パケットバッファ、およびチャンクでリークを検出できます。メモリ リークとは、メモリが静的または動的に割り当てられたまま有効に利用されていないことです。この機能では、動的なメモリ割り当てに焦点を絞って検出します。メモリリークが存在するかどうかを検出するには、show memory debug leaks EXECコマンドを使用できます。

バッファ オーバーフロー：レッドゾーン破損の検出と修正

Cisco IOSソフトウェアリリース12.3(7)T以降では、バッファオーバーフロー：レッドゾーン破損の検出と修正機能をデバイスでイネーブルにして、メモリブロックオーバーフローを検出して修正し、動作を続行できます。

この機能をイネーブルにするには、グローバルコンフィギュレーションコマンドを使用できます。いったん設定すると、show memory overflowコマンドを使用して、バッファオーバーフロー検出と修正の統計情報を表示できます。

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

強化された Crashinfo ファイル回収

強化された Crashinfo ファイル回収機能では、古い crashinfo ファイルが自動的に削除されます。この機能は Cisco IOS ソフトウェア リリース 12.3(11)T で追加されました。この機能を使用すると、領域が解放され、デバイスがクラッシュしたときに crashinfo ファイルを新規作成できるようになります。この機能では、保存するcrashinfoファイルの数も設定できます。

!
exception crashinfo maximum files <number-of-files>
!

ネットワーク タイム プロトコル

Network Time Protocol（NTP；ネットワークタイムプロトコル）は危険なサービスではありませんが、不要なサービスはどれでも、攻撃ベクトルとなる可能性があります。NTP が使用されている場合は、信頼できるタイミング ソースを明示的に設定して、適切な認証を使用することが重要です。攻撃の可能性に関するフォレンジック調査や、フェーズ1認証で証明書に依存している場合のVPN接続の成功など、syslogの目的のために正確で信頼できる時間が必要です。

• NTPのタイムゾーン:NTPを設定する場合、タイムスタンプが正確に関連付けられるように、タイムゾーンを設定する必要があります。グローバルプレゼンスを持つネットワーク上のデバイスに対してタイムゾーンを設定するには、一般的に2つの方法があります。一つは、すべてのネットワーク デバイスを Coordinated Universal Time（UTC; 世界標準時）（以前の Greenwich Mean Time（GMT; グリニッジ標準時））に設定する方法です。 もう1つの方法は、ネットワークデバイスをローカルタイムゾーンで設定することです。この機能についての詳細は、Cisco 製品ドキュメントの『clock timezone』を参照してください。
  
  
• NTP の認証：NTP の認証を設定すると、信頼できる NTP ピア間で確実に NTP メッセージを交換できます。

NTP認証を使用する設定例を次に示します。

クライアント:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server 172.16.1.5 key 5

サーバ:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5

Smart Installの無効化

Cisco Smart Install(SMI)機能に関するセキュリティのベストプラクティスは、特定のユーザ環境での機能の使用方法によって異なります。シスコは次の使用例を差別化しています。

• SMI機能を使用しないユーザー。
• SMI機能を活用するのは、ゼロタッチ導入のみを目的とするユーザーです。
• Smart InstallSMI機能を利用して、ゼロタッチ導入以上の展開（構成およびイメージ管理）を行うユーザー。

次のセクションでは、各シナリオについて詳しく説明します。

• SMI機能を使用しないユーザー。
• SMI機能を使用しないユーザは、コマンドを使用できるCisco IOSソフトウェアおよびCisco IOS XEソフトウェアのリリースを実行すると、no vstackコマンドでSMI機能を無効にできます。

注:vstackコマンドは、Cisco IOSリリース12.2(55)SE03で導入されました。

SMIクライアント機能が無効なCisco Catalystスイッチでのshow vstackコマンドの出力例を次に示します。

switch# show vstack 
config Role: Client (SmartInstall disabled) 
Vstack Director IP address: 0.0.0.0

SMI機能をゼロタッチ導入にのみ活用するお客様

ゼロタッチインストールの完了後にSMIクライアント機能を無効にするか、no vstackコマンドを使用します。

no vstackコマンドをネットワークに伝搬するには、次のいずれかの方法を使用します。

• すべてのクライアントスイッチで、手動またはスクリプトを使用してno vstackコマンドを入力します。
• ゼロタッチインストールの一部として各SMIクライアントにプッシュされるCisco IOS設定の一部として、no vstackコマンドを追加します。
• vstackコマンドをサポートしていないリリース(Cisco IOSリリース12.2(55)SE02とそれ以前のリリース)では、クライアントスイッチにAccess Control List（ACL；アクセスコントロールリスト）を適用して、TCPポート4786のトラフィックをブロックします。

SMIクライアント機能を後で有効にするには、手動またはスクリプトを使用してすべてのクライアントスイッチでvstackコマンドを入力します。

SMI機能を活用してゼロタッチ導入以上を実現しているお客様

SMIアーキテクチャの設計では、インフラストラクチャのIPアドレス空間が信頼できないユーザにアクセスされないように注意してください。vstackコマンドをサポートしていないリリースでは、SMIディレクタだけが、ポート4786上のすべてのSMIクライアントにTCP接続できることを確認します。

管理者は、影響を受けるデバイスでのSMIの導入に対して次のセキュリティ上のベストプラクティスを使用できます。

• インターフェイスACL
• コントロールプレーンポリシング(CoPP)。 この機能は、すべてのCisco IOSソフトウェアリリースで使用できるわけではありません。

次の例は、SMIダイレクタのIPアドレスが10.10.10.1、SMIクライアントのIPアドレスが10.10.10.200のインターフェイスACLを示しています。

ip access-list extended SMI_HARDENING_LIST
Permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any

このACLは、すべてのクライアントのすべてのIPインターフェイスに展開する必要があります。また、スイッチを初めて導入するときにダイレクタによってプッシュすることもできます。

インフラストラクチャ内のすべてのクライアントへのアクセスをさらに制限するために、管理者はネットワーク上の他のデバイスで次のセキュリティベストプラクティスを使用できます。

• Infrastructure Access Control List（iACL; インフラストラクチャ アクセス コントロール リスト）
• VLANアクセスコントロールリスト(VACL)

インフラストラクチャ ACL によるネットワーク アクセス制限

iACLは、ネットワークデバイスへの不正な直接通信を防止するために考案された、ネットワークに実装される最も重要なセキュリティ制御の1つです。iACLでは、ほとんどすべてのネットワークトラフィックがネットワークを通過し、ネットワーク自体を宛先としていないという考え方を利用します。

iACL を設定して適用するには、ホストまたはネットワークからネットワーク デバイスへのどの接続を許可する必要があるかを指定します。これらの接続タイプの一般的な例は、eBGP、SSH、およびSNMPです。必要な接続が許可された後、そのインフラストラクチャへの他のすべてのトラフィックは明示的に拒否されます。ネットワークを横断するが、そのインフラストラクチャ デバイスを宛先としていないすべての通過トラフィックは、明示的に許可されます。

iACL による保護は、管理プレーンとコントロール プレーンの両方に関係しています。iACLの実装は、ネットワークインフラストラクチャデバイスに異なるアドレスを使用することで容易になります。IPアドレスによるセキュリティへの影響についての詳細は、『IPアドレッシングに対するセキュリティ志向アプローチ』を参照してください。

次のiACL設定例は、iACL実装プロセスを開始する際の開始点として使用する必要がある構造を示しています。

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!

 permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
 permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
 permit tcp host <trusted-management-stations> any eq 22
 permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

作成した iACL は、非インフラストラクチャ デバイスと接続するすべてのインターフェイスに適用する必要があります。これには、他の組織、リモート アクセス セグメント、ユーザ セグメント、データセンター内のセグメントなどと接続するインターフェイスが含まれます。

インフラストラクチャ ACL についての詳細は、『コアの保護：インフラストラクチャ保護 ACL』を参照してください。

ICMP パケット フィルタリング

Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）は、IP コントロール プロトコルとしての設計になっています。そのため、伝送されるメッセージは、一般にTCPおよびIPプロトコルと有意な相互作用を持つ可能性があります。ネットワークツールのpingとtracerouteではICMPを使用しますが、ネットワークが正常に動作している場合、外部ICMP接続が必要になることはほとんどありません。

Cisco IOS ソフトウェアには、ICMP メッセージを名前または種類およびコードで詳細にフィルタリングする機能があります。次の例の ACL は、これまでの例のアクセス コントロール エントリ（ACE）と組み合わせて使用する必要があります。これにより、信頼できる管理ステーションと NMS サーバからの ping が許可され、その他の ICMP パケットはすべてブロックされます。

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!

 permit icmp host <trusted-management-stations> any echo
 permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

IP フラグメントのフィルタリング

フラグメント化されたIPパケットのフィルタプロセスは、セキュリティデバイスにとって困難な作業です。これは、TCPパケットとUDPパケットのフィルタリングに使用されるレイヤ4情報が先頭フラグメントだけに存在するためです。Cisco IOS ソフトウェアでは、特定の方式を使用して、設定されたアクセス リストと先頭以外のフラグメントを照合します。Cisco IOSソフトウェアは、これらの先頭以外のフラグメントをACLに対して評価し、レイヤ4でフィルタリングされた情報をすべて無視します。これにより、先頭以外のフラグメントは、設定されたACEのレイヤ3部分でのみ評価されるようになります。 

この設定例では、192.168.1.1(ポート22)宛のTCPパケットが転送中にフラグメント化された場合、先頭フラグメントは、パケット内のレイヤ4情報に基づいて、2番目のACEによって期待どおりに廃棄されます。ただし、残りのすべての（先頭以外の）フラグメントは、パケットとACEのレイヤ3情報に完全に基づいて、最初のACEによって許可されます。次のシナリオはこの設定を示したものです。

!

ip access-list extended ACL-FRAGMENT-EXAMPLE
 permit tcp any host 192.168.1.1 eq 80
 deny tcp any host 192.168.1.1 eq 22
!

フラグメント処理はわかりにくいため、ACL により IP フラグメントが誤って許可されることがあります。フラグメンテーションは、侵入検知システムによる検出を回避しようとする試みで頻繁に使用されます。これらの理由から、IPフラグメントは攻撃で使用されることが多く、設定されたiACLの先頭で明示的にフィルタリングする必要がある理由が挙げられます。このACLの例には、IPフラグメントの包括的なフィルタリングが含まれています。この例の機能は、前の例の機能と組み合わせて使用する必要があります。

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

フラグメント化された IP パケットの ACL による処理の詳細は、『アクセス コントロール リストと IP フラグメント』を参照してください。

ACLのIPオプションフィルタリングサポート

Cisco IOSソフトウェアリリース12.3(4)Tでは、ACLを使用して、パケットに含まれるIPオプションに基づいてIPパケットをフィルタリングする機能のサポートが追加されました。IP オプションは例外パケットとして処理されるので、ネットワーク デバイスのセキュリティにとって難しい問題です。これには、ネットワークを通過する一般的なパケットには不要なレベルのCPU負荷が必要です。パケット内にIPオプションが存在する場合は、ネットワーク上のセキュリティ制御を弱体化させようとしているか、パケットの転送特性を変更しようとしていることも示されています。これらの理由から、IPオプション付きのパケットはネットワークエッジでフィルタリングする必要があります。

次の例は、IPオプションを含むIPパケットの完全なフィルタリングを含めるために、前の例のACEとともに使用する必要があります。

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

ACL の TTL 値フィルタリング サポート

Cisco IOSソフトウェアリリース12.4(2)Tでは、存続可能時間(TTL)値に基づくIPパケットのフィルタをサポートするACLが追加されました。IP データグラムの TTL 値は、パケットが発信元から宛先へと移動する中で、ネットワーク デバイスを通過するごとに減少します。初期値はオペレーティングシステムによって異なりますが、パケットのTTLがゼロに達すると、パケットは廃棄される必要があります。TTL を 0 まで減らすことになったデバイスでは、パケットが廃棄され、ICMP Time Exceeded メッセージが生成されてパケットの発信元に送信されます。

このようなメッセージの生成と送信は、例外プロセスです。ルータは、期限切れになるIPパケットの数が少ない場合にこの機能を実行できますが、期限切れになるIPパケットの数が多い場合、これらのメッセージの生成と送信によって使用可能なすべてのCPUリソースが消費される可能性があります。これは、DoS 攻撃の兆候を示しています。このため、期限が切れる高レートのIPパケットを使用するDoS攻撃に対して、デバイスを強化する必要があります。

TTL 値が低い IP パケットは、ネットワークのエッジでフィルタリングすることを推奨いたします。ネットワークを通過するには不十分なTTL値を持つパケットの完全なフィルタリングにより、TTLベースの攻撃の脅威を軽減できます。

次の ACL の例では、TTL 値が 6 未満のパケットがフィルタリングされます。これにより、5 ホップまでのネットワークは TTL 期限切れ攻撃から保護されます。

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets with TTL values insufficient to traverse the network
!

 deny ip any any ttl lt 6
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

注：一部のプロトコルでは、TTL値が低いパケットを正当な目的で使用します。eBGPはこのようなプロトコルの1つです。TTL期限切れに基づく攻撃を緩和する詳細は、『TTL超過攻撃の識別と緩和』を参照してください。

インタラクティブ管理セッションの保護

デバイスへの管理セッションは、デバイスとその動作に関する情報を表示および収集する機能を提供します。この情報が悪意のあるユーザに公開されると、そのデバイスは攻撃対象となり、侵入され、さらなる攻撃に利用される可能性があります。デバイスへの特権アクセスを持つユーザは、そのデバイスに対して全面的な管理制御を行うことができます。情報の開示や不正アクセスを防ぐには、管理セッションのセキュリティを確保することが不可欠です。

管理プレーン保護

Cisco IOSソフトウェアリリース12.4(6)T以降では、管理プレーン保護(MPP)機能により、管理者はデバイスが受信するさまざまなインターフェイス管理トラフィックに制限を課すことができます。この機能により管理者は、デバイスとそのアクセス方法に対する制御を強化できます。

次の例は、MPP をイネーブルにして、GigabitEthernet0/1 インターフェイスで SSH と HTTPS のみを許可する方法を示しています。

!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https
!

MPP についての詳細は、『管理プレーン保護』を参照してください。

注:MPPはIPv6をサポートしておらず、IPv4入力パスに制限されています。IPv6はフィルタリングされないため、IPv4/IPv6混在環境ではCoPPを使用します。

コントロール プレーン保護

Control Plane Protection(CPPr)は、Control Plane Policing（コントロールプレーンポリシング）の機能に基づいて構築され、Cisco IOSデバイスのルートプロセッサ宛てのコントロールプレーントラフィックを制限およびポリシングします。Cisco IOSソフトウェアリリース12.4(4)Tで追加されたCPPrでは、コントロールプレーンがサブインターフェイスと呼ばれる個別のコントロールプレーンカテゴリに分割されます。コントロールプレーンサブインターフェイスには、Host、Transit、およびCEF-Exceptionの3つがあります。さらに、CPPrには次のコントロールプレーン保護機能があります。

• ポートフィルタリング機能：閉じているか受信状態ではないTCPポートやUDPポートに向かうパケットを管理者がポリシングまたは廃棄できるようにします。
  
  
• キューしきい値ポリシー機能：コントロールプレーンIP入力キューで許可されている指定されたプロトコルのパケット数を制限します。

CPPrを使用すると、管理者はホストサブインターフェイスを使用して、管理目的でデバイスに送信されるトラフィックを分類、ポリシング、および制限できます。ホストサブインターフェイスカテゴリ用に分類されるパケットの例としては、SSHやTelnetなどの管理トラフィックやルーティングプロトコルなどがあります。

注:CPPrはIPv6をサポートしておらず、IPv4入力パスに制限されています。

Cisco CPPr 機能についての詳細は、『コントロール プレーン保護機能ガイド - 12.4T』および『コントロール プレーン保護について』を参照してください。

管理セッションの暗号化

インタラクティブ管理セッションでは情報が開示される可能性があるため、悪意のあるユーザが送信データにアクセスできないようにするため、このトラフィックを暗号化する必要があります。トラフィックを暗号化することで、デバイスとのリモート アクセス接続が保護されます。管理セッションのトラフィックがネットワーク上にクリアテキストで送信された場合、デバイスとネットワークに関する機密情報が攻撃者に取得される可能性があります。

管理者は、SSH や HTTPS（Secure Hypertext Transfer Protocol）の機能を使用して、デバイスとのリモート アクセス管理接続を暗号化して保護できます。Cisco IOS ソフトウェアでサポートされるのは、SSH バージョン 1.0（SSHv1）、SSH Version 2.0（SSHv2）、および Secure Sockets Layer（SSL）と Transport Layer Security（TLS）を使用して認証やデータ暗号化を行う HTTPS です。SSHv1またはSSHv2は互換性がありません。SSHv1は安全ではなく、標準化されていないため、SSHv2がオプションの場合は使用しないことを推奨します。

また、Cisco IOSソフトウェアはSecure Copy Protocol(SCP)もサポートしています。SCPにより、デバイス設定やソフトウェアイメージを暗号化された安全な接続でコピーできます。SCP では SSH が使用されています。次の設定例では、Cisco IOSデバイスでSSHがイネーブルにされています。

!

ip domain-name example.com
!

crypto key generate rsa modulus 2048
!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!

line vty 0 4
 transport input ssh
!

次の設定例では、SCP サービスをイネーブルにしています。

!

ip scp server enable
!

次の設定例は、HTTPSサービス用です。

!

crypto key generate rsa modulus 2048
!

ip http secure-server
!

Cisco IOS ソフトウェアの SSH 機能の詳細は、『Cisco IOS が稼働するルータとスイッチでの Secure Shell の設定』および『Secure Shell（SSH）に関する FAQ』を参照してください。

SSHv2

Cisco IOSソフトウェアリリース12.3(4)Tで導入されたSSHv2サポート機能を使用すると、ユーザはSSHv2を設定できます。（SSHv1サポートは、Cisco IOSソフトウェアの以前のリリースで実装されました）。 SSHは信頼性の高いトランスポート層の上で動作し、強力な認証および暗号化機能を提供します。SSH用に定義された唯一の信頼性の高いトランスポートはTCPです。SSHは、ネットワークを介して別のコンピュータまたはデバイスに安全にアクセスし、コマンドを安全に実行する方法を提供します。SSH経由でトンネリングされたSecure Copy Protocol(SCP)機能により、ファイルの安全な転送が可能になります。

ip ssh version 2コマンドが明示的に設定されていない場合、Cisco IOSはSSHバージョン1.99を有効にします。SSHバージョン1.99では、SSHv1接続とSSHv2接続の両方が可能です。SSHv1は安全でないと見なされており、システムに悪影響を及ぼす可能性があります。SSHが有効な場合は、ip ssh version 2コマンドを使用してSSHv1を無効にすることを推奨します。

次の設定例では、Cisco IOS デバイスに対して SSHv2 をイネーブルにしています（SSHv1 はディセーブル）。

!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

ip ssh time-out 60  
ip ssh authentication-retries 3  
ip ssh source-interface GigabitEthernet 0/1    

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

SSHv2の使用の詳細については、セキュア シェル バージョン2サポートを参照してください。

RSAキーのSSHv2拡張機能

Cisco IOS SSHv2 は、キーボードインタラクティブでパスワード ベースの認証方式をサポートしています。RSA キーの SSHv2 拡張機能は、クライアントとサーバ向けの RSA ベースの公開キー認証もサポートしています。

ユーザ認証の場合、RSA ベースのユーザ認証では、各ユーザに関連付けられている秘密キー/公開キーのペアを認証に使用します。ユーザはクライアントで秘密キー/公開キーのペアを生成し、Cisco IOS SSHサーバで公開キーを設定して認証を完了する必要があります。

クレデンシャルの確立を試行する SSH ユーザは、秘密キーを使用して暗号化されたシグニチャを提示します。暗号化された署名とユーザ公開キーは、認証のためにSSHサーバに送信されます。SSH サーバでは、ユーザから提示された公開キーに対してハッシュを計算します。ハッシュは、サーバに一致するエントリがあるかどうかを判断するために使用されます。一致が見つかった場合、RSA ベースのメッセージ検証が公開キーを使用して実行されます。その結果、暗号化されたシグニチャに基づいて、ユーザのアクセスは認証されるか拒否されます。

サーバ認証の場合、Cisco IOS SSH クライアントが各サーバにホスト キーを割り当てる必要があります。クライアントがサーバとの間で SSH セッションを確立しようとすると、キー交換メッセージの一部として、サーバのシグニチャを受信します。厳密なホストキーチェックフラグがクライアントで有効になっている場合、クライアントはサーバに対応するホストキーエントリが事前に設定されているかどうかをチェックします。一致が見つかった場合、クライアントはサーバホストキーを使用して署名の検証を試みます。サーバの認証に成功した場合は、セッションの確立が続行されます。成功しなかった場合はセッションが終了し、「Server Authentication Failed」というメッセージが表示されます。

この設定例は、Cisco IOSデバイスのSSHv2のRSAキーを使用できます:

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using 
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits 
!

 crypto key generate rsa usage-keys label sshkeys modulus 2048
!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120
!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5
!
! Configure SSH version 2
!

ip ssh version 2 
!

  

SSHv2のRSAキーの使用の詳細については、RSAキーのセキュア シェル バージョン2の拡張機能を参照してください。

次の設定例では、Cisco IOS SSH サーバが RSA ベースのユーザ認証を実行できるように設定されます。サーバに保存されている RSA 公開キーが、クライアントに保存されている公開キーと秘密キーのペアを使用して検証されると、ユーザ認証は成功です。

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Configure the SSH username
!

        username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash command (followed by the SSH key type and version.)
!

Cisco IOS SSHサーバをSSHv2とRSAキーの使用の詳細については、RSAベースのユーザ認証を実行するように設定できます。を参照してください。

次の設定例では、Cisco IOS SSH クライアントが RSA ベースのサーバ認証を実行できるように設定されます。

!
!

hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name
!
! Specify the RSA public-key of the remote peer 
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash <key-type> <key-name> command (followed by the SSH key 
! type and version.)
!
! Ensure that server authentication takes place - The connection will be 
! terminated on a failure
!

ip ssh stricthostkeycheck 
!

SSHv2でのRSAキーの使用法の詳細については、『RSAベースのサーバ認証を実行するためのCisco IOS SSHクライアントの設定』を参照してください。

コンソール ポートと AUX ポート

Cisco IOS デバイスのコンソール ポートと補助（AUX）ポートは、非同期回線であり、デバイスへのローカル アクセスとリモート アクセスに使用できます。Cisco IOSデバイスのコンソールポートには特別な権限があることに注意してください。特に、管理者はこのような特権を使用して、パスワード回復手順を実行できることには注意が必要です。パスワード回復を実行するには、認証されていない攻撃者がコンソールポートにアクセスし、デバイスへの電源供給を中断したり、デバイスをクラッシュさせたりする機能が必要です。

デバイスのコンソールポートへのアクセスに使用される方式はすべて、デバイスへの特権アクセスに適用されるセキュリティと同じ方法で保護する必要があります。アクセスの保護に使用される方法には、AAA、exec-timeout、およびモデムパスワード（モデムがコンソールに接続されている場合）の使用が含まれている必要があります。

パスワード回復が不要な場合は、no service password-recoveryグローバルコンフィギュレーションコマンドでパスワード回復手順の実行機能を削除できます。ただし、no service password-recoveryコマンドがイネーブルにされると、そのデバイスに対してパスワード回復を実行できなくなります。

ほとんどの場合、デバイスのAUXポートを無効にして、不正アクセスを防止する必要があります。AUX ポートをディセーブルにするには、次のコマンドを使用します。

!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password
!

vty 回線と tty 回線の制御

Cisco IOS ソフトウェアのインタラクティブ管理セッションでは、tty またはバーチャル tty（vty）を使用します。 tty は、デバイスとのローカル アクセス用の端末や、デバイスとのダイヤルアップ アクセス用のモデムと接続できるローカルの非同期回線です。tty はその他のデバイスのコンソール ポートにも接続できます。これにより、tty 回線に接続されたデバイスはコンソール サーバとして機能でき、この状態で、tty 回線に接続されたデバイスのコンソール ポートにネットワークを介して接続を確立できます。ネットワーク上でこのようなリバース接続を行うtty回線も制御する必要があります。

vty 回線は、プロトコルにかかわらず（SSH、SCP、Telnet など）、デバイスによってサポートされるその他のすべてのリモート ネットワーク接続で使用されます。 ローカルまたはリモートの管理セッションでデバイスにアクセスできるようにするには、vty回線とtty回線の両方を適切に制御する必要があります。Cisco IOSデバイスのvty回線は限られています。利用可能な回線数は、show line EXECコマンドで特定できます。すべてのvty回線が使用中の場合、新しい管理セッションを確立できないため、デバイスへのアクセスに対してDoS状態が発生する可能性があります。

デバイスのvtyまたはttyへの最も簡単なアクセスコントロールは、ネットワーク上のデバイスの場所に関係なく、すべての回線で認証を使用することです。これは、ネットワークからアクセス可能なvty回線にとって重要です。デバイスへのリモートアクセスに使用されるモデムに接続されたtty回線、または他のデバイスのコンソールポートに接続されたtty回線も、ネットワークからアクセスできます。vty および tty のアクセス コントロールを行う他の方法としては、transport input または access-class コンフィギュレーション コマンドを使用する方法、CoPP 機能と CPPr 機能を使用する方法、またはデバイスのインターフェイスにアクセス リストを適用する方法があります。

AAA を使用することで認証を実行できます。デバイス アクセスの認証には、ローカル ユーザ データベースを使用するか、または vty 回線や tty 回線に直接設定された単純なパスワード認証を使用して AAA を適用することが推奨されています。

アイドル状態のvty回線またはtty回線のセッションをログアウトさせるには、exec-timeoutコマンドを使用します。また、service tcp-keepalives-inコマンドを使用して、デバイスへの着信接続でTCPキープアライブをイネーブルにすることも必要です。これにより、接続のリモートエンドにあるデバイスは引き続きアクセス可能であり、ハーフオープンまたは孤立した接続はローカルCisco IOSデバイスから削除されます。

vty 回線と tty 回線の転送制御

デバイスがコンソールサーバとして使用されている場合は、そのデバイスへの、またはそのデバイスを介した暗号化された安全なリモートアクセス管理接続のみを受け入れるように、vtyとttyを設定します。このセクションでは tty の場合について説明します。tty 回線は他のデバイス上のコンソール ポートに接続でき、これによりネットワーク経由で tty へのアクセスが可能になるからです。情報の開示や管理者とデバイスの間で送信されるデータへの不正アクセスを防止するには、Telnetやrloginなどのクリアテキストプロトコルを使用する代わりにtransport input sshを使用します。ttyに対しては、transport input noneコンフィギュレーションをイネーブルにできます。これにより、リバースコンソール接続でのtty回線の使用がディセーブルになります。

vty 回線と tty 回線はどちらも他のデバイスに接続できます。発信接続に使用できるトランスポートの種類を制限するには、transport outputラインコンフィギュレーションコマンドを使用します。発信接続が不要の場合は、transport output noneを使用します。ただし、発信接続が許可されている場合は、transport output sshを使用して、暗号化された安全なリモートアクセス方式を接続に適用します。

注:IPSecは、サポートされている場合、デバイスへの暗号化された安全なリモートアクセス接続に使用できます。IPSec を使用する場合は、デバイスにさらに CPU オーバーヘッドが加わります。ただし、IPSecを使用する場合でも、SSHをトランスポートとして適用する必要があります。

警告バナー

一部の司法管轄区域では、システムの使用が許可されていないことを悪意のあるユーザに通知しない限り、そのユーザを訴追することは不可能であり、悪意のあるユーザを監視することは違法です。この通知を行う方法の1つは、Cisco IOSソフトウェアのbanner loginコマンドで設定されるバナーメッセージにこの情報を含めることです。

法的通知要件は複雑で、管轄区域や状況によって異なり、弁護士との話し合いが必要です。司法管轄地域内でも、複数の法的見解が存在する場合もあります。弁護士と協力して、バナーは次の情報の一部またはすべてを提供できます。

• 特別に承認された人のみがシステムへのログインやシステムの使用を許可されていることを伝える通知と、だれが使用を承認できるのかを示す情報。
  
  
• システムの不正な使用は違法であり、民事罰および刑事罰が課される場合があることを伝える通知。
  
  
• システムの使用はすべて、これ以上の警告なしに記録または監視でき、その結果として得られたログは法廷で証拠として使用できることに注意してください。
  
  
• 地域法によって規定されている特定の通知

ログインバナーには、法的な情報ではなく、セキュリティの観点から、ルータの名前、モデル、ソフトウェア、所有権に関する特定の情報を含めることはできません。これらの情報は悪意のあるユーザに利用される可能性があります。

認証、許可、およびアカウンティング

ネットワークデバイスへのインタラクティブアクセスを保護するには、認証、認可、アカウンティング(AAA)フレームワークが重要です。AAAフレームワークは、ネットワークのニーズに基づいてカスタマイズできる、高度に設定可能な環境を提供します。

TACACS+ 認証

TACACS+は、Cisco IOSデバイスがリモートAAAサーバに対する管理ユーザの認証に使用できる認証プロトコルです。これらの管理ユーザは、SSH、HTTPS、telnet、またはHTTPを使用してCisco IOSデバイスにアクセスできます。

TACACS+ 認証、またはより一般的に AAA 認証では、各ネットワーク管理者が個々のユーザ アカウントを使用できます。単一の共有パスワードに依存しない場合、ネットワークのセキュリティが向上すると同時に、アカウンタビリティも強化されます。

RADIUSは、目的の点ではTACACS+に似たプロトコルですが、ネットワーク経由で送信されるパスワードを暗号化するだけです。一方、TACACS+ では、ユーザ名とパスワードを含む TCP ペイロード全体が暗号化されます。このため、AAAサーバでTACACS+がサポートされている場合は、RADIUSではなくTACACS+を使用してください。これら 2 つのプロトコルの詳細な比較は、『TACACS+ と RADIUS の比較』を参照してください。

Cisco IOS デバイスに対して TACACS+ 認証をイネーブルにするには、次の例のように設定します。

!

aaa new-model
aaa authentication login default group tacacs+
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

以前の設定は、組織固有のAAA認証テンプレートの開始点として使用できます。 

方式リストは、ユーザを認証するために照会する認証方式を記述したシーケンシャルリストです。方式リストを使用すると、認証に使用する1つ以上のセキュリティプロトコルを指定できるため、最初の方式が失敗した場合に認証のバックアップシステムを確保できます。正常にユーザを受け入れるか、または拒否するCisco IOSソフトウェアは最初にリストされている方式を使用します。後続の方式は、サーバが使用できないか、設定が正しくないことが原因で以前の方式が失敗した場合にのみ試行されます。

認証フォールバック

設定されたすべての TACACS+ サーバが利用不能になった場合、Cisco IOS デバイスはセカンダリ認証プロトコルを使用できます。一般的には、設定されたすべての TACACS+ サーバが利用不能になった場合は、ローカル認証かイネーブル認証を使用するように設定します。

オンデバイス認証のオプションは、enable、local、および line です。各オプションには利点があります。enable secretの使用が推奨されます。秘密鍵のハッシュには、回線認証やローカル認証で使用されるType 7パスワードで使用される暗号化アルゴリズムよりも、本質的に安全性が高い一方向アルゴリズムが使用されるためです。

ただし、ローカル定義ユーザに対してシークレット パスワードの使用をサポートしている Cisco IOS ソフトウェア リリースでは、ローカル認証にフォールバックすることが推奨されます。これにより、1人以上のネットワーク管理者に対してローカルに定義されたユーザを作成できます。TACACS+が完全に使用できない場合、各管理者はローカルのユーザ名とパスワードを使用できます。この措置によって TACACS+ 停止中のネットワーク管理者のアカウンタビリティが強化されますが、すべてのネットワーク デバイス上のローカル ユーザ アカウントを維持する必要があるので、管理上の負担は飛躍的に大きくなります。

次の設定例では、前のTACACS+認証例を踏まえて、enable secretコマンドでローカルに設定されたパスワードへのフォールバック認証が追加されています。

!

enable secret <password>
!

aaa new-model
aaa authentication login default group tacacs+ enable
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

Type 7 パスワードの使用

Type 7 パスワードは本来、保管されたパスワードを迅速に復号化する設計になっており、パスワードを保管するための安全な形式ではありません。これらのパスワードを簡単に復号化するには、多数のツールを使用できます。Cisco IOSデバイスで使用中の機能で必要とされない限り、Type 7パスワードの使用は避けてください。

可能な限りtype 9 (scrypt)を使用します。

username <username> privilege 15 algorithm-type scrypt secret <secret>

このタイプのパスワードの削除は、AAA認証（デフォルト）と、拡張パスワードセキュリティ機能を使用して実行できます。この機能により、usernameグローバルコンフィギュレーションコマンドでローカルに定義されたユーザがシークレットパスワードを使用できます。Type 7 パスワードの使用を完全にはなくせない場合は、これらのパスワードを暗号化するのではなく難読化することを検討してください。

Type 7パスワードの除去についての詳細は、「管理プレーン全般の強化」セクションを参照してください。

TACACS+ コマンド認可

TACACS+ と AAA によるコマンド認可は、管理ユーザによって入力された各コマンドを許可または拒否するメカニズムです。ユーザが EXEC コマンドを入力すると、Cisco IOS によって各コマンドは設定された AAA サーバに送信されます。AAAサーバは、設定されたポリシーを使用して、その特定のユーザに対してコマンドを許可または拒否します。

前のAAA認証例に次の設定を追加して、コマンド許可を実装できます。

!

aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none 
aaa authorization commands 15 default group tacacs none
!

TACACS+ コマンド アカウンティング

AAAコマンドアカウンティングを設定すると、入力された各EXECコマンドに関する情報が、設定されたTACACS+サーバに送信されます。TACACS+サーバに送信される情報には、実行されたコマンド、実行日、コマンドを入力したユーザ名が含まれます。RADIUS ではコマンド アカウンティングはサポートされていません。

次の設定例では、特権レベル 0、1、および 15 で入力された EXEC コマンドに対して AAA コマンド アカウンティングがイネーブルになります。この設定は、TACACSサーバの設定を含む以前の例に基づいて構築されています。

!

aaa accounting exec default start-stop group tacacs 
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs
!

冗長 AAA サーバ

環境内で活用されるAAAサーバは、冗長性を備え、耐障害性のある方法で展開できます。こうすることで、1 台の AAA サーバが利用できなくなっても、SSH などのインタラクティブ管理アクセスが可能になります。

冗長 AAA サーバ ソリューションを設計または実装する場合は、次の点を考慮に入れてください。

• ネットワーク障害時のAAAサーバのアベイラビリティ
  
  
• 地理的に分散した場所への AAA サーバの配置
  
  
• 定常状態と障害状態での個々の AAA サーバへの負荷
  
  
• ネットワーク アクセス サーバと AAA サーバの間のネットワーク遅延
  
  
• AAA サーバ データベースの同期

詳細は、『Access Control Server の展開』を参照してください。

Simple Network Management Protocol の強化

このセクションでは、Cisco IOSデバイスでのSNMPの展開を保護するために使用できるいくつかの方法について説明します。ネットワークデータと、データを送信するネットワークデバイスの両方の機密性、整合性、および可用性を保護するには、SNMPを適切に保護することが重要です。SNMPは、ネットワークデバイスの状態に関する豊富な情報を提供します。このデータを利用してネットワークに対する攻撃を行う悪意のあるユーザから、この情報を保護します。

SNMPコミュニティストリング

コミュニティストリングは、デバイス上のSNMPデータへの読み取り専用アクセスと読み取り/書き込みアクセスの両方を制限するためにCisco IOSデバイスに適用されるパスワードです。これらのコミュニティストリングは、他のパスワードと同様に、単純なものではないように慎重に選択されます。ネットワークセキュリティポリシーに従って、定期的にコミュニティストリングを変更します。たとえば、ネットワーク管理者がロールを変更したり、会社を退職するときに文字列を変更します。

次の設定では、読み取り専用のコミュニティ ストリングを READONLY、読み書きのコミュニティ ストリングを READWRITE としています。

!

snmp-server community READONLY RO
snmp-server community READWRITE RW  
!

注：前述のコミュニティストリングの例は、これらのストリングの使用法をわかりやすく説明するために選択されたものです。実稼働環境では、コミュニティストリングは慎重に選択し、英数字と英数字以外の記号を含めた一連の文字列を選択してください。 

この機能についての詳細は、『Cisco IOS SNMPコマンドリファレンス』を参照してください。

SNMP コミュニティ ストリングと ACL

コミュニティストリングに加えて、SNMPアクセスを特定の送信元IPアドレスグループにさらに制限するACLを適用します。次の設定では、SNMP 読み取り専用アクセスを 192.168.100.0/24 のアドレス レンジにあるエンド ホスト デバイスに制限し、SNMP 読み書きアクセスを 192.168.100.1 にあるエンド ホスト デバイスのみに制限しています。

注：これらのACLによって許可されるデバイスは、要求されたSNMP情報にアクセスするために適切なコミュニティストリングを必要とします。

!

access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1
!

snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99
!

この機能の詳細については、『Cisco IOS ネットワーク管理コマンド リファレンス』の「snmp-server community」を参照してください。

インフラストラクチャACL

インフラストラクチャACL(iACL)を展開すると、信頼できるIPアドレスを持つエンドホストだけがCisco IOSデバイスにSNMPトラフィックを送信できるようになります。iACLには、UDPポート161で不正なSNMPパケットを拒否するポリシーが含まれているのが理想的です。

iACL の使用方法についての詳細は、このドキュメントの「インフラストラクチャ ACL によるネットワーク アクセス制限」セクションを参照してください。

SNMP ビュー

SNMP ビューは、特定の SNMP MIB へのアクセスを許可または拒否できるセキュリティ機能です。ビューを作成して snmp-server community community-string view グローバル コンフィギュレーション コマンドでコミュニティ ストリングに適用すると、MIB データにアクセスする場合、そのビューに定義されたアクセス権に制限されます。必要に応じて、ビューを使用して、SNMPのユーザを必要なデータに制限します。

次の設定例では、コミュニティ ストリング LIMITED が設定された SNMP アクセスを、system グループ内にある MIB データに制限しています。

!

snmp-server view VIEW-SYSTEM-ONLY system include
!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!

詳細は、『SNMP サポートの設定』を参照してください。

SNMP バージョン 3

SNMP バージョン 3（SNMPv3）は、RFC3410 、RFC3411、RFC3412、RFC3413、RFC3414、および RFC3415 で定義されており、相互運用可能な標準ベースのネットワーク管理用プロトコルです。SNMPv3 では、ネットワーク上のパケットが認証され、オプションで暗号化されることから、デバイスへのアクセスが保護されます。サポートされている場合、SNMPv3を使用すると、SNMPを展開する際にセキュリティの別のレイヤを追加できます。SNMPv3 には、次の 3 つの主要設定オプションがあります。

• no auth：このモードでは、SNMPパケットの認証や暗号化は不要です。
  
  
• auth：このモードでは、SNMP パケットの認証は必要ですが、暗号化は不要です。
  
  
• priv：このモードでは、SNMP パケットの認証と暗号化（プライバシー）が必要です。

SNMPv3セキュリティメカニズム（認証または認証と暗号化）を使用してSNMPパケットを処理するには、正規のエンジンIDが必要です。デフォルトでは、エンジンIDはローカルに生成されます。エンジン ID を表示するには、次の例で示すように show snmp engineID コマンドを使用します。

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

注:engineIDを変更した場合は、すべてのSNMPユーザアカウントを再設定する必要があります。

次に、SNMPv3 グループの設定を行います。次のコマンドでは、SNMP サーバ グループ AUTHGROUP の SNMPv3 対応 Cisco IOS デバイスを設定していますが、auth キーワードの使用により認証のみがイネーブルにされています。

!
snmp-server group AUTHGROUP v3 auth
!

次のコマンドでは、SNMP サーバ グループ PRIVGROUP の SNMPv3 対応 Cisco IOS デバイスに priv キーワードを使用して、このグループでの認証と暗号化をイネーブルに設定しています。

!
snmp-server group PRIVGROUP v3 priv
!

次のコマンドでは、SNMPv3 ユーザ snmpv3user に、MD5 認証パスワード authpassword と 3DES 暗号化パスワード privpassword を設定しています。

!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword
!

snmp-server userコンフィギュレーションコマンドは、RFC 3414の規定に従って、デバイスのコンフィギュレーション出力には表示されません。したがって、パスワード、コンフィギュレーションから表示できません。設定されたユーザを表示するには、次の例で示すように、show snmp userコマンドを入力します。

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

この機能についての詳細は、『SNMP サポートの設定』を参照してください。

管理プレーン保護

Cisco IOSソフトウェアの管理プレーン保護(MPP)機能を使用すると、デバイス上でSNMPトラフィックを終端できるインターフェイスが制限されるため、SNMPを保護できます。MPP機能を使用すると、管理者は1つ以上のインターフェイスを管理インターフェイスとして指定できます。管理トラフィックは、これらの管理インターフェイスを経由してのみデバイスに入ることが許可されます。MPP をイネーブルにすると、指定された管理インターフェイス以外のインターフェイスでは、そのデバイス宛のネットワーク管理トラフィックは許可されません。

MPPはCPPr機能のサブセットであり、CPPrをサポートするCisco IOSのバージョンが必要です。CPPr についての詳細は、『コントロール プレーン保護について』を参照してください。

この例では、MPPを使用して、SNMPおよびSSHアクセスをFastEthernet 0/0インターフェイスだけに制限しています。

!
control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 
!

詳細は、『管理プレーン保護機能ガイド』を参照してください。

ロギングのベスト プラクティス

イベントログは、Cisco IOSデバイスの動作と、それが展開されているネットワークを可視化します。Cisco IOSソフトウェアには、組織のネットワーク管理と可視性の目標を達成するのに役立つ柔軟なログ設定オプションがいくつか用意されています。

以降のセクションでは、管理者がCisco IOSデバイスのログ機能への影響を最小限に抑えながらログ機能を正常に活用するのに役立つ、基本的なログ機能のベストプラクティスをいくつか紹介しています。

ログの一元的な場所への送信

ログ情報をリモートsyslogサーバに送信することを推奨します。こうすることで、複数のネットワーク デバイスが関係するネットワーク イベントとセキュリティ イベントの関連付けや監査をより効果的に実行できるようになります。syslog メッセージは UDP によってクリアテキストで送信され、信頼性は高くない点に注意してください。したがって、ネットワークが管理トラフィックに提供するすべての保護（暗号化やアウトオブバンドアクセスなど）を、syslogトラフィックを含むように拡張できます。

次の例では、リモートsyslogサーバにログ情報を送信するようにCisco IOSデバイスを設定しています。

!
logging host <ip-address>
!

ログの関連付けについての詳細は、『ファイアウォールとCisco IOSルータsyslogイベントを使用したインシデントの識別』を参照してください。

Cisco IOS 12.4(15)Tに統合され、12.0(26)Sで最初に導入されたローカル不揮発性ストレージ（ATAディスク）へのロギング機能により、システムログメッセージをAdvanced Technology Attachment(ATA)フラッシュディスクに保存できます。ATA ドライブに保存されたメッセージは、ルータが再起動した後も残ります。

次の設定行では、134,217,728バイト(128 MB)のログメッセージが、16,384バイトのファイルサイズを指定して、ATAフラッシュのsyslogディレクトリ(disk0)に設定されています。

logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384

ログメッセージがATAディスクのファイルに書き込まれる前に、Cisco IOSソフトウェアは十分なディスク領域があるかどうかを確認します。そうでない場合は、最も古いログファイルメッセージ（タイムスタンプによる）が削除され、現在のファイルが保存されます。ファイル名の形式はlog_month:day:year::timeです。

注:ATAフラッシュドライブのディスク領域は限られているため、保存されたデータを上書きする可能性を避けるために保持する必要があります。

次の例は、メンテナンス手順の一部として、ルータATAフラッシュディスクからFTPサーバ192.168.1.129の外部ディスクにログメッセージをコピーする方法を示しています。

copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog

この機能の詳細については、ローカル不揮発性ストレージ（ATAディスク）にロギングを参照してください。

ログ レベル

Cisco IOSデバイスによって生成された各ログメッセージには、レベル0（緊急）からレベル7（デバッグ）までの8つの重大度のいずれかが割り当てられます。特に必要がない限り、レベル7のログは使用しないことをお勧めします。レベル7のログでは、デバイスのCPU負荷が上昇し、デバイスとネットワークが不安定になる可能性があります。

どのログメッセージをリモートsyslogサーバに送信するかを指定するには、グローバルコンフィギュレーションコマンドlogging trap levelを使用します。level に指定する数値を下限とする重大度のメッセージが送信されます。バッファにログを記録するには、logging buffered levelコマンドを使用します。

次の設定例では、リモートsyslogサーバおよびローカルログバッファに送信されるログメッセージを重大度6（情報）から0（緊急）に制限しています。

!

logging trap 6
logging buffered 6
!

詳細は、『トラブルシューティング、障害管理、およびロギング』を参照してください。

コンソールまたはモニタ セッションへのログ送信の禁止

Cisco IOSソフトウェアでは、ログメッセージをモニタセッションやコンソールに送信することが可能です。モニタセッションはEXECコマンドterminal monitorが発行されたインタラクティブ管理セッションです。ただし、これによってCisco IOSデバイスのCPU負荷が上昇する可能性があるため、推奨されません。その代わり、show loggingコマンドで表示できるログ情報をローカルログバッファに送信します。

コンソールやモニタセッションへのログをディセーブルにするには、グローバルコンフィギュレーションコマンドのno logging consoleとno logging monitorを使用します。次の設定例は、これらのコマンドの使用法を示しています。

!

no logging console
no logging monitor
!

グローバル コンフィギュレーション コマンドの詳細については、『Cisco IOS ネットワーク管理コマンド リファレンス』を参照してください。

バッファログの使用

Cisco IOSソフトウェアでは、管理者がローカルに生成されたログメッセージを表示できるように、ローカルログバッファの使用がサポートされています。コンソールまたはモニタセッションへのログに対して、バッファログを使用することを強くお勧めします。

バッファログを設定する際には、ログバッファサイズと、バッファに保存されるメッセージの重大度という2つの関連する設定オプションがあります。ロギング バッファのサイズを設定するには、グローバル コンフィギュレーション コマンド logging buffered size を使用します。バッファに含まれる最低の重大度は、log buffered severityコマンドで設定します。管理者はshow logging EXECコマンドを使用して、ログバッファの内容を表示できます。

この設定例では、16,384バイトのログバッファの設定と、重大度6(Informational)の設定が含まれています。これは、レベル0（緊急）から6(Informational)のメッセージが保存されることを示します。

!

logging buffered 16384 6
!

バッファログの詳細については、『Cisco IOSネットワーク管理コマンドリファレンス』を参照してください。

ロギングの発信元インターフェイスの設定

ログメッセージを収集して確認する際の一貫性を高めるため、ロギングの発信元インターフェイスを静的に設定することを推奨いたします。これは、logging source-interfaceインターフェイスコマンドによって達成されます。静的に設定されたロギング送信元インターフェイスにより、個々のCisco IOSデバイスから送信されるすべてのログメッセージには、同じIPアドレスが表示されるようになります。安定性を高めるため、ログソースとしてループバックインターフェイスを使用します。

次の設定例では、logging source-interface interfaceグローバルコンフィギュレーションコマンドを使用して、すべてのログメッセージで使用されるループバック0インターフェイスのIPアドレスを指定しています。

!
logging source-interface Loopback 0
!

詳細は、『Cisco IOS コマンド リファレンス』を参照してください。

ログのタイムスタンプの設定

ログタイムスタンプの設定は、ネットワークデバイス間のイベントの関連付けに役立ちます。ログデータを関連付けられるように、正確で一貫したログタイムスタンプ設定を実装することが重要です。ログタイムスタンプを設定して、日付と時刻（ミリ秒単位）、およびデバイスで使用中のタイムゾーンを含めます。

次の例では、Coordinated Universal Time（UTC；世界標準時）ゾーン内でミリ秒単位の精度でログタイムスタンプを設定しています。

!
service timestamps log datetime msec show-timezone
!

ログの時刻を UTC 以外のタイム ゾーンにする場合は、ローカルのタイム ゾーンを指定して、生成されたログ メッセージにその情報が表示されるように設定できます。次の例では、Pacific Standard Time（PST; 太平洋標準時）にデバイスを設定しています。

!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!

Cisco IOS ソフトウェアのコンフィギュレーション管理

Cisco IOSソフトウェアには、Cisco IOSデバイス上でコンフィギュレーション管理の形式を有効にする複数の機能が含まれています。このような機能には、コンフィギュレーションをアーカイブする機能、コンフィギュレーションを以前のバージョンにロールバックする機能、および詳細なコンフィギュレーション変更ログを作成する機能が含まれます。

設定の置換と設定のロールバック

Cisco IOS ソフトウェア リリース 12.3(7)T 以降では、コンフィギュレーションの置換機能とコンフィギュレーションのロールバック機能により、Cisco IOS デバイス コンフィギュレーションをデバイス上でアーカイブ管理できます。このアーカイブに手動または自動で保存されたコンフィギュレーションを使用して、現在の実行コンフィギュレーションをconfigure replace filenameコマンドで置き換えることができます。これは、copy filename running-configコマンドとは異なる働きです。copyコマンドを実行するとマージが行われるのに対して、configure replace filenameコマンドを使用すると、実行コンフィギュレーションが置き換えられます。

ネットワーク上のすべてのCisco IOSデバイスでこの機能を有効にすることを推奨します。イネーブルにすると、archive config EXECコマンドを使用して、現在の実行コンフィギュレーションをアーカイブに追加できます。アーカイブに追加されたコンフィギュレーションは、show archive EXEC コマンドを使用して表示できます。

この例では、自動設定アーカイブの設定を示します。この例では、Cisco IOSデバイスに対して、アーカイブされたコンフィギュレーションをarchived-config-Nという名前のファイルとしてdisk0：ファイルシステムに保存し、最大14個のバックアップを保持して、管理者がwrite memory EXECコマンドを発行したときに1日に1回（1440分）アーカイブするように指示しています。

!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory
!

コンフィギュレーションアーカイブ機能では最大14個のバックアップコンフィギュレーションを保存できますが、スペースの要件を考慮した上でmaximumコマンドを使用することを推奨いたします。

コンフィギュレーション変更の排他的アクセス

Cisco IOSソフトウェアリリース12.3(14)Tでは、コンフィギュレーション変更の排他的アクセス機能が追加され、Cisco IOSデバイスのコンフィギュレーションの変更を管理者1人だけが一度に行うことができます。この機能により、関連するコンフィギュレーション コンポーネントが同時に変更されることによる、望ましくない影響をなくすことができます。この機能を設定するには、グローバルコンフィギュレーションコマンドconfiguration mode exclusive modeを使用します。動作モードにはautoとmanualの2つがあります。auto モードでは、管理者が configure terminal EXEC コマンドを発行すると、コンフィギュレーションが自動的にロックされます。manualモードでは、コンフィギュレーションモードに入る際に管理者がconfigure terminal lockコマンドを使用して、コンフィギュレーションをロックします。

次の例では、この機能を使用してコンフィギュレーションを自動的にロックする設定を示してます。

!
configuration mode exclusive auto
!

Cisco IOS ソフトウェアのコンフィギュレーション回復

Cisco IOSソフトウェアリリース12.3(8)Tで追加されたコンフィギュレーション復元機能を使用すると、Cisco IOSデバイスで現在使用されているCisco IOSソフトウェアイメージとデバイスコンフィギュレーションのコピーを安全に保存できます。この機能をイネーブルにすると、このバックアップ ファイルを変更したり削除したりすることはできません。不注意や悪意によってこれらのファイルが削除されないように、この機能をイネーブルにすることを推奨いたします。

!
secure boot-image
secure boot-config!

この機能をイネーブルにすると、削除されたコンフィギュレーションや Cisco IOS ソフトウェア イメージを復元できます。この機能の現在の状態を表示するには、show secure boot EXECコマンドを使用します。

デジタル署名付き Cisco ソフトウェアの識別

Cisco 1900、2900、および3900シリーズルータ用のCisco IOSソフトウェアリリース15.0(1)Mで追加されたデジタル署名付きCiscoソフトウェア機能は、セキュアな非対称（公開キー）暗号化を使用して、デジタル署名されているため信頼できるCisco IOSソフトウェアの使用を促進します。

デジタル署名されたイメージは、自身の暗号化された（秘密キーを使用して）ハッシュを運びます。チェック時に、デバイスはキーストア内にあるキーから関連する公開キーを使用してハッシュを復号化し、イメージの独自のハッシュも計算します。復号されたハッシュが計算されたイメージのハッシュと一致すると、イメージは改ざんされておらず信頼できます。

デジタル署名されたシスコのソフトウェア キーは、キーの種類やバージョンで識別されます。キーは、特殊、実稼働、またはロールオーバーのキーの種類です。実稼働および特殊なキータイプには、キーが失効および置換されるとアルファベット順に増分するキーバージョンが関連付けられています。ロード および標準 Cisco IOS イメージはいずれも、デジタル署名付きのシスコ ソフトウェア機能が使用されるときは、特殊キーまたは実稼働キーを使用して署名されます。ROMMON イメージはアップグレード可能で、ロードされる特殊または実稼働イメージと同じキーで署名される必要があります。

このコマンドは、デバイス キーのキーのフラッシュ イメージc3900-universalk9-mz.SSAの整合性を確認します:

show software authenticity file flash0:c3900-universalk9-mz.SSA

デジタルで署名済みのCiscoソフトウェア機能は、Cisco Catalyst 4500 Eシリーズ スイッチのCisco IOS XE Release 3.1.0.SGに統合されました。

この機能についての詳細は、『デジタル署名付き Cisco ソフトウェア』を参照してください。

Cisco IOS Software Release 15.1(1) T以降では、デジタルによって署名されたシスコ ソフトウェアのキー交換が導入されました。キーの置換と失効は、デジタル署名付きシスコソフトウェアのチェックに使用されるキーを置換し、プラットフォームキーストレージから削除します。特に、ネットワーク製品キーPrime侵害でキャンセルできます。

（特殊または実稼働）イメージの新しい（特殊または実稼働）キーは、前の特殊キーまたは実稼働キーの失効に使用される（実稼働または失効）イメージに含まれます。プラットフォームに初期化されている失効イメージ整合性がロールオーバーのキーによって検証されます。ロールオーバーのキーは変更されません。ROMMONイメージがアップグレードされ、新しい実稼働イメージが起動されている限り、実稼働キーを失効させる際に、失効イメージがロードされた後に搬送される新しいキーがキーストアに追加され、関連付けられている古いキーを失効させることができます。特別なキーをキャンセルすると、製品イメージがロードされます。このイメージは新しい特別なキーを追加し、既存の特別なキーをキャンセルできます。ROMMONをアップグレードした後、新しい特殊なイメージをブートできます。

次に、特別なキーの失効を示します。これらのコマンドは、現在の実稼働イメージからキーストアに新しい特殊キーを追加し、新しいROMMONイメージ(C3900_rom-monitor.srec.SSB)をストレージエリア(usbflash0:)にコピーし、ROMMONファイルをアップグレードし、古い特殊キーを失効させます。

software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special

新しい特殊なイメージ（c3900-universalk9-mz.SSB）は、新しく追加された特別なキー（.SSB）にロードするフラッシュとイメージ署名が確認されているコピーできます:

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

このスイッチがデジタル証明書によって署名されたシスコ ソフトウェア機能をサポートしますが、キー失効と交換はCisco IOS XEソフトウェアを実行しているCatalyst 4500 Eシリーズ スイッチではサポートされません。

この機能の詳細については、デジタル証明書によって署名された、Ciscoソフトウェアのマニュアルのデジタル証明書によって署名されたシスコのソフトウェア キー失効と交換の項を参照してください。

設定変更通知とロギング

コンフィギュレーション変更通知とロギング機能は、Cisco IOSソフトウェアリリース12.3(4)Tで追加されました。この機能を使用すると、Cisco IOSデバイスに加えられたコンフィギュレーションの変更をログに記録できます。ログはCisco IOSデバイスで保持され、変更を行ったユーザのユーザ情報、入力した設定コマンド、および変更時刻が記録されます。この機能をイネーブルにするには、logging enable 設定変更ロガー コンフィギュレーション モード コマンドを使用します。オプションコマンドのhidekeysとlogging size entriesを使用すると、パスワードデータのログが記録されなくなり、変更ログのサイズが増えるため、デフォルト設定が改善されます。

Cisco IOSデバイスのコンフィギュレーション変更履歴を理解しやすくするために、この機能を有効にすることを推奨いたします。さらに、コンフィギュレーションの変更時に syslog メッセージが生成されるように、notify syslog コンフィギュレーション コマンドを使用することを推奨いたします。

!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog
!

コンフィギュレーション変更通知とロギング機能をイネーブルにすると、特権EXECコマンドshow archive log config allを使用して、コンフィギュレーションログを表示できます。

コントロール プレーン

コントロール プレーン機能は、発信元から宛先へデータを移動するために、ネットワーク デバイス間でやりとりされるプロトコルとプロセスで構成されます。これには、Border Gateway Protocol（BGP；ボーダーゲートウェイプロトコル）などのルーティングプロトコルや、ICMPおよびResource Reservation Protocol（RSVP；リソース予約プロトコル）などのプロトコルが含まれます。

管理プレーンおよびデータ プレーンでのイベントによって、コントロール プレーンに悪影響が及ばないようにすることが重要です。DoS攻撃などのデータプレーンイベントがコントロールプレーンに影響を与えると、ネットワーク全体が不安定になる可能性があります。Cisco IOS ソフトウェア機能とコンフィギュレーションに関するこの情報は、コントロール プレーンの復元力確保に役立ちます。

コントロール プレーン全般の強化

ネットワークデバイスのコントロールプレーンの保護は重要です。コントロールプレーンによって、管理プレーンとデータプレーンの維持と運用が保証されるからです。セキュリティインシデントの発生中にコントロールプレーンが不安定になると、ネットワークの安定性を回復できなくなる可能性があります。

多くの場合、インターフェイスで特定のメッセージタイプの受信と送信を無効にして、不要なパケットの処理に必要なCPU負荷を最小限に抑えることができます。

IP ICMP リダイレクト

同じインターフェイスでパケットを送受信する際に、ルータでは ICMP リダイレクト メッセージが生成される場合があります。この場合、ルータはパケットを転送し、元のパケットの送信者には ICMP リダイレクト メッセージを送信します。この動作により、送信者はそのルータをバイパスして、後続パケットを宛先（または宛先により近いルータ）に直接転送できます。 正常に機能している IP ネットワークでは、ルータは自分のローカル サブネット上のホストに対してだけリダイレクトを送信します。つまり、ICMPリダイレクトは通常、レイヤ3の境界を越えることはありません。

ICMP リダイレクト メッセージには、ホスト アドレスのリダイレクトとサブネット全体のリダイレクトという 2 つのタイプがあります。悪意のあるユーザが、ルータにパケットを継続的に送信することでICMPリダイレクトを送信するルータの機能を悪用し、ルータにICMPリダイレクトメッセージで応答するように強制し、CPUとルータのパフォーマンスに悪影響を及ぼす可能性があります。ルータでICMPリダイレクトが送信されないようにするには、no ip redirectsインターフェイスコンフィギュレーションコマンドを使用します。

ICMP 到達不能

インターフェイスアクセスリストを使用してフィルタリングを行うと、フィルタリングされたトラフィックの送信元にICMP到達不能メッセージが返されます。これらのメッセージが生成されると、デバイスのCPU使用率が増加する可能性があります。デフォルトでは、Cisco IOSソフトウェアでICMP到達不能メッセージの生成が500ミリ秒ごとに1パケットに制限されています。ICMP 到達不能メッセージの生成を無効にするには、インターフェイス コンフィギュレーション コマンド no ip unreachables を使用します。ICMP到達不能レート制限をデフォルト設定から変更するには、グローバルコンフィギュレーションコマンドip icmp rate-limit unreachable interval-in-msを使用します。

プロキシ ARP

プロキシARPは、1つのデバイス（通常はルータ）が別のデバイス宛てのARP要求に応答する技法です。IDの偽装により、ルータはパケットを実際の宛先にルーティングする責任を引き受けます。プロキシARPは、ルート設定やデフォルトゲートウェイなしで、サブネット上のマシンがリモートサブネットに到達するのに役立ちます。プロキシ ARP は、RFC 1027 で定義されています。

プロキシARPの使用には欠点があります。プロキシ ARP を使用すると、ネットワーク セグメント上の ARP トラフィック、およびリソース枯渇攻撃や中間者（man-in-the-middle）攻撃が増加する可能性があります。プロキシ ARP では、プロキシ処理されたそれぞれの ARP 要求が少量のメモリを消費するので、リソース枯渇攻撃が誘発されます。攻撃者は、大量のARP要求を送信すると、使用可能なメモリをすべて使い果たす可能性があります。

中間者攻撃は、ネットワーク上のホストがルータのMACアドレスをスプーフィングすることによって、ホストが攻撃者にトラフィックを不注意に送信することを可能にします。プロキシ ARP をディセーブルにするには、インターフェイス コンフィギュレーション コマンド no ip proxy-arp を使用します。

コントロール プレーン トラフィックの CPU への影響の制限

コントロール プレーンの保護は非常に重要です。データトラフィックと管理トラフィックが存在しなければ、アプリケーションパフォーマンスとエンドユーザエクスペリエンスに悪影響が及ぶ可能性があるため、コントロールプレーンの耐障害性により、他の2つのプレーンが維持され、動作していることが保証されます。

コントロール プレーン トラフィックについて

Cisco IOSデバイスのコントロールプレーンを適切に保護するには、CPUによってプロセススイッチングされるトラフィックタイプを理解する必要があります。プロセススイッチされたトラフィックは、通常、2つの異なるトラフィックタイプで構成されます。最初のトラフィックタイプはCisco IOSデバイス宛てであり、Cisco IOSデバイスのCPUで直接処理する必要があります。このトラフィックは、受信隣接関係トラフィックカテゴリで構成されます。このトラフィックには、ネクストルータホップがそのデバイス自体であるCisco Express Forwarding(CEF)テーブルのエントリが含まれています。これは、show ip cef CLI出力のreceiveという用語で示されます。この用語が表示されるのは、Cisco IOS デバイスの CPU で直接処理する必要がある IP アドレスの場合です。これには、インターフェイス IP アドレス、マルチキャスト アドレス レンジ、ブロードキャスト アドレス レンジがあります。

CPUが処理する2つ目のトラフィックタイプは、データプレーントラフィックです。これは、Cisco IOSデバイス以外を宛先とするトラフィックであり、CPUによる特別な処理が必要です。データプレーントラフィックによるCPUへの影響の完全なリストではありませんが、次のトラフィックタイプはプロセススイッチングされるため、コントロールプレーンの動作に影響を与える可能性があります。

• アクセスコントロールリストロギング:ACLログトラフィックは、logキーワードが使用された場合のACEの一致（許可または拒否）によって生成されるあらゆるパケットで構成されます。
  
  
• ユニキャストリバースパス転送（ユニキャストRPF）：ユニキャストRPFは、ACLとともに使用され、特定のパケットのプロセススイッチングが行われる可能性があります。
  
  
• IP オプション：オプションが指定された任意の IP パケットは、CPU で処理する必要があります。
  
  
• フラグメンテーション：フラグメンテーションを必要とする任意のIPパケットは、CPUに渡して処理する必要があります。
  
  
• 存続可能時間(TTL)の期限切れ:TTL値が1以下のパケットでは、インターネット制御メッセージプロトコルのTime Exceeded（ICMPタイプ11、コード0）メッセージが送信される必要があります。これによりCPU処理が発生します。
  
  
• ICMP到達不能：ルート、MTU、またはフィルタリングによってICMP到達不能メッセージを発生させるパケットは、CPUで処理されます。
  
  
• ARP要求を必要とするトラフィック:ARPエントリが存在しない宛先は、CPUで処理されます。
  
  
• 非 IP トラフィック：すべての非 IP トラフィックは CPU で処理されます。

次のリストでは、Cisco IOSデバイスのCPUで処理されるトラフィックタイプを判別する方法について詳しく説明します。

• show ip cefコマンドを実行すると、CEFテーブルに含まれる各IPプレフィクスのネクストホップ情報が表示されます。前述したように、receive が「Next Hop」と表示されるエントリは受信隣接関係であるとみなされ、そのトラフィックは直接 CPU に送信される必要があることを示しています。
  
  
• show interface switching コマンドを実行すると、デバイスでプロセス スイッチングされているパケット数の情報が表示されます。
  
  
• show ip traffic コマンドを実行すると、次の IP パケットの数に関する情報が表示されます。
  
  
  • 宛先がローカルである（受信隣接関係トラフィック）
  • オプションがついている
  • フラグメンテーションを必要としている
  • ブロードキャスト アドレス レンジに送られている
  • マルチキャスト アドレス レンジに送られている
    
    
• 受信隣接関係トラフィックを識別するには、show ip cache flowコマンドを使用します。Cisco IOSデバイス宛てのフローの宛先インターフェイス(DstIf)はlocalです。
  
  
• コントロールプレーンポリシングを使用すると、Cisco IOSデバイスのコントロールプレーンに到達するトラフィックの種類とレートを識別できます。コントロールプレーンポリシングを実行するには、詳細な分類のACL、ログ、およびshow policy-map control-planeコマンドを使用します。

インフラストラクチャ ACL

Infrastructure ACL（iACL; インフラストラクチャ ACL）によって、外部通信をネットワークのデバイスに制限できます。iACLについては、このドキュメントの「インフラストラクチャACLによるネットワークアクセス制限」セクションで詳しく説明しています。

iACLを実装して、すべてのネットワークデバイスのコントロールプレーンを保護することを推奨します。

受信 ACL

分散プラットフォームでは、Cisco 12000（GSR）用の Cisco IOS ソフトウェア リリース 12.0(21)S2、Cisco 7500 用のリリース 12.0(24)S、および Cisco 10720 用のリリース 12.0(31)S に、Receive ACL（rACL; 受信 ACL）を使用することもできます。rACL は、ルート プロセッサが有害なトラフィックの影響を受ける前に、そのトラフィックからデバイスを保護します。rACLは、それが設定されているデバイスを保護するためだけに設計されており、通過トラフィックはrACLの影響を受けません。その結果、表示されているACLの例で使用されている宛先IPアドレス「any」は、ルータの物理IPアドレスまたは仮想IPアドレスのみを参照します。rACLは、ネットワークセキュリティのベストプラクティスとしても考慮され、優れたネットワークセキュリティへの長期的な付加機能としても考慮できます。

次に示すのは、192.168.100.0/24 ネットワーク上の信頼できるホストからの SSH（TCP ポート 22）トラフィックを許可するように記述された受信パス ACL です。

!
!--- Permit SSH from trusted hosts allowed to the device.
!

access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22
!
!--- Deny SSH from all other sources to the RP.
!

access-list 151 deny tcp any any eq 22
!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!

access-list 151 permit ip any any
!
!--- Apply this access list to the receive path.
!

ip receive access-list 151
!

デバイスへの正当なトラフィックを識別して許可を与え、望ましくないパケットをすべて拒否するには、『GSR：受信アクセスコントロールリスト』を参照してください。

CoPP

CoPP機能を使用して、インフラストラクチャデバイス宛てのIPパケットを制限することもできます。次の例では、信頼できるホストからの SSH トラフィックのみが Cisco IOS デバイスの CPU に到達することを許可されます。 

注：不明なIPアドレスまたは信頼できないIPアドレスからドロップされたトラフィックによって、動的に割り当てられたIPアドレスを持つホストがCisco IOSデバイスへの接続を確立できないことがあります。

!

access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any
!

class-map match-all COPP-KNOWN-UNDESIRABLE
 match access-group 152
!

policy-map COPP-INPUT-POLICY
 class COPP-KNOWN-UNDESIRABLE
  drop
!

control-plane
 service-policy input COPP-INPUT-POLICY
!

前のCoPPの例では、ACLエントリのpermitアクションに一致する不正なパケットがある場合、このようなパケットはポリシーマップのdrop機能によって廃棄されますが、denyアクション（非表示）に一致するパケットは、ポリシーマップdrop機能の影響を受けません。

CoPP は、Cisco IOS ソフトウェア リリース トレイン 12.0S、12.2SX、12.2S、12.3T、12.4、および 12.4T で使用できます。

コントロール プレーン保護

コントロールプレーン保護(CPPr)は、Cisco IOSソフトウェアリリース12.4(4)Tで導入されました。この機能を使用すると、Cisco IOSデバイスのCPU宛てのコントロールプレーントラフィックを制限またはポリシングできます。CPPrはCoPPと同様に、トラフィックをきめ細かく制限できます。CPPrは、集約コントロールプレーンを、サブインターフェイスと呼ばれる3つの個別のコントロールプレーンカテゴリに分割します。サブインターフェイスが存在するのは、Host、Transit、および CEF-Exception のトラフィック カテゴリです。さらに、CPPr には次のコントロール プレーン保護機能があります。

• ポートフィルタリング機能：閉じているか受信状態ではないTCPポートやUDPポートに送信されるパケットのポリシングと廃棄を行います。
  
  
• キューしきい値機能：コントロールプレーンIP入力キューで許可されている指定されたプロトコルのパケット数を制限します。

CPPr機能の使用方法についての詳細は、『コントロールプレーン保護(CPPr)について』を参照してください。

ハードウェア レート制限機能

Cisco Catalyst 6500シリーズSupervisor Engine 32およびSupervisor Engine 720は、特殊なネットワークシナリオに対して、プラットフォーム固有のハードウェアベースのレートリミッタ(HWRL)をサポートしています。これらのハードウェア レート制限機能は、IPv4、IPv6、ユニキャスト、マルチキャストの DoS 攻撃シナリオに関する詳細な定義済みセットをカバーしており、特殊なケースのレート リミッタと呼ばれています。HWRLは、パケットをCPUで処理する必要のあるさまざまな攻撃からCisco IOSデバイスを保護できます。

デフォルトでは、複数のHWRLが有効になっています。HWRLの詳細は、『PFC3ハードウェアベースレートリミッタのデフォルト設定』を参照してください。

HWRL の詳細は、『PFC3 でのハードウェアベース レート リミッタ』を参照してください。

BGPを固定します

Border Gateway Protocol（BGP; ボーダー ゲートウェイ プロトコル）は、インターネットのルーティングの基盤です。したがって、標準より厳しい接続要件を設けている組織では、多くの場合、BGP を利用しています。BGPは、そのユビキタス性と、小規模な組織でのBGP設定のセット&フォワード性から、しばしば攻撃者の標的となります。ただし、BGP設定のセキュリティを強化するために利用できるBGP固有のセキュリティ機能は数多くあります。

ここでは、最も重要なBGPセキュリティ機能の概要を示し、必要に応じて設定の推奨事項を示します。

TTL ベースのセキュリティ保護

それぞれの IP パケットには、Time To Live（TTL; 存続可能時間）と呼ばれる 1 バイトのフィールドが含まれています。 IP パケットがデバイスを通過するごとに、この値は 1 ずつ減ります。TTLの開始値はオペレーティングシステムによって異なり、通常は64 ～ 255の範囲です。TTL 値が 0 に達したパケットは廃棄されます。

Generalized TTL-based Security Mechanism(GTSM)およびBGP TTL Security Hack(BTSH)と呼ばれるTTLベースのセキュリティ保護では、IPパケットのTTL値を利用して、受信したBGPパケットが直接接続されたピアからのものであることが確認されます。この機能は、多くの場合、ピアルータからの調整を必要としますが、有効にすると、BGPに対する多くのTCPベースの攻撃を完全に防ぐことができます。

BGP 用の GTSM をイネーブルにするには、neighbor BGP ルータ コンフィギュレーション コマンドの ttl-security オプションを使用します。次の例は、この機能の設定を示しています。

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>
!

BGPパケットが受信されると、TTL値がチェックされます。TTL値は、255から指定のhop-countを差し引いた数値以上である必要があります。

MD5 による BGP ピア認証

MD5によるピア認証では、BGPセッションの一部として送信される各パケットのMD5ダイジェストが作成されます。具体的には、IPヘッダーとTCPヘッダーの一部、TCPペイロード、および秘密キーがダイジェストの生成に使用されます。

作成されたダイジェストは TCP オプション Kind 19 に保存されます。これは、この目的のために RFC 2385 で定義されたオプションです。受信側のBGPスピーカは、同じアルゴリズムと秘密鍵を使用して、メッセージダイジェストを再生成します。受信されたダイジェストと算出されたダイジェストが一致しない場合、パケットは廃棄されます。

MD5 によるピア認証を設定するには、neighbor BGP ルータ コンフィギュレーション コマンドの password オプションを使用します。このコマンドの使用方法を次に示します。

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>
!

MD5 による BGP ピア認証についての詳細は『ネイバー ルータの認証』を参照してください。

最大プレフィックス数の設定

BGP プレフィクスはルータによりメモリに保持されます。ルータが保持するプレフィクスが多いほど、BGPが消費するメモリは多くなります。一部の設定では、プロバイダーのユーザネットワークに対してデフォルトルートだけを利用する設定など、すべてのインターネットプレフィクスのサブセットを保存できます。

メモリの枯渇を防ぐには、ピアごとに受け入れられるプレフィクスの最大数を設定します。各 BGP ピアに上限を設定することを推奨いたします。

neighbor maximum-prefix BGPルータコンフィギュレーションコマンドを使用してこの機能を設定する場合、受け入れられるプレフィクスの最大数を引数として指定します。この数に達すると、ピアはシャットダウンされます。オプションで、1 ～ 100 の数値を入力することもできます。この数値は、ログメッセージの送信時の最大プレフィクス値のパーセンテージを表します。

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!

ピアごとの最大プレフィクスについての詳細は、『BGP 最大プレフィクス機能の設定』を参照してください。

プレフィックス リストによる BGP プレフィックスのフィルタリング

プレフィックスリストを使用すると、ネットワーク管理者は、BGPで送受信される特定のプレフィックスを許可または拒否できます。可能な場合は、プレフィックスリストを使用して、ネットワークトラフィックが目的のパスを介して送信されるようにします。着信と発信の両方向で各eBGPピアにプレフィックスリストを適用します。

設定されたプレフィックスリストは、送受信されるプレフィックスを、ネットワークのルートポリシーで特に許可されているものに制限します。受信したプレフィクスが多数あるためにフィージブルサクセサを使用できない場合は、既知の不正なプレフィクスを明確にブロックするようにプレフィックスリストを設定します。これらの既知の不正プレフィックスには、未割り当てのIPアドレススペースや、RFC 3330によって内部またはテストの目的で予約されたネットワークが含まれます。 組織がアドバタイズするプレフィックスだけを明示的に許可するように、発信プレフィックスリストを設定します。

次の設定例では、プレフィクス リストを使用して、学習するルートとアドバタイズするルートを制限しています。具体的には、プレフィクス リスト BGP-PL-INBOUND によってデフォルト ルートのみが着信を許可され、BGP-PL-OUTBOUND によってプレフィクス 192.168.2.0/24 のみがアドバタイズを許可されます。

!

ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24
!

router bgp <asn>
 neighbor <ip-address> prefix-list BGP-PL-INBOUND in
 neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out
!

BGPプレフィクスフィルタ情報の詳細は、『外部BGPを使用したサービスプロバイダーへの接続』を参照してください。

自律システムパスアクセスリストによるBGPプレフィックスのフィルタリング

BGP自律システム(AS)パスアクセスリストを使用すると、ユーザはプレフィックスのAS-pathアトリビュートに基づいて、受信およびアドバタイズされたプレフィックスをフィルタリングできます。これは、プレフィックスリストと組み合わせて使用することで、堅牢なフィルタセットを確立できます。

次の設定例では、AS パス アクセス リストを使用して、着信プレフィクスをリモート AS から発信されたプレフィクスに制限し、発信プレフィクスをローカルの自律システムから発信されたプレフィクスに制限しています。他のすべての自律システムから送信されたプレフィックスはフィルタリングされ、ルーティングテーブルにはインストールされません。

!

ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$
!

router bgp <asn>
 neighbor <ip-address> remote-as 65501
 neighbor <ip-address> filter-list 1 in
 neighbor <ip-address> filter-list 2 out
!

内部ゲートウェイ プロトコルの保護

ネットワークがトラフィックを適切に転送し、トポロジの変更や障害から回復できるかどうかは、トポロジを正確に把握できるかどうかにかかっています。多くの場合、Interior Gateway Protocol(IGP)を実行してこのビューを表示できます。デフォルトでは、IGP は動的であり、使用中の特定の IGP と通信するルータの追加を検出します。また、IGPはネットワークリンクに障害が発生したときに使用できるルートも検出します。

以降のサブセクションでは、最重要の IGP セキュリティ機能の概要を示しています。Routing Information Protocol バージョン 2（RIPv2）、Enhanced IGRP（EIGRP）、および OSPF（Open Shortest Path First）について、推奨事項や使用例を交えて説明しています。

MD5 によるルーティング プロトコル認証と検証

ルーティング情報の交換を保護できなければ、攻撃者が不正なルーティング情報をネットワークに持ち込むことが可能になります。パスワード認証とルータ間のルーティングプロトコルを使用して、ネットワークセキュリティを強化する。ただし、この認証はクリアテキストで送信されるので、攻撃者がこのセキュリティ制御を弱体化させるのは容易である可能性があります。

MD5ハッシュ機能が認証プロセスに追加されると、ルーティングアップデートにクリアテキストのパスワードが含まれなくなり、ルーティングアップデートの内容全体が改ざんされにくくなります。ただし、脆弱なパスワードが使用されている場合でも、MD5認証はブルートフォース攻撃や辞書攻撃の影響を受けやすくなります。十分にランダム化されたパスワードを使用してください。MD5 認証は、パスワード認証と比べると格段にセキュリティが強化されているので、次の例は MD5 認証に特化しています。IPSecは、ルーティングプロトコルの検証と保護にも使用できますが、次の例ではその使用法については詳しく説明しません。

EIGRPとRIPv2は両方とも、設定の一部としてキーチェーンを使用します。キー チェーンの設定と使用法の詳細は、『鍵』を参照してください。

MD5を使用するEIGRPルータ認証の設定例を次に示します。

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip authentication mode eigrp <as-number> md5
 ip authentication key-chain eigrp <as-number> <key-name>
!

RIPv2 用の MD5 ルータ認証の設定例を次に示します。RIPv1 では認証はサポートされていません。

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>
!

MD5によるOSPFルータ認証の設定例を次に示します。OSPFはキーチェーンを使用しません。

!

interface <interface>
 ip ospf message-digest-key <key-id> md5 <password>
!

router ospf <process-id>
 network 10.0.0.0 0.255.255.255 area 0
 area 0 authentication message-digest
!

詳細は、『OSPF の設定』を参照してください。

passive-interface コマンド

ルーティング情報のアドバタイズメントの制御を支援するpassive-interfaceコマンドを使用することで、情報のリーク、つまり不正な情報のIGPへの流入を緩和できます。管理制御外のネットワークに情報をアドバタイズしないようお勧めします。

次の例では、この機能の使用方法を示します。

!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>
!

ルート フィルタリング

ネットワークに誤ったルート情報が生じる可能性を減らすために、ルートフィルタリングを使用します。passive-interfaceルータコンフィギュレーションコマンドとは異なり、ルートフィルタリングがイネーブルになると、ルーティングはインターフェイス上で実行されますが、アドバタイズされる情報や処理される情報は制限されます。

EIGRPおよびRIPの場合、distribute-listコマンドにoutキーワードを指定すると、アドバタイズされる情報が制限され、inキーワードを指定すると、処理されるアップデートが制限されます。OSPFではdistribute-listコマンドを使用できますが、このコマンドによって、フィルタリングされたルートの伝搬がルータで阻止されることはありません。代わりに、area filter-list コマンドが使用できます。

次の EIGRP の例では、distribute-list コマンドとプレフィクス リストによって発信アドバタイズメントをフィルタリングしています。

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> out <interface>
!

次の EIGRP の例では、プレフィクス リストによって着信アップデートをフィルタリングしています。

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> in <interface>
!

次の OSPF の例では、OSPF 固有の area filter-list コマンドとプレフィクス リストを使用しています。

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 
!

ルーティング プロセスのリソース消費

ルーティングプロトコルプレフィックスはルータによってメモリに保存され、ルータが保持する必要のあるプレフィックスが追加されるとリソース消費が増加します。リソースの枯渇を防ぐには、リソースの消費を制限するようにルーティングプロトコルを設定します。これを OSPF で実現するには、リンクステート データベース過負荷保護機能を使用します。

次の例では、OSPF のリンクステート データベース過負荷保護機能の設定を示しています。

!

router ospf <process-id>
 max-lsa <maximum-number> 
!

ファーストホップ冗長プロトコルの保護

First Hop Redundancy Protocol（FHRP; ファースト ホップ冗長プロトコル）によって、デフォルト ゲートウェイとして機能するデバイスの復元力と冗長性が強化されます。この状況やこれらのプロトコルは、2 台のレイヤ 3 デバイスがネットワーク セグメント、またはサーバやワークステーションを含む VLAN においてデフォルト ゲートウェイとして機能している環境では一般的です。

Gateway Load-Balancing Protocol（GLBP; ゲートウェイ ロードバランシング プロトコル）、Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）、および Virtual Router Redundancy Protocol（VRRP; 仮想ルータ冗長プロトコル）は、どれも FHRP です。デフォルトでは、これらのプロトコルにより認証なしで通信されます。この種の通信により、攻撃者がFHRP準拠デバイスになりすまして、ネットワーク上でデフォルトゲートウェイの役割を引き継ぐことができます。この乗っ取りにより、攻撃者は中間者攻撃を実行し、ネットワークから出るすべてのユーザトラフィックを代行受信できます。

このタイプの攻撃を防止するために、Cisco IOSソフトウェアでサポートされているすべてのFHRPには、MD5またはテキスト文字列を使用する認証機能が含まれています。脅威がもたらされるのは認証が行われていない FHRP によるので、これらのプロトコルのインスタンスでは MD5 認証を使用することが推奨されます。次の設定例では、GLBP、HSRP、および VRRP の MD5 認証の使用法を示しています。

!

interface FastEthernet 1
 description *** GLBP Authentication ***
 glbp 1 authentication md5 key-string <glbp-secret>
 glbp 1 ip 10.1.1.1
!

interface FastEthernet 2
 description *** HSRP Authentication ***
 standby 1 authentication md5 key-string <hsrp-secret>
 standby 1 ip 10.2.2.1
!

interface FastEthernet 3
 description *** VRRP Authentication ***
 vrrp 1 authentication md5 key-string <vrrp-secret> 
 vrrp 1 ip 10.3.3.1
!

データ プレーン

データプレーンは送信元から宛先へのデータの移動を担当しますが、セキュリティの観点では、データプレーンは3つのプレーンの中で最も重要性の低いプレーンです。このため、ネットワークデバイスを保護する際には、データプレーンよりも管理プレーンとコントロールプレーンを保護することが重要です（保護する側のプレーンの種類を選択してください）。

ただし、データ プレーン自体にも、トラフィックの保護に役立つ機能や設定オプションが多数あります。次のセクションでは、ネットワークをより簡単に保護できるように、機能とオプションについて詳しく説明します。

データプレーン全般の強化

データプレーントラフィックの大部分は、ネットワークルーティング設定によって決定されたとおりにネットワークを通過します。ただし、ネットワークを通過するパケットのパスを変更する IP ネットワーク機能が存在します。IPオプション、特にソースルーティングオプションなどの機能は、今日のネットワークのセキュリティ上の課題を形成します。

トランジットACLの使用は、データプレーンの強化にも関連します。

詳細は、「通過トラフィックのトランジットACLによるフィルタリング」セクションを参照してください。

IP オプションの選択的廃棄

IP オプションに関係するセキュリティの懸念は 2 つあります。IPオプションを含むトラフィックは、Cisco IOSデバイスによってプロセススイッチングされる必要があり、これがCPU負荷の上昇につながる可能性があります。IPオプションには、ネットワークを通過するトラフィックのパスを変更する機能も含まれており、これによってセキュリティ制御が弱体化する可能性があります。

これらの懸念から、Cisco IOS ソフトウェア リリース 12.3(4)T、12.0(22)S、および 12.2(25)S には、グローバル コンフィギュレーション コマンド ip options {drop | ignore} が追加されています。最初の形式のip options dropを使用すると、Cisco IOSデバイスによって受信されるIPオプションを含むすべてのIPパケットが廃棄されます。これにより、CPU 負荷の上昇と、IP オプションによって引き起こされる可能性があるセキュリティ制御の弱体化の両方が防止されます。

2番目の形式のip options ignoreを使用すると、受信パケットに含まれるIPオプションが無視されるようにCisco IOSデバイスが設定されます。これにより、ローカルデバイスのIPオプションに関連する脅威は軽減されますが、ダウンストリームデバイスはIPオプションの存在の影響を受ける可能性があります。このため、このコマンドのdrop形式を使用することを強く推奨します。次の設定例で示されています。

!
ip options drop
!

一部のプロトコル（RSVPなど）では、IPオプションが正しく使用されます。このようなプロトコルの機能は、このコマンドの影響を受けます。

IPオプションの選択的廃棄をイネーブルにすると、show ip traffic EXECコマンドを使用して、IPオプションの存在によって廃棄されたパケットの数を把握できます。この情報は、forced drop カウンタに示されます。

IP ソース ルーティングを無効化

IPソースルーティングでは、Loose Source RouteオプションとRecord Routeオプションを同時に使用するか、Strict Source RouteオプションとRecord Routeオプションを使用して、パケットがたどるネットワークパスをIPデータグラムソースが指定できるようにします。この機能は、ネットワーク上のセキュリティ制御にトラフィックをルーティングする試みで使用できます。

IPオプションの選択的廃棄機能によってIPオプションが完全に無効にされていない場合は、IPソースルーティングを無効にすることが重要です。IPソースルーティングはすべてのCisco IOSソフトウェアリリースでデフォルトでイネーブルになっています。これをディセーブルにするには、no ip source-routeグローバルコンフィギュレーションコマンドを使用します。次の設定例は、このコマンドの使用方法を示しています。

!
no ip source-route
!

ICMPリダイレクトの無効化

ICMPリダイレクトは、ネットワークデバイスにIP宛先へのより良いパスを通知するために使用されます。デフォルトでは、受信したインターフェイスを介してルーティングを行う必要があるパケットを受信した場合に、リダイレクトが送信されます。

状況によっては、攻撃者がCisco IOSデバイスに多数のICMPリダイレクトメッセージを送信させ、結果としてCPU負荷を上昇させることも可能です。このため、ICMPリダイレクトの送信を無効にすることを推奨します。ICMPリダイレクトをディセーブルにするには、次の設定例に示すように、インターフェイスコンフィギュレーションのno ip redirectsコマンドを使用します。

!

interface FastEthernet 0
 no ip redirects
!

IP ダイレクト ブロードキャストのディセーブル化または制限

IP ダイレクト ブロードキャストによって、IP ブロードキャスト パケットをリモート IP サブネットに送信できるようになります。パケットがリモートネットワークに到達すると、転送IPデバイスはパケットをレイヤ2ブロードキャストとしてサブネット上のすべてのステーションに送信します。このダイレクトブロードキャスト機能は、smurf攻撃を含むいくつかの攻撃で増幅およびリフレクションの補助手段として利用されています。

Cisco IOSソフトウェアの現在のバージョンでは、この機能はデフォルトでディセーブルになっています。ただし、ip directed-broadcastインターフェイスコンフィギュレーションコマンドでイネーブルにできます。デフォルトでは、12.0より前のCisco IOSソフトウェアリリースでは、この機能が有効になっています。

ネットワークでダイレクトブロードキャスト機能が絶対的に必要な場合は、その使用を制御します。これを行うには、ip directed-broadcastコマンドのオプションとしてACLを使用します。次の設定例では、ダイレクトブロードキャストを信頼できるネットワーク192.168.1.0/24から発信されたUDPパケットに制限しています。

!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!

interface FastEthernet 0
 ip directed-broadcast 100
!

通過トラフィックのトランジットACLによるフィルタリング

トランジットACL(tACL)を使用すると、どのトラフィックがネットワークを通過するかを制御できます。 これは、ネットワーク自体を宛先とするトラフィックをフィルタリングしようとするiACLとは対照的です。特定のデバイスグループへのトラフィックまたはネットワークを通過するトラフィックをフィルタリングすることを目的としている場合は、tACLによるフィルタが便利です。

従来、ファイアウォールはこのフィルタタイプを実行します。ただし、ネットワーク上のCisco IOSデバイスでこのフィルタを実行すると有益な場合があります。たとえば、フィルタリングを実行する必要があるが、ファイアウォールが存在しない場合です。

tACLは、スタティックアンチスプーフィング保護を実装する適切な場所でもあります。

詳細については、「アンチスプーフィング保護」のセクションを参照してください。

tACL についての詳細は、『トランジット アクセス コントロール リスト：エッジでのフィルタリング』を参照してください。

ICMP パケット フィルタリング

インターネット制御メッセージプロトコル(ICMP)は、IPの制御プロトコルとして設計されました。そのため、伝送されるメッセージは、一般にTCPおよびIPプロトコルに重大な影響を及ぼす可能性があります。ICMPは、ツールのpingやtraceroute、ネットワークのトラブルシューティング、およびパスMTUディスカバリで使用されます。ただし、適切なネットワーク動作のために外部ICMP接続が必要になることはほとんどありません。

Cisco IOS ソフトウェアには、ICMP メッセージを名前または種類およびコードで詳細にフィルタリングする機能があります。次のACLの例では、信頼できるネットワークからのICMPを許可し、その他の送信元からのすべてのICMPパケットをブロックしています。

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Permit ICMP packets from trusted networks only
!

 permit icmp host <trusted-networks> any 
!
!--- Deny all other IP traffic to any network device
!

 deny icmp any any
!

IP フラグメントのフィルタリング

このドキュメントの「インフラストラクチャACLによるネットワークアクセス制限」セクションで説明したように、フラグメント化されたIPパケットのフィルタは、セキュリティデバイスにとっての課題です。

フラグメント制御はわかりにくいため、IPフラグメントが誤ってACLによって許可されることがあります。また、侵入検知システムによる検出を逃れようとして、フラグメンテーションが使用されることもよくあります。これらの理由から、IPフラグメントは攻撃で使用されることが多く、設定されたtACLの先頭で明示的にフィルタリングできます。リストされているACLの例には、IPフラグメントの包括的なフィルタが含まれています。この例で示されている機能は、前の例の機能と組み合わせて使用する必要があります。

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in 
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!

フラグメント化された IP パケットの ACL による処理の詳細は、『アクセス コントロール リストと IP フラグメント』を参照してください。

ACLのIPオプションフィルタリングサポート

Cisco IOSソフトウェアリリース12.3(4)T以降では、ACLを使用して、パケットに含まれるIPオプションに基づいてIPパケットをフィルタリングできます。パケット内にIPオプションが存在することは、ネットワーク上のセキュリティ制御を弱体化させようとしているか、パケットの転送特性を変更しようとしていることを示している可能性があります。これらの理由から、IPオプションを持つパケットは、ネットワークのエッジでフィルタリングすることを推奨します。

IPオプションを含むIPパケットの完全なフィルタを含めるには、前の例の内容に加えて、次の例を使用します。

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!

アンチスプーフィング保護

攻撃の多くは、効果を高めるためや、攻撃の実際の発信元の隠蔽や正確なトレースバックの妨害のために、発信元 IP アドレスのスプーフィングを利用しています。Cisco IOS ソフトウェアには、発信元 IP アドレスのスプーフィングを利用した攻撃を防止するために、ユニキャスト RPF および IP Source Guard（IPSG; IP ソース ガード）という機能があります。さらに、多くの場合、スプーフィングを手動で阻止する手段として ACL とヌル ルーティングが展開されます。

IPSGは、スイッチポート、MACアドレス、および送信元アドレスの検証のパフォーマンスによって、直接管理制御下にあるネットワークのスプーフィングを最小限に抑えるように動作します。ユニキャストRPFでは、発信元ネットワークの検証が行われるため、直接管理制御下にないネットワークからのスプーフィング攻撃を減らすことができます。ポートセキュリティを使用すると、アクセスレイヤでMACアドレスを検証できます。Dynamic Address Resolution Protocol（ARP）Inspection（DAI）により、ローカル セグメントの ARP ポイズニングを利用する攻撃が抑制されます。

ユニキャスト RPF

ユニキャストRPFを使用すると、転送されたパケットの送信元アドレスが、そのパケットを受信したインターフェイスを介して到達可能かどうかをデバイスで確認できます。スプーフィングに対する唯一の保護としてユニキャストRPFに依存しないでください。発信元 IP アドレスに戻る適切なルートが存在する場合は、スプーフィングされたパケットが、ユニキャスト RPF に対応したインターフェイスを介してネットワークに侵入する可能性があります。ユニキャスト RPF を使用するには、各デバイスで Cisco エクスプレス フォワーディングがイネーブルになっている必要があります。ユニキャスト RPF はインターフェイスごとに設定されます。

ユニキャスト RPF には loose と strict という 2 つの動作モードがあり、どちらかを設定します。非対称ルーティングが存在する場合は、loose モードを推奨いたします。strict モードではこのような場合、パケットが廃棄されるからです。ip verify インターフェイス コンフィギュレーション コマンドの設定で、キーワード any を指定すると loose モード、キーワード rx を指定すると strict モードになります。

次の例は、この機能の設定を示しています。

!

ip cef
!

interface <interface>
  ip verify unicast source reachable-via <mode>
!

ユニキャスト RPF の設定と使用法についての詳細は、『ユニキャスト リバース パス転送について』を参照してください。

IP ソース ガード

レイヤ 2 インターフェイスを制御できる場合、IP ソース ガードはスプーフィングを防止する有効な手段です。IPソースガードでは、DHCPスヌーピングからの情報を使用して、レイヤ2インターフェイス上にポートアクセスコントロールリスト(PACL)が動的に設定されます。これは、IPソースバインディングテーブルに関連付けられていないIPアドレスからのトラフィックを拒否します。

IPソースガードは、DHCPスヌーピング対応のVLANに属するレイヤ2インターフェイスに適用できます。DHCP スヌーピングは次のコマンドによってイネーブルになります。

!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

DHCP スヌーピングをイネーブルにした後、次のコマンドによって IPSG がイネーブルになります。

!
interface <interface-id>
   ip verify source 
!

ポートセキュリティをイネーブルにするには、Tip verify source port securityインターフェイスコンフィギュレーションコマンドを使用します。これには、グローバル コンフィギュレーション コマンド ip dhcp snooping information option を実行する必要があります。さらに、DHCP サーバが DHCP オプション 82 をサポートしている必要があります。

この機能の詳細は、『DHCP 機能および IP ソース ガードの設定』を参照してください。

ポート セキュリティ

ポートセキュリティは、アクセスインターフェイスでのMACアドレスのスプーフィングを軽減するために使用されます。ポート セキュリティでは、動的に学習された（スティッキ）MAC アドレスを使用することで、初期設定が容易になります。ポート セキュリティによって MAC 違反が特定されると、4 つの違反モードのいずれかが適用されます。これらのモードには、protect、restrict、shutdown、およびshutdown VLANがあります。ポートが標準プロトコルを使用して1台のワークステーションへのアクセスのみを提供する場合は、最大数として1を指定するだけで十分です。HSRPなどの仮想MACアドレスを利用するプロトコルは、最大数が1に設定されていると機能しません。

!

interface <interface> 
  switchport
  switchport mode access 
  switchport port-security
  switchport port-security mac-address sticky
  switchport port-security maximum <number>
  switchport port-security violation <violation-mode>
!

ポート セキュリティの設定の詳細は、『ポート セキュリティの設定』を参照してください。

ダイナミック ARP インスペクション

ダイナミックARPインスペクション(DAI)を使用すると、ローカルセグメントのARPポイズニング攻撃を軽減できます。ARP ポイズニング攻撃は、攻撃者が不正な ARP 情報をローカル セグメントに送信するために利用されます。この情報は、他のデバイスの ARP キャッシュを破損する設計になっています。攻撃者は、ARPポイズニングを使用して中間者攻撃を実行することがよくあります。

DAI では、信頼されていないポートですべての ARP パケットを傍受し、IP アドレスと MAC アドレスの関連付けを検証します。DHCP環境では、DAIはDHCPスヌーピング機能によって生成されたデータを使用します。信頼できるインターフェイスで受信されたARPパケットは検証されず、信頼できないインターフェイスの無効なパケットは廃棄されます。非DHCP環境では、ARP ACLを使用する必要があります。

DHCPスヌーピングを有効にするには、次のコマンドを使用します。

!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

DHCP スヌーピングをイネーブルにした後、次のコマンドによって DAI がイネーブルになります。

!
ip arp inspection vlan <vlan-range> 
!

非DHCP環境では、DAIを有効にするにはARP ACLが必要です。次の設定例は、DAI と ARP ACL の基本設定を示しています。

!

arp access-list <acl-name>
 permit ip host <sender-ip> mac host <sender-mac>
!

ip arp inspection filter <arp-acl-name> vlan <vlan-range>
!

DAIは、サポートされている場所でインターフェイスごとに有効にすることもできます。

ip arp inspection limit rate <rate_value> burst interval <interval_value>

DAI の設定方法の詳細は、『ダイナミック ARP インスペクションの設定』を参照してください。

アンチスプーフィング ACL

手動で設定された ACL は、既知で未使用のアドレス レンジや信頼できないアドレス レンジを使用する攻撃に対して、静的なアンチスプーフィング機能を提供します。通常、このようなアンチスプーフィング ACL は、より大規模な ACL のコンポーネントとしてネットワーク バウンダリで入トラフィックに適用されます。アンチスプーフィングACLは頻繁に変更される可能性があるため、定期的な監視間隔が必要です。送信 ACL を適用してトラフィックを有効なローカル アドレスに制限すると、ローカル ネットワークから発信するトラフィックでのスプーフィングを最小に抑えることができます。

次の例は、ACLを使用してIPスプーフィングを制限する方法を示しています。この ACL は、対象のインターフェイスの着信側に適用されます。この ACL を構成する ACE は、すべてを網羅しているわけではありません。これらのACLタイプを設定する場合は、確実な最新の参照を探してください。

!

ip access-list extended ACL-ANTISPOOF-IN
 deny	ip 10.0.0.0 0.255.255.255 any
 deny	ip 192.168.0.0 0.0.255.255 any
!

interface <interface>
 ip access-group ACL-ANTISPOOF-IN in
!

アクセス コントロール リストの設定方法の詳細は、『一般的に使用される IP ACL の設定』を参照してください。

未割り当てのインターネット アドレスの公式リストは、Team Cymru によって管理されています。未使用アドレスのフィルタリング方法についての詳細は、『Bogon Reference Page』を参照してください。

データ プレーン トラフィックの CPU への影響の制限

ルータとスイッチの主目的は、パケットやフレームをデバイス経由で最終的な宛先まで転送することです。これらのパケットは、ネットワーク上に展開されたデバイスを通過するので、デバイスの CPU 動作に影響を及ぼす可能性があります。ネットワークデバイスを通過するトラフィックで構成されるデータプレーンを保護し、管理プレーンとコントロールプレーンの動作を保証します。通過トラフィックによってデバイスでスイッチトラフィックが処理されると、デバイスのコントロールプレーンが影響を受け、運用中断が発生する可能性があります。

CPU に影響する機能とトラフィックの種類

このリストには、完全ではありませんが、特別なCPU処理を必要とし、CPUによってプロセススイッチングされるデータプレーントラフィックのタイプが含まれています。

• ACLロギング:ACLログトラフィックは、logキーワードが使用された場合のACEの一致（許可または拒否）によって生成されるあらゆるパケットで構成されます。
  
  
• ユニキャストRPF：ユニキャストRPFがACLとともに使用される場合、特定のパケットのプロセススイッチングが行われる可能性があります。
  
  
• IPオプション：オプションが指定された任意のIPパケットは、CPUで処理する必要があります。
  
  
• フラグメンテーション：フラグメンテーションを必要とする任意の IP パケットは、CPU に渡して処理する必要があります。
  
  
• 存続可能時間（TTL）の期限切れ：TTL 値が 1 以下のパケットでは、インターネット制御メッセージ プロトコルの Time Exceeded（ICMP タイプ 11、コード 0）メッセージが送信される必要があります。これにより CPU 処理が発生します。
  
  
• ICMP到達不能：ルート、MTU、またはフィルタリングによってICMP到達不能メッセージを発生させるパケットは、CPUで処理されます。
  
  
• ARP要求を必要とするトラフィック:ARPエントリが存在しない宛先は、CPUで処理されます。
  
  
• 非IPトラフィック：すべての非IPトラフィックはCPUで処理されます。

データプレーンの強化の詳細については、「データプレーン全般の強化」セクションを参照してください。

TTL 値に基づくフィルタ

拡張IPアクセスリストで、ACLのTTL値フィルタリングサポート機能(Cisco IOSソフトウェアリリース12.4(2)Tで導入)を使用すると、TTL値に基づいてパケットをフィルタリングできます。この機能は、TTL値が0または1のトランジットトラフィックを受信するデバイスを保護できます。TTL値に基づくパケットのフィルタを使用して、TTL値がネットワークの直径を下回らないようにすることもできます。これにより、ダウンストリームのインフラストラクチャデバイスのコントロールプレーンがTTL超過攻撃から保護されます。

アプリケーションやtracerouteなどのツールでは、テストや診断のためにTTL期限切れパケットが使用されます。IGMP など一部のプロトコルでは、TTL 値が 1 のパケットが正規の目的で使用されます。

次の ACL の例では、TTL 値が 6 未満の IP パケットをフィルタリングするポリシーが作成されます。

!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any ttl lt 6
 permit ip any any
!
!--- Apply access-list to interface in the ingress direction
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

TTL値に基づいてパケットをフィルタリングする方法についての詳細は、『TTL超過攻撃の識別と緩和』を参照してください。

この機能についての詳細は、『ACL の TTL 値フィルタリング サポート』を参照してください。

Cisco IOS ソフトウェア リリース 12.4(4)T 以降では、Flexible Packet Matching（FPM）機能によって、パケット内の任意のビットを照合することができます。このFPMポリシーは、6未満のTTL値を持つパケットをドロップします。

!

load protocol flash:ip.phdf
!

class-map type access-control match-all FPM-TTL-LT-6-CLASS
 match field IP ttl lt 6
!

policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
 class  FPM-TTL-LT-6-CLASS
  drop
!

interface FastEthernet0
 service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY
!

IP オプションの有無によるフィルタ

Cisco IOSソフトウェアリリース12.3(4)T以降では、名前付き拡張IPアクセスリストでACLのIPオプションフィルタリングサポート機能を使用して、IPオプションを含むIPパケットをフィルタリングできます。IPオプションの有無に基づくIPパケットのフィルタを使用して、インフラストラクチャデバイスのコントロールプレーンで、これらのパケットをCPUレベルで処理する必要がないようにすることもできます。

ACLのIPオプションフィルタリングサポート機能は、名前付き拡張ACLでのみ使用できます。RSVP、マルチプロトコルラベルスイッチングトラフィックエンジニアリング、IGMPバージョン2および3、およびIPオプションパケットを使用するその他のプロトコルは、これらのプロトコルのパケットが廃棄されると正常に機能しません。これらのプロトコルがネットワークで使用されている場合は、ACLのIPオプションフィルタリングサポートを使用できます。ただし、ACLのIPオプション選択的廃棄機能によって、このトラフィックが廃棄される可能性があり、これらのプロトコルは正しく機能しません。これらのパケットの廃棄に ACL の IP オプション選択的廃棄が推奨されるのは、IP オプションを必要とするプロトコルが使用されていない場合です。

次の ACL の例では、IP オプションを含む IP パケットをフィルタリングするポリシーが作成されます。

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option any-options
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

次の ACL の例では、特定の 5 つの IP オプションを含む IP パケットをフィルタリングするポリシーを示しています。次のオプションを含むパケットが拒否されます。

• 0オプションリストの終了(eool)
  
  
• 7 ルートの記録（record-route）
  
  
• 68 タイム スタンプ（timestamp）
  
  
• 131 ルース ソース ルート（lsr）
  
  
• 137 ストリクト ソース ルート（ssr）

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option eool
 deny ip any any option record-route
 deny ip any any option timestamp
 deny ip any any option lsr
 deny ip any any option ssr
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

ACLのIPオプション選択的廃棄についての詳細は、このドキュメントの「データプレーン全般の強化」セクションを参照してください。

通過トラフィックとエッジトラフィックをフィルタリングする方法についての詳細は、『トランジットアクセスコントロールリスト：エッジでのフィルタリング』を参照してください。

Cisco IOSソフトウェアのもう1つの機能であるCoPPを使用すると、IPオプションを持つパケットをフィルタリングできます。Cisco IOSソフトウェアリリース12.3(4)T以降では、CoPPによってコントロールプレーンパケットのトラフィックフローをフィルタリングできます。Cisco IOSソフトウェアリリース12.3(4)Tで導入された、CoPPおよびACLのIPオプションフィルタリングサポートをサポートするデバイスでは、アクセスリストポリシーを使用して、IPオプションを含むパケットをフィルタリングできます。

次の CoPP ポリシーでは、デバイスで受信される通過パケットに IP オプションが付いている場合、そのパケットが廃棄されます。

!

ip access-list extended ACL-IP-OPTIONS-ANY
 permit ip any any option any-options
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS-ANY
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

次の CoPP ポリシーでは、デバイスで受信される通過パケットに次の IP オプションが付いている場合、そのパケットが廃棄されます。

• 0 オプション リストの終端（eool）
  
  
• 7 ルートの記録（record-route）
  
  
• 68 タイム スタンプ（timestamp）
  
  
• 131 ルース ソース ルート（lsr）
  
  
• 137 ストリクト ソース ルート（ssr）

!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

以前のCoPPポリシーでは、permitアクション（非表示）に一致するアクセスコントロールリストエントリ(ACE)があるパケットでは、ポリシーマップのdrop機能によってこれらのパケットが廃棄されますが、denyアクション（非表示）に一致するパケットは、ポリシーマップのdrop機能の影響を受けません。

コントロール プレーン保護

Cisco IOSソフトウェアリリース12.4(4)T以降では、コントロールプレーン保護(CPPr)を使用して、Cisco IOSデバイスのCPUによるコントロールプレーントラフィックを制限またはポリシングできます。CPPrはCoPPと同様に、CoPPよりも細かくトラフィックを制限またはポリシングできます。CPPr によって集約コントロール プレーンは、サブインターフェイスと呼ばれる 3 つの個別のコントロール プレーン カテゴリに分割されます。Host、Transit、および CEF-Exception というサブインターフェイスが存在します。

次の CPPr ポリシーでは、デバイスで受信される通過パケットの TTL 値が 6 未満の場合、またはデバイスで受信される通過パケットや非通過パケットの TTL 値が 0 か 1 の場合、そのパケットは廃棄されます。さらに、デバイスで受信されるパケットに指定の IP オプションが付いている場合、そのパケットもドロップされます。

!

ip access-list extended ACL-IP-TTL-0/1
 permit ip any any ttl eq 0 1
!

class-map ACL-IP-TTL-0/1-CLASS
 match access-group name ACL-IP-TTL-0/1
!

ip access-list extended ACL-IP-TTL-LOW
 permit ip any any ttl lt 6
!

class-map ACL-IP-TTL-LOW-CLASS
 match access-group name ACL-IP-TTL-LOW
!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map CPPR-CEF-EXCEPTION-POLICY
 class ACL-IP-TTL-0/1-CLASS
  drop
 class ACL-IP-OPTIONS-CLASS
  drop
!

!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device

!

control-plane cef-exception
 service-policy input CPPR-CEF-EXCEPTION-POLICY
!

policy-map CPPR-TRANSIT-POLICY
 class ACL-IP-TTL-LOW-CLASS
  drop
!

control-plane transit
 service-policy input CPPR-TRANSIT-POLICY
!

以前のCPPrポリシーでは、permitアクションの結果と一致するアクセスコントロールリストエントリ(ACE)では、これらのパケットはポリシーマップのdrop機能によって廃棄されていましたが、denyアクション（非表示）と一致するパケットは、ポリシーマップのdrop機能の影響を受けていませんでした。

CPPr機能についての詳細は、『コントロールプレーン保護について』および『コントロールプレーン保護』を参照してください。

トラフィックの識別とトレースバック

時には、ネットワーク トラフィックを迅速に識別してトレースバックする必要があることもあります。とりわけ、問題への対応時やネットワーク パフォーマンスが悪いときです。NetFlowおよび分類ACLは、Cisco IOSソフトウェアでこれを実現する2つの主要な方法です。NetFlow を使用すると、ネットワーク上のすべてのトラフィックを把握できます。さらに、NetFlow には長期的なトレンディングと自動分析を実行するコレクタを実装できます。分類 ACL は、ACL のコンポーネントであり、トラフィックを識別するための事前計画と分析中の手動介入が必要です。次のセクションでは、各機能の概要を説明します。

NetFlow

NetFlowは、ネットワークフローを追跡することで、異常なセキュリティ関連のネットワークアクティビティを特定します。NetFlowデータは、CLIで表示および分析したり、市販またはフリーウェアのNetFlowコレクタにエクスポートして集約および分析したりできます。NetFlowコレクタは、長期的なトレンドを通じて、ネットワークの動作と使用分析を提供できます。NetFlowはIPパケット内の特定の属性を分析し、フローを作成します。NetFlowの最も一般的に使用されているバージョンは5ですが、バージョン9の方が拡張性に優れています。NetFlow のフローは、高ボリュームの環境でサンプリングされたトラフィック データを使用して作成できます。

NetFlowをイネーブルにするには、前提条件としてCEF（分散型CEF）が必要です。NetFlow はルータやスイッチ上で設定できます。

この例では、NetFlowの基本設定について説明します。Cisco IOS ソフトウェアのこれまでのリリースでは、インターフェイスに対して NetFlow をイネーブルにするコマンドは、ip flow {ingress | egress} ではなく ip route-cache flow です。

!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!

interface <interface> 
 ip flow <ingess|egress> 
!

CLI からの NetFlow の出力例を次に示します。SrcIf アトリビュートはトレースバックに使用できます。

router#show ip cache flow
IP packet size distribution (26662860 total packets):
   1-32   64   96  128	160  192  224  256  288  320  352  384	416  448  480
   .741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  55 active, 65481 inactive, 1014683 added
  41000680 ager polls, 0 flow alloc failures
  Active flows timeout in 2 minutes
  Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
  110 active, 16274 inactive, 2029366 added, 1014683 added to flow
  0 alloc failures, 0 force free
  1 chunk, 15 chunks added
  last clearing of statistics never
Protocol	 Total	  Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------	 Flows	   /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet	 11512	    0.0        15    42      0.2      33.8      44.8
TCP-FTP 	  5606	    0.0 	3    45      0.0      59.5      47.1
TCP-FTPD	  1075	    0.0        13    52      0.0       1.2      61.1
TCP-WWW 	 77155	    0.0        11   530      1.0      13.9      31.5
TCP-SMTP	  8913	    0.0 	2    43      0.0      74.2      44.4
TCP-X		   351	    0.0 	2    40      0.0       0.0      60.8
TCP-BGP 	   114	    0.0 	1    40      0.0       0.0      62.4
TCP-NNTP	   120	    0.0 	1    42      0.0       0.7      61.4
TCP-other	556070	    0.6 	8   318      6.0       8.2      38.3
UDP-DNS 	130909	    0.1 	2    55      0.3      24.0      53.1
UDP-NTP 	116213	    0.1 	1    75      0.1       5.0      58.6
UDP-TFTP	   169	    0.0 	3    51      0.0      15.3      64.2
UDP-Frag	     1	    0.0 	1  1405      0.0       0.0      86.8
UDP-other	 86247	    0.1       226    29     24.0      31.4      54.3
ICMP		 19989	    0.0        37    33      0.9      26.0      53.9
IP-other	   193	    0.0 	1    22      0.0       3.0      78.2
Total:	       1014637	    1.2        26    99     32.8      13.8      43.9

SrcIf	      SrcIPaddress    DstIf	    DstIPaddress    Pr SrcP DstP Pkts
Gi0/1	      192.168.128.21  Local	    192.168.128.20  11 CB2B 07AF   3
Gi0/1	      192.168.150.60  Gi0/0	    10.89.17.146    06 0016 101F  55
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 101F 0016   9
Gi0/1	      192.168.150.60  Local	    192.168.206.20  01 0000 0303  11
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 07F1 0016   1

NetFlow の機能の詳細は、『Cisco IOS NetFlow』を参照してください。

NetFlow の技術概要については、『Cisco IOS NetFlow の概要 - 技術的概要』を参照してください。

分類 ACL

分類 ACL を使用すると、インターフェイスを通過するトラフィックを把握できます。分類 ACL によって、ネットワークのセキュリティ ポリシーが変更されることはありません。通常、分類 ACL は、個別のプロトコル、発信元アドレス、または宛先を分類するように作成されます。たとえば、すべてのトラフィックを許可する ACE は、プロトコル単位、またはポート単位に分類できます。トラフィックを特定のACEに細かく分類することで、各トラフィックカテゴリに独自のヒットカウンタが設定されるため、ネットワークトラフィックを可視化できます。また、ACLの最後にある暗黙的なdenyを詳細なACEに分割することで、拒否されたトラフィックタイプを特定することもできます。

管理者は、show access-list EXECコマンドおよびclear ip access-list counters EXECコマンドで分類ACLを使用することにより、インシデント対応を迅速化できます。

次の例は、デフォルトのdenyの前にSMBトラフィックを識別する分類ACLの設定を示しています。

!

ip access-list extended ACL-SMB-CLASSIFY
 remark Existing contents of ACL
 remark Classification of SMB specific TCP traffic 
 deny	tcp any any eq 139
 deny	tcp any any eq 445
 deny	ip any any 
!

分類ACLを使用するトラフィックを識別するには、show access-list EXECコマンドを使用します。ACLカウンタをクリアするには、clear ip access-list counters EXECコマンドを使用します。

router#show access-list ACL-SMB-CLASSIFY 
Extended IP access list ACL-SMB-CLASSIFY
    10 deny tcp any any eq 139 (10 matches)
    20 deny tcp any any eq 445 (9 matches)
    30 deny ip any any (184 matches) 

ACLのログ機能をイネーブルにする方法についての詳細は、『アクセスコントロールリストのロギングについて』を参照してください。

VLAN マップとポート アクセス コントロール リストによるアクセス コントロール

VLAN アクセス コントロール リスト（VACL）、つまり VLAN マップとポート ACL（PACL）を使用すると、ルーティングされたインターフェイスに適用されるアクセス コントロール リストよりもエンドポイント デバイスに近い場所にある、ルーティングされていないトラフィックに対してアクセス コントロールを適用できます。

以降のセクションでは、VACLとPACLの機能、利点、および潜在的な使用シナリオの概要を説明します。

VLAN マップによるアクセス コントロール

VLANに入ってくるすべてのパケットに適用されるVACLまたはVLANマップにより、VLAN内トラフィックにアクセスコントロールを適用する機能が提供されます。これは、ルーティングされたインターフェイスに対して ACL を使用するのでは不可能なことです。たとえば、VLANマップを使用して、同じVLANに含まれるホストが相互に通信することを防止できます。これにより、ローカル攻撃者やワームによる同じネットワークセグメント上のホストの悪用を低減できます。パケットによるVLANマップの使用を拒否するには、トラフィックに一致するアクセスコントロールリスト(ACL)を作成し、VLANマップでアクションをdropに設定します。VLAN マップを設定すると、LAN に流入するすべてのパケットは順に、設定された VLAN マップに照らして評価されます。VLANアクセスマップはIPv4およびMACアクセスリストをサポートしますが、ログまたはIPv6 ACLはサポートしません。

次の例では、名前付き拡張アクセス リストを使用し、この機能の設定を示しています。

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address>
     <destination-port>
!

vlan access-map <name> <number>
 match ip address <acl-name>
 action <drop|forward>
!

次の例は、VLANマップを使用してTCPポート139と445、およびvines-ipプロトコルを拒否する方法を示しています。

!

ip access-list extended VACL-MATCH-ANY
 permit ip any any
!

ip access-list extended VACL-MATCH-PORTS
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139
!

mac access-list extended VACL-MATCH-VINES
 permit any any vines-ip
!

vlan access-map VACL 10
 match ip address VACL-MATCH-VINES 
 action drop
!

vlan access-map VACL 20 
 match ip address VACL-MATCH-PORTS
 action drop
!

vlan access-map VACL 30
 match ip address VACL-MATCH-ANY
 action forward
!

vlan filter VACL vlan 100 
!

VLAN マップの設定についての詳細は、『ACL によるネットワーク セキュリティの設定』を参照してください。

PACL によるアクセス コントロール

PACL を適用できるのは、スイッチのレイヤ 2 物理インターフェイスの着信側のみです。PACL では VLAN マップと同様に、ルーティングされていないトラフィックやレイヤ 2 トラフィックに対してアクセス コントロールが適用されます。PACL を作成するための構文はルータ ACL と同じであり、PACL は VLAN マップおよびルータ ACL より優先されます。レイヤ 2 インターフェイスに適用される ACL は、PACL と呼ばれます。設定では、IPv4、IPv6、または MAC の ACL の作成と、レイヤ 2 インターフェイスへの適用を行います。

次の例では、名前付き拡張アクセスリストを使用して、この機能の設定を説明しています。

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address> 
     <destination-port>
!

interface <type> <slot/port>
 switchport mode access
 switchport access vlan <vlan_number>
 ip access-group <acl-name> in 
!

PACL の設定についての詳細は、『ACL によるネットワーク セキュリティの設定』のポート ACL に関するセクションを参照してください。

MAC によるアクセス コントロール

MACアクセスコントロールリスト(ACL)または拡張リストは、インターフェイスコンフィギュレーションモードで次のコマンドを使用することにより、IPネットワークに適用できます。

Cat6K-IOS(config-if)#mac packet-classify

注:MACアクセスコントロールリスト(ACL)は、レイヤ3パケットをレイヤ2パケットとして分類することです。コマンドは、Cisco IOSソフトウェアRelease 12.2(18) SXD （SUP 720）とCisco IOSソフトウェアRelease 12.2(33) SRA以降でサポートされます。

このインターフェイスコマンドは入力インターフェイスに適用する必要があり、フォワーディングエンジンにIPヘッダーを検査しないように指示します。その結果、IP環境でMACアクセスリストを使用できます。

プライベート VLAN ドメイン

プライベートVLAN(PVLAN)は、VLAN上のワークステーションまたはサーバ間の接続を制限するレイヤ2セキュリティ機能です。PVLAN を使用しない場合、レイヤ 2 VLAN 上のすべてのデバイスは自由に通信可能です。1つのVLAN上のデバイス間の通信の制限によってセキュリティが強化されるネットワーク環境があります。たとえば、一般にアクセス可能なサブネット上にあるサーバ間の通信を禁止するために、PVLANがよく使用されます。1台のサーバが侵害された場合、PVLANの適用による他のサーバへの接続の欠如が、侵害を1台のサーバに限定するのに役立ちます。

プライベート VLAN には、隔離 VLAN、コミュニティ VLAN、およびプライマリ VLAN という 3 つの種類があります。PVLAN の設定では、プライマリ VLAN とセカンダリ VLAN を使用します。プライマリ VLAN には、すべての混合モード ポート（後述）と、1 つ以上のセカンダリ VLAN（隔離 VLAN またはコミュニティ VLAN）が含まれます。

隔離 VLAN

セカンダリVLANを隔離VLANとして設定すると、セカンダリVLAN上のデバイス間の通信が完全に防止されます。プライマリVLANごとに隔離VLANを1つだけ設定でき、隔離VLAN上のポートと通信できるのは混合ポートだけです。隔離VLANは、ゲストをサポートするネットワークなどの非信頼ネットワークで使用できます。

次の設定例では、VLAN 11 を隔離 VLAN として設定し、プライマリ VLAN である VLAN 20 に関連付けています。また、この例では、インターフェイスFastEthernet 1/1をVLAN 11の隔離ポートとして設定しています。

!

vlan 11
 private-vlan isolated
!

vlan 20
 private-vlan primary
 private-vlan association 11
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

コミュニティ VLAN

コミュニティVLANとして設定されたセカンダリVLANでは、VLANのメンバー間の通信や、プライマリVLAN上の任意の混合ポートとの通信が可能です。ただし、2 つのコミュニティ VLAN 間の通信や、コミュニティ VLAN から隔離 VLAN への通信は許可されません。相互に接続する必要があるが、VLAN上の他のすべてのデバイスへの接続が不要なサーバをグループ化するには、コミュニティVLANを使用する必要がある。このシナリオは、一般にアクセス可能なネットワークや、サーバが信頼できないクライアントにコンテンツを提供する場所でよく見られます。

次の例では、1 つのコミュニティ VLAN を設定し、スイッチ ポート FastEthernet 1/2 をその VLAN のメンバとして設定しています。コミュニティVLAN(VLAN 12)は、プライマリVLAN 20に対するセカンダリVLANです。

!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 12
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

混合モード ポート

プライマリVLANに配置されるスイッチポートは、混合ポートと呼ばれます。混合ポートは、プライマリおよびセカンダリVLAN上の他のすべてのポートと通信できます。ルータまたはファイアウォールインターフェイスは、これらのVLANで見られる最も一般的なデバイスです。

次の設定例では、これまでの隔離 VLAN とコミュニティ VLAN の例を組み合わせて、インターフェイス FastEthernet 1/12 を混合モード ポートとして追加しています。

!

vlan 11
 private-vlan isolated
!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 11-12
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

interface FastEthernet 1/12
 description *** Promiscuous Port ***
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 20 add 11-12
!

PVLANを実装する場合は、配置されているレイヤ3設定がPVLANによる制限をサポートし、PVLAN設定が妨害されないことを確認することが重要です。ルータACLまたはファイアウォールを使用したレイヤ3フィルタは、PVLAN設定の妨害を防ぐことができます。

プライベート VLAN の使用法と設定についての詳細は、『LAN セキュリティ』ホームページの『プライベート VLAN（PVLAN）：混合モード、隔離、コミュニティ』を参照してください。

結論

このドキュメントでは、Cisco IOSシステムデバイスのセキュリティ保護に使用できる方法の概要について説明します。デバイスを保護すると、管理対象のネットワークの全体的なセキュリティが向上します。この概要では、管理プレーン、コントロール プレーン、およびデータ プレーンの保護について説明し、設定に関する推奨事項を示しています。関連のある各機能の設定については、可能な限り、十分詳しく説明しています。ただし、より詳しい評価に必要な情報を提供するためには、すべての場合で包括的な参照先を示しています。

確認

このドキュメントの機能の説明の一部は、シスコの情報開発チームによって作成されたものです。

付録：チェックリストを強化するCisco IOSデバイス

このチェックリストは、このガイドで説明したデバイスを強化するためのすべての手順をまとめたものです。管理者が適用されていないため、関数を実行されなくてがすべてに強化リマインダがCisco IOSデバイスに使用されていないと機能になったときにも使用できます。管理者は、オプションには潜在的リスクの各オプションを評価することを推奨します。

管理プレーン

• パスワード
  
  
  • 有効およびローカル ユーザ パスワードのMD5ハッシュ（秘密のオプション）をイネーブルにします
  • パスワード再試行のロックアウトを設定します
  • パスワード回復をディセーブルにします（リスクを考慮します）
    
    
• 使用していないサービスを無効にする
  
  
• 管理セッションのTCPキープアライブを設定します
  
  
• メモリおよびCPUしきい値通知を設定します
  
  
• 設定
  
  
  • メモリおよび CPU しきい値通知
  • コンソール アクセス用のメモリ予約
  • メモリ リーク検出
  • バッファ オーバーフロー検出
  • 強化されたcrashinfo収集
    
    
• 管理アクセスを制限するのにiACLsを使用します
  
  
• フィルタリング（リスクを考慮します）
  
  
  • ICMP パケット
  • IP フラグメント
  • IP オプション
  • パケットの TTL 値
    
    
• コントロール プレーン保護
  
  
  • ポートフィルタリングの設定
  • キューのしきい値を設定する
    
    
• 管理アクセス
  
  
  • 管理インターフェイスを制限しても、管理プレーン保護を使用します
  • exec タイムアウトを設定する
  • CLIアクセスに暗号化トランスポートプロトコル（SSHなど）を使用する
  • vtyの転送を制御するTTYは回線（アクセス クラス オプション）
  • バナーを使用した警告
    
    
• [AAA]
  
  
  • 認証とフォールバックにAAAを使用する
  • コマンド許可のためのAAA （TACACS+）を使用します
  • アカウントにAAAを使用する
  • 冗長AAAサーバを使用する
    
    
• SNMP
  
  
  • SNMPコミュニティを設定し、ACLを適用します
  • SNMPv3 を設定する
    
    
• Logging
  
  
  • 一元化されたログの設定
  • 関連するすべてのコンポーネントのログレベルの設定
  • ログソースインターフェイスの設定
  • ログタイムスタンプの粒度の設定
    
    
• 構成管理
  
  
  • 置換とロールバック
  • コンフィギュレーション変更の排他的アクセス
  • ソフトウェア復元の設定
  • 設定変更の通知

コントロール プレーン

• 無効にリスクを考慮します）
  
  
  • ICMP リダイレクト
  • ICMP 到達不能
  • プロキシ ARP
    
    
• NTPを使用する場合はNTP認証を設定する
  
  
• コントロールプレーンポリシング/保護の設定（ポートフィルタ、キューしきい値）
  
  
• ルーティング プロトコルを保護する
  
  
  • BGP（TTL、MD5、最大プレフィックス、プレフィックス リスト、システム パス ACL）
  • IGP（MD5、受動インターフェイス、ルートフィルタ、リソース消費）
    
    
• ハードウェア レート リミッタを設定します
  
  
• セキュア ファーストホップ冗長プロトコル（GLBP、HSRP、VRRP）

データ プレーン

• IP オプションの選択的ドロップを設定する
  
  
• 無効にリスクを考慮します）
  
  
  • IPソースルート
  • IP 誘導ブロードキャスト
  • ICMP リダイレクト
    
    
• IP ダイレクト ブロードキャストを制限する
  
  
• tACLsを設定します（リスクを考慮します）
  
  
  • ICMPをフィルタリングします
  • IP フラグメントのフィルタリング
  • IP オプションをフィルタリングする
  • TTL値をフィルタリングします
    
    
• configureアンチスプーフィング保護を必要とする
  
  
  • ACL
  • IP ソース ガード
  • ダイナミック ARP インスペクション
  • ユニキャスト RPF
  • ポート セキュリティ
    
    
• コントロール プレーン保護（コントロール プレーンcef例外）
  
  
• トラフィックを識別するためのNetFlowおよび分類ACLを設定します
  
  
• configure必要なアクセス コントロールACL （VLANマップ、PACL、MAC）
  
  
• プライベートVLANの設定

更新履歴

改定	発行日	コメント
2.0	12-Sep-2024	概要、機械翻訳、スタイル要件、多数の更新されたリンクなど、CCWアラートの全面的な見直し。
1.0	10-Dec-2001	初版