새벽의 알림: nginx-proxy-manager 사고와 우리가 빠르게 복구한 방법

TL;DR: 4월 11일 새벽, 내부 프록시 설정이 무단으로 변경되어 일부 서비스 접속에 문제가 생겼습니다. 저희는 즉시 시스템을 격리하고 검증된 백업으로 복구했으며, 인증서·자격정보를 회전하고 보안 조치를 강화해 현재는 정상 운영 중입니다. 아래는 현장 기록을 블로거 관점으로 정리한 이야기와, 직접 따라 할 수 있는 점검·대응 팁입니다.

훅 — 새벽에 알람이 울렸을 때

새벽에 모니터링 알림이 울리면 보통은 커피가 더 필요하다는 신호입니다. 이번에는 “프록시 설정 변경”이라는 알람이 떴습니다. 로그를 열어보니 평소 보지 못한 프록시 항목 변경 내역이 있었고, 몇몇 도메인의 트래픽이 엉뚱한 곳으로 향하고 있었습니다. 바로 복구에 착수했습니다.

캡션: 새벽에 로그와 대시보드를 확인하며 원인 추적을 시작한 모습.

발견과 대응

1) 알람 -> 확인: 모니터링 경고로 문제 인지.
2) 격리: 의심되는 프록시 서비스를 네트워크에서 분리해 추가 변경을 차단.
3) 증거 확보: 로그와 구성 스냅샷을 확보해 포렌식 보관.
4) 복구: 검증된 백업으로 프록시 구성을 복원하고 서비스 라우팅을 단계적으로 재적용.
5) 안전조치: 관리자 자격증명·토큰·인증서를 회전하고 방화벽·아웃바운드 필터를 강화.

중요한 건 ‘속도’와 ‘증거 보전’의 균형입니다. 빨리 복구하되 증거를 지우거나 덮어쓰지 않도록 항상 스냅샷을 먼저 만들었습니다.

타임라인

04:40 — 모니터링 알림 수신 및 초기 확인
04:48 — 의심 서비스 격리
05:05 — 로그/디스크 스냅샷 및 증거 수집 시작
06:20 — 백업으로 구성 복원 및 단계적 라우팅 복구 시작
07:10 — 자격증명과 인증서 회전, 긴급 패치 적용
09:30 — 정상 운영 전환 및 강화된 모니터링상태

무슨 일이었나

간단히 말하면 ‘교통표지판’이 바뀌었기 때문에 일부 트래픽이 의도하지 않은 방향으로 흐른 것입니다. 웹 서비스는 도메인 이름을 보고 어느 서버로 보내야 할지 결정하는데, 그 연결 정보를 관리하는 곳이 변조되면 트래픽 흐름이 꼬입니다. 다행히 데이터베이스 백업과 로그가 있어 정상 상태로 되돌릴 수 있었습니다.

현장에서 바로 써먹는 점검·대응 팁

1) 즉시 차단: 의심되는 관리 UI는 외부 접속을 차단하세요. 관리 네트워크만 허용된 Bastion/VPN을 사용하십시오.
2) 증거 확보: 디스크/로그 스냅샷을 읽기 전용으로 복사하고 타임스탬프ed 아카이브로 보관하세요.
3) 검증된 백업으로 복원: 백업을 먼저 해시로 검증한 뒤 복원하고 변경 로그를 추적하세요.
4) 자격증명 회전: 관리자 비밀번호·API 토큰·웹훅 비밀값을 교체하고 모든 활성 세션을 무효화하세요.
5) 인증서 확인: ACME 챌린지가 실패하는지 확인하고 필요한 경우 인증서 재발급을 진행하세요.

간단한 체크용 curl 예시

# Host 헤더로 특정 도메인의 라우팅 응답을 확인
curl -I -H "Host: joplin.example.com" https://joplin.example.com -v

# 또는 DNS가 아직 전파되지 않거나 확인용이면 --resolve 사용
curl -I -H "Host: joplin.example.com" https://joplin.example.com --resolve joplin.example.com:443:203.0.113.12 -v

그리고 프록시 블록 예시

server {
 listen 80;
 server_name joplin.example.com;

 location / {
 proxy_pass http://joplin-backend:22300;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

우리가 이번에 바꾼 것들

관리자 비밀번호 및 통합 토큰 교체
인증서 재발급 및 HTTPS 복구
관리 포트에 대한 접근 제한 및 아웃바운드 필터링 강화
로그·알람 규칙 개선: 비정상 설정 변경에 대한 즉시 알림 및 자동 차단 룰 추가

만약 여러분이 우리 플랫폼과 통합한 사용자라면

사용 중인 API 키·웹훅·토큰을 즉시 교체하세요.
4월 11일 새벽 로그에서 비정상 요청을 확인하세요.
계정에 2단계 인증을 설정해 주세요.
이상이 발견되면 support@ourcompany.example 로 알려주세요.

마무리 — 경험을 나누자

이번 사고는 ‘모니터링 알림’이 얼마나 중요한지 다시금 일깨워줬습니다. 기술적 문제는 언제든 발생할 수 있지만, 준비와 팀의 빠른 대응이 피해를 줄입니다. 앞으로는 이 경험을 바탕으로 자동화된 초안→검수→발행 파이프라인도 도입해, 사고 소통을 더 빠르고 친근하게 할 수 있도록 하겠습니다.

궁금한 점이나 더 자세한 기술 부록을 보고 싶으시면 알려주세요. 필요한 부분은 별도 문서로 제공하겠습니다.

NPM 보안 사고 발생으로 인한 고생기