설치 가이드를 따르지 않으면 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 전용이라고 할 수 없습니다.

차이는 HTTPS 없이 불안전하게 연결하는 것을 허용하지 않고 서버의 원본 IP를 노출하지 않는다는 점입니다. 그렇게 하는 데 따른 이점은 제가 아는限り 없습니다.

세계 상위 50개 사이트의 DNS 조회를 해보면, IP 주소로 직접 불안전하게 접근할 수 있는 사이트가 하나도 없는 것으로 보입니다. 세계 상위 50개 사이트가 모범 사례를 따르고 있다고 가정하는 것은 합리적이라고 생각합니다.

아래는 꽤 정확한 상위 목록입니다:

아래는 DNS 조회 도구입니다:

5

기본적으로 IP를 통해 접근을 시도하면 올바른 도메인으로 301 Redirect가 반환됩니다:

$ 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

8개 설치 중 8개 모두 Digital Ocean 이미지를 사용하여 설치했으며, Communiteq(구 DiscourseHosting)을 통해 설치(이후 마이그레이션)한 경우와 이 가이드(discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub)를 수동으로 따라 설치한 경우 모두 기본적으로 IP를 통해 보안 없이 접근할 수 있습니다. 그중 2개는 지난주에 설치되었습니다(위 GitHub 가이드 사용).

혹시 제가 놓치고 있는 추가 단계가 있을까요? IP 주소를 탐색하는 대부분의 사람은 좋은 의도가 아닐 것이므로, 301 리다이렉트보다는 404가 더 낫다고 생각합니다. 하지만 301 리다이렉트도 보안 없이 접근하는 것보다는 낫죠.

7

재현되지 않음..

http://38.242.24.122는 https://discourse.codinghorror.com/으로 올바르게 리다이렉트됩니다.

4개의 좋아요
8

음, 아마도 Cloudflare 템플릿 때문일 겁니다. 완전히 기본 설치 환경과 비교했을 때, 모든 경우에서 일관되게 다른 점은 아마도 이것뿐일 것입니다.

1개의 좋아요
9

클라우드 설치에 나열되지 않은 조치를 취했다면, 정의상 "바닐라 설치(vanilla install)"가 아닙니다.

Cloudflare 템플릿은 리다이렉트를 방해하는 눈에 띄는 작업을 수행하지 않습니다:

run:
  - file:
      path: /tmp/add-cloudflare-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Download list of CloudFlare ips
        wget https://www.cloudflare.com/ips-v4/ -O - > /tmp/cloudflare-ips
        wget https://www.cloudflare.com/ips-v6/ -O - >> /tmp/cloudflare-ips
        # Make into nginx commands and escape for inclusion into sed append command
        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")
        # Insert into discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header CF-Connecting-IP;" /etc/nginx/conf.d/discourse.conf
        # Clean up
        rm /tmp/cloudflare-ips

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

이 스크립트는 IP 범위를 가져와 임시로 cloudflare-ips에 저장한 뒤, CF-Connecting-IP 헤더에 대한 지원을 추가합니다.

2개의 좋아요
10

맞습니다. 제가 "바닐라 설치"라고 주장한 적은 없습니다.

그래서 그중 하나에서 공식 Cloudflare 템플릿을 제거한 뒤 다시 빌드해 보았지만, 불행히도 상황이 달라지지 않았습니다. 여전히 IP를 통해 안전하지 않은 방식으로 접근할 수 있습니다.

해당 설치 환경들 사이에 특별한 차이점을 생각해 내기 어렵습니다. 해당 인스턴스에 설치된 플러그인은 기본으로 포함된 Docker 매니저와 공식 광고 플러그인뿐이었습니다. 이 인스턴스는 stable 브랜치를 사용 중이지만, 동일한 문제를 보이는 다른 사이트들은 stable, beta, tests-passed 브랜치를 혼합하여 사용하고 있습니다.

11

특정 구성이나 Cloudflare에 국한된 내용은 아니며, 그저 또 하나의 데이터 포인트와 관점입니다:

Apache2와 Nginx 모두 여러 방식으로 “포트 80의 네이키드 IP 주소”(예시)를 다른 FQDN으로 리디렉션하도록 프록시를 설정할 수 있습니다.

이를 수행하는 방법은 다양합니다(rewrite 및 redirect, virtual host 및 redirect 등).

예를 들어, 리버스 프록시에서 포트 80의 해당 IP 주소를 경청(listen)하도록 가상 호스트를 생성하고, 해당 요청을 우리가 선택한 FQDN(또는 IP 주소)으로 리디렉션할 수 있습니다.

또한 Apache2의 mod_rewrite와 Nginx의 rewrite 규칙을 사용하는 리버스 프록시를 통해 이 작업을 수행할 수도 있습니다.

운영 중인 모든 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를 통해 사용될 가능성이 거의 없다는 점을 더 잘 알 수 있습니다. 어쨌든, 웹에서 안전하지 않은 직접 IP 접근을 허용하는 데 동의하는 사람은 아무도 없는 것 같습니다.

네, 맞습니다.

1개의 좋아요
16

Digital Ocean의 마켓플레이스 앱을 사용하여 인스턴스를 빠르게 배포하는 방식으로, 2개의 Discourse 인스턴스를 배포하는 것을 방금 테스트했습니다.

거의 커스텀 설정 없이 테스트하고 싶었기 때문에, smtp, dev email, discourse_hostname 항목만 허위 정보로 편집했습니다(재구성을 허용하기 위해).

설치 프로그램은 제가 설정한 허위 도메인/서브도메인이 도메인 검증 단계를 통과하지 못해 중단되었습니다(그리고 app.yml 파일을 수동으로 편집한 후 재구성할 것을 권장합니다).

app.yml을 편집하고 재구성한 후(smtp, dev email, discourse_hostname만), Cloudflare에 개입 없이 사이트가 IP 주소로 불안전하게 접근 가능해졌습니다. 설정된 discourse_hostname으로 리디렉션되지 않습니다.

제 대부분의 설치 작업은 Digital Ocean 마켓플레이스 앱을 사용하지 않고 표준 docker 설치 가이드를 사용하여 수동으로 수행되었습니다.

참고로, 도메인을 검증할 수 없어 설치 프로그램이 중단되는 문제는 Cloudflare를 사용한 최근 2건의 설치에서도 발생했습니다. 아마도 프록싱 때문일 것입니다. 다른 설치 작업들은 설치 프로그램에 도메인 검증 단계가 도입되기 전에 수행되었습니다.

수정: 8개의 Discourse 설치 중 초기 설치 시 도메인 검증 문제가 발생한 것은 2건뿐입니다(위에서 만든 2개의 테스트 인스턴스는 제외). 도메인 검증 오류가 발생하면 Discourse 설정 스크립트는 사용자에게 app.yml을 수동으로 편집하고 재구성하도록 제안합니다. 이것이 유용하지 않다면 문제가 되지 않지만, 제 경우에는 해결책이 되지 못했습니다.

수정: 일반적으로 Cloudflare의 유연한 SSL을 사용하고 있으며, letsencrypt(이것이 더 좋겠지만)는 사용하지 않습니다. @neounix 감사합니다.

17

참고 @markersocial

모든 Discourse 설치 환경에서는 LETSENCRYPT를 활성화하여 Discourse 컨테이너의 .yml 파일에 설정된 https://FQDN으로 http://the.ip.add.res를 리디렉션합니다.

이 모든 것이 정상적으로 작동하고 LETSENCRYPT 인증서가 올바르게 기능하려면, 이미 잘 알고 계시겠지만 완전히 정상 작동하는 SSL 구성(일반적으로 LETSENCRYPT 사용)이 필요합니다.

간단히 상기시켜 드리는 것입니다… 도움이 되길 바랍니다.

2개의 좋아요
18

Vanilla는 유효한 도메인을 사용하고 discourse 설치 스크립트를 실행하고 있습니다.

이 두 가지 중 어느 것도 수행하지 않았다면, 결과가 달라지는 것은 예상할 수 있는 일입니다.

이 주제에는 실행 가능한 정보가 없으며, 지침을 따랐다면 재현할 수 없습니다.

7개의 좋아요