피드로 돌아가기
I Spent Hours Fighting a Silent Subnet Conflict to Build an Isolated ICS Security Lab (And What It Taught Me About the Linux Kernel)
Dev.toDev.to
Infrastructure

Subnet Conflict 해결을 통한 격리된 ICS 보안 샌드박스 구축

I Spent Hours Fighting a Silent Subnet Conflict to Build an Isolated ICS Security Lab (And What It Taught Me About the Linux Kernel)

404Saint2026년 5월 22일6intermediate

Context

EndeavourOS 호스트 기반 GNS3와 Docker 컨테이너를 조합한 OT/ICS 보안 랩 구축 시도. 가상 네트워크 대역과 물리적 호스트 네트워크 대역의 중복으로 인한 Kernel Routing 충돌 및 패킷 드롭 발생.

Technical Solution

  • 호스트 OS의 물리 인터페이스(192.168.1.X)와 가상 네트워크 대역 간의 Subnet Isolation을 위해 10.10.10.0/24 대역으로 전면 재설계
  • 진단 도구가 제거된 Minimal Container 환경에서 /proc/net/tcp 파일을 직접 분석하여 Kernel 수준의 Socket 상태 검증
  • GNS3의 인터페이스 네임스페이스 바인딩 특성을 고려한 전용 Virtual Switch Fabric 구조 적용
  • firewalld의 Cross-zone 트래픽 차단 정책을 회피하기 위한 독립적인 Private Pool 할당
  • Modbus TCP(502) 및 HTTP(8080) 포트의 개방 상태를 nmap으로 검증하여 서비스 가용성 확인

1. 가상 환경 설계 시 호스트 물리 네트워크 대역과 절대 겹치지 않는 고유 Subnet 할당 여부 확인

2. 컨테이너 내 진단 도구 부재 시 /proc 파일 시스템을 통한 커널 상태 직접 조회 방법 숙지

3. 가상 브릿지와 호스트 방화벽(firewalld 등) 간의 트래픽 허용 정책 및 Zone 설정 검토

4. 서비스 기동 전 포트 스캔을 통해 프로토콜 엔진의 실제 초기화 상태 정밀 검증

원문 읽기