{ "componentChunkName": "component---src-templates-blog-template-js", "path": "/Music_Pipeline_09/", "result": {"data":{"cur":{"id":"d43844ee-35e5-550c-8c4b-84d8b83c50da","html":"

어느 날 애플리케이션이 뜨지 않았다

\n

M3 작업 중 bootRun 이 Unknown database 'music_pipeline' 으로 실패했다.\n어제까지 멀쩡했던 로컬 DB 다. 안에 들어가 보니:

\n
SHOW DATABASES;\n-- RECOVER_YOUR_DATA      ← ???\n-- information_schema\n-- mysql\n-- ...\n-- music_pipeline 이 없다
\n

RECOVER_YOUR_DATA 데이터베이스 안에는 이런 내용이 있었다.

\n
\n

All your data was backed up by us. You must pay 0.013 bitcoin to …\nor in 48 hours, your data will be publicly disclosed and deleted.

\n
\n

노출된 MySQL/MariaDB 를 스캔해서 약한 비밀번호로 로그인하고, DB 를 삭제한 뒤\n랜섬 노트를 남기는 자동화 봇의 전형적인 수법이다.

\n

뚫린 경로

\n

거창한 취약점이 아니다. 조합이 문제였다.

\n
# docker-compose.yml (사고 전)\nports:\n  - \"3307:3306\"          # = 0.0.0.0:3307, IPv6 [::]:3307 까지 바인딩\nenvironment:\n  MARIADB_ROOT_PASSWORD: root   # 개발용 \"임시\" 비밀번호
\n

Docker 포트 매핑의 기본값은 모든 인터페이스(0.0.0.0)다. “로컬 개발용이니까”라고\n쓴 root/root 와 만나는 순간, 네트워크에서 접근 가능한 무인 DB 가 된다.\n공유기 NAT 뒤라고 안심할 수 없다 — IPv6 는 공인 주소가 직접 붙는 경우가 많고,\n같은 네트워크의 감염된 기기가 경유지가 되기도 한다.

\n

대응

\n
    \n
  1. 몸값은 지불하지 않는다. 이런 봇은 대부분 백업 없이 삭제만 한다. 그리고 잃은 것은\n전부 재생성 가능한 로컬 샘플 데이터였다 — 결과적으로 피해 0.
    2. \n
  2. 모든 포트를 루프백 바인딩으로 변경. MariaDB 만이 아니라 Kafka(무인증 PLAINTEXT),\nRedis(무인증 — 노출 시 RCE 까지 가능) 전부.
    3. \n
\n
ports:\n  - \"127.0.0.1:3307:3306\"\n  - \"127.0.0.1:9092:9092\"\n  - \"127.0.0.1:16379:6379\"
\n
    \n
  1. 오염된 볼륨은 폐기하고 재생성 — 공격자가 root 로 만졌던 데이터는 신뢰하지 않는다.\nFlyway 가 스키마를, 샘플 생성기 + 입수 API 가 데이터를 복원했다 (5,000 릴리스 / 50,000 트랙).
    2. \n
  2. mysql.user 에 주입된 계정이 없는지 확인.
    3. \n
\n

복원이 몇 분에 끝난 것은 우연이 아니라 “파일이 아니라 재현 방법을 버전관리한다”\n원칙 덕이었다. 데이터가 전부 스크립트에서 재생성되는 구조면 랜섬은 협박이 못 된다.

\n

배운 것

\n\n
\n
\n\n
","excerpt":"어느 날 애플리케이션이 뜨지 않았다 M3 작업 중 bootRun 이 으로 실패했다.\n어제까지 멀쩡했던 로컬 DB 다. 안에 들어가 보니: 데이터베이스 안에는 이런 내용이 있었다. All your data was backed up by us. You must pay 0.013 bitcoin to …\nor in 48 hours, your data will be publicly disclosed and deleted. 노출된 MySQL/MariaDB 를 스캔해서 약한 비밀번호로 로그인하고, DB 를 삭제한 뒤\n랜섬 노트를 남기는 자동화 봇의 전형적인 수법이다. 뚫린 경로 거창한 취약점이 아니다. 조합이 문제였다. Docker 포트 매핑의 기본값은 모든 인터페이스()다. “로컬 개발용이니까”라고\n쓴 root/root 와 만나는 순간, 네트워크에서 접근 가능한 무인 DB 가 된다.\n공유기 NAT 뒤라고 안심할 수 없다 — IPv6 는 공인 주소가 직접 붙는 경우가 많고,\n같은 네트워크의…","frontmatter":{"date":"July 24, 2026","title":"음악 스트리밍 파이프라인 만들기 - 09. 번외, 로컬 Docker DB가 랜섬 공격당했다","categories":"Music_Pipeline","author":"shim8934","emoji":"🚨"},"fields":{"slug":"/Music_Pipeline_09/"}},"next":{"id":"aabb9630-b1e7-5303-8dd0-3c3828c61149","html":"

선택 모듈 — 오디오를 실제로 흘려보내기

\n

메타데이터와 집계만 있던 파이프라인에 실제 재생 경로를 붙였다.\n제약: 기존 코드 무변경 — streaming/ 패키지와 audio_asset 테이블만 추가.

\n

원본 음원은 ffmpeg 합성 사인파다. 저작권 문제가 없고, 길이를 track.duration_ms\n와 정확히 일치시킬 수 있어 검증이 깨끗하며, 저장소엔 바이너리 대신 재현 방법을\n버전관리한다. 트랙마다 주파수를 trackId 에서 유도해서 “다른 트랙인데 같은 소리” 같은\n배선 오류를 귀로 잡을 수 있게 했다.

\n

HLS 구조 — RFC 8216 을 코드에 대응시키기

\n
media-store/{trackId}/\n├─ master.m3u8          마스터 플레이리스트: \"무엇을 고를 수 있나\" (EXT-X-STREAM-INF)\n├─ v64k/playlist.m3u8   미디어 플레이리스트: \"어떤 순서로 재생하나\" (EXTINF, ENDLIST)\n├─ v64k/seg_000.ts ...  MPEG-TS 세그먼트 (AAC)\n└─ v128k/...
\n

variant 인코딩·분할은 ffmpeg 에 맡기고 마스터 플레이리스트는 직접 썼다 —\nBANDWIDTH(비트레이트 + TS 오버헤드)와 CODECS(“mp4a.40.2” = AAC-LC)가 어디서\n오는지 코드에 남는다. 플레이어는 이 두 값으로 다운로드 전에 variant 를 고른다.\nABR 의 선택 근거가 마스터에 선언돼 있다는 게 HLS 구조의 핵심이다.

\n

검증은 ffprobe 교차 검증 — 우리가 만든 산출물을 우리가 아닌 도구가\n“AAC + MPEG-TS, 길이 N초”로 읽는지 확인한다. 생성기와 검증기가 같으면 순환 논증이다.

\n

Range Request(206) 와 HLS 의 관계

\n

같은 문제(“파일 일부만 전송”)를 자르는 주체가 다르다.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Range (프로그레시브)HLS
자르는 주체클라이언트, 바이트 단위서버, 미디어 단위(미리)
탐색Range: bytes=N- 재요청다른 세그먼트 요청
화질 전환표현 불가variant 의 같은 시점 세그먼트
CDN부분 요청이라 비효율세그먼트 = 완결된 정적 파일
\n

Spring 은 ResponseEntity<Resource> 를 반환하면 Range 를 자동 처리한다 —\n세그먼트에 bytes=0-99 를 보내면 206 + Content-Range 가 온다. HLS 플레이어는 안\n쓰지만 두 방식의 차이를 설명하는 살아 있는 데모가 된다.

\n

사전 생성 vs 온디맨드 — 측정이 가설을 기각한 네 번째 사례

\n

패키징을 입수 후 미리 할 것인가, 첫 재생 요청 때 할 것인가. 측정을 위해\naudio_asset 테이블에 packaging_ms/storage_bytes 컬럼을 스키마 단계에 넣었다.

\n

실카탈로그 21트랙(평균 220초) 측정:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
지표값
패키징 시간평균 5.4초 (2.6~7.9초)
스토리지5.51 MB/트랙 (비트레이트 역산과 일치)
5만 트랙 외삽269 GB, 8워커 병렬 약 9.4시간
\n

가설은 “온디맨드도 1초쯤이면 쓸 만하다”였다. 실측 5.4초로 기각. 음악 재생의 기대\n반응시간은 백 ms 대다. Zipf 분포로 “롱테일은 안 들으니 아끼자”는 온디맨드 옹호 논리도\n뒤집으면 “롱테일 청취자만 5초 페널티”다. 사전 생성을 기본으로, 온디맨드는 같은\n준비 경로를 쓰므로 한계 비용 0 으로 보조·복구용으로 남겼다.

\n

재사용된 패턴들

\n

새 도메인인데 새 개념이 거의 없었다.

\n\n

패턴의 재사용이 곧 설계 일관성이라는 게 이 모듈의 결론이다.

\n

상세: ADR-0006,\nHLS 구현 노트

\n
\n
\n\n
","frontmatter":{"date":"July 24, 2026","title":"음악 스트리밍 파이프라인 만들기 - 08. HLS 스트리밍, 온디맨드 패키징이 기각당한 이유","categories":"Music_Pipeline","author":"shim8934","emoji":"🎧"},"fields":{"slug":"/Music_Pipeline_08/"}},"prev":null,"site":{"siteMetadata":{"siteUrl":"https://shim8934.github.io","comments":{"utterances":{"repo":"Shim8934/shim8934.github.io"}}}}},"pageContext":{"slug":"/Music_Pipeline_09/","nextSlug":"/Music_Pipeline_08/","prevSlug":""}}, "staticQueryHashes": ["1073350324","1956554647","2938748437"]}