실운영 서버 /home 디렉토리가 통째로 증발했다 (범인은 내부에...)

오픈 일주일 남은 우분투 서버가 먹통이 됨. 해킹인 줄 알고 식은땀 흘렸는데 까보니 시트콤이다.

Jun Noh
#Ubuntu #Linux #Incident #Troubleshooting #개삽질

오늘 오후, 밀린 작업을 처리하기 위해 사무실에 출근했다.

커피 한 잔을 마시고 여유롭게 터미널을 열었는데, 서버 접속이 되지 않았다.

ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused

네트워크 문제인가 싶어 핑(Ping)을 날려보았으나 정상이었다.

하지만 개발자 계정, Tomcat 계정, 심지어 Git Action 배포용 계정까지 전부 로그인이 불가능했다.

순간 사고가 정지했다.

다음 주가 서비스 오픈이다.

등줄기에 식은땀이 흘렀지만, 침착하게 GCP 웹 콘솔(Serial Console)을 통해 접속을 시도했다.

다행히 이곳은 접속이 가능했다.

현상 파악 (멘붕의 시작)

루트 권한을 획득한 뒤 가장 먼저 /home 디렉토리를 확인했다.

root@prod-server:~# ls -al /home
total 8
drwxr-xr-x  3 root root 4096 Jan 15 14:00 .
drwxr-xr-x 20 root root 4096 Jan 15 14:00 ..
drwxr-xr-x  2 google-sudoers google-sudoers 4096 Jan 15 14:00 google-sudoers

뭐야? 아무것도 없었다.

dev_jun도 없고, tomcat도 없고, 배포 계정도 존재하지 않았다.

방금 웹 콘솔로 접속하며 생성된 임시 계정을 제외하고는 /home 디렉토리가 초기화된 것처럼 깨끗했다.

누가 rm -rf /home/*을 갈기고 튀었나?

해킹 의심 및 로그 분석

가장 먼저 해킹을 의심했다.

누군가 침입해 데이터를 삭제했을 가능성이 높았다.

보통 해커가 침입하여 데이터를 삭제하면 로그도 함께 지우거나 훼손되어 있어야 정상이다.

우분투 환경이므로 auth.log를 확인했다.

# 로그인 기록 확인
last | head -n 20

# 명령어 히스토리 확인
history | grep "rm"

# 인증 로그 확인
tail -n 1000 /var/log/auth.log | grep "Accepted"

하지만 로그가 너무 깨끗했다.

외부 IP에서의 침입 흔적도, rm 명령어를 대량으로 실행한 기록도 없었다.

시스템 재부팅(reboot) 기록 또한 존재하지 않았다.

그렇다고 로그를 지웠다기엔… 특정 시간대가 비어있지도, 로그파일이 삭제되지도 않았다.

그리고 SSH 키로만 접속 가능한 서버에, 우리 회사 IP말고는 외부에서 직접 붙는게 불가능한데… 말이 안됐다.

디스크 마운트 확인 (lsblk)

혹시 디스크 마운트가 풀린 것은 아닐까?

단순히 마운트 포인트가 떨어져 나간 것이라면 데이터는 살아있을 것이다.

파티션과 마운트 정보를 확인하기 위해 lsblk 명령어를 사용했다.

# 블록 장치 및 마운트 포인트 확인
lsblk

출력 결과를 확인했으나, 디스크는 정상적으로 마운트되어 있었다.

물리적인 디스크 문제나 마운트 해제 문제는 아니라는 뜻이다.

데이터는 사라졌는데 범인의 흔적도, 시스템 오류도 없다. 미칠 노릇이었다.

추적 및 발견

외부 소행이 아니라면 내부에서 무언가 꼬인 것이다.

삭제된 것이 아니라 어딘가로 옮겨진 것일 수도 있다는 합리적 의심이 들었다.

내 계정 디렉토리 이름으로 전체 검색을 시도했다.

# 2>/dev/null은 permission denied 에러 제외
find / -type d -name "dev_jun" 2>/dev/null

결과는 충격적이었다.

/etc/home/dev_jun

형이 왜 거기서 나와…?

/etc 디렉토리 아래에 /home이 통째로 들어가 있었다. 시스템 설정 파일이 모여있는 /etc 안에 홈 디렉토리가 존재할 이유는 없다.

사건의 전말

범인은 우리 회사 막내였다.

오전 업무 중 FileZilla를 사용하여 서버에 접속했는데, 문제는 Root 계정을 사용했다는 점이다.

게다가 마우스가 아닌 노트북의 흔히 빨콩이라 불리는 Track Point를 사용하고 있었다.

FileZilla UI에서 /home 폴더를 클릭하려다 손이 미끄러졌고, 그대로 드래그 앤 드롭이 되어 /etc 디렉토리 안으로 이동된 것이다.

당연히 Root니까 아무런 에러 없이 옮겨졌을 것이다.

  1. FileZilla Root 접속: 권한 제약 없이 시스템 디렉토리 이동 가능.
  2. 조작 실수: /home 전체가 /etc/home으로 이동.
  3. 결과: OS는 /home 경로를 찾지 못해 SSH 접속 불가, Tomcat 등 서비스 설정 경로 불일치로 장애 발생.

수습 및 결론

뭐, 어려울 거 있나.

# 원상복구
mv /etc/home/* /home/

데이터 유실은 없었다.

위치를 원상복구 시키자 SSH 접속과 서비스가 정상적으로 돌아왔다.

막내를 호출해 호되게 질책하려 했으나, 본인도 사색이 되어 있기에 주의만 주고 마무리했다.

나 또한 주니어 시절 멍청한 실수로 연계 서버를 거의 날려먹을 뻔한 경험이 있기에, 크게 화를 낼 수는 없었다.

오늘의 교훈:

  1. FileZilla 등 FTP 툴 사용 시 절대 Root 계정으로 접속하지 않는다.
  2. 서버 작업 시 부정확한 입력 장치(트랙포인트 등) 사용을 지양하고 마우스를 사용한다. 그리고 그냥 앵간하면… 터미널로 하자.
  3. 오픈 직전에는 불필요한 접속을 자제한다.

마침. (진짜 심장 없어지는 줄 알았다.)

목록으로 가기

다른 글 보기