パケットフィルタとは

パケットフィルタとは、ルータを通過するパケットを特定の条件に基づいて許可したり、破棄したりする機能です。通常のルータは、受信したIPパケットの宛先IPアドレスとルーティングテーブルを見て、転送先を判断します。ルーティングテーブルに一致するルート情報があれば、そのパケットをネクストホップへと転送します。万が一、不正な通信であったとしても、パケットはルーティングされてしまいます。

そこで、パケットフィルタにより、不正な通信のフローのパケットを破棄して、セキュリティを確保します。パケットフィルタはアクセスコントロールリストの最も多い用途です。

パケットフィルタの動作

パケットフィルタは、アクセスコントロールリストでフローを識別します。そして、識別したフローのパケットを通過(permit)させるか、破棄(deny)するかを決めます。パケットフィルタのときは、アクセスコントロールリストのpermitとdenyは言葉通りに解釈してください。permitは「通過させる」で、denyは「破棄する」です。

パケットフィルタを行うときは、アクセスコントロールリストをインタフェースに適用します。インタフェースに適用するときにインバウンド/アウトバウンドの2つの方向があります。アクセスコントロールリストをインタフェースに適用するときには、インバウンド方向、アウトバウンド方向に対してそれぞれ1つです。効果的なパケットフィルタを行うためには、インバウンド/アウトバウンドの違いをしっかりと把握しておくことが重要です。

インバウンドとアウトバウンド

ルータがフローのパケットをルーティングするときには、次の3つの動作を行っています。

  1. ルーティング対象のパケットを受信
  2. ルーティングテーブルから宛先IPアドレスに一致するルート情報を検索してネクストホップと出力インタフェースを決定(ルーティング処理)
  3. 出力インタフェースからパケットを送信

1.と2.の間でアクセスコントロールリストをチェックするのがインバウンド方向です。2.と3.の間でアクセスコントロールリストをチェックするのがアウトバウンド方向です。

インバウンドでアクセスコントロールリストを適用すると、ルーティング対象のパケットを受信してルーティングテーブルの検索を行う前にリストの条件をチェックします。permitされたフローのパケットのみがルーティング処理されて、出力インタフェースから送信されるようになります。

アウトバウンドでアクセスコントロールリストを適用すると、他のインタフェースで受信しルーティング処理されたパケットを出力するときに、リストの条件をチェックします。permitされたフローのパケットのみが出力インタフェースから送信されます。

図 インバウンドとアウトバウンド
図 インバウンドとアウトバウンド

なお、パケットフィルタはルータを通過するフローのパケットのみが対象です。ルータ自身が送信するパケットは対象外です。たとえば、ルータのコンソールからPingを実行した場合、アウトバウンド方向で適用したアクセスコントロールリストの対象外です。

図 ルータ自身のパケットは対象外
図 ルータ自身のパケットは対象外

ルータ自身が生成したパケットをフィルタするにはPBR(Policy Based Routing)の設定で実現できます。

インタフェースへの適用のポイント

パケットフィルタのためアクセスコントロールリストをインタフェースに適用するときのポイントは、これまでに何度も触れているとおり「通信は原則双方向である」ということをしっかりと意識することです。

通信させるには行きと戻りのフロー両方をpermit

通信は双方向で何らかのリクエスト(行きのフロー)に対してリプライ(戻りのフロー)が返ってきます。アプリケーションの通信を成立させるためには、当然ながら、行きと戻りの両方のフローがpermitされるようにしなければいけません。

図 通信させる場合
図 通信させる場合

戻りのフローをpermitすることを忘れてしまって、「パケットフィルタの設定をすると、まったく通信できなくなった」というのはとてもありがちな設定ミスです。

通信できなくするには行きまたは戻りのフローをdeny

また、不要なアプリケーションの通信ができなくするためには、行きのフローか戻りのフローのどちらかをdenyすればよいです。たいていの場合、行きのフローをdenyします。通信を止めるならば、行きのフローをpermitしても意味がなく、ルータやネットワークリソースを無駄に消費してしまうからです。denyするときもアウトバウンド方向よりもインバウンド方向の方がルータのリソース消費を抑えることができます。

図 通信をとめる場合
図 通信をとめる場合

クライアントとサーバの位置関係は固定されているわけではない

さらに、クライアントとサーバの位置関係は相対的で固定されているわけではないことにも注意が必要です。最もよく利用するアプリケーションの通信であるWebアクセスでも、次の2つのアクセスは違うものです。

  • 社内からインターネット上のWebサイトへのアクセス
  • インターネットから公開しているWebサイトへのアクセス
図  Webアクセスの例
図 Webアクセスの例
この図の社内のネットワーク構成はものすごく簡略化しています。インターネットへ公開する公開サーバとクライアントPCは同一ネットワークにすることはまずありません。

アクセスコントロールリストを適用するインタフェースを集約する

パケットフィルタを行うためには、必要な通信について行きのフローと戻りのフローの方向もきちんと考慮することが重要です。設定はどのようにでもできますが、たくさんのアクセスコントロールリストを作成していろんなインタフェースのインバウンド/アウトバウンドで適用すると煩雑になってしまいます。

いろんなインタフェースにアクセスコントロールリストを適用する代わりに、「制御したい通信が必ず通るインタフェース」を見極めます。そして、制御したい通信が必ず通るインタフェースのインバウンドとアウトバウンド方向それぞれに必要なフローをpermitしているアクセスコントロールリストを適用すると設定をシンプルにできます。

たとえば、社内ネットワークとインターネットの境界でインターネットとの通信を制御したいのであれば、インターネットに接続している側のインタフェースが制御したい通信が必ず通るインタフェースです。インターネット側のインタフェースのアウトバウンドとインバウンドにそれぞれアクセスコントロールリストを適用します。

簡単な例を考えます。シンプルにするために、以降はWebアクセスだけに限定します。アウトバウンドに適用するアクセスコントロールリストでは、次のフローをpermitします。

  • 社内からインターネットWebサーバへのアクセスのリクエストのフロー(1)
  • インターネットから社内Webサーバへのアクセスのリプライのフロー(2)

インバウンドに適用するアクセスコントロールリストでは、次のフローをpermitします。

  • 社内からインターネットWebサーバへのアクセスのリプライのフロー(3)
  • インターネットから社内Webサーバへのアクセスのリクエストのフロー(4)
図 WebアクセスについてのACLの例
図 WebアクセスについてのACLの例

もちろん、Webアクセス以外にもいろんなアプリケーションのフローがあります。それらのフローも同様に考えて、必要なフローだけをpermitできるようにします。

アプリケーションの通信の前提

アクセスコントロールリストでのパケットフィルタを行うときには、アプリケーションの通信を行うための大前提も考慮してください。

  • 宛先IPアドレスがわかっている : DNSで名前解決を行う
  • 宛先IPアドレスまでルーティング可能である : ルーティングプロトコルでルーティグテーブルを作成する

このアプリケーションの通信の大前提を満足するためにアクセスコントロールリストの条件には次の2点を考慮してください。

  • DNSの名前解決ができるようにpermitする
  • ルーティングプロトコルをpermitする

TCP/IPの通信を行うためには、IPアドレスを指定してIPパケットを送信します。宛先IPアドレスが分かっていなければ通信自体が成立しません。そして、宛先IPアドレスを求めるために、通常、DNSを利用します。つまり、DNSによる名前解決ができるようにしておかなければ、そもそもの宛先IPアドレスがわからなくなってしまいます。アクセスコントロールリストの条件では、必ずDNSをpermitするようにしてください。

そして、宛先IPアドレスまでルーティング可能でなければいけません。そのために、ルーティングテーブルに宛先IPアドレスに対するルート情報が必要です。ルーティングプロトコルによってルーティングテーブルを作成している場合は、アクセスコントロールリストの条件に必ず利用しているルーティングプロトコルをpermitするようにしてください。

Cisco CCNA試験の問題ではDNSとかルーティングプロトコルをpermitするということをきちんと考えていません。実際にパケットフィルタの設定を行うときにはきちんと考えてください。

Ciscoルータでアクセスコントロールリスト(ACL)を利用したパケットフィルタの設定は、以下の記事をご覧ください。

関連記事