마이크로소프트가 WINS(Windows Internet Name Service) 사용을 오는 2034년까지 중단하라고 안내했다. 하지만 9년이라는 유예 기간조차 충분하지 않을 것이라는 지적이 나온다. WINS는 현재도 교체하기 까다로운 일부 레거시 시스템에서 여전히 핵심 기능을 담당하고 있기 때문이다.

WINS는 1994년 윈도우 NT 시대에 등장한 기술로, 이후 DNS(Domain Name System)이 표준으로 자리 잡으며 점차 자리를 내줬다. 마이크로소프트는 윈도우 서버 2022 출시 시점인 2021년에 WINS를 공식 폐기(deprecate) 대상으로 지정했다. 이는 유지보수는 하되 기능 개발은 중단한다는 뜻으로, 사실상 퇴출 시계가 돌아가기 시작했음을 의미했다.

마이크로소프트는 WINS를 지원하는 마지막 운영체제가 윈도우 서버 2025라고 발표했다. 이 운영체제가 LTSC(Long-Term Servicing Channel)에서 제공되는 기간이 9년이므로, 2034년이 사실상 최종 마이그레이션 시한으로 정해진 셈이다.

마이크로소프트는 11월 초 윈도우 메시지 센터 공지를 통해 “WINS를 사용하는 조직은 DNS 기반의 현대적 방식으로 마이그레이션하는 것을 권한다”라고 전했다.

또한 마이크로소프트는 이번 일정이 충분히 여유 있는 편이라고 설명했다. 회사는 “계획을 세우고 이전 작업을 진행하는 과정을 최대한 예측 가능하고 부담 없이 만들고자 한다. 충분한 사전 고지와 지원 기간을 제공함으로써 각자의 속도에 맞춰 환경을 현대화할 수 있을 것”이라고 덧붙였다.

수년 전부터 이어진 WINS 제거 움직임

마이크로소프트는 앞으로 출시될 윈도우 버전에서 WINS를 제외하면서 WINS 서버 역할과 관련 바이너리, WINS용 MMC(Microsoft Management Console) 스냅인, 자동화 API와 관련 관리 인터페이스도 운영체제에서 빠질 것이라고 설명했다.

WINS 마이그레이션은 1980~1990년대 네트워크 기술이 빠르게 발전하던 시기에 탄생한 유산이다. 당시 업계는 수많은 네트워크 문제를 서둘러 해결해야 했고, DOS나 윈도우 같은 데스크톱 운영체제를 실용적인 서버 플랫폼으로 바꾸는 방법을 찾는 데 집중했다.

당시 WINS는 중요한 과제를 해결했다. 1980년대 넷바이오스(NetBIOS) 네트워크 이름 체계를 통해 컴퓨터를 식별하던 방식과 이후 등장한 IP 주소 기반 체계를 연결하는 역할을 했다. 인터넷과 사설 네트워크 모두에 적용할 수 있는 계층형 구조의 DNS가 등장하면서 넷바이오스는 사실상 시대에 뒤처졌지만, 두 기술은 한동안 공존했다. 같은 문제에 대해 서로 다른 해결책이 산업 전반에 동시에 존재했던 셈이다.

오늘날 WINS를 걷어내야 한다는 주장에는 구식 기술이라는 이유만 있는 것이 아니다. 보안 위험도 주요한 근거로 꼽힌다. 2017년, 포티넷(Fortinet) 산하 포티가드 랩(FortiGuard Labs)은 윈도우 서버 2008·2012·2016 버전의 WINS 서버에서 원격 메모리 손상 취약점을 발견했다.

당시 마이크로소프트가 포티넷에 보낸 답변은 의미심장했다. 회사는 “포괄적인 수정을 하려면 코드를 전면 재작성해야 한다. WINS가 제공하던 기능은 이미 DNS로 대체됐고, 마이크로소프트는 고객에게 WINS에서 벗어나기를 권고했다”라고 적었다.

즉, 마이크로소프트는 해당 결함을 패치할 계획이 없었다. 회사가 제시한 해결책은 WINS를 완전히 걷어내고 다른 방식으로 마이그레이션하는 것이었고, 일부 조직은 이 작업을 2030년대까지 이어갈 가능성이 있다는 점이 그동안 드러났다.

WINS가 여전히 사용되는 이유

WINS를 계속 사용하는 조직은 대체로 두 부류로 나뉜다. 운영기술(OT) 시스템처럼 수명이 길고 교체하기 어려운 오래된 기술을 지원하는 경우, 그리고 WINS에 의존하고 있다는 사실을 조직 내부에서 거의 잊고 있는 경우다.

영국 보안 컨설팅 업체 브라이드웰(Bridewell)에서 보안 엔지니어링을 총괄하는 키어런 바드와즈는 “WINS·넷바이오스를 중심으로 구축된 OT 환경에서 이를 교체하는 작업은 단순하지 않다. 이름 확인 방식이 바뀌면 안전에 직결되는 시스템과 맞춤형 통합 구조에 영향을 주기 때문”이라고 설명했다.

레거시 기술이 사라지지 않는 이유도 같은 맥락이다. 바드와즈는 “산업·OT 환경처럼 일부 특수 시스템은 기본적으로 수십 년을 전제로 설계된다. 많은 제어 시스템이 구조적으로 고정돼 있어 다른 플랫폼으로 옮길 수 없다. 마이크로소프트 입장에서도 WINS 제거는 쉽지 않다. WINS는 네트워크 스택 깊숙이 자리 잡은 핵심 구성 요소였기 때문에 이를 없애려면 예기치 않은 결함을 막기 위한 광범위한 회귀 검증이 필요하다”라고 말했다.

클로즈드 도어 시큐리티(Closed Door Security)에서 침투 테스트를 담당하는 윌리엄 라이트는 또 다른 이유로 여러 레거시 기술이 제 역할을 다한 뒤에도 오래 남는 것처럼, WINS 역시 비슷한 이유로 일부 네트워크에서 계속 작동하고 있다고 지적했다. 핵심은 마이그레이션에 대한 무관심이다.

라이트는 “지금 WINS를 돌리는 조직 대부분은 이를 핵심 업무에 활용하지 않는다. 그저 끌어야 할 이유를 못 찾았을 뿐이다. WINS는 백그라운드에서 조용히 복제 작업을 이어가며 자원을 거의 쓰지 않고, 눈에 띄는 문제도 일으키지 않는다. 레거시 인프라의 특징이 바로 이런 점이다. 꼭 필요해서가 아니라, 제거하려면 노력이 들고 위험 부담이 생기기 때문에 그대로 두는 것이 더 쉽다”라고 설명했다.

WINS는 보안 위험

라이트는 WINS가 태생적인 설계 한계를 안고 있어 보안 측면에서 큰 위험 요소가 된다며 “WINS는 이름 등록의 적법성을 검증하는 메커니즘이 없다. 이 때문에 스푸핑 공격에 쉽게 노출된다”라고 지적했다.

이어 “공격자는 네트워크 안에서 악성 항목을 마음대로 등록할 수 있다. WPAD(Web Proxy Auto-Discovery) 레코드를 추가해 웹 트래픽을 가로채거나, 자신이 통제하는 시스템으로 연결을 우회시키는 방식도 가능하다. 이런 공격은 내부망에서 측면 이동을 시도하기에 매우 손쉬운 경로가 된다”라고 설명했다.

네트워크에 WINS가 여전히 활성화된 상태로 남아 있는 것은 공격자에게 ‘선물’과도 같다. 공격자는 오픈소스 도구인 리스펀더(Responder)를 활용해 이름 확인 정보를 오염시키는 공격을 수행할 수 있기 때문이다. 이런 공격은 LLMNR(Link-Local Multicast Name Resolution)이나 NBT-NS(NetBIOS Name Service) 같은 레거시 윈도우 프로토콜을 노릴 때 특히 효과적이다.

더 큰 문제는 WINS가 존재한다는 사실 자체가, 해당 조직이 다른 취약한 레거시 프로토콜도 함께 사용하고 있을 가능성을 시사한다는 점이다. 라이트는 “WINS가 없으면 시스템은 종종 넷바이오스 브로드캐스트 질의로 되돌아가는데, 이 방식은 로컬 네트워크에서 손쉽게 스푸핑할 수 있다. 리스펀더 같은 도구가 바로 이 취약점을 악용한다. 이는 침투 테스트뿐 아니라 실제 공격에서도 여전히 흔하게 활용되는 기법”이라고 설명했다.

WINS 제거의 첫 단계는 네트워크 인벤토리 점검

브라이드웰의 바드와즈는 WINS를 제거하려는 조직이 가장 먼저 해야 할 일로 네트워크 인벤토리 조사를 꼽았다. 바드와즈는 “많은 조직이 레거시 자산이 아직도 WINS에 의존하고 있다는 사실을 제대로 파악하지 못한다. 구형 네트워크 구간이나 OT·ICS 환경을 선제적으로 조사하고, 다음 업그레이드 시점 전에 이름 확인 경로를 반드시 검증해야 한다”라고 조언했다.

또한 바드와즈는 WINS를 계속 사용하는 조직이라면 그만큼 더 많은 준비가 필요하다며 “DNS로 마이그레이션하려면 의존성을 점검하고, 레거시 워크로드를 현대화하거나 격리하고, DNS를 구축하는 과정이 필수다. 그 결과로 따라오는 것은 더 단순하고 안전한 플랫폼”이라고 말했다.

결국 가장 뛰어난 기술도 시간이 지나면 레거시가 될 수밖에 없다. WINS에서 벗어나는 과정은 각 조직이 이런 더 큰 문제를 얼마나 잘 다루고 있는지 보여주는 시험대다. 바드와즈는 “사용하지도 않으면서 공격 표면만 넓히는 레거시 기술이 너무 많다”라고 지적했다.

dl-itworldkorea@foundryco.com