Discourseのファイアウォールを設定する

標準的なDockerベースのDiscourseインストールを使用している場合、以下のUncomplicated Firewallルールは、サーバー上のDocker以外のサービスを保護します。

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

つまり、HTTP(ポート80)、HTTPS(ポート443)、およびSSH(ポート22)のみを許可し、その他は許可しません。

:warning: 注意: Dockerはiptablesを直接操作し、ufwルールをバイパスします。これは、ufwがDockerコンテナによって公開されるポート(標準的なDiscourseインストールではポート80および443)へのアクセスをブロックまたは制限できないことを意味します。上記のufwルールは、ホストで実行されているDocker以外のサービスのみを保護します。

ファイアウォールの現在のステータスを次で確認します。

ufw status verbose

出力例:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80                         ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere
80 (v6)                    ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
22 (v6)                    ALLOW IN    Anywhere (v6)

そして、オフにしたい場合はいつでも

ufw disable

DiscourseのデフォルトのDockerインストールではポート80と443のみが公開されるため、ホストファイアウォールは厳密には必要ありません。しかし、追加のポートでリッスンする他のサービスがホストで実行されている場合は、ファイアウォールを追加することで、それらのサービスに対して「念には念を入れた」セキュリティの追加レイヤーを提供できます。

「いいね!」 33

私の理解では、Dockerコンテナはホストシステムに対して非常に少ないポートしか開いていないため、Discourseは実行されているサーバーから事実上ファイアウォールで保護されています。

もちろん、ホストシステムで他のものが実行されている場合は、適切な予防措置を講じる必要があると、キャプテン・オブビアスが言っています。

私が以前管理していたサーバーは、かなりロックダウンされていると考えていましたが、ハッキングされました。それは見苦しいものではありませんでした。

「いいね!」 1

トピックは完全に正確ではありません。UFWがDockerの外で、VPSで「通常」のように使用されている場合、Discourseには適用されません。ポート80を無効にしても、Discourse/dockerには開いたままです。

もちろん、他のすべてを保護しますが、他にサービスがリッスンしていない場合は不要です。

enter app の後にUFWまたはiptablesがどのように機能するか、またはファイアウォールがそのように使用できるかどうかはわかりません。

このトピックを参照しています。

「いいね!」 3

ぜひこの話を聞いてみたいです。別スレッドでお願いします :slight_smile:

ちなみに、Dockerとufw / ファイアウォールとの関係についての議論は、Dockerが登場した当初からほとんど変わっていません。以下に、非常に注目度の高い、興味深い洞察に満ちた議論があります。

Docker自身も、関連する詳細の文書化に関して近年改善されています。Packet filtering and firewalls | Docker Docs

トピックをリンクで spam したくはありませんが、ファイアウォールに興味がある場合は、これらの記事と、一般的なGoogle検索で詳細を確認するのが非常に役立つでしょう。

これらの意見の一部と、@Jagster がリンクした非常に役立つスレッドに基づくと、Dockerのデフォルトのディスコース(Discourse)のインストール構成はそれ自体で十分かもしれませんか?結局のところ、私の環境は以下のようになっています。

$ docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED      STATUS        PORTS                                                                      NAMES
5dd4a572cd8e   local_discourse/app   \"/sbin/boot\"   6 days ago   Up 16 hours   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app

したがって、私の認識が間違っていなければ、またサーバー上の他のソフトウェアによって他のポートが使用されていない限り、着信接続はこれらのリストされたポート80と443のみになるはずです。

確認したい場合は、サーバー上のリスニングポートを確認するためにnetstatを使用できると思います(How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/)。

netstat -tunlp

さらに強力な確認のためには、2台目の小さなLinuxサーバーを起動し、ディスコース(Discourse)サーバーのオープンポートをスキャンしてみることを検討してください。How To Use Nmap to Scan for Open Ports | DigitalOcean

# すべてのポートをスキャン ; ここにあなたのIPアドレスを挿入してください
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • スキャンなどの追加コマンドについては、DigitalOceanのドキュメントへのリンクを確認してください。

ディスコース(Discourse)サーバーのファイアウォールについて懸念している場合、これらのリソースと洞察は非常に役立つと思います :slight_smile:

「いいね!」 3

些細なことですが、このリンクは無効になっているようです。

「いいね!」 1

最新のUbuntu LTS ufwでは、ALLOW INではなくALLOWが出力されます。

これはmail-recieverの管理者にとって迷惑なことで、ufwでポート25を開いていても./launcher logs mail-receiver でAPIの準備に失敗していました。

すべての送受信を許可してから、必要なポートを拒否することが解決策となっています。

iptablesについては、まだ十分に理解していないため、さらに微調整することはできません。