約100万のIPアドレスをブラックリストに登録するには、IPtablesまたはヌルルートを使用しますか？

クライアントが100万個未満の個々のIPアドレス（サブネットなし）のセットをブラックリストに登録する必要があり、ネットワークパフォーマンスが懸念される状況に遭遇しました。IPTablesルールは、ルートよりもパフォーマンスへの影響が少ないと推測しますが、それは単なる推測です。

IPアドレスの長いリストをブラックリストに登録するためのソリューションとして、IPTablesまたはnullルーティングのいずれかを支持する確固たる証拠やその他の正当性はありますか？この場合、すべてが自動化されているため、使いやすさは実際には問題になりません。

11月26日編集

いくつかのテストと開発の後、これらのオプションはどれも機能しないようです。ルート検索とiptablesの両方がルールセットを介して線形検索を実行し、この多くのルールを処理するのに時間がかかりすぎるようです。最新のハードウェアでは、iptablesブラックリストに100万個のアイテムを入れると、サーバーの速度が1秒あたり約2ダースまで低下します。そのため、IPTablesとnullルートが出ています。

ipset、Jimmy Hedmanが推奨しているように、セットで65536個を超えるアドレスを追跡できないことを除いて、素晴らしいと思います。

このように多くのIPをブロックする唯一の解決策は、アプリケーション層でインデックス付きルックアップを実行することです。そうではありませんか？

詳しくは：

この場合の使用例は、IPアドレスの「既知の攻撃者」リストがWebサーバー上の静的コンテンツにアクセスするのをブロックすることです。FWIWでは、Apacheを介したブロックの実行Deny fromは、線形スキャンも実行するため、同様に遅くなります（そうでない場合）。

参考までに：最終的な作業ソリューションは、Apacheのmod_rewriteをberkeley DBマップと組み合わせて使用​​して、ブラックリストに対してルックアップを行うことでした。バークレーDBのインデックス付きの性質により、リストはO（log N）のパフォーマンスに合わせてスケーリングできます。

ルックアップの数を減らすために、iptablesを使用してマルチレベルツリーを構築してみてください。

iptables -N rules_0_0_0_0_2
iptables -N rules_64_0_0_0_2
iptables -N rules_128_0_0_0_2
iptables -N rules_192_0_0_0_2
iptables -N rules_0_0_0_0_4
iptables -N rules_16_0_0_0_4

iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/2 -j rules_0_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 64.0.0.0/2 -j rules_64_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 128.0.0.0/4 -j rules_128_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 192.0.0.0/4 -j rules_192_0_0_0_2

iptables -A rules_0_0_0_0_2 -s 0.0.0.0/4 -j rules_0_0_0_0_4
iptables -A rules_0_0_0_0_2 -s 16.0.0.0/4 -j rules_16_0_0_0_4

など-ネストレベルを追加します。明らかに、ルールを自動的に構築する方法が必要であり、1人以上の犯罪者がいるネットワークだけにチェーンを持たせる必要があります。この方法で、かなり大幅に実行する必要があるルックアップの数を減らすことができます。実際に動作します。

これがまさにそのipset目的です。

ウェブサイトhttp://ipset.netfilter.org/から：

あなたがしたい場合は

• 複数のIPアドレスまたはポート番号を保存し、1回でiptablesによるコレクションと照合します。
• パフォーマンスを低下させることなく、IPアドレスまたはポートに対してiptablesルールを動的に更新します。
• 単一のiptablesルールで複雑なIPアドレスとポートベースのルールセットを表現し、IPセットの速度の恩恵を受ける

ipsetが適切なツールかもしれません。

これはnetfilterコアチームメンバーのJozsef Kadlecsik（REJECTターゲットも作成した）によって作成されているため、これは私が考えることができる最良の選択です。

最近のカーネルにも含まれています。

私自身はこれをテストしていませんが、あなたの問題の説明を聞いたとき、私は即座に「pf」と考えました（OpenBSDから）。

pfあなたが探しているものだけかもしれないアドレステーブルの概念を持っています。

私が行ったいくつかの非常に大まかな研究によると、これはのスケーリングよりも優れている可能性があるようですipset。PF FAQのランタイムオプションに関する章によると、チューニングなしですぐに使用できるpfは、合計1,000テーブルをサポートし、デフォルトですべてのテーブルで合計200,000エントリをサポートします。（システムの物理メモリが<100MBの場合は100,000）。これは、少なくともこれをテストして、何らかの有用なレベルで機能するかどうかを確認することを検討する価値があると考えるようになります。

もちろん、サーバーをLinuxで実行していると想定しているので、pf（OpenBSDやFreeBSDなど）でOSを実行する別のファイアウォールボックスが必要になります。また、あらゆる種類のステートフルパケットフィルタリングを廃止することで、スループットを改善できる場合があります。

FIB_HASHの代わりにFIB_TRIEを使用して調査しましたか。

FIB_TRIEは、プレフィックスカウントに対してはるかに優れたスケーリングを行う必要があります。（/ 32s nullルートはまだプレフィックスであり、非常に具体的です）

使用するには、独自のカーネルをコンパイルする必要があるかもしれませんが、役立ちます。

FIB_TRIEノート

後世：ipsetドキュメントによると、セットのデフォルトサイズは65536です。これはオプションで変更できます。

maxelemこのパラメーターは、すべてのハッシュタイプセットのcreateコマンドに有効です。セットに格納できる要素の最大数、デフォルトは65536を定義します。例：ipset create test hash:ip maxelem 2048.

私はまだコメントできないので、これをここに置きます。

将来この問題に出くわした人のためのいくつかの役立つメモ：

まず、必要のないトラフィックを分析しないでください。たとえば、TCPトラフィックをブロックしている場合は、SYNパケットのみをフィルタリングします。そのようにして、接続ごとに1回だけフィルターをヒットします。必要に-m state応じて使用できますが、接続追跡には独自のオーバーヘッドがあり、パフォーマンスが問題になる場合は回避することができます。

第二に、100万個のルールをiptablesに入れるには長い時間がかかります：数分。その数のエンティティを追跡する必要がある場合は、おそらくnetfliterから遠ざけることをお勧めします。ルールセットの大きさが違いを生みます。

第三に、目標は線形スキャンを避けることです。しかし、残念ながら、iptablesとiproute2はどちらも本質的に線形です。ルールをバイナリツリースタイルから多数のチェーンに分割して、相談するルールの数を制限できますが、それでも、iptablesはこのサイズの問題にはあまり適していません。動作しますが、貴重なリソースの無駄です。

第4に、そして最も重要なこととして、ユーザースペースにワークロードをプッシュすることは悪い考えではありません。これにより、独自のタイトなコードを記述したり、問題セットに合わせて市販のソリューションを使用したりできます。前述のように、この問題に対する私自身の解決策は、Apacheのmod_rewriteシステムを介してトリガーされるBDBルックアップを使用することでした。これには、有効なリクエストが送信された後にのみ、セッションごとに1つのルックアップのみをトリガーするという追加の利点がありました。この場合、パフォーマンスは非常に速く、ブロックリストのコストはほとんど無視できました。

-j QUEUEターゲットをとともに使用して、iptablesで同様のユーザー空間操作を行うことができますlibnetfilter_queue。このツールは強力でシンプルであり、文書化が不十分です。公式ドキュメントの一部ではない多くの興味深い資料がウェブ上に散らばっているので、できるだけ多くの情報源からできるだけ多くの情報源を読むことをお勧めします。