適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5
この記事では、Linux 仮想マシン (VM) をセキュリティで保護するようにローカル ファイアウォールを構成する方法について説明します。
前提条件
チュートリアルのこの部分を完了するための前提条件はありません。
このパートの目標
ファイアウォールを構成して Linux VM をセキュリティで保護する方法について説明します。
このパートの前提条件はありませんが、理想的なセットアップは前のパートのガイダンスに従います。 次のものが必要です。
- Nginx が自動的に実行され、ポート 80 で送信された要求をリッスンしています
- リバース プロキシとして構成され、受信要求をポート 5000 でリッスンしている ASP.NET Core アプリケーションにルーティングする Nginx。
- サーバーの再起動後、またはプロセスが停止またはクラッシュしたときに自動的に起動するように構成された ASP.NET Core アプリケーション
リモート コンピューターからのアクセスを許可するようにローカル ファイアウォールを構成する
ほぼすべての Linux ディストリビューションには、 iptables という名前のローカル ファイアウォールが含まれています。 この ガイド はクイック スタートに十分です。 Iptables は、ポリシー チェーンを使用してトラフィックを許可またはブロックする、軽量でありながら強力なファイアウォールです。
Ubuntu コミュニティのヘルプ ページによると既定では、iptables はすべての公式 Ubuntu ディストリビューションにインストールされ、すべてのトラフィックを許可するように構成されています。
iptables は軽量のファイアウォールですが、永続的な規則を管理するのは簡単ではありません。 幸いなことに、Linux でファイアウォール規則を構成するタスクをはるかに簡単にするファイアウォール構成ツールがいくつかあります。 非公式の Ubuntu ファイアウォールのドキュメントによると、Ubuntu の既定のファイアウォール構成ツールはufw。 このツールは、iptables が IPv4 または IPv6 ホスト ベースのファイアウォールを作成するために提供する方法よりもわかりやすい方法を提供します。
Note
ufw は、既定で無効になっています。 したがって、それを使用できるようにするには、有効にする必要があります。
このチュートリアル全体で使用されている Linux VM は、ファイアウォール規則によって保護されていません。 これは、iptable がインストールされ、実行されていますが、定義された規則がないためです。
ここでの目標は、HTTP および SSH (Secure Shell) トラフィックのみが外部から VM に到達できるようにすることです。 これを実現するには、次の手順に従います。
ufwを有効にする前に、既定のポリシー規則が allow に設定されていることを確認します。 それ以外の場合は、VM への SSH 接続が失われます。 既定のルールは、他のルールが一致しない場合に処理されるルールです。 既定の "許可" ルールを有効にすると、着信 SSH トラフィックがブロックされていないことが確認されます。 この時点で、"拒否" ルールはまったくありません。 そのため、すべての受信トラフィックが許可されます。-
重要
SSH と HTTP の "許可" 規則を明示的に追加します。 また、SSH ポートを既定値の 22 とは異なる値に構成した場合は、そのポートを許可する必要があることに注意してください。 たとえば、SSH ポートを 2222 に変更した場合は、次のコマンドを実行する必要があります:
sudo ufw allow 2222。 - 既定の規則を "拒否" ルールとして設定します。 これにより、プロトコルが SSH または HTTP とは異なる場合、既定の "拒否" 規則によってトラフィックが拒否されます。 たとえば、受信 HTTP トラフィックは拒否されます。
ufwを有効にします。
これらの手順のコマンドは、次のスクリーンショットに示されています。
これは、各手順で発生します。
は、
sudo ufw status verboseコマンドを実行して ufw の状態を確認します。 既定では、ufw は有効ではなく、非アクティブです。コマンド
sudo ufw default allow実行します。 既定の "許可" 規則以外の規則がないため、VM 上のすべてのポートが開いていると見なされます。-
重要
sudo ufw allow sshコマンドを実行して、許可リストに SSH プロトコルを追加します。 Protocol.ssh は既知のプロトコルであり、 /etc/services ファイルで定義されています。 そのため、"22" ではなく "ssh" を使用できます。 既定のポート 22 以外のポートでリッスンするように SSH サービスを構成する場合は、他のポートを明示的に追加する必要があります。 たとえば、ポート 2222 をリッスンするように SSH を構成する場合は、次のコマンドを実行します:sudo ufw allow 2222。 sudo ufw allow httpを実行して HTTP プロトコルを許可します。 HTTP は、/etc/services ファイルで定義されている既知のプロトコルです。 そのため、プロトコル名を使用して、sudo ufw allow httpコマンドを実行できます。sudo ufw allow 80の実行も完全に有効です。Note
SSH プロトコルと HTTP プロトコルの両方を許可したら、他のすべてのプロトコルを "拒否" リストに追加します。
これを行うには、
sudo ufw default denyコマンドを実行して、既定の規則を拒否するように変更します。 SSH プロトコルと HTTP プロトコルのみが許可されます。 その他のプロトコルは拒否されます。ufwを有効にします。
この手順を完了した後の sudo ufw status verbose 出力を次に示します。
ファイアウォールが構成されたら、ファイアウォールが機能するかどうかをテストします。
ローカル ファイアウォールをテストする
ファイアウォールのテストは簡単です。HTTP プロトコルの "拒否" 規則を作成してから、別のコンピューターからサイトにアクセスしてみてください。 要求はブロックする必要があります。
この "拒否" ルールを作成する前に、アプリケーションが現在の構成でブラウザーからアクセスできることを確認します。 これを行うには、クライアント コンピューター上の C:\Windows\System32\drivers\etc\hosts ファイルを編集します。そのためには、バグのあるホスト名を追加し、Linux VM のパブリック IP アドレスを使用します。 バグのあるホスト名は、Linux VM の IP アドレスを解決します。 ホスト名を hosts ファイルに追加することも、Linux VM のパブリック IP アドレスに直接接続することもできます。
HTTP 要求が VM に到達できることを確認したら、HTTP トラフィックをブロックするルールを有効にしてみてください。 これは、ファイアウォールが動作することを確認します。 これを行うには、 sudo ufw deny httpを実行して HTTP の "拒否" 規則を追加します。 これにより、HTTP プロトコルの 2 つの "拒否" 規則が追加されます (ポート 80 の場合)。 1 つは IPv4 用で、もう 1 つは IPv6 用です。
ブラウザーをもう一度開き、Linux で実行されている ASP.NET Core アプリケーションにアクセスしてみてください。
このスクリーンショットは、予想される結果を示しています。
wget コマンドを使用して、Linux VM 内で同様のテストを直接実行できます。 次のスクリーンショットは、 wgetを実行して同じテストに必要な手順を示しています。
これは、各手順で発生します。
HTTP プロトコルの "拒否" 規則が追加されました。
wget buggyamb-externalコマンドが実行されました。 ご想像のとおり、"buggyamb-external" ホスト名は Linux VM のパブリック IP アドレスを解決します。 これを行うには、viを使用して/etc/hostsファイルを編集します。 示されているように、wgetは接続しようとしましたが、成功しませんでした。 操作を中断するには、 CTRL + C を押す必要がありました。HTTP プロトコルの "許可" 規則が追加されました。
wget buggyamb-externalコマンドをもう一度実行すると、異なる結果が生成されました。 今回は、HTTP プロトコルが許可されたため、wget接続できました。 次に示すように、wgetIndex.html ファイルを現在のディレクトリにダウンロードします。
これで、ASP.NET Core アプリケーションをデバッグするために必要な構成の完了にもう一歩近づくようになりました。 次のパートに進む前に、SSH と HTTP の両方がローカル ファイアウォールで許可されていることを確認してください。
