안녕하세요,
최근 Discourse 인스턴스를 Discourse/2.9.0.beta3에서 최신 버전인 Discourse/2.9.0.beta14로 업그레이드했습니다.
그 후 discourse 웹훅 이벤트가 작동하지 않게 되었습니다.
현재 설정은 다음과 같습니다.
페이로드 URL: http://server-name:port/rest : 이는 우리가 정의한 내부 REST API 서비스입니다.
이 값을 저장하려고 하면 다음 오류가 발생합니다:
“오류가 발생했습니다: 페이로드 URL은 차단되거나 내부 IP로 해석되므로 사용할 수 없습니다.”
같은 페이로드 URL 값(http://server-name:port/rest)은 Discourse/2.9.0.beta3 버전에서는 정상적으로 작동했습니다.
최신 discourse 버전에서 변경된 사항이 있거나, 이는 버그인가요?
확인해 주시면 감사하겠습니다. 미리 감사합니다.
이것은 맞지 않는 것 같습니다. 웹훅의 페이로드 URL이 Discourse가 자체 호스팅되는 경우 내부 리소스일 수 있습니다. 웹훅 처리를 위해 내부적으로 해석되는 URL이나 주소를 구성할 수 없도록 막고 싶은 이유가 무엇인지 모르겠습니다. 사용자 프로필에 잘못된/잘못된 웹사이트 URL이 입력되는 것을 방지하기 위해 변경 사항이 있었던 것 같습니다. 이 변경 사항이 웹훅 페이로드 URL 검증에까지 영향을 미친 것일까요?
Discourse 관리자가 웹 훅을 사용하여 자신들의 네트워크가 아닌 네트워크의 내부 리소스를 발견하거나 공격할 수 있는 보안 문제가 될 수도 있기 때문이죠?
네, 이 내용을 Contribute > Feature 채널로 옮겼습니다. 이 기능은 내부 네트워크에 대한 정보를 수집하는 데 사용할 수 있습니다. 특정 인스턴스에서 동작을 조정할 수 있는 몇 가지 설정 항목이 있습니다.
우리의 셀프 호스팅 인스턴스도 이 문제에 영향을 받고 있습니다. 웹훅을 수신하는 서비스를 내부 Docker 네트워크에서만 호스팅하고 싶으며, 외부에서 접근할 필요가 없습니다.
내부 웹훅을 허용하는 방법이 있을까요?
제 이해가 맞다면, 서버 관리자로 권한이 부여되지 않은 Discourse 관리자가 네트워크 내부 정보를 엿볼 수 없도록 내부 웹훅이 허용되지 않는 것입니다. 하지만 이는 우리의 셀프 호스팅 인스턴스에서는 문제가 되지 않습니다. 우리의 Discourse 관리자는 어차피 내부 구조를 알고 있을 것이기 때문입니다.
내부 웹훅을 허용하거나, 내부 도메인/IP의 화이트리스트를 제공하도록 app.yml 설정에 옵션을 추가하는 것을 제안합니다. 이렇게 하면 서버 관리자(Discourse 관리자가 아닌)가 내부 네트워크에서 웹훅을 사용할 수 있는 대상을 통제할 수 있습니다.
특정 내부 호스트를 차단 해제할 수 있는 설정을 찾았습니다. 이 설정은 웹훅이 차단되는 원인이 되는 SSRF 보호 메커니즘에서도 준수됩니다:
allowed_internal_hosts 설정을 사용하여 웹훅에서 허용할 내부 호스트 이름을 지정하세요.
관리자 패널에서 이 매개변수를 찾을 수 없습니다. 삭제되었거나 이름이 변경되었나요?
아마도 자체 호스팅 버전에서만 사용 가능한 것일까요?
아니요, allowed_internal_hosts 사이트 설정은 여전히 존재합니다.
하지만 디스코urses 호스팅 고객에게는 숨겨져 있는 것 같습니다. 다만 Hidden Settings on Discourse Hosted Sites 에는 목록에 포함되어 있지 않습니다. 그럼에도 불구하고 해당 서비스를 통해 호스팅을 받고 있고 설정을 찾을 수 없다면, 그들의 지원팀에 문의하는 것이 좋습니다.
자기 호스팅 버전에서만 사용 가능한 것 같아요!
사실 이게 더 말이 되네요. 클라우드 버전은 비공개 URL에 접근할 수 없으니까요.
