<중요>

react 또는 next.js 로 플랫폼을 구축했다면  react-server-dom-parcel, react-server-dom-turbopack 및 react-server-dom-webpack 과 같은 패키지에서 보안 버그가 발생하고 있으니 빠르게 확인 필요.

React 19.0, 19.1.0, 19.1.1 및 19.2.0을 사용하는 기업은 최신 수정 버전으로 긴급히 업데이트 필요!

<서론>
- 서론이 좀 길으니 급하면 아래 본론부터 읽자 -

어제 우리 서버들 중에 가볍게 개발자들이 개발용으로 사용할 수 있는 테스트용 서버가 있는데 몇일전 여기에 외부에서 접근한 흔적을 찾아냈다.
물론 이 서버는 실제 플랫폼하고 연관성도 없고 DB도 없고 개인정보도 없는 그냥 날 것의 장난감 같은 서버이다. (뭔가 마루타처럼 쓰고 싶은 그런 실험용? 작업을 하기 위한 용도로 회사들마다 종종 가지고 있다.)
우리는 이걸 토이 서버라 쓰겠다.

이제 이 토이 서버에서 문제점을 발견하고 해결하고 방어하는 과정의 기록을 적으려고 한다.

물론, 가장 안전한 설정은 지금 회사에서 운영중인 서버들에 적용된 여러가지 보안 설정과 배포 설정대로 하면 뚫릴 일은 없지만 그 설정들을 다 쓰기엔 너무 내용이 많다. 그리고 비용도 나가기 때문에 오히려 중소기업에서 작은 플랫폼이나 어플리케이션을 운영중이라면 부담이 될 수 있다.

참고 자료 :
- 2025년12월 5일 - 중국 해커들이 React2Shell이라는 새로운 취약점을 이용해서 공격하고 있다. [ 링크 ]

<본론>

어느날 잘 사용하지 않는 서버(토이 서버)가 웹으로 접속이 안된다는 직원의 제보를 받았다.
서비스에 별 중요한 내용이 없는 그냥 정적인 페이지들만 있는 AWS EC2 서버다.

ssh로 접속해보니 웹서버를 위해 구동시켰던 pm2 나 node 들이 설치에서 사라졌다.
뭔가 서버에 이상이 있음을 감지하게 된다.

공지. react, Next.js 업데이트부터 진행해 주세요.

이 글을 보시는 분들은 프론트 개발자에게 전해 주세요!!!

1. CPU 부터 상황 체크

먼저 AWS에서 이 서버의 CPU 내역을 확인해 봤다.

2시간전부터 CPU 사용률이 90%가 넘었다.
이 상태에서 유추된건 '아! 서버에 코인 채굴 심었다.' 부터 생각났다.
왜냐하면 비슷한 사례로 이커머스 플랫폼 회사에서 팀빌딩하고 플랫폼 만들어서 런칭하고 사람들이 몰렸을 때 비슷한 사례가 있었기 때문이다.

서버에서 top 를 실행해 봤다.

top - 15:07:33 up 31 min,  1 user,  load average: 1.06, 1.06, 0.96
Tasks: 108 total,   1 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.0 us,  0.3 sy, 97.7 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    957.3 total,     65.1 free,    500.2 used,    391.9 buff/cache
MiB Swap:   4096.0 total,   4070.0 free,     26.0 used.    298.7 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                   
    405 root      30  10  104876   8224     32 S  97.7   0.8  30:33.17 dsminer                   
    724 ubuntu    20   0   22.0g 160268  47360 S   2.0  16.3   0:07.52 next-server (v1           
    594 ubuntu    20   0  670284  66544  17152 S   0.3   6.8   0:03.09 node /home/ubun           
      1 root      20   0  166268  11648   8320 S   0.0   1.2   0:05.64 systemd                   
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kthreadd                  
      3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_workqueue_release    
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_g           
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_p           
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-slub_                          

어이구야~ dsminer 라는 프로세스가 cpu를 97% 이상을 사용하고 있었다.
저 프로세스를 바로 죽이기 보다는 이번이 기회라고 나는 이미지(AMI) 를 떠놨다. 지금 서버 상태를 그대로 백업해 두었다는 것이다. 해킹 시도 방법과 어떤 해킹 코드를 어떻게 구동시켰는 지 분석해 보는 것도 재미있을 것 같아서다.

하지만, 실제 서비스를 운영 중인 기업들은 꼭 저 프로세스를 죽이고 방어부터 하는 것을 추천한다.

나의 경우는 있으나 마나 한 서버였기 때문에 토이 서버라 리스크가 있는 것도 아니고 해커의 이런 시도를 미리 감지해서 사전에 분석하고 공부해 두는 것이 좋을 것 같기 때문에 여유있게 프로세스를 죽이지 않고 모니터링 한 것 뿐이다.

실제 이렇게 과다한 프로세스가 돌면 거의 코인 채굴 악성코드이다. 우선 이 프로세스부터 죽이자.

위 프로세스 목록의 dsminer 를 보면 PID가 405 이다.
바로 죽이지 말고 해당 프로세스가 돌고 있는 파일과 위치도 확인해 보자.

ps -ef | grep dsminer | grep -v grep

이렇게 실행하면 아래처럼 결과가 나온다.

root         405       1 98 14:36 ?        00:30:56 /home/ubuntu/.dspool/dsminer --config=/home/ubuntu/.dspool/config.json

PID 405 확인했고 /home/ubuntu/.dspool/dsminer 경로에 있는 파일이 돌고 있다.
아래처럼 프로세스를 죽이고 해당 파일을 삭제한다.

sudo kill 405
sudo rm /home/ubuntu/.dspool/dsminer

이렇게 하면 일단 프로세스는 죽었다.
파일도 지웠기 때문에 주기적으로 스케쥴을 돌리는 무언가가 해당 파일을 다시 돌릴 수 없겠지만 실제 서비스를 돌리던 코드들을 뒤져봐야 좀 더 정확히 아는 것이다.

여기까지 했다고 해결된 것이 아니다.
pem(ppk) 인증키가 해커에게 유출되었거나 퇴사자가 가지고 장난 칠 수 있기 때문에 이 키를 바꾸는게 안전하다.
하지만 이 교체하는 건 오래 걸리니까.
다음 단계부터 하자!

그리고 프로세스 명칭이 dsminer 아닐 수 있다. 해커들이 프로세스 명칭을 다르게도 만들 수 있으니 cpu 점유가 높다? 싶으면 의심하고 해당 파일을 역추적해야 한다. 실행 파일들의 설정 파일들을 보면 결국엔 채굴 코인을 넣는 지갑 주소를 찾을 수 있다.

2. SSH 인바운드 제한

인증키로 서버에 ssh 로 들어왔다는 가정하에 우선 ssh로 들어오는 골목을 제한한다.
보안그룹을 설정하면 되는데 인바운드 포트나 트래픽을 설정하면 된다.

다른 운영 서버들의 경우 VPC 안에서만 서로 통신하고 VPN과 인바운드 정책을 통해 외부에서 들어올 수 없지만 토이 서버의 경우 그런 설정들을 해놓지 않았다.

이렇게 IT 전문업체가 아닌 이상 서버에 하나하나 보안 설정을 안하는 것이기 때문에 쉽게 해커들이 접근할 수 있던 것이다.

서버의 네트워크 보안 설정에서 인바운드 규칙 편집에 가면 이렇게 SSH 유형에 0.0.0.0/0 으로 되어 있다면 그냥 모든 사람에게 어디서든 SSH를 접속할 수 있게 열어주는 것이다.

이 것부터 막자.
SSH 를 접속하는 사람 (거의 개발자나 유관 엔지니어) 들이 작업하는 곳의 IP만 허용해 주면 된다.
아마 다들 공유기를 쓸테니 정확한 IP를 모를 수도 있기 때문에 네이버에서 '내 아이피'라고 써주면 알려준다.

이렇게 아이피를 알게되면 아래처럼 이 아이피만 추가한다.

내아이피/32 라고 써주고 설명에 보안 문서(우리는 컨플루언스에 정리한다.) 안에 허용한 아이피와 누구의 것인지 날짜까지 적어서 현황을 꼭 공유한다.

이유는 AWS 계정에 들어와서 이 부분까지 수정하는 해커들이 있다. AWS 계정 자체를 탈취 당하는 경우다.
우리는 마스터부터 직원들까지 AWS 계정은 2차인증 MFA가 설정되어 있고 비밀번호와 토큰을 주기적으로 변경하기 때문에 AWS 계정이 탈취되지는 않는다.

AWS를 사용하는 기업이라면 꼭 2차인증 설정해 둬라!

이제 대망의 인증키 변경이다. 이건 좀 번거롭다.
그렇기 때문에 개발자들이 잘 안바꾸려고 하는 것이다.
그래도 분기별로 바꾸자.
스크립트 만들어두면 편하다.

아무튼 이건 좀 정리해서 다시 업데이트 하겠다.

! 2025년 12월 12일 업데이트

급한 불 부터 끄고 작성할 예정입니다.
위에 공지, 1번, 2번에 알려드린대로 먼저 해도 급한 불을 끌 수 있을 것 같습니다!