[랜섬웨어 예방 가이드 ⑤] 리눅스 서버는 안전하다는 착각

[랜섬웨어 예방 가이드 ⑤] 리눅스 서버는 안전하다는 착각

[핵심요약] 리눅스는 상대적으로 안전하다는 믿음과 달리 킬린(Qilin)·아키라(Akira) 같은 조직이 SSH와 ESXi 가상화 인프라를 정조준하고 있어요. AI가 CVE 공개 후 익스플로잇 제작 시간을 10시간대로 앞당기면서, 패치를 며칠만 미뤄도 침해로 이어지는 시대가 됐어요.

지난 4화에서는 BitLocker로 OS 드라이브를 암호화해 해커가 데이터를 훔쳐가도 쓸모없게 만드는 법을 다뤘어요. 이번 5화에서는 "리눅스는 윈도우보다 안전하다"는 오래된 통념이 왜 유효하지 않은지, 리눅스·ESXi 서버를 노리는 실제 공격과 방어법을 짚어볼게요.

2026년 8월 17일 기준 킬린 랜섬웨어가 유출 사이트에 공개한 피해 기업은 누적 2,170곳이고, 이 중 150곳이 최근 30일 안에 새로 추가됐어요. 피해 산업군은 제조업(21%)이 가장 많았어요. 킬린은 Go·Rust 변종으로 윈도우뿐 아니라 리눅스, VMware ESXi 호스트까지 한 번에 노려요. 록빗·플레이·아키라·최근 등장한 크라켄까지 전용 리눅스·ESXi 암호화 도구를 갖췄다는 게 2026년 보안 업계의 공통된 경고예요.

리눅스·ESXi 서버, 어떻게 뚫리나

공격은 크게 두 경로예요. 하나는 SSH예요 — 리눅스에서 가장 많이 쓰이는 서비스인 만큼 무차별 대입 공격도 SSH 포트에 몰려요. 다른 하나는 알려진 취약점이에요. 리눅스 커널 nftables 결함 CVE-2024-1086은 2025년 내내 랜섬허브·아키라가 악용해 커널 수준 임플란트를 심었고(랜섬허브는 2025년 4월 와해돼 지금은 킬린이 흡수), ESXi 인증 우회 취약점 CVE-2024-37085는 아키라·블랙바스타가 삭제된 관리자 그룹을 재생성해 호스트를 장악하는 데 썼어요. 하이퍼바이저 하나만 뚫리면 그 위 가상머신 수십 대가 한꺼번에 암호화돼요.

여기에 AI가 상황을 더 급하게 만들고 있어요. CVE 공개 뒤 실제 익스플로잇 유포까지 걸리는 평균 시간이 2024년 56일에서 2026년 현재 약 10시간으로 줄었어요. AI가 취약점 공고문만 보고 10~15분, 1달러 안팎으로 익스플로잇을 만들어내기 때문이에요. 구글 위협 인텔리전스 팀은 2026년 5월, AI가 찾아내고 코드까지 작성한 제로데이가 실전 공격에 쓰인 사례를 처음 공식 확인했어요. "패치는 다음 점검 때"라는 여유가 더는 통하지 않아요.

왜 특히 위험한가

"리눅스는 원래 안전하다"는 인식 때문에 패치·계정 관리가 윈도우 서버보다 느슨하게 방치되는 경우가 많아요. root 계정으로 직접 SSH 로그인이 가능한 서버, 기본 22번 포트를 그대로 쓰는 서버가 여전히 흔해요. 게다가 ESXi처럼 여러 가상머신을 한 몸에 담은 인프라는 침투 지점 하나의 파급력이 훨씬 커요 — 관리 인터페이스 하나가 뚫리면 업무 서버·DB·백업 에이전트까지 통째로 넘어갈 수 있어요.

리눅스·ESXi 서버, 이렇게 경화하세요

SSH 설정부터 손봐야 해요. PermitRootLogin no로 root 직접 로그인을 막고, 키 기반 인증으로 전환하고, 가능하면 기본 22번 포트도 바꿔주세요. iptables 방화벽에서 인가된 관리자 IP만 SSH 접속을 허용하도록 좁혀두는 것도 중요해요.

파일 무결성도 챙기세요. 리눅스의 불변(immutable) 속성 플래그를 핵심 설정 파일·백업 스크립트에 적용해두면, 공격자가 root 권한까지 손에 넣었더라도 그 파일만큼은 지우거나 고쳐 쓰지 못하게 막을 수 있어요(`chattr +i` 명령이 대표적입니다).

마지막은 패치 속도예요. CVE 공개부터 실제 공격까지 10시간대로 좁혀진 지금, 핵심 패키지나 ESXi 업데이트를 미루면 이미 늦은 경우가 많아요. 패치 공지가 뜨면 당일~익일 안에 적용하는 프로세스를 만들어두세요.

• root 계정으로 SSH 원격 로그인이 그대로 허용돼 있지는 않은지 확인해 보세요
• SSH 포트가 기본 22번 그대로 열려 있고, 전 세계 각지에서 반복 로그인 시도가 몰리고 있지 않은지 로그를 확인해 보세요
• iptables·방화벽에 인가된 관리자 IP 외 접속이 차단돼 있는지 점검해 보세요
• 핵심 설정 파일·백업 스크립트에 chattr +i가 걸려 있어 root 권한으로도 삭제·변조가 안 되는지 확인해 보세요
• ESXi 관리 인터페이스가 인터넷에 그대로 노출돼 있지는 않은지, 최신 보안 패치가 적용됐는지 확인해 보세요
• 보안 업데이트 공지가 뜨면 당일~1~2일 안에 적용되는 프로세스가 있는지 점검해 보세요

Q. 리눅스가 윈도우보다 원래 안전하다고 들었는데, 지금도 그런가요?

공격 표면이 상대적으로 작았던 건 사실이지만, 킬린·아키라처럼 리눅스·ESXi 전용 도구를 갖춘 조직이 늘면서 격차가 많이 좁혀졌어요. "안전하다"는 인식 때문에 관리를 소홀히 하는 게 오히려 더 위험해요.

Q. 전산 인력이 소규모인 중견기업도 SSH·ESXi 설정까지 다 신경 써야 하나요?

네, root 로그인 차단과 관리자 IP 화이트리스트는 설정 자체는 몇 분이면 끝나요. 인력이 적을수록 초기 설정 한 번으로 오래 방어 효과를 보는 항목부터 우선순위를 두는 게 현실적이에요.

리눅스·ESXi 서버는 더 이상 "상대적으로 안전한 영역"이 아니에요. 하이퍼바이저 하나가 뚫리면 가상머신 수십 대가 한꺼번에 암호화되는 만큼, 파급력은 윈도우 서버보다 클 수도 있어요. SSH 경화, 파일 무결성, 빠른 패치라는 기본기가 공격 속도가 빨라진 지금 더 큰 차이를 만들어요.

그런데 SSH를 아무리 잘 막고 패치를 빨리 해도, root 권한 자체가 뚫리는 순간까지 완전히 막기는 어려워요. 이런 상황에서 마지막 방어선이 되는 게 백업이에요. 관리자 권한이 넘어가도 손댈 수 없는 구조가 필요한데, 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요.