윈도우 서버는 화면이 보이니 리눅스보다 다루기 편합니다. 그런데 바로 그 편의성 때문에 원격 데스크톱을 열어두고 쓰는 경우가 많아요. 문제는 이 RDP가 랜섬웨어 침투 경로로 가장 많이 지목되는 통로라는 점입니다. 관리 화면이 인터넷에 그대로 노출돼 있는 셈이니까요.
RDP를 그대로 열지 않는 방법
가장 확실한 건 RDP를 인터넷에 직접 노출하지 않는 것입니다. VPN으로 먼저 내부망에 들어온 뒤 접속하게 하면, 외부에서는 RDP 포트 자체가 보이지 않아요. 이것만으로 무작위 대입 시도가 사라집니다.
VPN 구성이 어렵다면 차선책이 있습니다. 방화벽에서 접속 허용 IP를 지정해 사무실이나 담당자 회선에서만 열어두는 방식이에요. 여기에 기본 포트 변경, 계정 잠금 정책(연속 실패 시 일정 시간 차단), 그리고 관리자 계정명을 기본값에서 바꾸는 조치를 더하면 훨씬 나아집니다.
다단계 인증을 붙일 수 있다면 그게 가장 강력합니다. 비밀번호가 유출돼도 한 겹이 더 남으니까요. 그리고 접속 계정에 굳이 관리자 권한을 줄 필요가 없다면 일반 권한으로 낮춰두세요. 뚫렸을 때 피해 범위가 완전히 달라집니다.
업데이트를 미루지 마세요
윈도우 서버는 재부팅이 필요한 업데이트가 많아서 미루기 쉽습니다. 하지만 취약점이 공개되면 공격 도구에 반영되는 속도가 훨씬 빨라요. 패치를 미루는 기간이 그대로 노출 기간이 됩니다.
현실적인 방법은 정기 점검 창을 미리 정해두는 것입니다. 트래픽이 적은 시간대를 골라 매달 고정 일정으로 잡아두면, 그때그때 판단하느라 미루는 일이 줄어듭니다. 중요한 서버라면 패치 전 스냅샷을 떠두고 진행하면 문제가 생겨도 되돌릴 수 있어요.
그리고 윈도우 서버에 기본 탑재된 백신 기능을 꺼두지 마세요. 성능 때문에 끄는 경우가 있는데, 필요하다면 특정 폴더만 검사에서 제외하는 방식으로 조정하는 게 맞습니다.
비밀번호 없이 침입했던 블루킵 사례
RDP 공격이라고 하면 비밀번호를 계속 대입하는 장면부터 떠올리기 쉬워요. 하지만 로그인 정보를 몰라도 원격 데스크톱 서비스의 결함을 이용하는 공격이 있었어요. 대표적인 사례가 2019년 공개된 블루킵(BlueKeep), 취약점 번호 CVE-2019-0708이에요. 당시 윈도우 서버 2008과 2008 R2 등이 영향을 받았고, 인증 전 단계에서 공격자가 코드를 실행할 수 있었어요. 사용자가 파일을 열거나 버튼을 누를 필요도 없었어요.
마이크로소프트는 2019년 5월 14일 보안 수정본을 배포했고, 같은 해 11월에는 이 취약점을 이용해 암호화폐 채굴 악성코드를 설치한 공격을 분석해 공개했어요. 당시 확인된 피해는 랜섬웨어가 아닌 암호화폐 채굴 악성코드 감염이었어요. 마이크로소프트는 확인된 채굴 공격을 설명하면서, 랜섬웨어를 이용한 다른 공격은 아직 검증되지 않았다고 밝혔어요. 실제 관찰된 피해와 앞으로 가능한 위험은 구분해서 이해해야 해요.
여기서 알아둘 용어가 네트워크 수준 인증(NLA)이에요. 원격 연결 과정에서 먼저 인증을 요구하는 보호 장치예요. 마이크로소프트는 블루킵에 대해 NLA가 일부 공격을 완화하지만, 공격자가 유효한 계정 정보를 가지고 있으면 여전히 악용할 수 있다고 설명했어요. 서버 설정에서 NLA 사용 여부를 확인하되, 이를 켰다는 이유로 해당 서버의 취약점 문제가 해결됐다고 판단하면 안 돼요.
서버 버전에는 보안 지원 종료일이 있어요
업데이트를 설치하는 습관과 별개로, 그 서버에 새 보안 수정본이 계속 나오는지도 확인해야 해요. 윈도우 서버 2012와 2012 R2의 연장 지원은 2023년 10월 10일 끝났어요. 운영체제가 정상적으로 부팅되고 업무 프로그램이 실행된다고 해서 제조사의 보안 지원까지 유지되는 것은 아니에요. 서버 목록에는 제품명과 버전뿐 아니라 지원 종료일, 종료 이후 적용 중인 보안 업데이트 제도도 함께 적어두는 게 좋아요.
지원 종료 후 이전 시간을 확보하는 제도가 확장 보안 업데이트(ESU)예요. 마이크로소프트 설명에 따르면 중요 및 긴급 등급의 보안 업데이트를 제공하지만, 새 기능이나 고객 요청에 따른 비보안 수정까지 포함하지는 않아요. 애저에서 운영하는 대상 서버에는 별도 ESU 비용 없이 제공되고, 애저 밖의 대상 서버에는 구매 방식이 있어요. 단순히 오래된 서버를 계속 사용할 수 있게 해주는 일반 지원 계약으로 생각하면 범위를 잘못 이해하기 쉬워요.
2012와 2012 R2의 ESU 종료 예정일은 2026년 10월 13일이에요. 2026년 8월 6일 기준으로 종료까지 약 두 달이 남아 있어요. 해당 버전을 쓰고 있다면 ESU 적용 상태를 확인하고, 지원되는 버전으로 이전할 계획도 잡아두세요. 마이크로소프트가 제시한 선택지는 새 서버를 구축해 애플리케이션과 데이터를 옮기거나, 지원되는 경로로 기존 서버를 업그레이드하는 방식이에요.
백업은 저장보다 복구 확인이 중요해요
침입을 막는 조치와 함께 서비스가 멈췄을 때 돌아올 방법도 준비해야 해요. 미국 사이버보안·인프라보안국(CISA)의 랜섬웨어 대응 가이드는 중요한 데이터의 암호화된 오프라인 백업을 유지하라고 권고해요. 일부 랜섬웨어는 접근 가능한 백업까지 찾아 삭제하거나 암호화하기 때문이에요. 백업 파일이 있다는 사실만 확인하지 말고, 운영 서버에서 그 사본에 접근할 수 있는지도 점검해야 해요.
같은 가이드는 재해 복구 상황을 가정해 백업의 가용성과 무결성을 정기적으로 시험하라고 설명해요. 관리 화면에 성공 표시가 뜨는지에 그치지 않고, 저장한 사본을 실제로 읽고 복원할 수 있는지 확인하는 과정이에요. 복구할 핵심 시스템의 운영체제와 업무 프로그램을 미리 구성한 표준 이미지도 권고하고 있어요. 데이터 사본과 서버를 다시 구성할 준비를 함께 갖추는 셈이에요.
복구 순서도 미리 정해두세요. CISA는 중요한 자산과 시스템 사이의 의존 관계를 파악해 서비스 복원 우선순위를 정하도록 안내해요. 어떤 데이터와 시스템이 매출이나 핵심 업무에 직접 연결되는지 목록으로 확인해두면 좋아요. 사고 뒤에는 깨끗한 시스템만 복구 환경에 연결해 재감염을 피하라는 권고도 있어요. 백업을 돌려놓는 작업과 침해된 환경을 정리하는 작업을 함께 준비해야 하는 이유예요.
이벤트 로그가 사고의 실마리입니다
윈도우는 로그인 성공과 실패를 이벤트 로그에 남깁니다. 사고가 났을 때 언제 어디서 들어왔는지 추적할 수 있는 거의 유일한 단서예요. 그런데 로그 보관 크기가 작게 잡혀 있으면 오래된 기록부터 덮어써져서, 정작 필요할 때 그 시점 기록이 없는 경우가 많습니다.
보안 로그의 최대 크기를 넉넉히 늘려두고, 가능하면 별도 서버로 로그를 모아두세요. 공격자가 침입 후 로그를 지우는 경우도 있는데, 외부에 복사본이 있으면 그것까지는 못 지웁니다.
평소에 어떤 로그인이 정상인지 감을 잡아두는 것도 도움이 됩니다. 업무 시간 외 접속이나 낯선 국가의 IP처럼 평소와 다른 패턴이 보이면 그때 확인할 수 있으니까요.
윈도우 서버 운영이 부담스러우시면 TIDC 서버관리 서비스를 살펴보세요. 원격 접속 구성부터 패치 일정, 로그 관리까지 전담 엔지니어가 맡아드립니다.
