피드로 돌아가기
Dev.toInfrastructure
원문 읽기
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)
AI 요약
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. 서비스 기동 전 포트 스캔을 통해 프로토콜 엔진의 실제 초기화 상태 정밀 검증