Hacker News 의견들

• 예전에야 UFW를 켰지만, 지금은 firewalld를 추천함
  UFW는 시간이 지나면 관리가 어려워지지만 firewalld는 XML 기반 설정이라 훨씬 안정적임
  firewall-cmd 명령으로 SSH, HTTPS, 80포트 등을 설정할 수 있고, nftables 백엔드를 쓰는 게 좋음
  Docker의 경우 방화벽 규칙을 우회해 포트를 열어버리는 경우가 많으므로, /etc/firewalld/firewalld.conf에서 StrictForwardPorts=yes로 설정하는 게 안전함

  • 포트를 8080:8080처럼 열지 말고 192.168.0.1:8080:8080처럼 사설 IP에 바인딩하는 게 좋음
    나는 10.0.10.11 VM에서 Docker를 돌리는데, WireGuard로만 접근 가능하게 해서 Caddy로 리버스 프록시를 두는 방식이 편리했음
  • Docker 대신 Podman을 설치하라고 권함. Docker는 방화벽 우회 문제가 흔함
  • 어떤 netfilter 프론트엔드를 쓰든, 아웃바운드 연결 제한이 없으면 무의미함
    악성코드는 외부 마이닝 풀이나 C2 서버로 연결하려 하기 때문에, 허용되지 않은 바이너리의 네트워크 접근을 막아야 함
    /tmp, /var/tmp, /dev/shm의 실행 권한을 제거하는 것도 유용함
  • Hetzner는 무료 외부 방화벽 서비스를 제공하므로, 1차 방어선으로 활용할 수 있음
  • 개인적으로는 nftables.conf만으로도 충분히 단순하고 명확하다고 느낌
    iptables는 이미 폐기된 상태라 firewalld 같은 추가 계층이 꼭 필요하진 않음

• 이건 “React2Shell CVE-2025-55182” 관련 이슈로 보임
  1년 넘게 영향을 준 취약점인데도 주목을 거의 못 받는 게 이상함
  지난 12개월간 Next.js로 배포한 웹앱이라면 이미 봇넷 일부일 가능성이 높음
  업계가 “Docker 써라”, “방화벽 켜라” 수준의 조언만 하는 게 답답함
  요즘 프론트엔드 생태계에 회의감이 들어서 C++ 쪽으로 커리어를 옮길까 고민 중임

  • 프론트엔드의 기술 교체 주기는 예전보다 훨씬 완화되었음
    지금은 Next.js, React, Tailwind, Postgres 조합이 5년째 표준처럼 굳어 있음
    2000년대 후반~2010년대 초반의 프레임워크 난립 시절에 비하면 안정적임
    유행과 변화가 싫다면 AI 개발 쪽이 훨씬 더 빠르게 변하고 있음
  • 최신 JS 프레임워크를 안 써도 웹앱은 충분히 만들 수 있음
    백엔드는 .NET, Java, Go 같은 견고한 기술 스택을 쓰고, 프론트는 자유롭게 선택하면 됨
    이렇게 하면 CVE도 줄고 기술 피로도도 낮아짐
  • 내 Pangolin 인스턴스도 이 취약점에 뚫렸음
    관련 GitHub 토론
  • 나도 100개 정도의 Next.js 프론트를 배포했는데, Server Components를 안 써서 다행히 영향은 없었음

• Docker 컨테이너의 CPU 사용량을 --cpus="0.5"로 제한하면, 오작동 서비스나 마이너가 시스템 전체에 영향을 주지 않음

  • 컨테이너를 read-only 모드로 돌리면 공격 표면을 더 줄일 수 있음
  • 다만 CPU 제한이 너무 낮으면 침입이 눈에 띄지 않아 탐지 지연이 생길 수도 있음
  • 앱의 성능 프로파일을 잘 알고 있어야 함. 나중에 버스트 트래픽이 생기면 의도치 않게 쓰로틀될 수 있음
  • 메모리의 soft/hard limit도 함께 설정하는 게 좋음

• 방화벽 없이 서버를 운영하는 건 꽤 대담한 선택임
  Hetzner의 외부 방화벽을 함께 쓰면 실수했을 때도 방어층이 하나 더 생김
  나는 SSH를 집 IP로만 허용하고, 외부에서 필요할 땐 Hetzner 웹사이트에서 임시로 열어둠

  • 대부분의 경우 방화벽은 큰 효과가 없음
    진짜 중요한 건 RCE 취약점이 있는 소프트웨어를 돌리지 않는 것임
    Docker가 구세주처럼 보이는 건 사실상 운이 좋았던 것뿐임
  • 퍼블릭 웹서비스라면 방화벽이 큰 도움이 안 됨
    대신 bastion host를 두고 HTTP 프록시로 입출력을 제어하는 방법이 있지만 설정이 복잡함
  • 30년 동안 리눅스를 운영하면서 해킹당한 유일한 경우는 잘 알려진 포트를 열었을 때였음
    비표준 포트를 쓰는 것만으로도 의외로 효과적이었음
  • 비밀번호 인증을 켜두는 건 위험함. 개인적으로는 fail2ban이 꼭 필요하진 않다고 생각함
  • SSH 포트를 무작위로 바꿔서 포트 스캐너 회피를 시도함
    효과가 확실한지는 모르겠지만, 일종의 심리적 우산 같은 느낌임

• Docker 컨테이너를 root로 돌리면, 호스트까지 공격 가능한가 궁금했음

  • Docker는 보안 경계가 아님. 단순히 프로세스 수준의 격리만 제공함
    신뢰할 수 없는 코드를 돌리려면 VM(KVM/QEMU)이나 gVisor(https://gvisor.dev/), Firecracker(https://firecracker-microvm.github.io/) 같은 기술을 써야 함
    Docker는 샌드박스가 아니라 격리된 실행 환경 정도로 이해해야 함
  • 공격자는 컨테이너 안에서도 CPU를 써서 Monero 채굴을 할 수 있음
    Docker의 기본 설정은 RAM, CPU, 디스크 사용량 제한이 없어 DoS 공격에도 취약함
    게다가 많은 가이드가 --privileged나 CAP_SYS_PTRACE 같은 위험한 옵션을 권장함
  • privileged 모드에서는 Docker 소켓을 통해 호스트 루트 파일시스템에 접근 가능함
    새 컨테이너를 띄워서 루트 권한으로 변경할 수도 있음
  • user namespace를 활성화해야 진짜 보안 경계가 생김
    Docker는 아직 기본값이 아니라서, 설정하지 않으면 탈출 위험이 큼
    과거 대부분의 컨테이너 탈출은 user namespace로 막을 수 있었음
  • 컨테이너 탈출이 존재하긴 하지만, 대부분은 단순한 자동화된 마이닝 공격임
    민감한 데이터를 다루지 않는 서버라면 컨테이너만 정리해도 충분함

• 공격 표면을 줄이려면 공개할 필요 없는 서비스는 외부에 노출하지 말아야 함
  예를 들어 분석 툴은 WireGuard나 SSH SOCKS 프록시를 통해서만 접근하도록 하면 됨

• 나도 Hetzner 서버에서 Monero 마이너 감염을 겪었음
  다행히 Incus의 LXC 컨테이너 안에서만 발생했고, CPU 우선순위가 낮아 눈치채지 못했음
  root 계정에 SSH 키가 추가되고 원격 관리 에이전트가 설치되어 있었음
  결국 컨테이너를 폐기했지만, 몇 가지 교훈을 얻었음

  • 시스템이 언젠가 뚫릴 걸 가정하고 격리와 자원 제한을 설정해야 함
  • ZFS 스냅샷과 백업을 주기적으로 유지하면 복구가 쉬움
  • 침해된 시스템은 폐기하는 게 이상적이지만, 상황에 따라 롤백 후 강화도 가능함
  • 마이너가 제대로 설정되지 않아 눈에 띄었지만, 만약 조용히 침입했다면 몰랐을 수도 있음
  • Umami를 설치한 컨테이너에서 발생했음

• 글에 사람이 교정하지 않은 AI 환각 내용이 포함되어 있었음
  Puppeteer 관련 취약점이라고 반복 주장하지만 사실이 아님

  • 원문 첫 문단에 Claude 세션의 전사본이라고 명시되어 있었음

• 최근 React 19 취약점을 이용한 Monero 마이너가 여기저기 설치되고 있음
  나도 같은 문제를 겪었음

  • 이런 마이닝 악성코드는 눈에 잘 띄고 피해도 적어서 오히려 유용함
    일종의 자동 버그 바운티처럼 작동해서, 취약점을 알려주는 셈임
    네트워크나 프로세스 모니터링이 잘 되어 있다면 쉽게 탐지 가능함
  • Oracle Cloud에서 Umami 서버가 감염되어 서버를 초기화했음
    덕분에 백업 시스템을 업그레이드할 좋은 계기가 되었음

• 이런 사례를 보면 VPS를 직접 운영하지 않길 잘했다는 생각이 듦
  예전에 해봤지만, 나는 평범한 관리자 수준이라 보안 유지가 어렵다고 느낌
  그래서 지금은 전문가에게 맡기고 비용을 지불하는 편이 훨씬 마음이 편함