UFWにブロックリスト全体を追加することには欠点がありますか?

UFWにブロックリスト全体を追加することには欠点がありますか?

私は、いくつかのマシンのトラフィックをリダイレクトする nginx ベースのプロキシ サーバーを作成しました。これにより、管理可能な単一のセキュリティ フィルターを使用できるようになります。特別なことは何もしていませんが、いくつかの広告追跡エージェンシーをブロックし、限られたデータ プランを少し節約するのに十分なだけです。

とにかく、nginx はパフォーマンスの面で完璧で、実際に Web 使用中にいくつかのデバイスを高速化しました。ただし、nginx のフィルタリング ソリューションは簡単には見つからないため、Ubuntu で他にフィルターが存在できる場所を探す必要がありました。

悪意のある IP と追跡防止リストのオープンソース リストをいくつか hosts ファイルに追加したところ、nginx が hosts ファイルを回避して動作することがあり、それがうまくいかなかったため、ファイアウォール ベースのソリューションを検討し始めました。

ufw はドメインをブロックするように設計されていないことは知っていますが、nginx による不要なリンクの要求を完全にブロックすることに成功した唯一のものだったので、リストされているすべてのドメインの IP と、記録された悪意のある IP アドレスを含むシェル スクリプトを作成し、現在マシンで処理しています。

# Example of the script
ufw deny out to 1.2.3.4;
ufw deny out to 1.2.3.5;
ufw deny out to 1.2.3.6;

皆さんに質問したいのは、あまり忙しくない DigitalOcean Droplet でスクリプトが処理するのに非常に長い時間がかかるので、IPtables ルールが多数あるためパフォーマンスが低下することに気付くでしょうか。それとも、UFW は IPtables の実行方法に影響を与えない単なるセットアップ レイヤーであり、UI に重点を置いたアプリであることを考えると、少しかさばる可能性があるのでしょうか。IP テーブルが成熟していることを考えると、それほどオーバーヘッドは発生しないと思いますし、一度待たされるのは気になりませんが、スクリプトがすべてのルールをルールに読み込むのに時間がかかるという点だけが少し心配です。

これを設定ファイルの 1 つにパイプするだけでもよかったと思いますが、使いやすいコマンド インターフェースを介して実行する方が安定した安全なソリューションであると感じました。皆さんはどう思いますか?

関連情報