와일드카드 DNS 레코드는 모든 서브도메인을 단일 IP 주소로 자동 해석하여 서비스 게시를 용이하게 합니다. Nginx Proxy Manager(NPM)는 몇 가지 필드만으로 서비스를 HTTPS로 안전하게 노출할 수 있어 게시를 더욱 단순화합니다. 이러한 자동화는 다양한 인증 방식을 사용하는 자체 호스팅 소프트웨어를 실행하는 19개의 프록시 호스트를 생성하는 결과를 낳았습니다. 여기서 파악된 핵심 문제는 게시의 용이성이 액세스 제어에 대한 중요한 보안 결정을 우회한다는 것입니다.저자의 목표는 서비스를 완전히 숨기는 것이 아니라 공개 인프라를 기반으로 구축된 개인 네트워크에서만 액세스할 수 있도록 하는 것이었습니다. 와일드카드 DNS 레코드는 설정은 단순화하지만 본질적으로 보안을 제공하지는 않습니다. NPM은 Let's Encrypt 인증서에 HTTP-01 챌린지를 사용하므로 포트 80이 열려 있어야 하며, 이는 보안 취약점입니다. DNS-01을 통한 와일드카드 인증서는 포트 80을 닫을 수 있지만 DNS 영역에 대한 쓰기 액세스 권한을 부여해야 합니다.서비스는 컨테이너를 공유 Docker 네트워크에 배치하여 게시되며, 이를 통해 NPM이 내부적으로 요청을 프록시할 수 있습니다. 이는 서비스가 호스트에 직접 포트를 노출할 필요가 없음을 의미하며 보안을 강화합니다. 동일한 VPS에 있는 자체 호스팅 프록시 게이트웨이는 트래픽을 NPM으로 다시 라우팅하며, 이는 VPS의 공용 IP에서 들어오는 HTTPS로 나타납니다. 이 게이트웨이의 동작은 처음에 라우팅 오류로 오인되었지만 보안 설계에 필수적입니다.NPM은 게이트웨이의 내부 Docker IP 또는 VPS의 공용 IP에서 오는 요청만 허용하는 Nginx 구성 블록을 사용하여 액세스 제어를 시행하며, 그 뒤에 기본 HTTP 인증이 따릅니다. 이를 통해 서비스가 공개적으로 해석 가능하고 유효한 인증서를 가지고 있더라도 액세스가 제한됩니다. Let's Encrypt 챌린지에 대한 특정 위치는 인증서 유효성 검사에 필요한 대로 인터넷에 열려 있습니다. 게이트웨이의 관리 패널과 구성 배포 엔드포인트라는 두 개의 중요한 호스트는 전체 게이트웨이 통합 전에 액세스 가능해야 하므로 엄격한 액세스 제어에서 예외입니다.서비스가 사용자 연결 프로필에 서버 주소를 내장하고 잘못된 주소를 잘못 광고하는 문제가 발생했습니다. NPM은 X-Forwarded-For 헤더를 통해 실제 클라이언트 IP를 전달하므로, 서비스는 이 헤더를 자체 공용 주소로 해석하여 클라이언트가 잘못된 서버에 연결하게 되었습니다. 저자 자신의 테스트에서는 게이트웨이를 사용하여 항상 올바른 예상 주소를 제시했기 때문에 이 버그는 숨겨져 있었습니다. TLS 종료는 NPM에서 발생하며, NPM과 백엔드 컨테이너 간의 트래픽은 Docker 네트워크에서 암호화되지 않은 HTTP로 전송됩니다.