VPS 해킹 시 대처 방법: 서버 복구 및 보안 조치 가이드

해킹된 VPS를 정리하지 마십시오

VPS가 해킹당했을 때 가장 중요한 결정은 어떤 명령어를 실행하기 전에 내려야 합니다. 해당 장비를 정리하려고 시도하지 마십시오. 제공업체 수준에서 격리하고, 증거로 디스크 스냅샷을 생성한 뒤, 해당 서버에 저장되어 있던 모든 자격 증명을 교체하십시오. 그 후 신뢰할 수 있는 소스에서 새로운 서버로 재구축하십시오.

루트킷이 제거되었음을 증명할 방법은 없습니다. 이를 증명하는 데 사용해야 할 도구들조차 공격자가 통제하고 있기 때문입니다.

이것이 핵심 논리입니다. 그 이면에 있는 메커니즘은 다음과 같습니다. 루트 권한을 획득한 공격자는 ps를 교체하여 특정 프로세스 ID가 출력에 나타나지 않게 할 수 있습니다. /etc/ld.so.preload의 한 줄은 공격자의 코드를 시스템의 모든 동적 링크 프로그램에 로드하므로, ls, ss, find 모두가 동일하게 일관된 거짓 정보를 제공하게 됩니다. 로드 가능한 커널 모듈은 시스템 호출 단계에서 파일을 숨길 수 있으므로, 새로 다운로드한 바이너리조차 깨끗한 디스크로 인식하게 됩니다. 채굴기를 삭제하면 CPU 그래프가 떨어지고 서버는 조용해집니다. 하지만 조용한 상태는 작동 중인 백도어의 모습이기도 합니다.

재구축은 생각보다 비용이 적게 듭니다. 일반적인 VPS는 몇 개의 패키지, 하나의 설정 디렉터리, 하나의 데이터 세트로 구성되므로 재구축은 끝이 명확한 작업입니다. 공격자가 가한 모든 변경 사항을 추적하는 것은 끝이 없는 작업이며, 결코 완벽한 증명을 얻을 수 없습니다.

침해 여부 확인하기

해킹되었다고 보고되는 서버 중 상당수는 실제로는 침해되지 않은 상태입니다. 하루에 수천 건씩 발생하는 SSH 로그인 실패 기록은 인터넷의 배경 잡음과 같으며, 모든 공개 IPv4 주소는 지속적으로 스캔 대상이 되기 때문입니다. lastb 출력에 root 및 admin 시도가 가득한 것은 스캐너가 귀하의 포트를 발견했다는 의미일 뿐, 누군가 침입했다는 뜻은 아닙니다.

다음과 같은 신호는 실제 침해를 의미합니다:

• Accepted password for root from 203.0.113.7와 같이 본인이 알 수 없는 성공적인 로그인 기록.
• 본인이 추가하지 않은 authorized_keys 내의 키.
• 서버에서 나가는 트래픽에 대해 호스팅 업체로부터 받은 악용(abuse) 통지.
• 커널 스레드 이름을 도용한 CPU 100% 점유 프로세스. 노출된 Redis 및 Docker 소켓을 통해 유입된 채굴기는 흔히 kdevtmpfsi 및 kinsing과 같은 이름으로 보고됩니다.
• 서비스에서 사용하지 않는 주소로의 아웃바운드 연결.

커널 스레드 위장 여부는 간단한 테스트로 확인할 수 있습니다. 실제 커널 스레드는 대괄호 안에 출력되며 실행 파일이 존재하지 않으므로, sudo ls -l /proc/<pid>/exe을 실행하면 No such file or directory 오류가 발생합니다. 만약 [kworker/0:2]으로 출력되는 프로세스의 exe 링크가 /tmp 하위의 경로를 가리키고 있다면, 이는 커널 이름을 도용한 일반 사용자 프로그램입니다.

이 점검들은 서버가 거짓 정보를 제공할 가능성을 염두에 두고 수행해야 합니다. 이 확인 절차는 무언가 잘못되었다는 것을 판단하기에는 충분하지만, 아무런 문제가 없다고 확신하기에는 부족합니다.

서버 내부가 아닌 제공업체 수준에서 네트워크 차단하기

격리가 최우선입니다. 공격자가 여전히 셸을 확보한 상태에서 수행하는 모든 후속 조치는 무의미하기 때문입니다. 공격자가 실시간으로 지켜보는 상황에서 로그를 읽거나, 키를 교체하거나, 데이터를 복구하는 것은 아무런 의미가 없습니다.

제공업체의 제어판에서 운영체제 외부에서 작동하는 네트워크 방화벽을 사용하십시오. 인바운드와 아웃바운드 트래픽을 모두 거부하고, 웹 콘솔을 통해서만 접근하십시오. 그곳에서 적용된 규칙은 디스크에서 발생하는 그 어떤 상황에서도 유지됩니다.

서버 내부에서 이 작업을 수행해서는 안 되는 두 가지 이유가 있습니다. 침해된 커널 내부에서 설정한 방화벽은 해당 커널에 의해 강제되므로, root 권한을 가진 공격자는 방화벽 규칙을 작성하는 것만큼이나 쉽게 nftables를 초기화할 수 있습니다. 또한 SSH를 통한 sudo ip link set enp1s0 down은 자신의 세션을 먼저 끊어버리므로, 조사 중이던 장비에서 스스로를 차단하게 됩니다.

인바운드뿐만 아니라 아웃바운드도 차단하십시오. 리버스 셸은 서버에서 공격자 쪽으로 연결을 시도하므로, 인바운드만 차단하면 이미 수립된 연결은 완벽하게 유지됩니다. 제공업체가 인바운드 규칙만 제공한다면, 네트워크 인터페이스를 분리하거나 인스턴스의 전원을 끄는 것이 남은 선택지입니다.

아직 재부팅하지 마십시오. 먼저 /var/log/journal가 존재하는지 확인하십시오. 해당 디렉터리가 없다면 journald는 메모리에 상주하는 /run/log/journal에 로그를 기록하고 있는 것이며, 이 경우 재부팅 시 침입 기록이 삭제됩니다. 실행 중인 프로세스 역시 재부팅 시 사라지며, 프로세스의 커맨드 라인은 침입을 증명할 수 있는 가장 확실한 증거인 경우가 많습니다.

작업 전 디스크 스냅샷 생성

여기서 스냅샷과 백업은 서로 다른 역할을 수행합니다. 지금 생성하는 스냅샷은 침해된 디스크의 복사본으로, 이는 증거 자료가 되며 실수로 데이터를 덮어썼을 때 되돌릴 수 있는 유일한 수단입니다. 기존의 백업은 복구 경로로 활용합니다. 사용 중인 서비스 제공업체의 제어판에서 두 용어를 혼용한다면, 먼저 VPS 스냅샷과 실제 백업의 차이점을 읽어보시기 바랍니다. 보관 정책과 복구 방식이 서로 다르기 때문입니다.

다시 로그인하기 전에 서비스 제공업체 제어판에서 스냅샷을 생성하십시오. 라이브 스냅샷은 크래시 일관성(crash consistent)을 유지합니다. 즉, 전원을 갑자기 껐을 때와 동일하게 해당 시점의 디스크 상태를 그대로 캡처합니다. 증거 확보 용도로는 충분합니다. 실수로 복원하지 않도록 이름을 명확하게 지정하십시오. COMPROMISED-do-not-restore-2026-08-12와 같이 직관적인 이름을 사용하는 것이 좋습니다. 조사가 완료되고 호스팅 업체와의 악용 관련 티켓이 종료될 때까지 해당 스냅샷을 보관하십시오.

SSH 접속이 불가능할 때의 대처 방법

두 가지 방법이 있으며, 모두 제공업체 패널에서 수행합니다. 웹 콘솔(VNC 또는 시리얼)은 마치 물리적인 키보드를 연결한 것처럼 서버에 직접 접근합니다. 이 방법은 sshd가 중단되었거나, 방화벽 설정이 잘못되었거나, 공격자가 SSH 포트를 변경했을 때 유용합니다. 로컬 비밀번호로 인증하므로, 키 기반 인증만 사용하는 서버라면 콘솔을 사용하기 전에 root 비밀번호를 재설정해야 할 수도 있습니다.

Rescue 모드를 사용하는 것이 더 나은 선택입니다. 이 모드는 디스크를 마운트하지만 실행하지는 않는 소규모 라이브 시스템으로 부팅하므로, 명령어를 신뢰할 수 있습니다. 즉, 침해된 커널이나 바이너리가 실행되지 않습니다. 디스크는 읽기 전용으로 마운트하십시오.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

만약 lsblk 명령 결과에 일반 파티션 대신 LVM(logical volume manager) 볼륨이 표시된다면, 먼저 sudo vgchange -ay 명령으로 볼륨을 활성화한 뒤 /dev/mapper/ 아래에 나타나는 장치를 마운트하십시오.

마운트된 디스크로 chroot을 수행하여 내부를 살펴보지 마십시오. chroot를 실행하면 공격자의 바이너리가 사용자의 권한으로 실행되므로, Rescue 모드로 부팅한 목적 자체가 무의미해집니다.

신뢰할 수 있는 증거 수집

디스크를 /mnt/victim에 읽기 전용으로 마운트한 상태에서 레스큐 모드로 다음 명령을 실행합니다. 침입 시점을 파악할 수 있도록 로그인 기록부터 확인하십시오. 시간 범위를 확보하면 나머지 작업이 훨씬 수월해집니다.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

/var/log/auth.log가 없다고 해서 반드시 의심스러운 것은 아닙니다. 최신 Ubuntu 이미지 중에는 rsyslog 없이 배포되는 경우가 있으며, 이 경우 sshd 로그는 저널에만 기록되므로 journalctl -D 명령으로 확인해야 합니다. 연속적인 로그 기록에 공백이 있거나 로그 파일이 0바이트로 잘려 나간 경우를 주의 깊게 살펴야 합니다. 로그 삭제는 흔히 발생하며 대개 서투르게 처리됩니다.

다음으로 계정과 키를 확인합니다.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

awk 명령은 사용자 ID가 0인 모든 계정을 출력합니다. 이 출력 결과에 root 외의 항목이 있다면 이는 두 번째 root 계정입니다. find 패턴은 authorized_keys2도 함께 검색하도록 의도적으로 설정되었습니다. OpenSSH는 기본적으로 두 파일 이름을 모두 읽으며, 두 번째 파일은 간과하기 쉽기 때문입니다. lsattr 명령의 속성 목록에 i가 출력된다면 해당 파일은 변경 불가능(immutable) 상태입니다. 공격자는 이 플래그를 설정하여 관리자가 키를 삭제하려 할 때 Operation not permitted 오류가 발생하게 만들며, 지친 관리자는 편집이 성공했다고 착각하게 됩니다.

지속성(persistence)은 소수의 위치에 숨겨지므로 모두 확인해야 합니다.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload은 일반적인 Ubuntu나 Debian 시스템에는 존재하지 않으므로, No such file or directory가 정상적인 결과입니다. 내용이 조금이라도 출력된다면 주의를 기울여야 합니다. base64 -d의 출력을 셸로 파이프하는 로그인 파일도 마찬가지입니다. 정상적인 설정 파일은 자신의 내용을 숨길 필요가 없습니다.

수정 시간(mtime)이 아닌 변경 시간(ctime)을 기준으로 타임라인을 구축하십시오.

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch는 공격자가 원하는 값으로 수정 시간을 변경할 수 있으므로 mtime은 쉽게 조작됩니다. 변경 시간(ctime)은 inode가 변경될 때마다 업데이트되며 touch로는 시간을 과거로 되돌릴 수 없으므로, -newerct을 사용하면 최근에 기록된 내용을 더 정확하게 파악할 수 있습니다. 물론 root 권한으로 시스템 시계를 변경하거나 블록 장치에 직접 쓰기를 수행할 수 있으므로 이것이 완벽한 증거는 아닙니다.

패키지 무결성 검사는 한 가지 명령과 주의 사항이 필요합니다. 라이브 시스템에서 sudo dpkg --verify은 체크섬이 일치하지 않는 모든 패키지 파일에 대해 5을 포함한 행을 출력하며, debsums 패키지가 설치된 경우 sudo debsums -ac를 사용하면 설정 파일까지 포함하여 동일한 작업을 수행합니다. 결과는 한 방향으로만 해석하십시오. 변경된 /usr/sbin/sshd은 확실한 증거입니다. 하지만 깨끗한 보고서가 무죄를 증명하지는 않습니다. 바이너리를 교체한 동일한 root 계정이 /var/lib/dpkg/info/ 아래의 체크섬 목록도 다시 작성할 수 있기 때문입니다. rkhunter이나 chkrootkit와 같은 루트킷 스캐너도 같은 원칙을 따릅니다. 탐지 결과가 나오면 정보가 되지만, 깨끗한 결과가 나왔다고 해서 안전하다는 의미는 아닙니다.

파괴적인 작업을 수행하기 전에 수집한 데이터를 서버 외부로 복사하십시오.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

해당 해시 값을 서버 외부의 안전한 곳에 기록해 두십시오. 향후 보험 청구나 경찰 신고가 필요한 경우, 수집 시점 이후로 아카이브가 변경되지 않았음을 증명하는 것이 단순한 파일 폴더와 증거를 가르는 기준이 됩니다. 조사 과정에서 실수로 파일을 삭제하는 일은 흔하며, 스냅샷과 이 아카이브가 있어야 복구가 가능합니다. 나중에 잘못된 rm를 되돌리는 것은 예상보다 훨씬 어렵습니다. 이에 대해서는 rm -rf로 삭제된 파일 복구에서 설명합니다.

침입 경로 파악하기

침입 경로를 차단하지 않은 상태에서 서버를 재구축하면 며칠 내로 다시 침해를 당하게 됩니다. 서버를 처음 찾아낸 스캔 작업은 멈추지 않기 때문입니다. 단일 서버 침해 사례의 대부분은 다음 네 가지 경로를 통해 발생합니다.

SSH 비밀번호 로그인. 알 수 없는 주소에서 발생한 Accepted password for root 기록이 그 자체로 답이 됩니다. /etc/ssh/sshd_config 파일과 /etc/ssh/sshd_config.d/ 디렉터리 하위의 모든 파일에서 PasswordAuthentication 설정을 확인하십시오. sshd는 키워드에 대해 처음 발견한 값을 사용합니다. Ubuntu의 메인 설정 파일 상단에는 Include 줄이 위치하므로, 나중에 추가한 설정 파일이 하단에서 수정한 설정을 무시하고 우선 적용될 수 있습니다.

인증 없이 노출된 서비스. 6379 포트의 Redis, 2375 포트의 Docker API, 127.0.0.1가 아닌 0.0.0.0에 바인딩된 데이터베이스가 대표적입니다. Docker는 흔히 간과하는 원인입니다. 컨테이너 포트를 공개하면 ufw 체인보다 먼저 평가되는 DNAT(목적지 네트워크 주소 변환) 규칙이 삽입됩니다. 따라서 ufw status은 포트가 차단된 것으로 표시할 수 있지만, 실제로는 컨테이너가 전 세계 인터넷을 향해 응답하고 있을 수 있습니다. 재구축 전에 이 점을 반드시 이해해야 합니다. Docker 공개 포트가 ufw를 우회하는 이유에서 규칙 적용 순서와 해결 방법을 다룹니다.

패치되지 않은 웹 애플리케이션. 의심스러운 타임스탬프 전후의 웹 서버 접근 로그에서 업로드 경로 또는 관리자 경로로 향하는 POST 요청을 검색하십시오. 그 후 웹 루트 디렉터리에서 해당 시점에 변경된 파일이 있는지 확인하십시오. 업로드 디렉터리에 남아 있는 엉뚱한 PHP 파일이 전형적인 침해 결과입니다.

유출된 자격 증명. 저장소에 커밋된 키, 채팅창에 붙여넣은 토큰, 잘못 설정된 웹 서버를 통해 정적 파일로 제공된 .env 파일 등이 원인입니다. 자동화 도구를 사용하면 실수로 이런 일이 발생하기 쉬우며, 이것이 AI 에이전트와 설정 파일에서 비밀 정보를 제외해야 하는 이유에 대한 근거가 됩니다.

위의 모든 과정을 거치고도 침입 경로를 찾을 수 없다면, 자격 증명이 유출되었다고 가정하고 해당 서버가 보유했던 모든 비밀 정보를 공개된 것으로 간주하십시오.

서버가 노출했을 가능성이 있는 모든 자격 증명 교체

네트워크를 차단한 후에 교체를 진행하십시오. 차단하기 전에 교체하면 공격자가 여전히 연결된 상태에서 새로운 비밀 정보를 넘겨주는 꼴이 됩니다.

• 서버에 저장된 모든 SSH 개인 키와, 해당 공개 키를 신뢰하는 다른 모든 계정의 자격 증명.
• ssh -A를 사용하여 서버로 전달(forwarding)한 모든 키. 에이전트 포워딩은 /tmp 아래에 소켓을 남기며, 해당 머신의 root 권한을 가진 공격자는 세션이 유지되는 동안 귀하의 키가 허용되는 모든 곳에서 귀하를 사칭할 수 있습니다.
• .env 파일, systemd의 Environment= 라인, CI 설정 및 공급자 자격 증명에 포함된 모든 API 토큰.
• 데이터베이스 비밀번호 및 이를 사용하는 애플리케이션 계정.
• 서버가 보유했던 TLS(transport layer security) 개인 키. 인증서를 재발급하고 기존 인증서는 폐기하십시오.
• 2단계 인증을 활성화한 상태의 호스팅 계정 비밀번호. 호스팅 관리 패널은 귀하가 소유한 모든 서버를 재구축하거나, 스냅샷을 생성하거나, 콘솔로 접속할 수 있으므로 실질적인 보안 경계선입니다.
• 침해된 상태에서 해당 호스트의 셸 세션에 입력한 모든 비밀번호. root 권한은 터미널 세션 내용을 실시간으로 기록할 수 있기 때문입니다.

해당 머신에서 사용한 비밀번호가 다른 곳에서도 사용되고 있다면, 그곳의 비밀번호도 함께 변경하십시오. 비밀번호 재사용은 하나의 VPS 침해가 이메일 계정 침해로 이어지는 주된 경로입니다.

재구축 체크리스트

1. 기존 배포판 이미지를 사용하여 새 서버를 생성합니다. 침해된 서버의 스냅샷이나 전체 루트 파일 시스템 복구본을 사용하지 마십시오.
2. 배포판 저장소에서 패키지를 설치합니다. 이전 디스크에서 바이너리를 복사하지 마십시오.
3. 타임라인상 침해 증거가 나타나기 이전 시점의 백업에서 데이터만 복구합니다. 데이터베이스 덤프, 업로드 파일, 애플리케이션 상태 등이 해당합니다. /etc, /usr 및 이전 unit 파일은 가져오지 마십시오.
4. 교체한 비밀 정보는 수동으로 입력합니다. 이전 .env을 그대로 복사하지 마십시오.
5. 복구된 웹 콘텐츠를 다시 서비스하기 전에, 침해 발생 기간 중에 추가된 파일이 있는지 검사합니다.
6. 서비스를 공개하기 전에 보안을 강화합니다. SSH 키 인증 사용, root가 아닌 작업용 계정 생성, 기본 거부(default-deny) 인바운드 방화벽 설정, 필요한 범위 이상으로 서비스를 노출하지 않는 원칙을 지킵니다. 새 VPS 설정 후 첫 10분 과정을 수행하고, SSH 보안을 올바르게 강화한 뒤, Ubuntu 24.04에 fail2ban을 추가하여 무차별 대입 공격 시도를 차단합니다. 각 서비스에 최소 권한 계정을 부여하여 다음 침해 시 root 권한을 탈취당하지 않도록 합니다.
7. 이전 서버의 전원을 끄고, 조사 및 관련 악용 사례 티켓이 종결될 때까지 스냅샷을 보관합니다.
8. 백업 체계를 수정합니다. 3단계에서 복구 시점을 추측해야 했다면, 백업 보관 기간이 침해 이전 시점까지 도달하지 못했다는 것이 핵심 문제입니다. 버전 관리가 지원되는 외부 백업과 긴 보관 주기가 다음번의 안전한 복구를 보장합니다. VPS에서 restic 백업을 사용하면 두 가지 모두 해결할 수 있습니다.

침해 시점을 특정할 수 없다면 안전한 백업을 선택할 수 없습니다. 이 경우 육안으로 검사 가능한 데이터만 복구하십시오. 읽을 수 있는 SQL 덤프나 이미지 디렉터리 등이 해당합니다. 실행 가능한 모든 파일은 의심스러운 것으로 간주하고 저장소에서 다시 설치하십시오.

호스팅 업체로부터 받은 악용 통지의 의미

대부분의 사용자는 자신의 모니터링이 아닌 호스팅 업체를 통해 서버가 침해되었다는 사실을 알게 됩니다. 호스팅 업체는 외부로 나가는 트래픽을 감시하는데, 다른 네트워크를 대상으로 하는 SSH 무차별 대입 공격, 25번 포트를 통한 스팸 발송, 또는 반사 공격(reflection attack)의 일부로 활용되는 경우 등이 이에 해당합니다. 문의 티켓에는 일반적으로 타임스탬프, 포트 번호, 트래픽 흐름 샘플과 함께 몇 시간 단위의 처리 기한이 명시되어 있습니다.

서버를 격리하고 재구축 중이라는 답변이라도 반드시 회신해야 합니다. 티켓에 응답하지 않으면 호스팅 업체는 서버를 null-route 처리하거나 일시 정지시키며, 이로 인해 보안 사고가 서비스 중단 사태로 이어지게 됩니다. 이후 신고의 근거가 된 원본 로그를 요청하십시오. 해당 타임스탬프는 서버 외부에서 기록된 것이므로 공격자가 수정할 수 없는 유일한 타임라인 정보이며, 종종 디스크에 남은 그 어떤 기록보다 침입 시점을 정확하게 알려줍니다.

고객 서버의 침해 사고는 호스팅 업체 입장에서 일상적인 업무이며, 이를 잘 처리한다고 해서 불이익을 받는 일은 없습니다. VPS 호스팅의 안전성에 대한 더 넓은 관점의 질문은 결국 고객이 어떻게 설정하느냐에 달려 있으며, 지금 바로 그 설정을 처음부터 다시 수행해야 하는 상황입니다.

전문가의 도움이 필요한 경우

• 서버에 타인의 개인정보가 포함되어 있는 경우입니다. GDPR(일반 개인정보 보호 규정)에 따라 개인정보 유출 사고는 지체 없이, 그리고 인지 후 72시간 이내에 감독 기관에 신고해야 합니다. 신고 기한의 시작 시점을 판단하는 것은 시스템 관리자가 아닌 법률 전문가의 영역입니다.
• 결제 카드 데이터가 유출 범위에 포함된 경우입니다. 카드사 규정상 승인된 포렌식 조사관이 필요하며, 직접 조사하는 과정에서 증거가 훼손될 수 있습니다.
• 금전 요구가 있거나 데이터가 암호화된 경우입니다.
• 해당 장비가 내부 네트워크, 하이퍼바이저, 운영 환경 자격 증명을 보유한 CI 러너 등 다른 장비에 접근할 수 있는 경우입니다. 그룹 내 한 대의 호스트가 침해되었다면, 입증되기 전까지는 전체 그룹의 사고로 간주해야 합니다.
• 보험 청구나 법 집행을 위해 증거를 보존해야 하는 경우입니다. 스냅샷 단계에서 멈추고 전체 디스크 이미지를 생성한 뒤, 누가 언제 해당 장비를 다루었는지 기록하십시오.

타인의 데이터가 없는 개인 서비스용 VPS 한 대를 운영 중이라면, 위에서 설명한 대응 절차가 전부입니다. 제공업체 수준에서 격리하고, 증거를 위해 스냅샷을 생성하십시오. 신뢰할 수 있는 데이터를 수집한 뒤, 모든 자격 증명을 교체하고 깨끗한 상태로 재구축하십시오.

FAQ

해킹당한 VPS를 재구축하는 대신 정리해서 사용할 수 있습니까?

확신할 수 없습니다. 침해당한 시스템에 스스로의 상태를 보고하도록 요청하는 꼴이기 때문입니다. 교체된 ps는 프로세스를 숨길 수 있고, /etc/ld.so.preload의 한 줄은 실행하는 모든 동적 링크 도구에 코드를 주입할 수 있으며, 커널 모듈은 모든 프로그램에서 파일을 동시에 숨길 수 있습니다. 무언가를 발견했다면 그것은 의미 있는 증거가 되지만, 아무것도 발견하지 못했다고 해서 시스템이 깨끗하다는 증거가 되지는 않습니다. 서버에 중요한 데이터가 없고 다시 침해당해도 상관없다는 경우에만 정리를 고려할 수 있습니다.

침해당한 서버의 전원을 꺼야 합니까, 아니면 켜두어야 합니까?

먼저 제공업체 수준에서 네트워크를 차단하십시오. 그 후 스냅샷을 생성하고 실행 중인 프로세스를 확인할 수 있을 만큼만 켜두십시오. 전원을 끄면 프로세스 목록이 사라지며, /var/log/journal가 존재하지 않을 경우 journald가 /run 아래의 메모리에 로그를 기록하므로 저널 전체가 삭제됩니다. 단, 서버가 다른 네트워크를 활발히 공격 중이고 아웃바운드 트래픽을 차단할 방법이 없다면 즉시 전원을 끄십시오. 피해를 막는 것이 증거 보존보다 우선합니다.

공격자가 언제 침입했는지 어떻게 파악합니까?

/var/log/auth.log이나 저널에서 설명할 수 없는 가장 이른 시점의 Accepted password 또는 Accepted publickey 항목을 찾으십시오. mtime보다 위조하기 어려운 ctime을 사용하는 find / -xdev -newerct 'YYYY-MM-DD' -type f 명령으로 변경 시간 목록을 확인하여 교차 검증하십시오. 그런 다음, 서버 외부에서 기록되어 수정이 불가능한 제공업체의 어뷰즈 티켓 타임스탬프와 비교하십시오. 이 세 가지 날짜 중 가장 이른 시점보다 이전의 백업을 선택하십시오. 일치하는 정보가 없다면 침해 시점이 백업 기록보다 더 오래되었다고 가정하고, 직접 검사할 수 있는 데이터만 복구하십시오.

침해 후 백업을 복구해도 안전합니까?

데이터는 검사를 거친다면 대개 안전하지만, 시스템 파일은 그렇지 않습니다. 침입 이후에 생성된 백업에는 백도어가 포함되어 있으므로, 루트 파일시스템 전체를 복구하면 공격자도 함께 복구됩니다. 백업 저장소 자체도 확인하십시오. 만약 백업 저장소의 자격 증명이 침해당한 서버에 저장되어 있었다면 기록이 삭제되거나 변경되었을 수 있습니다. 이것이 바로 추가 전용(append-only) 또는 풀(pull) 방식의 백업 저장소를 권장하는 이유입니다. 애플리케이션 데이터만 복구하고, 소프트웨어는 배포 저장소에서 다시 설치하십시오.

VPS가 침해당했다는 사실을 누군가에게 알려야 합니까?

호스팅 제공업체의 어뷰즈 통지에는 반드시 응답해야 합니다. 그 외의 알림 여부는 서버에 누구의 데이터가 있었는지에 따라 다릅니다. 타인의 개인정보가 포함되어 있다면 GDPR의 72시간 내 감독 기관 통지 의무와 같은 법적 보고 의무가 발생할 수 있습니다. 서버에 사용자 자격 증명이 저장되어 있었다면, 해당 사용자들이 다른 곳의 비밀번호를 변경할 수 있도록 알려야 합니다. 서버 내의 키가 코드 호스팅이나 클라우드 계정 등 제3자 시스템에 대한 접근 권한을 가지고 있었다면, 해당 제공업체에 알려 오용 여부를 확인하도록 해야 합니다. 타인의 데이터가 없는 순수 개인용 서버라면 어뷰즈 티켓에 대응하는 것 외에 별도의 의무는 없습니다.