Linux VPS向けのおすすめ無料ファイアウォール

Linux VPSに最適な無料ファイアウォールは、単一のツールではありません。ホストファイアウォール（すべてのサーバーに必要な層）と、Webアプリを運用するならその上に重ねるWeb Application Firewallの組み合わせです。本ガイドではその両方を取り上げ、各層で最も優れた無料またはオープンソースのファイアウォールの選択肢を挙げ、それぞれがRAMとセットアップの手間の面でどれだけのコストになるかを示します。対象はLinux VPSの運用者です。Windows向けのまとめではありません。

短いバージョン

• 「おすすめ無料ファイアウォール」は、4つの異なる製品を指します。Linuxホストファイアウォール、ネットワークファイアウォールのディストリビューション、Web Application Firewall（WAF）、そしてWindows向けのコンシューマー製ツールです。VPSに該当するのは1番目と3番目だけです。
• ホスト層では、お使いのディストリビューションに合った最もシンプルなツールを使いましょう。UbuntuならUFW、RHEL系ならfirewalld、Debianでは必要な制御の度合いに応じてUFWまたはnftablesを直接使います。最近のフロントエンドツールは一般的にnftables上で動作しますが、nftables自体がDebianのデフォルトかつ推奨されるフレームワークです。
• WAFは、Webアプリのための独立した補完的な層です。ホストファイアウォールの代わりになるものではありません。
• SafeLineは最も軽量な無料WAF（1 GB RAM）です。BunkerWebは最も機能が充実していますが、8 GBを必要とします。Haltdos Communityは、Web UIを備えた3つ目の無料の選択肢です。

本ガイドで扱わないもの

他の「おすすめ無料ファイアウォール」の一覧に登場するいくつかのファイアウォールのカテゴリは、ここでは該当しません。一度整理しておけば、見当違いのツールを追いかけずに済みます。

• Windowsおよびコンシューマー向けエンドポイントファイアウォール（ZoneAlarm、Comodo、TinyWall）。オペレーティングシステムもマシンも対象外です。
• 有償の商用・エンタープライズ向けファイアウォール（Cisco ASA、Palo Alto、Fortinet）。「無料」の範囲外です。
• クラウドWAFのSaaS（Cloudflare、Sucuri）。有効な選択肢ですが、DNS/プロキシベースであり、本記事のセルフホスト型VPSの範囲外です。Cloudflareは無料の基本的なWAFルールセットを提供していますが、より充実したマネージドルールやOWASPルールセットの対応範囲はプランによって異なります。
• 共有VPS上でpfSenseやOPNsenseをゲートウェイとして動かすこと。NICパススルーがなければアーキテクチャ上不向きです。ネットワークディストリビューションのセクションで説明します。

「おすすめ無料ファイアウォール」が実際に意味するもの（4つのカテゴリ）

この検索キーワードで堂々巡りになる理由は、4つの異なるマシンで4つの異なる問題を解決する4つの製品を一括りにしているからです。まず自分がどのカテゴリに当てはまるかを見極めてから、ツールを選びましょう。

1. Linuxホスト/VPSファイアウォール： サービスと同じマシン上で動作し、どのポートに到達できるかを制御するソフトウェアです。UFW、firewalld、nftables。これはすべてのVPSに必要な層です。
2. ネットワークファイアウォールのディストリビューション： ファイアウォールエンジンを中心に構築された完全なオペレーティングシステムで、ネットワーク全体を保護するために専用マシンやVMに導入します。OPNsense、pfSense、IPFire。これらはホームラボやオフィスのLAN向けであり、保護しようとしているVPS向けではありません。
3. Web Application Firewall（WAF）： SQLインジェクション、XSS、そのほかのOWASP Top 10といったWeb層の攻撃をHTTPトラフィックから検査するリバースプロキシです。SafeLine、BunkerWeb、Haltdos、ModSecurity。これらはVPS上で動作するWebアプリやAPI向けです。
4. コンシューマー/Windowsエンドポイントファイアウォール： Windows上でアプリケーションごとのインターネットアクセスを制御するデスクトップソフトウェアです。ここでは除外対象として挙げているに過ぎません。

VPSで運用するのはカテゴリ1と3です。カテゴリ2は別のマシンで動作します。カテゴリ4は別のオペレーティングシステムで動作します。あなたの状況に適した無料またはオープンソースのファイアウォールの選択肢は、お使いのディストリビューションとトラフィックに合う、カテゴリ1（場合によってはカテゴリ3）のツールです。

結論を先に言うと ほとんどのVPS運用者には、ホストにUFWを使い、Webアプリを運用していて8 GBのサーバーを立ち上げずにWAFを導入したい場合はSafeLineを追加することをおすすめします。

このセクションの要点： VPSでは、ホストファイアウォールとWAFの中から選ぶことになります。ネットワークディストリビューションやコンシューマー向けツールは、別のマシン向けの別の製品です。

ホストファイアウォール：UFW対nftables対firewalld

ホストファイアウォールは、常に必要となる唯一の層です。サーバー上のどのポートが接続を受け付けるかを制御し、新規のVPSでは、しっかり閉じられたサーバーと無防備なサーバーの違いを生みます。UbuntuではそのファイアウォールはたいていUFWです。RHEL系のディストリビューションではfirewalldです。DebianではUFWはシンプルなホストファイアウォールのフロントエンドですが、Debianのデフォルトかつ推奨されるファイアウォールのフレームワークはnftablesです。

3つの選択肢は、ディストリビューションと必要な制御の度合いによってきれいに分かれます。

UFWは Ubuntuのデフォルトのファイアウォール設定ツール であり、Debianでも一般的でシンプルな選択肢ですが、Debianのデフォルトのファイアウォールフレームワークはnftablesです。1台のVPSであれば、少数の許可/拒否ルールだけで済む場合、UFWは依然として最も手軽な出発点です。CLIは3つの中で最もシンプルで、ルールは再起動をまたいで自動的に保持され、いくつかのコマンドでほとんどのVPS運用者が必要とすることをすべてカバーできます。その限界は高度なルールにあります。複雑なセットベースのロジックやきめ細かいマッチングは、UFWでは扱いにくいのです。

firewalldはRHEL、CentOS、AlmaLinux、Rockyのデフォルトです。ゾーンベースで、systemdと統合されており、インターフェースや信頼レベルごとにトラフィックを分割する点でUFWよりも高機能です。その分、セットアップに時間がかかります。RHEL系のVPSを使っているなら、firewalldはすでに用意されており、最も抵抗の少ない選択肢です。

nftablesは、両者の基盤となるカーネルレベルのエンジンです。そのルール規模や速度が本当に必要になったとき、つまり数千のルール、高性能なフィルタリング、あるいはフロントエンドが公開していない制御が必要なときに、直接使います。 Better StackのUFW対nftables比較によれば、数千のルールが存在する状況では、nftablesはiptablesより10倍から100倍高速に動作します。この数値はnftables対iptablesであり、UFW対iptablesではありません。ごく少数の許可ルールしかない一般的なVPSでは、その差を体感することはなく、より急な学習曲線と使いやすいUIの欠如は割に合いません。セキュリティの観点も念頭に置いておく必要があります。nftablesには、次のような実際のカーネルのバグがありました。 CVE-2025-40206そのため、カーネルにはパッチを当て続けましょう。これは最新の状態を保つ理由であって、すでに動かしているバックエンドを避ける理由ではありません。

UFWのルールの具体的な設定方法を知りたい場合は、 CloudzyのUFWコマンドガイド がコマンドを一つずつ解説しています。このセクションは、ルールの記述方法ではなく、ツールの選び方についてのものです。

プロのヒント： 「iptablesは非推奨」という言葉は、何か作業が必要だという意味ではありません。nftablesはカーネルのバックエンドとしてiptablesを置き換えており、最近のディストリビューションではUFWもfirewalldもすでにnftables上で動作しています。既存のUFWのルールを書き直す必要はありません。フロントエンドのコマンドは同じで、変わったのはその下のエンジンだけです。生のiptablesから移行してきて、その変遷を理解したい場合は、 Cloudzyのiptablesルールリファレンス が今も有効です。あなたが書いたルールは新しいバックエンドに対応づけられるからです。

このセクションの要点： お使いのディストリビューションの標準的な方法を使いましょう。UbuntuならUFW、RHEL系ならfirewalld、Debianでは必要な制御の度合いに応じてUFWまたはnftablesを直接使います。nftablesを直接使うのは、そのルール規模や速度が本当に必要なときだけにしましょう。

ネットワークファイアウォールのディストリビューション：OPNsenseとpfSenseが適する場面（そしてVPSに向かない理由）

OPNsense、pfSense、IPFireは、ネットワーク全体を保護する専用マシンやVM向けの完全なオペレーティングシステムです。保護しようとしているVPS上で動かすものではありません。検索結果には必ず出てくるので知っておく価値はあります。そこで、これらがどこに適し、どこに適さないかを説明します。

実際に必要になる場面はこうです。ホームラボや小規模オフィスのLANで、専用ハードウェアやNICパススルーを備えたVM上に置き、あなたのネットワークとインターネットの間に配置する場合です。オフィスのマシンのラックを保護する場合でも、インターネットに公開する個人のラボを保護する場合でも、役目を果たすのはこのカテゴリです。

共有VPSでこれが不適切なツールである理由はこうです。これらのディストリビューションは、複数のネットワークインターフェース間のトラフィックを制御することを前提としています。共有VPSでは、それにはNICパススルーが必要ですが、ほとんどのプロバイダーはこれを提供していません。それがなければ、制御すべきネットワークが存在しないマシンでネットワークゲートウェイOSを動かしていることになります。単一のVPSを使っているなら、このカテゴリ全体が間違った層であり、UFWとWAFの組み合わせが正しい層です。

2026年時点での3つの無料の選択肢を簡単に紹介します。

• OPNsense （BSDライセンス、現行の安定版CEシリーズ：26.1、 26.1.11は2026年7月1日リリース）。完全にオープンソースで、頻繁に更新され、pfSenseのようなCE/Plusモデルには分かれていません。そのため、機能ティアの混乱なしに完全にオープンソースのファイアウォールディストリビューションを求める多くのユーザーにとって、よりすっきりした無料のネットワークアプライアンスの選択肢となっています。
• pfSense Community Edition （現行のCEリリース： 2.8.1、2025年9月リリース）。今も無料でオープンソースであり、OPNsenseよりも豊富なドキュメントとコミュニティの資産を備えています。注意点はCE/Plusの分かれ方です。pfSense CEは無料のコミュニティ版のままですが、pfSense Plusは、Netgateアプライアンス、クラウド導入、サードパーティ製ハードウェア向けの別の商用の道です。現行のPlusの条件については、 NetgateのpfSense Plusページ を確認し、比較記事に載っている数字を鵜呑みにしないようにしましょう。
• IPFire （最新は2.29 Core Update 202、出典は IPFireのリリースブログ）。他の2つよりもリソース消費が軽く、コミュニティは小規模です。より軽量なアプライアンスが欲しく、OPNsenseのようなプラグインの幅広さを必要としない場合には妥当な選択肢です。

これらの要約は、現行のドキュメントとリリースノートに基づいています。ネットワークファイアウォールのディストリビューションを実際のネットワークで頼りにする前に、必ずVMでテストしてください。

このセクションの要点： 保護すべきネットワークと予備のマシンがあるなら、2026年ではOPNsenseが無料の選択肢です。単一のVPSしかないなら、このカテゴリ全体が間違った層です。

Web Application Firewall：SafeLine対BunkerWeb対Haltdos

ホストファイアウォールは、どのポートが開いているかを制御します。WAFはそれとは別のことをします。SQLインジェクション、XSS、そのほかのOWASP Top 10といったWeb層の攻撃をHTTPトラフィックから検査するのです。これらはポートベースのファイアウォールには見えません。VPS上でWebアプリやAPIを運用しているなら、WAFは2つ目の補完的な層になります。ホストファイアウォールの代わりではありません。両者はスタックの異なる位置に配置されます。

VPSへの導入では、リソース消費から検討を始めましょう。RAMの予算に収まるWAFが、たいていは実際に動かし続けられるWAFです。

SafeLine は最も軽量な入り口です。そのGitHubリポジトリでは、GPL-3.0ライセンスのセルフホスト型WAF/リバースプロキシと位置づけられています。 サードパーティによるインストール解説 では、最小要件を1 CPUコア、1 GB RAM、5 GBのディスクとし、Docker 20.10.14以降とDocker Compose 2.0.0以降を挙げています。SafeLineは従来のルールリストだけに頼るのではなく、意味解析を用いていますが、公開されている検知率の数値は、独立したベンチマークの結果ではなく、プロジェクトやベンダーが提示した主張として扱うべきです。リソースだけで見れば、SafeLineは依然として小規模VPS向けの選択肢です。

BunkerWeb は最も機能が充実しており、最も重量級です。AGPLv3のNGINXベースのリバースプロキシ型WAFで、OWASP Core Rule Setを備えたModSecurity上に構築されています。その代償はRAMです。 BunkerWeb公式のドキュメント では、最小推奨スペックとして2 vCPUと8 GBのRAMを挙げ、多数のサービスを伴う本番環境向けには4 vCPUと16 GBを挙げています。

Haltdos Community は3つ目の無料の選択肢です。その コミュニティ版のページ では、OWASP Top 10への対応、DDoSおよびボット対策、レート制限、組み込みルール、そしてWebベースの管理GUIが挙げられています。ドキュメントでは、最小要件として2 GB RAM、60 GBのディスク、少なくとも2 vCPUを挙げ、VM、Docker、ハードウェアへの導入をサポートしています。

SafeLine, BunkerWeb、そして Haltdos はいずれもCloudzyのマーケットプレイスでワンクリック導入が可能で、手作業であればどのVPSでも動作します。顧客向けのAPIを保護する場合でも、インターネットに公開する個人向けサービスを保護する場合でも、層は同じです。選択の決め手は、主にどれだけのRAMを割り当てられるかにあります。

このセクションの要点： WAFは、ホストファイアウォールとは別の層です。SafeLineは最も軽量な無料の選択肢で、BunkerWebは最も機能が充実していますが、はるかに大きなサーバーを必要とします。

サーバーにWAFを置くと決めたなら、導入の手順こそマーケットプレイスが時間を節約できる場面です。SafeLineとBunkerWebはどちらもDockerで動作するため、通常はComposeファイル、リバースプロキシの設定、初回起動時のデバッグが伴います。SafeLine、BunkerWeb、Haltdos向けのCloudzyマーケットプレイスの選択肢は初期のインストール手順を省けますが、それでもアップストリームのルーティング、DNS、TLS、誤検知の処理、ホストファイアウォールのルールは自分で設定する必要があります。ホストファイアウォールの層そのものは軽量で、通常はディストリビューションのパッケージから利用できます。サービスを公開する前に、必ずインストール、設定、有効化を済ませておきましょう。プランはWAFに合わせて選びます。SafeLineには1 GBで十分ですが、BunkerWebの8 GBという下限は、より大きなインスタンスを意味します。WAFは次のような環境に導入でき、 クラウジー リナックス VPS 同じサーバー上でホストファイアウォールを動かすこともできます。

Dockerに関する注意点が1つあります。アプリやWAFがDockerで動作している場合、公開されたすべてのコンテナポートをUFWだけで制御できると思い込まないでください。 Dockerは独自のファイアウォールルールを作成します デフォルトでそうなるため、可能な限りバックエンドのコンテナはlocalhostやプライベートなDockerネットワークにバインドし、実際に公開するつもりのWAF向けのポートだけを公開しましょう。

ホストファイアウォールとWAFの両方が必要ですか？

公開されたWebアプリを運用しているなら、答えはイエスです。両者は異なる層を保護します。ホストファイアウォール（UFWまたはfirewalld）は、どのポートが開いているかを制御し、すべてのVPSにとっての土台となります。WAFは、それらの開いたポートを流れるHTTPトラフィックを検査し、アプリケーション層の攻撃を捉えます。WAFはホストファイアウォールを置き換えるものではなく、その背後に配置されます。

ホストファイアウォールは譲れません。Webアプリの有無にかかわらず、すべてのVPSに必要です。公開するつもりのなかったサービスに、インターネットの他の部分が到達するのを止めてくれるのがこれだからです。WAFは条件付きです。アプリケーション層で攻撃されうるHTTPまたはHTTPSのトラフィックを提供するとき、つまり公開API、CMS、Web経由でユーザー入力を受け付けるものなどを運用するときに追加します。静的サイトや、VPNの背後にある内部専用のサービスであれば、WAFはまったく不要かもしれません。その場合はホストファイアウォールだけが正解であり、WAFを追加するのは不要なオーバーヘッドです。層は、チェックリストではなく、実際に運用しているものに合わせましょう。

このセクションの要点： ホストファイアウォールは、すべてのVPSの土台です。Webアプリをインターネットに公開するときにWAFを追加しましょう。

よくある質問

Linuxではiptablesは非推奨ですか？

実質的にはイエスです。最近のLinuxでは、nftablesがカーネルのパケットフィルタリングのバックエンドとしてiptablesを置き換えました。ただしこれはバックエンドの変更であって、何か行動を促すものではありません。現行のディストリビューションではUFWもfirewalldもすでにnftables上で動作しており、既存のUFWのルールを書き直す必要はありません。フロントエンドのコマンドは変わっておらず、動いたのはその下のエンジンだけです。

pfSenseは2026年でも無料ですか？

はい。pfSense Community Edition（現在は2.8.1）は無料でオープンソースです。注意点はCE/Plusの分かれ方です。pfSense CEは無料のコミュニティ版のままですが、pfSense Plusは、Netgateアプライアンス、クラウド導入、サードパーティ製ハードウェア向けの別の商用の道です。現行のPlusの条件やサブスクリプション料金については、サードパーティの比較に載っている数字に頼るのではなく、NetgateのpfSense Plusページを確認してください。

VPS上でpfSenseやOPNsenseを動かせますか？

技術的には可能ですが、共有VPSではアーキテクチャ上不向きです。これらは複数のネットワークインターフェース間のトラフィックを制御することを前提としたネットワークゲートウェイのオペレーティングシステムであり、ほとんどのVPSプロバイダーが提供していないNICパススルーを必要とします。単一のVPSで実際に必要なのは、ホストファイアウォール（UFWまたはfirewalld）と、Webアプリ向けにはWAFです。

Linuxサーバーにすでにファイアウォールがあれば、WAFは必要ですか？

両者は異なる層を保護するため、何を運用しているかによります。ホストファイアウォールは、どのポートが開いているかを制御します。WAFは、そこを流れるHTTPトラフィックを検査し、SQLインジェクションやXSSといったWeb層の攻撃を捉えます。公開されたWebアプリやAPIを提供しているなら、ホストファイアウォールの上にWAFを追加しましょう。静的サイトや内部向けサービスだけを運用しているなら、ホストファイアウォールだけで十分です。

小規模なLinux VPSに最適な無料WAFは何ですか？

SafeLineは最も軽量な無料の選択肢で、Dockerで動作する際の最小要件が1 GB RAMのため、小規模VPSに収まります。BunkerWebはより機能が充実していますが、8 GBのRAMを必要とするため、小規模サーバー向けの導入ではありません。Haltdos Communityは、Web UIを備えた3つ目の無料の選択肢です。サーバーのサイズを決める前に、現行のリソース要件をドキュメントで確認してください。