▲

IPv6는 NAT가 없다고 해서 보안에 취약하지 않다

 (johnmaguire.me)
4P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • IPv4가 NAT를 기본적으로 사용하기 때문에 더 안전하다는 주장은 보안과 주소 변환의 혼동에서 비롯됨
  • NAT(Network Address Translation) 은 보안 기능이 아니라 IPv4 주소 부족을 해결하기 위한 주소 절약 메커니즘임
  • NAT의 동작은 포트 매핑을 기반으로 여러 장치가 하나의 공인 IP를 공유하도록 하는 것에 불과함
  • 실제로 외부 트래픽을 차단하는 역할은 NAT가 아니라 상태 기반 방화벽(stateful firewall) 이 수행함
  • IPv6 환경에서도 기본적으로 방화벽이 비인가 트래픽을 차단하므로, NAT의 부재가 보안 약화를 의미하지 않음

NAT와 보안의 혼동

  • IPv4가 NAT를 사용하기 때문에 더 안전하다는 주장은 잘못된 인식임
    • NAT는 보안 기능이 아니라 주소 절약(address conservation) 을 위한 기술임
    • IPv6에서도 NAT를 사용할 수 있지만, 그것이 보안을 강화하지는 않음
  • NAT는 내부 네트워크의 여러 장치가 하나의 공인 IP 주소를 공유하도록 함
    • 패킷의 목적지 포트를 기반으로 목적지 IP를 재작성(rewrite) 하여 라우팅 수행
    • 네트워크 관리자가 설정한 포트 매핑(port mapping) 또는 포트 포워딩(port forwarding) 규칙에 따라 동작

NAT의 실제 동작 방식

  • NAT 환경에서 외부에서 들어오는 트래픽은 예상치 못한 목적지 포트를 가진 경우 내부 장치로 전달되지 않음
    • 이러한 트래픽은 공인 IP를 가진 장치에 머무르며, 내부 네트워크로 라우팅되지 않음
  • 이로 인해 NAT가 외부 접근을 차단하는 것처럼 보이지만, 이는 부수적인 결과일 뿐 보안 설계 목적이 아님

방화벽의 역할

  • NAT가 제공한다고 오해되는 보안 효과는 사실상 상태 기반 방화벽(stateful firewall) 에서 비롯됨
    • 대부분의 현대 라우터는 NAT 여부와 관계없이 기본적으로 인바운드 트래픽을 차단하는 방화벽 정책을 포함
    • 방화벽은 패킷을 재작성하거나 라우팅하기 전에 예상치 못한 목적지 트래픽을 폐기(drop) 함
  • 예시로 UniFi 라우터의 기본 IPv6 방화벽 규칙은 다음과 같음
    • Established/Related 트래픽 허용 (아웃바운드 응답 트래픽)
    • Invalid 트래픽 차단
    • 그 외 모든 트래픽 차단

IPv6 환경에서의 보안

  • IPv6 네트워크에서도 기본 방화벽 규칙이 비인가 인바운드 트래픽을 차단함
    • NAT를 사용하지 않아도 동일한 수준의 보호가 적용됨
  • 외부에서 IPv6 장치로 비요청 트래픽을 허용하려면 명시적으로 방화벽 규칙을 추가해야 함
    • 이는 NAT 사용 여부와 무관하게 동일하게 적용됨

결론

  • IPv6가 NAT를 사용하지 않는다는 이유로 보안이 약화된다는 주장은 근거 없음
  • 실제 보안은 NAT가 아닌 방화벽 정책과 트래픽 제어 규칙에 의해 결정됨
  • IPv6 환경에서도 적절한 방화벽 설정을 통해 기본 거부(default-deny) 보안 전략을 유지할 수 있음
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 토론에 참여하기 전에 RFC 4787의 섹션 5를 살펴보길 권함
    NAT는 방화벽이 아님에도 불구하고 트래픽을 필터링하며, 그로 인해 일정 수준의 보안 기능을 제공함
    현실에서는 NAT가 단순 주소 변환을 넘어 발전해왔으며, IPv6가 NAT를 사용하지 않아도 방화벽으로 동일한 필터링을 구현할 수 있음

    • RFC 4787은 실제 구현과는 다름. 대부분의 SOHO 라우터는 Linux 기반이므로, netfilter 기반 NAT의 동작을 논의하는 게 현실적임
      Linux netfilter는 NAT와 방화벽을 모두 구현하며, nat 테이블의 DNAT/SNAT 규칙은 NAT, filter 테이블의 REJECT/DROP 규칙은 방화벽 역할을 함
      NAT 규칙만 적용된 경우에는 기존 연결에 속하지 않은 트래픽도 그대로 통과시킴
    • RFC 4787의 해당 섹션은 아웃바운드 연결에 대한 설명임
      NAT가 외부로 나가는 연결을 만들 때 상태 테이블을 생성하고, 그에 대응하는 인바운드 패킷을 허용하는 과정을 다룸
      즉, 이 문서의 “filtering”은 비요청 인바운드 연결을 의미하지 않음
    • IPv6가 NAT가 없어도 덜 안전한 건 아니지만, 기본 설정(defaults) 이 중요함
      IPv6도 IPv4만큼 안전할 수 있지만, 설정에 따라 달라짐
    • 30년 IT 경력상 NAT 환경은 게으른 설계를 유도함
      시스템과 애플리케이션 엔지니어들이 문제를 전체적으로 이해하지 않고, NAT와 경계 방화벽에 의존하는 것은 나쁜 보안 습관임
    • RFC가 항상 절대적인 기준은 아님
      특히 실제 구현과 멀어질수록 RFC의 신뢰성은 떨어짐

  • 미국의 모바일 네트워크에서는 NAT 없이도 IPv6 주소를 사용함
    예를 들어 T-Mobile은 464XLAT로 IPv4를 IPv6 위에 터널링함
    이는 NAT 없이도 대규모로 상태 기반 방화벽이 운영될 수 있음을 보여줌

    • 핀란드의 Elisa 네트워크에서는 IPv6 인바운드 TCP 연결이 잘 작동함
      Termux와 netcat으로 테스트했으며, IPv4는 CGNAT 뒤에 있지만 IPv6는 직접 연결 가능했음
    • “스마트폰이 서버로 동작하지 못하게 하는 이유”가 궁금함
    • 개인 기기에서 데이터를 직접 제공할 수 있어야 한다는 건 자연스러운 권리라고 생각함
      네트워크 용량이 부족하다면 그걸 해결해야 함
      IPv6이 보편화되면 사람들은 직접 통신하는 것이 당연해질 것임
    • 핫스팟을 사용할 때 클라이언트 PC가 같은 IPv6 주소를 받는지 궁금함
    • 모바일 기기는 샌드박스 환경으로 제한되어 있음

  • 네트워크 엔지니어로서 처음 배운 것은 NAT와 보안의 관계였음
    IPv4의 사설 주소(192.168.0.1) 는 외부에서 접근하기 어렵지만, IPv6의 글로벌 주소는 장치 정보를 노출시킬 수 있음
    IPv6에는 Prefix Translation 같은 대안이 있어, NAT의 장점을 일부 유지하면서도 투명한 접근이 가능함

    • IPv4의 사설 주소와 IPv6의 글로벌 주소를 비교하는 건 불공정함
      둘 다 내부 혹은 외부 주소로 맞춰야 공정한 비교가 가능함
      CGNAT 환경에서는 인바운드 연결이 불가능하므로 IPv6에서도 동일한 방식으로 제한할 수 있음
    • 내부 주소가 유출돼도 실제 공격 지점은 인터넷 경계 방화벽임
      NAT66으로 프리픽스를 숨길 수 있지만, 실질적 보안 이점은 크지 않음
    • 192.168.0.1은 너무 쉽게 접근 가능했음 (농담 섞인 말투)
    • NAT66은 “필요악”이지만, 특정 상황에서는 최선의 선택일 수 있음

  • 많은 해커들이 NAT와 방화벽의 차이를 혼동함
    NAT는 보안을 위한 것이 아니며, 보안은 방화벽이 제공함

    • NAT와 방화벽의 차이를 이해하지만, 현실에서는 둘이 함께 동작함
      NAT는 네임스페이싱, 방화벽은 정책 기반 보안임
      네임스페이싱 자체도 공격자가 리소스를 “이름조차 모르게” 만드는 강력한 보안 속성임
      IPv6 방화벽은 한 줄의 잘못된 규칙으로 전 세계에 노출될 수 있음
    • NAT는 외부 접근을 차단하므로 실질적인 보안 효과가 있음
      방화벽 없이도 NAT만으로 내부 자원을 보호할 수 있음
      NAT는 가정용 네트워크의 공격 표면을 라우터 하나로 줄여줌
    • NAT는 대부분의 사용자가 원하는 동작을 기본값으로 제공함
      반면 방화벽은 기본 설정이 다를 수 있어 오히려 IPv6가 일반 사용자에게는 보안 후퇴로 느껴짐
    • 소비자용 NAT는 사실상 기본 차단 방화벽과 동일한 동작을 함
      UPnP가 NAT의 보안을 깨뜨린다고 주장하는 건, PCP가 방화벽을 깨뜨린다고 말하는 것과 같음
    • 대칭 NAT나 CGNAT은 방화벽이 아니지만, 현실적으로는 비슷한 효과를 냄

  • NAT의 기본 차단 특성이 IPv4 보안의 장점이라는 주장에 대해
    IPv6의 기본 차단 규칙이 동일한 보안 수준을 제공하므로, 구조적 보안 차이는 없음

    • “내재적 보안”이라는 개념은 의미가 없음
      IPv4 NAT와 IPv6 기본 차단 규칙은 동일한 불변 조건을 유지함
      둘 다 잘못된 설정 시 동일하게 취약해질 수 있음

  • NAT가 있다고 방심했다가 IPv6 방화벽 미설정으로 SBC가 해킹당한 경험이 있음
    NAT가 아닌 IPv6 설정 오류가 원인이었음

    • IPv6 주소 공간이 너무 커서 전체 스캔은 불가능한데, 공격자가 어떻게 주소를 알아냈는지 궁금함
    • 꽤 당황스러운 실수였음

  • NAT도 보안 문제를 일으킴
    리플렉션 공격이나 주소-엔드포인트 분리로 인한 추적 어려움이 생김
    과거 AOL이 소수의 egress 주소를 공유해 일부 사용자 차단이 어려웠던 사례가 있음

    • RFC 1631에 따르면 NAT는 “보안 제공 옵션을 줄인다”고 명시되어 있음
      하지만 시간이 지나면서 NAT가 보안 신앙(cargo cult) 처럼 여겨지게 되었음

  • ISP와 라우터 설정에 따라 NAT의 효과가 달라짐
    NAT는 의도된 보안 기능은 아니지만, 부수적 보안 효과를 제공함
    IPv6에서는 각 장치가 직접 주소를 받으면 기본 차단 방화벽이 필요함

    • 대부분의 라우터는 IPv6에서도 기본 차단을 적용하지만, UPnP 같은 자동 포트 포워딩 기능이 이를 무력화할 수 있음
      UPnP 명세 링크
    • IPv6에서도 인바운드 차단은 IPv4와 동일하게 작동함
    • NAT를 꺼도 동일하게 접근 불가능하다면, NAT 자체가 아니라 라우팅 설정이 원인일 수 있음
    • IPv6 NAT를 사용하는 경우는 드물며, fc00::/7 주소를 NAT하는 건 특이한 사례임
    • ISP가 단 하나의 IPv6 주소만 제공하는 건 비정상적 구성임. 최소 /56은 제공해야 함

  • NAT가 보안의 근거라고 주장하는 사람은 네트워크를 잘 모른다는 말에

    • “그건 과한 일반화”라며, NAT가 보안이 될 수는 없지만 완전히 무시할 것도 아님
    • 자신이 IPv6 전문가라며, 2008년부터 IPv6 운영 경험이 있다고 밝힘
      당시 프라이버시 주소 누적 문제로 SIP 서버가 실패했던 사례를 공유함
      관련 토론은 Reddit VOIP 스레드에서도 여전히 유효함

  • NAT가 인바운드 트래픽을 드롭하지 않는다는 주장에 대해
    NAT는 단순히 주소 변환만 수행하며, 패킷을 드롭하지 않음

    • 하지만 라우터 설정에 따라 egress 인터페이스에서 들어오는 트래픽을 명시적으로 차단하는 경우가 많음
    • NAT가 패킷을 드롭하지 않더라도, 목적지 IP가 라우터 자신이라면 결국 라우팅되지 않음
      이 피드백을 반영해 글을 수정했다고 함
답변달기