외부 해킹 시도 로그 분석으로 본 모바일 서버의 한계

“외부 해킹 시도 로그를 분석해 본 모바일 서버의 실제 한계와 대응 전략. SSH·웹로그 기반 공격 패턴 분석, 자원 고갈 문제, 단기·중기·장기 대응 및 아키텍처 재설계 권고.”

사건 개요와 로그 수집 방식

출처:pixabay

 

한 달 전, 개인적으로 운영하던 Termux 기반 구형 스마트폰 안 쓰는 스마트폰 서버에서 이상징후(비정상적 트래픽 폭주·응답 지연)를 감지했다.
서버는 Apache(포트 8080)와 SSH를 제공하고 있었고, 외부 접속은 라우터에서 특정 포트만 포워딩한 상태였다.
문제 발생 즉시 나는 access.log와 auth.log, dmesg 로그를 수집해 타임스탬프별로 정렬했고, fail2 ban 스타일의 자동 차단 규칙의 로그도 함께 확보했다.

주요 로그 샘플(가독성 위해 축약):

2025-10-03T02:14:07 GET /login 200 "-" "Mozilla/5.0 (scanner)" 2025-10-03T02:14:07 POST /wp-login.php 401 192.0.2.45 2025-10-03T02:14:07 SSHD [pam_unix(sshd:auth)] failed for invalid user admin from 203.0.113.12 port 45432 2025-10-03T02:14:08 GET /wp-login.php?xmlrpc=1 403 198.51.100.7

 

로그 수집은 cron으로 1분 단위 집계를 만들고, 이상 징후(초당 요청수 증가, 다중 IP의 동시접속)를 기준으로 경보를 설정했다.
이 데이터 축적이 이후 분석의 근간이 되었다.

추가로 초기 탐지 시점에는 자동화된 알림(메일/슬랙)을 통해 즉각적으로 서버 상태를 확인했고, 그 덕분에 피해 확산을 빠르게 억제할 수 있었다.
또한 사건 발생 이전의 정상 활동 로그를 비교 분석해 비정상 패턴의 '변곡점'을 정확히 도출할 수 있었다.

---

로그 분석: 공격 패턴과 취약점 지표

수집한 로그를 시간대·IP·요청 경로별로 분해해 보니, 공격은 크게 세 유형으로 나뉘었다.

1. 무차별 로그인 시도(Brute-force) — SSH·관리자 로그인 엔드포인트에 대한 동시 다발 요청. 단시간에 수백 건의 인증 실패가 발생했다.
2. 스캐닝 및 취약점 탐지(Scanner) — WordPress·phpMyAdmin·XML-RPC 같은 흔한 취약점 엔드포인트를 노출 여부 확인. User-Agent가 알려진 스캐너로 식별됐다.
3. 취약 구성 이용(Exploit attempts) — 알려진 취약점(예: 오래된 플러그인 RCE 시도) 패턴으로 보이는 POST/GET 변형 요청.
   로그에서 핵심 지표는 다음과 같았다.

• 단일일 최대 실패 로그인 수: SSH 1,842건(3시간).
• 동시 연결 발생 IP 군집: 87개 서로 다른 소스 IP(스포오핑 의심).
• 요청당 평균 처리 시간 급증: 평소 12ms → 공격시 220ms(응답 지연).
  이 수치는 모바일 서버의 리소스(저전력 CPU·작은 메모리)가 인증·입출력 부하에 취약하다는 것을 곧바로 보여주었다.
  특히 인증 실패가 반복되며 로그 쓰기·디스크 I/O가 늘어나자 CPU가 쓰로틀링을 시작했고, 최종적으로 정상 서비스 응답이 급격히 떨어졌다.
  추가 분석에서는 공격이 주로 새벽 시간대(02:00~05:00)에 집중되는 경향을 보였고, 이는 자동화 봇의 스케줄링 패턴과 일치했다.
  또한 일부 요청은 동일한 페이로드를 여러 경로로 변형해 보내는 '다중 인젝션' 형태였는데, 이는 탐지 회피를 노린 전형적인 시도였다.

---

모바일 서버의 구조적 한계 — 로그가 말해주는 진짜 문제

로그 분석은 왜 스마트폰 서버가 ‘취약점의 좋은 표적’이 되는지를 드러냈다. 핵심 한계는 세 가지로 요약된다.

첫째, 자원 제약(Resource Constraint): 스마트폰은 장시간 고부하 연산용으로 설계되지 않아, 다중 인증 실패와 동시 연결 처리에서 CPU·메모리·저장장치가 쉽게 포화된다. 로그에서 I/O wait가 급증한 부분이 이를 증명한다.

둘째, 네트워크 식별 및 차단 한계: 공격은 IP 회전·프록시·봇넷을 이용해 분산시켰다. 라우터 단의 단순 포트 차단으로는 근본 봉쇄가 어렵다.

셋째, 운영체제·앱의 낮은 격리성: Termux 같은 앱 내부에서 실행되는 서버는 시스템 서비스 대비 권한·프로세스 격리가 미흡하다. 공격자가 서비스 권한을 악용하면 앱 내부 데이터에 쉽게 접근할 가능성이 로그 상의 반복적인 권한 관련 에러로 감지되었다.

결과적으로 로그는 ‘공격 자체보다도 공격이 유발하는 자원 고갈(resource exhaustion)’이 모바일 서버의 가장 취약한 점임을 가리켰다. 즉, 방화벽 규칙이나 인증 강화만으로는 부족했고, 아키텍처 수준의 재설계가 필요했다.
또한 스마트폰은 스와핑(swap)이나 고성능 캐시 계층을 갖추기 어렵기 때문에, 일단 메모리 포화가 오면 서비스 회복에 시간이 더 걸렸다.

로그 회전이나 압축 정책이 미흡하면 로그 자체가 디스크를 소모해 또 다른 병목을 만들어내는 '자기 증폭' 현상이 발생할 수 있다는 점도 확인되었다.

---

대응 조치와 재설계 권고안

로그 분석 결과를 바탕으로 즉시 적용한 단기·중기 대응은 다음과 같다.

• 즉시 조치(Short-term): fail2ban 규칙 강화(짧은 기간 다수 실패 IP 자동 차단), SSH 포트 변경 및 공개키 인증 강제, 관리자 페이지 기본 인증 추가. 또한 로그 레벨을 올려 추가 시그니처를 확보하고, rsync 등 쓰기 빈도가 높은 서비스의 I/O 우선순위를 낮춰 로그 쓰기 병목을 완화했다.
• 중기 조치(Mid-term): 라우터 수준에서 GeoIP 기반 차단 적용, VPN(또는 WireGuard) 접속으로 내부 서비스 접근을 제한해 외부 직접 노출을 제거했다. Syncthing·rsync 등 동기화는 로컬 네트워크 우선으로 전환하고, 외부 전송은 SFTP/tunnel로 통제한다.
• 장기 권고(Long-term): 모바일 단일 노드의 역할을 경량화해 ‘에지 게이트웨이’로 전환하고, 핵심 데이터·인증은 NAS나 클라우드의 안전한 노드로 옮긴다. 또한 로그는 중앙집중형 SIEM(간단한 ELK 스택)으로 수집해 상관분석을 자동화하면 분산 공격 패턴을 더 빨리 식별할 수 있다.
  추가로 권장하는 실무적 보완: rate limiting(nginx/apache에서), WAF 연동(룰셋 업데이트), 정기적인 취약점 스캔(Nikto, OpenVAS), 그리고 무엇보다 복구 절차(백업·롤백 테스트)를 문서화해 운영자의 대응 시간을 최소화할 것을 권한다.
  더불어 허니팟(honeypot)을 임시로 설치해 공격자의 행위를 유인·분석하면, 이후 차단 규칙을 더 정교하게 설계할 수 있다.
  또한 재설계 과정에서는 서비스별 우선순위를 명확히 하여, 중요한 인증·로그인 루틴은 반드시 외부로부터 격리된 인프라에서 처리하도록 아키텍처를 분리해야 한다.

---

교훈: 로그는 방어의 원천이자 설계의 거울이다

이번 사건 분석으로 얻은 핵심 교훈은 단순하다. 로그는 공격의 증거일 뿐 아니라, 시스템 설계의 약점을 그대로 비춘다.
모바일 서버는 비용·전력 측면에서 매력적이지만, 로그가 보여준 바와 같이 동시성·인증·I/O 공격에는 구조적으로 취약하다. 따라서 모바일 노드를 ‘완전한 독립형 공개 서버’로 두기보다는, 인증과 중요 로직은 신뢰할 수 있는 별도 노드에 두고 모바일 기기는 보조·에지 역할로 활용하는 설계가 현실적이다.

마지막으로 운영자는 로그 집계·상관분석·자동 대응 루틴을 갖추어야 한다. 그 준비가 되어 있지 않다면, 어느 날 기록된 수천 줄의 로그는 ‘어떤 일이 있었는지’가 아니라 ‘왜 일이 더 커졌는지’를 되묻게 할 뿐이다.
이번 사례는 개인 운영자에게도 충분히 적용 가능한 실전 매뉴얼을 제공했다는 점에서 가치가 있다.
앞으로 이와 같은 공격 패턴과 대응 노하우를 공유해 커뮤니티 차원에서 방어 역량을 높이는 작업을 지속할 계획이다.

---