공개 주소 공간과 사설 주소 공간
공개 IP
192.0.2.10
전역에서 고유, 어디서나 라우팅 가능
사설 대역
공개 인터넷에서는 라우팅 불가
사설 IP 대역이 공개적으로 확인되어서는 안 되는 이유
RFC 1918은 세 개의 IPv4 대역인 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 사설 네트워크 내부용으로 따로 정해 두었습니다. 모든 사설 네트워크의 모든 기기가 전 세계에서 고유한 주소를 가질 만큼 공인 IPv4 주소가 충분하지 않기 때문입니다. 이 대역들은 전 세계 수백만 개의 무관한 네트워크 안에서 동시에 재사용됩니다. 여러분의 집 공유기도 거의 확실히 192.168.x.x 주소를 나눠 주며, 다른 사람들의 공유기도 마찬가지입니다.
공개 도메인이 이 대역으로 확인된다는 것의 의미
이 주소들은 질의하는 로컬 네트워크 안에서만 의미가 있으므로, 이 대역으로 확인되는 공개 도메인은 기껏해야 설정 오류이고, 최악의 경우 공개 시스템이 자신의 내부 네트워크에서 그 주소에 있는 무엇이든 요청하도록 만들려는 의도적인 시도입니다. 공용 인터넷은 10.0.0.5가 무엇을 가리키는지 일관되게 알지 못합니다. 어느 네트워크가 묻느냐에 따라 전혀 다른 컴퓨터입니다.
| 대역 | 이름 | 차단되는 이유 |
|---|---|---|
| 10.0.0.0/8 | 사설(RFC 1918) | 수백만 개의 무관한 네트워크 내부에서 재사용됨 |
| 172.16.0.0/12 | 사설(RFC 1918) | 위와 같음 |
| 192.168.0.0/16 | 사설(RFC 1918) | 위와 같음. 가정용 공유기에서 흔한 대역 |
| 127.0.0.0/8 | 루프백 | 질의하는 컴퓨터 자신을 가리킴 |
| 169.254.0.0/16 | 링크 로컬 | 클라우드 메타데이터 엔드포인트인 169.254.169.254 포함 |
| 100.64.0.0/10 | 공유 주소 공간(RFC 6598) | 통신사급 NAT. 직접 만든 차단 목록에서 자주 빠짐 |
| 0.0.0.0/8 | 미지정 | 라우팅 가능한 실제 목적지가 아님 |
| 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | 문서화용 대역 | 예시용으로 예약되었으며 실제로 사용되도록 의도되지 않음 |
- 정상적인 공개 도메인이 사설 대역 주소로 확인될 이유는 전혀 없습니다. 그런 결과를 본다면 정상적인 결과가 아니라 조사할 가치가 있는 신호로 취급하세요.
- IPv6에도 이에 해당하는 사설/예약 대역이 있으며, 고유 로컬 주소(fc00::/7)와 링크 로컬(fe80::/10)은 똑같이 처리해야 합니다.
공개용처럼 보이는 도메인이 항상 공개용처럼 보이는 주소로 확인되리라 믿는 대신 확인 시점에 이 대역들을 걸러 내는 것은, 사용자를 대신해 도메인을 확인하는 모든 도구에 대한 기본적인 기대 수준입니다.
대부분의 차단 목록이 잊는 대역
100.64.0.0/10은 RFC 6598이 정의한 "공유 주소 공간"으로, 공용 인터넷에서 똑같이 라우팅될 수 없는데도 10.0.0.0/8이나 192.168.0.0/16만큼의 인지도는 전혀 얻지 못합니다. 이 대역은 통신사급 NAT를 위해 존재하며, ISP가 연결마다 공인 IPv4 공간을 소모하지 않고 내부적으로 많은 고객 연결에 주소를 부여할 수 있게 해 줍니다. 고전적인 RFC 1918 대역보다 새롭고 덜 알려져 있기 때문에, 직접 만든 차단 목록에서 가장 흔히 빠지는 대역입니다. 누군가 의도적으로 도메인이 그 안의 주소를 가리키게 해 보고서야 드러나는 종류의 허점입니다.
"실패 시 차단(fail closed)"은 목록만큼이나 중요합니다
차단 목록은 주소를 아예 파싱할 수 없을 때 어떻게 동작하느냐에 따라 그 가치가 정해집니다. 잘못된 형식의 입력, 특이한 표기, 알려진 어떤 대역과도 깔끔하게 일치하지 않는 값은 기본적으로 "아마 괜찮을 것"으로 취급해서는 안 됩니다. 안전한 기본값은 알려진 불량 대역에 확실히 일치하는 주소만 거부하는 것이 아니라, 공인 주소라고 확신을 가지고 분류할 수 없는 것은 모두 거부하는 것입니다. 이러한 "실패 시 차단" 태세가 차단 목록이 이미 올라 있는 잘 알려진 대역뿐 아니라 아무도 아직 추가할 생각을 못 한 대역에 대해서도 견고함을 유지하게 해 줍니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
이 주제의 무료 도구
관련 글
SSRF는 서버를 의도치 않은 프록시로 만듭니다
공격자
요청 URL 조작
취약한 서버
SSRF에 속아 가져옴
169.254.169.254
메타데이터 엔드포인트
자격 증명
공격자에게 반환
클라우드 메타데이터 엔드포인트, 숨은 공격 표면
라우팅되지 않을 것처럼 보이는 IP 주소 하나가 클라우드 인스턴스의 자격 증명과 설정으로 이어지며, SSRF의 단골 표적이 됩니다.
같은 주소를 쓰는 네 가지 방법
SSRF 공격 설명: DNS는 어떻게 악용될까
서버 측 요청 위조(SSRF)는 서버가 속아서 확인하고 요청해 버린, 평범해 보이는 도메인 이름 하나에서 시작되는 경우가 많습니다.
같은 도메인, 서로 다른 두 가지 응답
첫 번째 요청
공개 IP로 확인됨
검증
통과, 안전해 보임
TTL 만료
몇 초 후
두 번째 요청
127.0.0.1로 확인됨
DNS 리바인딩이란 무엇이며 왜 신경 써야 할까요?
처음에는 안전한 주소로, 나중에는 내부 주소로 확인되는 도메인. DNS 리바인딩은 DNS 자체를 공격 표면으로 바꿉니다.