[m-a-king]

한눈에

컨테이너가 사내망 주소로 연결하지 못하게 막는 서버 방화벽 규칙

• 이전: 상품 주소를 여는 두 서비스가 사내망 주소를 각자 코드로 판정
  • 두 판정이 주소 대역 6개에서 서로 다름
  • 브라우저의 백그라운드 작업(service worker 등)은 renderer 의 검사를 거치지 않음
  • 원인: AWS 보안 그룹은 허용 규칙만 있어 "사내망만 막기" 를 못 함
• 사내망 대역 목록을 이 저장소의 파일 하나로 모음
• 서버 방화벽 규칙을 거는 공용 배포 스크립트 추가
  • 컨테이너가 사내망으로 여는 새 연결을 서버가 거절
  • DNS·인스턴스 메타데이터·관측 수집기 포트는 모든 서버 공통 예외
• renderer 가 extractor 에 "사내망 주소에서 응답을 받음" 을 알리는 응답 필드 추가
• 머지만으로는 서버에 아무것도 걸리지 않음
  • 두 서비스 저장소의 배포가 이 스크립트를 부를 때 걸림
• 머지 직후 renderer 계약 대조 테스트가 실패함
  • renderer PR 을 이어서 머지하면 해소
• 머지 뒤 개발자 로컬에도 사내망 대역 파일이 깔림
  • 저장소를 열 때 도는 공용 설치 스크립트가 깔음

Situation

원인 추가

• SSRF 내부 대역 정본과 서버 벽 블록 추가 #137
• 추가
  • 두 서버 실측(10-14·15): Ubuntu 24.04·Docker 29.8.1·iptables nft 백엔드, 컨테이너 IPv6 꺼짐, 컨테이너 DNS 는 VPC 리졸버 10.0.0.2
  • VPC 엔드포인트 0개라 AWS 서비스 호출은 전부 공인 IP 로 나감. 서버 방화벽 예외에 사내망 AWS 주소가 필요 없음

Task

범위

• SSRF 내부 대역 정본과 서버 벽 블록 추가 #137

Action

내부 대역 정본

• IPv4 9개·IPv6 5개
• 인터넷에 라우팅되지 않을 뿐 우리 서버에서 닿을 곳이 없는 대역(벤치마크·문서용)은 뺌
• CI 가 정규형·겹침·IPv4 와 IPv6 존재를 검사
  • 원인: 소비자 셋(서버 방화벽·extractor·renderer)이 각자 파싱함

대역	이전 extractor	이전 renderer	이후 셋 다
100.64.0.0/10·224.0.0.0/4	차단	통과	차단
0.0.0.0/8·240.0.0.0/4	통과	차단	차단
198.18.0.0/15·192.0.2.0/24	통과	차단	통과
사설·loopback·링크 로컬·ULA	차단	차단	차단

서버 방화벽 블록

• 컨테이너가 서버 밖으로 가는 새 연결은 DOCKER-USER, 서버 자신으로 가는 새 연결은 INPUT 에서 거름
  • 서버의 사설 IP 로 sshd·nginx 에 닿는 경로도 INPUT 에서 막힘
• 공통 예외는 블록이 가짐
  • DNS: Docker 가 컨테이너 resolv.conf 를 만드는 원본에서 읽음
  • 인스턴스 메타데이터 80: 앱의 AWS 자격. IMDSv2 필수라 브라우저는 토큰을 못 얻음
  • Alloy OTLP 4318: 관측 계약
• 서비스만 쓰는 목적지는 호출부가 --allow-tcp IP:PORT 로 넘김
• TCP 는 RST 로 거절
  • 원인: ICMP 거절은 커널 제한(icmp_ratelimit 1000ms, 두 서버 실측)에 묶여 연달아 막히면 SYN 재전송을 기다림
  • 결과: dind 실측 거절 응답 1.05초에서 즉시로
• 재부팅 유지: 규칙 파일과 적용 스크립트를 /etc 에 두고 systemd 단위가 Docker 보다 먼저 적용
  • DOCKER-USER 를 블록이 통째로 가짐. 매 적용이 비우고 다시 채워 몇 번 돌려도 같음
• 적용 뒤 docker0 에 잠깐 붙인 시험용 netns 에서 예외 목적지와 차단 목적지를 찔러 확인
  • 그 출발 주소만 세는 카운터 규칙으로 거절 횟수를 봄. 목적지가 꺼져 있어도 판정이 같음
  • 시험 주소는 Docker 가 앞에서부터 나눠 주는 bridge 대역의 끝쪽에서 빈 것을 고름
  • 어긋나면 규칙을 걷고 exit 1. 서비스는 그대로 돌고 배포만 멈춤
  • 이전(이 PR 첫 판): 운영 컨테이너의 네트워크에서 찌르고 서버 전체 거절 수를 봄
    • 기각: 운영 트래픽이 그 사이 벽에 걸리면 정상 벽을 걷음. 컨테이너가 재시작 중이면 오판 (독립 리뷰 지적)
• --remove 로 벽과 부팅 단위를 걷음
  • 원인: 규칙 파일과 부팅 단위가 남아, 배포의 블록 호출을 되돌려도 벽이 영구히 남음
• IPv6 가 켜진 bridge 가 있으면 적용하지 않음

선택지	장점	비용
서버 iptables (채택)	내부만 거절하고 인터넷 허용. 앱이 못 보는 요청까지 연결 단계에서 막음	서버마다 규칙 유지 장치 필요
보안 그룹 나가는 방향	AWS 가 관리	허용 규칙만 있어 "사내망만 막기" 불가
서브넷 NACL	거부 규칙 가능	상태 없는 규칙이라 응답 포트까지 직접 열어야 함. 같은 서브넷 서버 사이 통신은 못 거름
앱 검사만	추가 장치 없음	service worker·WebRTC·이름 재해석을 못 봄

계약 필드와 code 설명

• RenderResponse.internal_address_hit(optional): 브라우저가 내부 대역 주소에서 응답을 받으면 참
  • 판정은 브라우저가 실제로 연결한 IP 기준
  • 판정하는 renderer 는 거짓도 늘 실어 보냄. 필드가 없으면 판정하지 않는 renderer
  • extractor 는 필드 없는 응답의 홉을 쓰지 않음
    • 원인: extractor 가 홉 재검사를 지움. 배포 순서가 어긋나거나 renderer 를 롤백하면 판정 없는 홉이 들어옴 (독립 리뷰 지적)
    • 결과: 머지 순서를 코드가 지킴. 순서가 어긋나면 렌더만 일시 실패
• BLOCKED_HOST·MALFORMED_REDIRECT 설명을 실제 의미에 맞춤
  • 이전: extractor 가 https 아닌 redirect 를 BLOCKED_HOST 로 내 내부 주소가 아닌데 SSRF 로 집계됨

로컬 계약 설치

• install.sh 가 internal-ranges.txt 도 소비 repo 의 shared-infra/contracts/ 에 설치
  • 원인: extractor 는 빌드가 classpath 에 싣고 renderer 는 기동 때 읽음. 없으면 둘 다 뜨지 않음
  • 이전(이 PR 앞선 판): proto 두 개만 설치. 머지 뒤 개발자 로컬에서 renderer 테스트와 extractor 기동이 깨질 뻔함
• 설치 전 검사에 목록 유형 추가. 첫 CIDR 줄이 없으면 설치하지 않음
  • 결과: 오류 페이지·빈 본문은 설치하지 않음

문서

• conventions/infra.md 3절: egress 항목을 보안 그룹 기준으로 좁히고 서버 방화벽 항목 추가
  • 막는 대상·거는 시점·공통 예외와 서비스 고유 예외의 주인
  • 방화벽을 거치지 않는 곳은 각 서비스의 앱 검사 몫
• README.md 구조에 internal-ranges.txt·egress_wall.sh 추가

Result

실제 커널 규칙으로 검증

• 운영과 같은 Docker 29.8.1 dind 안에 서버·VPC·인터넷 netns 를 두고 확인. CI 에서도 같은 시험이 돎
  • 방화벽 전에는 닿던 목적지(VPC 의 다른 서버·서버 sshd)가 방화벽 뒤 거절됨
  • 허용 9건: 인터넷·DNS tcp·DNS udp 왕복·메타데이터·서비스 예외·OTLP 두 주소·들어오는 연결·컨테이너 loopback
  • 차단 7건: 예외 서버의 다른 포트·VPC 다른 서버·링크 로컬 다른 주소·메타데이터 다른 포트·서버 sshd 두 주소·즉시 거절
  • 같은 bridge 의 옆 컨테이너는 커널 설정(br_netfilter)에 따라 갈림. 켜진 로컬은 거절, 꺼진 CI 러너는 통과
  • Docker 재시작·재부팅 흉내(규칙 전부 비움 뒤 적용 스크립트를 Docker 보다 먼저)·실패 시 원복·IPv6 거부·컨테이너 없음·--remove
  • 운영 컨테이너가 벽에 계속 걸리는 중에 적용해도 확인 통과. 시험 netns·카운터 규칙은 남지 않음
• 음성 대조: DNS 예외를 뺀 사본은 확인에서 걸려 벽을 걷고 exit 1
• 두 운영 서버에서 같은 규칙 묶음을 iptables-restore --test 로 검사만 함(적용 0)
  • LOG·tcp-reset·conntrack·limit 전부 수용
• systemd 단위는 Ubuntu 24.04 의 systemd 255 로 systemd-analyze verify 통과
• 위험: 커널 로그(piki-wall:)는 dind 에서 볼 수 없어 운영 서버에서 처음 확인
• 위험: 컨테이너 자기 loopback 은 서버 방화벽 밖. 각 서비스 앱 검사가 맡음
• 위험: 같은 bridge 의 옆 컨테이너도 운영 서버에서는 방화벽 밖 (두 서버 br_netfilter 꺼짐 실측)
  • 옆 컨테이너는 같은 서비스의 다른 슬롯뿐이라 자기 loopback 과 같은 표면
  • 대안: 블록이 br_netfilter 를 켬
    • 기각: 막는 표면이 늘지 않고 모든 bridge 트래픽이 iptables 를 지나는 비용만 생김
• 위험: 부팅 때 적용이 실패해도 알림이 없음. Docker 는 벽 없이 컨테이너를 띄우고 다음 배포가 다시 검
  • 대안: RequiredBy=docker.service
    • 기각: 벽 적용 실패가 서비스 중단으로 번짐. 앱 판정이 남아 있어 가용성을 택함
• 위험: DNS 예외는 서버의 리졸버 설정에서 읽음. 컨테이너가 받은 값과 어긋나면 확인도 같은 값으로 찔러 못 잡음. 지금 두 서버는 둘 다 10.0.0.2

후속

• renderer·extractor PR 이 이 블록과 정본을 소비
  • 머지 순서: 이 PR, TeamPiKi/renderer#69, SSRF 검사를 직접 가져오기 한 곳으로 정리 extractor#112
  • 이 PR 머지 뒤 두 PR 의 CI 를 다시 돌려 확인

---

연관 이슈

• close SSRF 내부 대역 정본과 서버 벽 블록 추가 #137

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: ab8da63e-e864-4947-99a2-bf0d9c34fcb5

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}