導入
| ネットフィルター | |
 | |
| 開発者 | ネットフィルターチーム |
|---|---|
| 環境 | GNU/Linux |
| 親切 | ファイアウォール |
| ライセンス | GNU GPL |
| Webサイト | http://netfilter.org/ |
Netfilterは、 Linux カーネルのバージョン 2.4 以降でファイアウォールを実装するフレームワークです。これは、ネットワーク インターフェイスからパケットを受信または送信するためのルーチンの呼び出し中にネットワークパケットを傍受および操作するためのフックをカーネルに提供します。
バージョン 1.4.2 は、National Information Systems Security Agency (ANSSI) から First Level Security Certificate (CSPN) を取得しました [1]。
歴史
netfilter/iptablesプロジェクトは、以前のプログラム ipchains の作者でもあったRusty Russellによって 1998 年に開始されました。プロジェクトは成長しましたが、彼は 1999 年にNetfilter コア チーム(または単にコアチーム、コア開発チーム) を設立しました。彼らが作成したソフトウェア(以降、ネットフィルターと呼ばれます) は GNU 一般公衆利用許諾書 (GPL) に基づいてライセンスされており、 2000 年 3 月にLinux 2.3 をリリースしました。2003 年 8 月に、Harald Welte がコアチームの社長に就任し、2004 年 4 月には、Netfilter プロジェクトによるライセンス条項に準拠せずにソフトウェアを配布した商用製品に関する集中的な調査を行った後、Harald Welte が管理したGPL ライセンスの条項に従うことを拒否した Sitecom Germany に対して歴史的な差し止め命令を取得するためです。 2007 年 9 月、近年開発を主導してきた Patrick McHardy がコアチームの新しい社長に選出されました。
iptables が登場する前は、Linux 上でファイアウォールを作成するための主なソフトウェアは、もともと BSD で設計されたプログラムである ipfw をベースにした ipchains (Linux kernel 2.2) とipfwadm (Linux kernel 2.0) でした。 Netfilter までは一般的なパケット制御フレームワークがなかったため、ipchains と ipfwadm はネットワーク コードを直接変更してパケットを操作できるようにしました。
ipchains と ipfwadm はパケット フィルタリングと NAT (具体的にはマスキング、ポート フォワーディング、フォワーディングと呼ばれる 3 種類の NAT) を組み合わせたものですが、Netfilter はパケット操作を以下に説明するようにいくつかの部分に分割します。それぞれが Netfilter フック内の異なるアクセス ポイントに接続して、パケットを検査します。接続追跡および NAT サブシステムは、ipchains および ipfwadm の下位バージョンよりも汎用的で強力です。
接続追跡
Netfilter フレームワークに基づいて構築された重要な機能の 1 つは、接続追跡です。 CT を使用すると、カーネルはすべての論理ネットワーク接続またはセッションを追跡できるため、その接続を構成するすべてのパケットを伝送できます。 NAT はこの情報に基づいてすべてのパケットを同じ方法で変換し、iptables はこの情報を使用して「ステートフル」ファイアウォールとして機能できます。
ただし、接続状態は、TCP や SCTP 状態などの高レベルの状態から完全に独立しています。その理由の 1 つは、パケットが (ローカル配信ではなく) 通過しているだけの場合、TCPエンジンを呼び出す必要がないことが挙げられます。 UDP、 IPsec (AH/ESP)、GRE、その他のトンネリング プロトコルなどのコネクションレス モードでも、少なくとも何らかの疑似接続状態があります。これらのプロトコルのヒューリスティックは、多くの場合、事前に設定されたアイドルタイムアウト値に基づいており、この値が経過すると Netfilter 接続がドロップされます。
各 Netfilter 接続は、タプル (レイヤー 3 プロトコル、送信元アドレス、宛先アドレス、レイヤー 4 プロトコル、レイヤー 4 キー) によって一意に識別されます。レイヤ 4 キーはトランスポート プロトコルによって異なります。TCP/UDP プロトコルの場合はポート番号です。トンネルの場合、これはトンネルID です。それ以外の場合、キーはタプルの一部ではないかのように値0 をとります。 TCP ポートを検査できるようにするには、パケットを最適化する必要があります。
Netfilter 接続は、 conntrackツールを使用して操作できます。
iptables は、ステータス、ステータスなどの接続情報を検査できます。パケット フィルタリング ルールをより強力にし、管理しやすくします。ほとんどの場合、状態は次のとおりです。
- 「NEW」: パケットは新しい接続を作成しようとしています
- 「ESTABLISHED」: パケットは既存の接続の一部です
- 「関連」: この状態は、新しい接続を開始し、「待機」しているパケットに割り当てられます。前述のミニ ALG は、たとえば、 nf_conntrack_ftpモジュールが「PASV」FTPコマンドを認識したときに、これらの期待を適切に実行します。
- 「INVALID」：パケットは無効であると判断されました。最も一般的な原因は、TCP プロトコルの状態図が尊重されないことです。
- 「UNTRACKED」: 接続追跡をバイパスするために管理者が割り当てることができる特別な状態 (上記の生の表を参照)
したがって、実際には、conntrack サブシステムが認識する最初のパケットは「新規」として分類されます。応答パケットは「確立」として分類されます。逆に、ICMP エラーは「関連」しており、既知の接続に一致しない ICMP エラー パケットは「無効」として分類されます。
接続追跡が役立ちます
プラグインモジュールを使用すると、CT はアプリケーション層プロトコルを認識できるため、2 つ以上の個別の接続が「関連している」ことを理解できます。たとえば、FTP プロトコルを考えてみましょう。制御接続は確立されますが、データが転送されるたびに、データを転送するために別の接続が確立されます。 nf_conntrack_ftpモジュールがロードされると、FTP データ接続の最初のパケットは論理的に既存の接続の一部であるため、「新規」ではなく「リンク済み」として分類されます。
ヘルパーは一度に 1 つのパッケージのみを検査します。 IP フラグメンテーションまたは TCPセグメンテーションにより、CT にとって重要な情報が 2 つのパケットに分割されている場合、ヘルプは必ずしもパターンを認識しないため、適切に機能しません。 TCP セグメンテーションは処理されませんが、 IPv4フラグメンテーションは最適化を必要とする CT サブシステムで処理されます。 FTP の場合、パケットはセクター サイズ (MSS) を持つ PASV コマンドの「近く」でセグメント化されていないとみなされ、そのため Netfilter によって処理されません。