# 내부 호스트명이 클라우드에 유출될 때 > Clean Markdown view of GeekNews topic #26443. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26443](https://news.hada.io/topic?id=26443) - GeekNews Markdown: [https://news.hada.io/topic/26443.md](https://news.hada.io/topic/26443.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-06T09:46:47+09:00 - Updated: 2026-02-06T09:46:47+09:00 - Original source: [rachelbythebay.com](https://rachelbythebay.com/w/2026/02/03/badnas/) - Points: 1 - Comments: 1 ## Topic Body - 가정용 **NAS 장비**의 웹 인터페이스가 내부 전용 호스트네임을 외부 서비스로 전송하는 사례 발견 - NAS 웹 UI에 포함된 **sentry.io 오류 보고 스크립트**가 스택 트레이스와 함께 내부 호스트네임을 외부로 전송 - sentry.io 측에서 해당 호스트네임으로 **TLS 연결을 역으로 시도**하지만 실제 요청은 보내지 않는 이상한 동작이 관찰됨 - 와일드카드 DNS를 미리 설정해 둔 덕분에 **유출 사실을 탐지**할 수 있었으며, 민감한 호스트네임 사용 시 심각한 정보 노출 위험 존재 - 이 메커니즘을 악용하면 **임의의 호스트에 대한 DNS 스캔**을 유도할 수 있는 잠재적 보안 문제 --- ### NAS 설치와 내부 호스트네임 구성 - NAS 장비를 구매해 드라이브를 장착하고 홈 네트워크에 연결, **HTTPS 모드**로 운영 - 공개 인터넷에서 의미 없는 도메인의 하위 서브존(예: `*.nothing-special.whatever.example.com`)에 대한 **와일드카드 TLS 인증서**를 설치 - `/etc/hosts` 파일에 `172.16.12.34 nas.nothing-special.whatever.example.com`과 같은 **로컬 전용 항목**을 추가하여 브라우저에서 접근 ### 외부로부터의 예상치 못한 접속 발견 - NAS 설치 며칠 후, 동일한 호스트네임으로 **외부("outside world")에서 요청**이 들어오기 시작 - 해당 호스트네임은 노트북의 `/etc/hosts` 파일에만 존재하는 **완전히 내부 전용 이름** - 사전에 `*.nothing-special.whatever.example.com` 전체에 대해 자신이 관리하는 머신으로 향하는 **와일드카드 DNS 항목**을 설정해 두었기 때문에 유출을 탐지 가능 - NAS를 로드할 때마다 **GCP 호스트**가 해당 내부 호스트네임을 SNI로 제시하며 접속을 시도 ### 유출 원인: sentry.io 오류 보고 - NAS 웹 인터페이스에 **폰홈(phone home) 기능**이 포함되어 있으며, 그 일부로 **sentry.io**에 스택 트레이스를 전송 - 브라우저가 sentry.io에 콜백하면서 내부 스토리지 장비에 사용하는 **호스트네임을 함께 전달** - sentry.io 측에서 해당 호스트네임으로 **TLS 연결을 역으로 생성**하지만, 실제 HTTP 요청은 전혀 보내지 않는 동작 확인 ### 보안 시사점과 대응 - 호스트네임에 민감한 정보(예: `mycorp-and-othercorp-planned-merger-storage` 같은 이름)를 포함할 경우 **심각한 정보 유출** 위험 - 이 sentry 보고 메커니즘을 이용해 **임의의 외부 호스트에 대한 DNS 스캔을 유도**하는 것이 가능(구체적 방법은 독자에게 맡김) - 대응 조치로 **Little Snitch**를 실행해 해당 도메인 전체를 모든 앱에 대해 차단 처리 ## Comments ### Comment 50701 - Author: neo - Created: 2026-02-06T09:46:47+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46895972) - 사람들이 오해하고 있는 것 같음. 이건 **CT 로그** 문제가 아니라 **와일드카드 인증서** 관련임 Sentry가 클라이언트 측 트레이스를 수집하면서 요청을 보낸 호스트명을 추출해 그걸 다시 폴링하려다 거부당한 상황임 - 아마도 트레이스 UI에서 보여줄 **favicon**을 가져오려는 시도였을 수도 있음 - 하지만 이런 구조라면 Sentry가 임의의 IP로 요청을 보낼 수 있는 **보안 취약점**이 생길 수 있음. 특히 자동으로 악성 트래픽을 신고하는 IP에 반복적으로 접근할 수도 있음 - 사람들이 헷갈리는 이유는 블로그 글이 너무 **혼란스럽고 불명확하게 작성**되어 있기 때문임 - 호스트명은 본질적으로 **비공개 정보가 아님** DNS 쿼리나 TLS 인증서 등 여러 경로로 외부에 노출됨 비공개 서비스를 숨기려면 호스트명 대신 **URL 경로**에 비밀을 넣는 게 나음 예시로 `fileservice.example.com/my-hidden-service-007-abc123/`처럼 하면 HTTPS로만 전달되어 노출이 훨씬 적음 - 물론 이 경우에도 Sentry 같은 외부 서비스로 경로가 전송될 수 있으므로, **불투명한 URL**을 쓰고 비밀을 URL에 넣지 않는 습관이 필요함 - “HTTP만 쓴다면 이런 노출이 줄어드나?”라는 질문도 있었음 - “**clown GCP Host**”가 기술 용어인지 궁금했음. 알고 보니 작성자가 **cloud를 풍자**해서 쓴 표현이었음 NAS 웹 인터페이스가 Sentry로 로그를 보내면서 내부 호스트명이 포함된 게 문제의 핵심임 나는 이런 경우 **신뢰할 수 있는 오픈소스 OS**로 교체하거나, **PiHole** 같은 DNS 차단으로 Sentry 호출을 막을 것 같음 - “clown”은 Big Tech의 **cloud를 비꼬는 표현**으로, 예전 IRC에서도 “clown computing”이란 말을 썼다고 함 어떤 이는 로컬 DNS와 **TLS 프록시**를 써서 외부로 나가는 트래픽을 완전히 차단한다고 설명함 - 또 다른 사람은 “clown”이 **대형 클라우드 제공자와 그 사용자**를 풍자하는 오래된 용어라고 덧붙였음 - 어떤 이는 “clown” 대신 “**weenie**”라는 단어를 쓰기도 한다고 농담함 - “서커스는 떠났지만 **광대들은 남았다**”는 식의 유머도 있었음 - 이런 사례 때문에 나는 **uBlock Origin**을 웹 보안의 최소 기준으로 봄 대부분의 웹페이지가 제3자 스크립트를 잔뜩 불러와 데이터를 새는 게 너무 심각함 근본적인 해결은 아니지만, 당장 우리가 할 수 있는 최선임 - 나도 **AdGuard Home**을 라우터에 설치했는데 트래픽의 15~20%가 차단됨. 추적과 광고가 얼마나 심한지 실감함 - 이런 문제를 막으려면 **Nginx 리버스 프록시**를 앞단에 두고 **CSP 헤더**를 주입하는 게 좋음 이렇게 하면 NAS가 외부로 요청을 보내는 건 막지 못하지만, 브라우저가 대신 요청하는 건 차단 가능함 예를 들어 Steam 아바타 요청(`https://avatars.steamstatic.com/HASH_medium.jpg`)도 CSP 정책으로 막을 수 있음 필요하면 일부만 열어두면 됨. 또 **Referrer-Policy: no-referrer**를 추가해 호스트명이 외부 로그에 남지 않게 함 - 누군가는 “ATM machine”이라며 중복 표현을 지적했고 - 또 다른 사람은 “**NPM은 꽤 간단함**”이라며 농담처럼 답했음 - 나는 **Synology NAS**를 샀는데 여러 번 후회했음 커뮤니티 소프트웨어 외에는 할 수 있는 게 거의 없음 **Let's Encrypt**로 SSL 적용도 복잡하고, 경로가 비표준이라 설정 위치를 찾기 힘듦 오래된 rsync 버전, 기본 유틸 부족 등 불만이 많음. 차라리 **리눅스나 BSD 기반 NAS**를 쓸 걸 그랬음 - Synology는 파일 서버로만 쓰면 **매우 안정적**이라 만족한다는 의견도 있었음. 다만 폐쇄적인 정책 때문에 **UniFi NAS**로 옮길 계획이라는 사람도 있었음 - “서버를 원하면서 NAS가 서버가 아니라고 불평하는 건 모순”이라는 반응도 있었음 - Synology NAS에 **최신 Debian**을 올리는 가이드가 [Doozan 포럼](https://forum.doozan.com/list.php)에 있다고 공유한 사람도 있었음 - “그냥 파일/iscsi 서버로만 두면 **매우 안정적**이니 건드리지 말라”는 조언도 있었음 - 반대로 RS217 모델을 $100에 사서 최고의 구매였다고 한 사람도 있었음. **Synology Office**를 Google Docs 대신 쓰고, UI 완성도에 감탄했다고 함 - 최근 Sentry를 설정해봤는데, 이 시스템이 **자동으로 업타임 모니터링**을 구성하려는 기능이 있음 호스트를 인식하면 주기적으로 핑을 보내고, 며칠 안정적으로 응답하면 “이 호스트에 업타임 모니터링을 설정할까요?”라는 알림을 띄움 - 누군가는 “**확장 기회**”라고 짧게 코멘트함 - 나는 개인적으로 **Sentry 관련 도메인 전체를 차단**함 일반적인 해결책은 아니지만 내 환경에서는 그게 최선임 - **역방향 주소 조회 서버**는 내부 네트워크 주소(ULA, RFC1918)까지도 해석하려는 시도를 종종 봄 이런 데이터를 다른 정보와 결합하면 내부 상태를 추론할 수 있음 “Darknet 수집 중 UDP 오디오가 포착된 적도 있다”고 함 - 이에 대해 “그 UDP 오디오는 어느 해의 **SIP 트래픽**이었는가?”라는 질문이 나왔음 - 예전에 **Heroku**에서 비슷한 현상을 조사했음 새 앱을 만들면 무작위 서브도메인이 부여되는데, DNS 조회를 하지 않아도 바로 **취약점 스캐너의 요청**이 들어옴 Heroku에 문의하니, 새 앱의 URL이 **인증서 투명성(CT) 로그**에 공개되기 때문이라고 함 - 누군가는 “이건 새 서비스마다 **‘나를 공격해 주세요’ 표지판**을 붙이는 셈”이라며, CT 로그에 실제 인증서 대신 **해시만 기록했어야 했다**고 지적함 [Certificate Transparency 작동 방식](https://certificate.transparency.dev/howctworks/) 링크도 공유함 - 또 다른 사람은 “나는 **와일드카드 도메인**을 써서 그런 문제를 피하고 있다”며 스크린샷([이미지 링크](https://i.postimg.cc/SQ82S0Dp/image.png))을 올렸음