インストールガイドに従わない場合、サイトはIPアドレスでアクセス可能

貢献 特徴
1

セキュリティの観点から、ブラウザで IP アドレスに直接アクセスした際に Discourse フォーラムがデフォルトで表示されない方がよいと思います。

その理由はいくつかあります：

  • HTTPS が使用できない環境でも、ユーザーや管理者による初期設定が可能になります。
  • オリジンサーバーのアドレスが漏洩するリスクがあります。Cloudflare などのサービスを使ってオリジン IP を DDoS 攻撃やサーバーハッキングから保護している場合、攻撃者がサーバーを重要と判断すれば特に問題となります。実際、ウェブホスティング会社が所有するすべての IP 範囲をスキャンするボットを運用している人々も存在します。

また、Discourse のインストーラーは、ドメインまたはサブドメインが正しく設定されていない限り、インストールを続行しないように確認を行うようになりました。

これを実現するために、Docker コンテナ内の /etc/nginx/conf.d/discourse.conf ファイルの一番下に以下の設定を追加するだけで済みます：

server {
    listen 80;
    server_name 1.1.1.1;
    server_tokens off;
    return 404;
}

ここで 1.1.1.1 はサーバーの公開 IP アドレスです。IP アドレスをハードコーディングするよりも、よりエレガントな方法があるかもしれませんが、いくつか試してみましたが動作しませんでした。

私にとっては非常にうまく機能しています（Cloudflare のプロキシ経由でも同様です）。IP アドレスへの直接アクセスを許可する必要がある、あるいは有用なケースはほとんど考えられません。このアクセスを禁止するのは比較的一般的な慣行のようです。ただし、これをやめるべき理由があれば、ぜひお聞かせください！

「いいね！」 1
2

既定のガイドではHTTPSのみの動作するサイトが提供されているのに、なぜ変更する必要があるのでしょうか？

特別なニーズを持つ人々は各自で対応できますが、既定の設定は変更せず、動作するドメイン名とHTTPSを前提としたままにします。

「いいね！」 9
3

ありがとうございます！

「いいね！」 1
4

客観的に言えば、これは正確ではありません。IP アドレスから直接アクセスできるため、HTTPS のみというわけではありません。

違いは、HTTPS 以外の不安全な接続を禁止し、サーバーのオリジン IP を公開しないようにすることです。それによる利点は知られていません。

世界のトップ 50 サイトの DNS 検索を行ってみると、IP アドレスから直接不安全にアクセスできるサイトは一つもないようです。世界のトップ 50 サイトがベストプラクティスを採用していると考えても不自然ではないでしょう。

以下は非常に正確なトップリストです：

以下は DNS 検索ツールです：

5

デフォルトの状態では、IP アドレスからアクセスしようとすると、正しいドメインへ 301 リダイレクト が返されます。

$ curl 159.203.68.6 -I
HTTP/1.1 301 Moved Permanently
Server: nginx/1.16.1
Date: Mon, 29 Jun 2020 20:24:41 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://falcoland.falco.dev/

ご提案は、301 から 404 への変更でしょうか？

「いいね！」 3
6

Digital Ocean イメージを使用してインストールした 8 件中 8 件が、デフォルトで IP アドレス経由で安全でないアクセスを許可されています。Communiteq（旧 DiscourseHosting）によるインストール（その後移行）も、このガイド discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub に従った手動インストールも同様です。そのうち 2 件は先週にインストールされました（上記の GitHub ガイドを使用）。

もしかして、見落としている追加の手順があるのでしょうか？IP アドレスを覗き見ている人の多くは悪意を持っている可能性が高いので、301 よりも 404 の方がマシだとは思いますが、それでも安全でないアクセスよりは 301 の方がマシです。

7

再現できません。

http://38.242.24.122 は正しく https://discourse.codinghorror.com/ にリダイレクトされます。

「いいね！」 4
8

うーん、もしかして Cloudflare のテンプレートが原因かもしれません。それなら、完全にバニラのインストールと比較して、すべてに共通する唯一の違いでしょう。

「いいね！」 1
9

クラウドインストールに記載されていない手順を踏んでいる場合、それは定義上「バニラインストール」ではありません。

Cloudflare テンプレートは、リダイレクトに明らかな干渉を行いません。

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # CloudFlare の IP リストをダウンロード
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # nginx コマンドに変換し、sed の追加コマンドに含めるためにエスケープ
        CONTENTS=$(</tmp/cloudflare-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo CloudFlare IPs:
        echo $(echo | sed "/^/a $CONTENTS")
        # discourse.conf に挿入
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # クリーンアップ
        rm /tmp/cloudflare-ips

  - exec: "/tmp/add-cloudflare-ips"
  - exec: "rm /tmp/add-cloudflare-ips"

これは IP 範囲を取得し、一時的に cloudflare-ips として保存した後、CF-Connecting-IP のサポートを追加します。

「いいね！」 2
10

はい、それらを「バニラインストール」とは主張していません。

そこで、そのうちの1つから公式の Cloudflare テンプレートを削除して再構築してみるテストを行いました。残念ながら効果はなく、IP アドレス経由で依然としてインセキュアにアクセスできてしまいます。

それらのインストール間で他に特筆すべき違いは思い当たりません。そのインスタンスにインストールされていたプラグインは、デフォルトで含まれている Docker マネージャーと公式の広告プラグインのみです。これは安定版ブランチ上にありますが、同様の挙動を示す他のサイトは、安定版、ベータ版、テスト通過版が混在しています。

11

特定の構成や Cloudflare に限定された話ではなく、単なる別のデータポイントと視点として：

Apache2 と Nginx の両方を使って、例えば「ポート 80 の裸の IP アドレス」を任意の FQDN にリダイレクトするプロキシを設定することは可能です。

これには様々な方法があります（書き換えとリダイレクト、仮想ホストとリダイレクトなど）。

例えば、リバースプロキシで仮想ホストを作成し、そのリバースプロキシを IP アドレスのポート 80 でリスニングさせ、すべてのリクエストを任意の FQDN（または IP アドレス）にリダイレクトすることもできます。

また、Apache2 の mod_rewrite や Nginx の書き換えルールを使って、リバースプロキシで同様の処理を行うことも可能です。

運用中のすべての Discourse 設定において、Discourse の前面にリバースプロキシ（一部は Apache2、一部は Nginx）を配置しており、これらの問題（発生した際）を、リバースプロキシを設定して対応させることで容易に緩和しています。

ただし、私は特別なケースとして Cloudflare をプロキシとして使用していませんが、どのようなプロキシでも、これらの種類の問題を管理するように設定可能であると思われます。つまり、どのようなリバースプロキシでも「ほぼ何でも任意の他のものへ」リダイレクトするように設定できるのと同じです。

一歩進んで考えてみると、もし私が Cloudflare のような商用プロキシユーザーで、特定の IP アドレスやドメイン名をリダイレクト（またはブラックホール）させたい場合、プロキシ（この場合は Cloudflare）を設定（または依頼）して、「ポート 80 の裸の IP アドレス」を私が選択した FQDN（または任意の場所）にリダイレクトさせるでしょう。

これはプロキシが本来（設計上）処理するように作られていることです。前述の通り、この種のリダイレクトは Apache2 や Nginx で容易に行えるため、Cloudflare ユーザーではないとしても、Cloudflare のような商用サービスであれば、このような些細なリダイレクトを容易に管理できると推測します。

「いいね！」 3
12

私は、生 IP でアクセスしてくるボットを特別なページに誘導するために、この設定を使用しています。

server {
        listen 80;
        # listen [::]:80;

        server_name ~^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+;

        root /var/www/ip-address;
        default_type text/plain;
        index nothing.doing;
        location / {
                try_files $uri /nothing.doing;
        }
}

しかし、他の人と同じく、私のプライベートフォーラムでも IP でのアクセスを再現できません。リダイレクトされてしまいます。私の環境には特別な設定も Cloudflare もなく、月額 0 ドルのバーチャルサーバーで、特に機能も付いていない環境で動作しています。

「いいね！」 3
13

しかし、よく考えてみると、それらのサイトはすべて、数千万ドル規模のインフラストラクチャ上で負荷分散された構成を採用していることに気づくかもしれません。つまり、それらも代表性があるとは言えません。

移行しても nginx の設定はコピーされないため、実際には新規インストールと同じです。

「いいね！」 2
14

素晴らしい、スニペットを共有してくれてありがとう、@elijah！とても助かります！ハードコードされた IP をあなたの正規表現に置き換えるか、またはスニペット全体を使います。:slight_smile:

「いいね！」 2
15

はい、それはさらに、それらのサイトが直接 IP 経由で Web 上で利用できない可能性が高いことを示唆しています。とにかく、Web 上で安全でない直接 IP アクセスを許可することに賛成する人は誰もいないようです。

はい、その通りです。

「いいね！」 1
16

Digital Ocean のマーケットプレイスアプリを使用して、Discourse インスタンスを 2 台起動するテストを行いました。これは迅速に起動するためのものです。

このテストでは、カスタム設定をほぼゼロにし、smtp、dev_email、discourse_hostname を架空の情報に編集してリビルドを許可するだけに行いました。

設定したドメイン/サブドメインがドメイン検証ステップを通過しなかったため、インストーラーが停止しました（その後、app.yml ファイルを手動で編集してリビルドすることが推奨されました）。

app.yml を編集してリビルドした後（smtp、dev_email、discourse_hostname のみ）、Cloudflare の関与なしに、IP アドレス経由で不安全な状態でサイトが利用可能になりました。設定された discourse_hostname へのリダイレクトは行われませんでした。

私のインストールのほとんどは、Digital Ocean のマーケットプレイスアプリを使用せず、標準の Docker インストールガイドに従って手動で行われました。

なお、ドメインの検証ができないためにインストーラーが停止する問題は、Cloudflare を使用した最近の 2 つのインストールでも発生しました。これはおそらくプロキシによるものです。他のインストールは、インストーラーにドメイン検証ステップが追加される前に行われたものです。

編集：ドメイン検証の問題が初期インストール中に発生したのは、上記の 2 つのテストインスタンスを除く 8 つの Discourse インストールのうち 2 つのみでした。Discourse のセットアップスクリプトは、ドメイン検証エラーが発生した場合にユーザーが app.yml を手動で編集してリビルドすることを提案しています。これが役立たない場合でも問題ありません。私自身にとっては解決策ではなかったためです。

編集：一般的には Cloudflare の Flexible SSL を使用しており、Let’s Encrypt（より良い選択肢）は使用していません。@neounix さん、ありがとうございます。

17

FYI @markersocial

当社のすべての Discourse インストールでは、.yml Discourse コンテナファイルで有効化された LETSENCRYPT によって設定された https://FQDN に、http://the.ip.add.res をリダイレクトしています。

これらが正しく機能し、LETSENCRYPT 証明書が動作するためには、ご存知の通り、完全な SSL 設定（通常は LETSENCRYPT を使用）が必要です。

念のためお知らせしました。ご参考になれば幸いです。

「いいね！」 2
18

Vanilla は有効なドメインを使用しており、Discourse のセットアップスクリプトを利用しています。

どちらも実行しない場合、結果が異なることは予想されます。

このトピックには実行可能な情報が含まれておらず、手順通りに実行しても再現できません。

「いいね！」 7