T-Pot을 안전하게 운영하기 위한 DMZ 네트워크 설계

2026. 6. 18. 02:52·Network

1. T-Pot이란?

T-Pot은 인터넷에서 들어오는 공격 시도를 관찰하기 위한 허니팟 통합 플랫폼

허니팟은 실제 운영 서버가 아니라 공격자를 유도하고 행동을 기록하기 위한 보안 관찰 환경

이 플랫폼은 하나의 서비스만 실행하는 구조가 아니라 여러 허니팟과 로그 분석 도구를 함께 실행하는 구조

예를 들어 SSH 공격은 Cowrie 같은 가짜 SSH 환경에서 받고, 

웹이나 악성코드 관련 시도는 다른 허니팟 서비스가 담당하는 방식

겉으로는 공격자가 실제 서버에 접근한 것처럼 보이지만, 

내부적으로는 가짜 서비스와 상호작용하도록 만든 구조임.


중요한 점은 이 장비가 OS 자체가 아니라 Linux 위에서 Docker 컨테이너 여러 개로 동작하는 보안 플랫폼이라는 점

Linux OS 위에 Docker가 있고, 그 위에서 여러 허니팟 컨테이너와 로그 분석 도구가 실행되는 구조

 

2. 왜 별도 VLAN과 DMZ가 필요한가

허니팟은 일반 서버와 성격이 완전히 다른 장비

일반 서버는 공격을 방어해야 하는 대상이지만, 허니팟은 공격을 일부러 받아 관찰하는 대상

따라서 내부 서비스망이나 관리자망과 같은 공간에 두면 위험한 구조

(진짜 큰일나는겁니다)

만약 허니팟 서버가 내부 LAN과 같은 VLAN에 있다면 공격자가 장비를 악용했을 때 

내부 서버, NAS, DB, NPM, 관리 페이지 등으로 이동할 가능성이 생기는 구조

이런 공격 흐름을 측면 이동이라고 부름.

측면 이동은 공격자가 한 장비를 발판으로 삼아 같은 네트워크 안의 다른 장비로 옮겨가는 공격 방식

따라서 허니팟 서버는 반드시 별도의 DMZ VLAN에 보수적으로 단독 배치하는 것이 안전한 구조.

공인 IP를 따로 쓰는 것은 외부에서 들어오는 주소를 분리하는 것

VLAN과 DMZ로 나누는 것은 내부에서 움직일 수 있는 범위를 제한하는 것

공인 IP 분리와 VLAN 격리는 서로 다른 목적을 가진 보안 설계

 

3. 현재 네트워크 기준 목표 구조

현재 네트워크는 외부 트래픽이 먼저 OPNsense를 거친 뒤 기존 서비스망 또는 DMZ로 분기되는 구조.

기존 서비스는 OPNsense에서 NPM or 내부망으로 전달되는 구조

허니팟으로 들어오는 공격 트래픽은 OPNsense에서 별도 VLAN으로 전달하는 구조가 적절

전체 흐름은 아래와 같은 형태

Internet → OPNsense WAN → 기존 서비스용 포트포워딩 → NPM → 서비스

Internet → OPNsense WAN → 허니팟용 포트포워딩 → VLAN4 DMZ → 허니팟 서버

관리자  → WireGuard VPN 또는 관리 VLAN → 허니팟 관리페이지 포트

이 구조에서 핵심은 공격자용 경로와 관리자용 경로를 분리하는 것

공격자는 WAN 포트포워딩을 통해 관찰용 포트로 들어오게 하는 구조

관리자는 WAN에서 직접 접속하지 않고 VPN 또는 관리망을 통해서만 접속하는 구조

 

4. 권장 IP 설계

DMZ는 기존 LAN과 다른 VLAN 및 다른 IP 대역으로 구성하는 방식이 적절함.

예시 구조는 아래와 같음.

VLAN1 LAN: 기존 서비스망.

VLAN1 대역: 192.168.10.0/24.

VLAN4 DMZ: 허니팟 전용망.

VLAN4 대역: 192.168.40.0/24.

OPNsense VLAN4 IP: 192.168.40.1.

허니팟 서버 IP: 192.168.40.10.

허니팟 서버 Gateway: 192.168.40.1.

허니팟 서버 DNS: 1.1.1.1 또는 8.8.8.8.

VLAN4에는 허니팟 서버만 두는 것이 가장 안전한 방식

같은 VLAN 안의 장비끼리 통신할 때는 OPNsense 방화벽을 거치지 않을 수 있기 때문

따라서 VLAN4에는 허니팟만 두는걸로

 

5. OPNsense는 게이트웨이이지 관리 대상이 아님

허니팟 서버의 기본 게이트웨이가 192.168.40.1이라는 것은 인터넷으로 나갈 때 OPNsense를 통과한다는 의미임.

이 말이 OPNsense 관리 페이지에 접속한다는 뜻은 아님.

예를 들어 외부 GitHub 서버로 HTTPS 접속을 하면 최종 목적지는 GitHub의 공인 IP임.

이때 OPNsense는 다음 홉이자 라우터 역할을 하는 구조임.

OPNsense를 게이트웨이로 통과하는 것과 OPNsense 자체에 접속하는 것은 서로 다른 개념임.

허니팟 서버 → 8.8.8.8:443은 인터넷으로 나가는 통신

허니팟 서버 → 192.168.40.1:443은 OPNsense 관리 페이지로 접속하는 통신

전자는 필요한 경우 허용할 수 있는 통신

후자는 반드시 차단해야 하는 통신

 

6. WAN 포트포워딩 설계

외부 공격 트래픽은 OPNsense의 Port Forward를 통해 DMZ 서버로 유도하는 구조


공인 IP를 별도로 사용할 수 있다면 기존 서비스와 충돌을 줄일 수 있는 구조

예시 포트포워딩은 아래와 같음.

 

(포트는 예시)


허니팟용 공인 IP:22 → 192.168.40.10:22.

허니팟용 공인 IP:23 → 192.168.40.10:23.

허니팟용 공인 IP:80 → 192.168.40.10:80.

허니팟용 공인 IP:443 → 192.168.40.10:443.


(허니팟용 공인아이피는 실제로 새로 할당받는 것일수도 있고 기존 공인일 수도 있음)


이 포트들은 공격자를 관찰 환경으로 유도하기 위한 포트

기존 서비스는 기존 공인 IP에서 NPM으로 보내는 구조가 적절

기존 서비스용 공인 IP:80 → NPM:80

기존 서비스용 공인 IP:443 → NPM:443

공인 IP가 하나뿐이면 같은 공인 IP의 443번을 NPM과 허니팟 서버에 동시에 일반 포트포워딩하기 어려운 구조

(하지만 돈이 추가로 든다면 설계해야겠쥬)

따라서 가능하다면 허니팟용 공인 IP를 따로 두는 것이 가장 깔끔한 설계

 

7. 관리 접속 설계

관리 포트는 인터넷에 직접 노출하지 않는 것이 원칙

진짜 SSH 관리 포트와 웹 관리 포트는 VPN 또는 관리 VLAN에서만 접근 가능해야 하는 대상

관리 흐름은 아래와 같은 구조

관리자 PC → WireGuard VPN → OPNsense → VLAN4 DMZ → 관리 포트.

SSH 접속 예시는 아래와 같음.

ssh -p 64295 사용자명@192.168.40.10.

64295는 관리용 SSH 포트 예시

실제 포트는 설치 환경에 따라 다를 수 있으므로 서버에서 직접 확인하는 것이 안전

확인 명령어는 아래와 같음.

sudo ss -tulnp.

 

8. DMZ 방화벽 기본 원칙

DMZ 방화벽 정책은 Default Deny 방식이 적절

Default Deny는 기본적으로 모든 통신을 막고 필요한 통신만 예외적으로 허용하는 방식

이 서버는 공격자를 유도하는 장비이므로 내부망으로 나가는 통신을 최대한 제한해야 하는 대상

허용할 통신은 DNS, NTP, 필요한 HTTPS 정도로 시작하는 것이 현실적인 방식

차단할 통신은 OPNsense 자체 접속, 내부 LAN 접근, 관리망 접근, 사설 IP 대역 접근, 불필요한 인터넷 포트 접근

OPNsense 방화벽 룰은 위에서 아래로 순서대로 검사하는 구조

따라서 차단 룰과 제한된 허용 룰을 먼저 두고, 마지막에 나머지를 차단하는 방식이 적절

 

VLAN4 DMZ 방화벽 룰 예시

VLAN4 인터페이스의 룰 순서는 아래와 같은 구조가 적절

1번 룰은 OPNsense 자체 접속 차단

Action: Block

Interface: VLAN4 DMZ

Source: 192.168.40.10.

Destination: This Firewall

Protocol: any

이 룰은 OPNsense Web UI, SSH, API, 관리 서비스로 접속하는 것을 막는 역할

이 룰은 게이트웨이 통과를 막는 룰이 아님.

 

2번 룰은 외부 DNS 허용

Action: Pass

Interface: VLAN4 DMZ

Source: 192.168.40.10

Destination: 1.1.1.1 또는 8.8.8.8

Protocol: TCP/UDP

Destination Port: 53

DNS는 도메인 이름을 실제 IP 주소로 바꾸기 위해 필요한 기능

 

3번 룰은 외부 NTP 허용.

Action: Pass.

Interface: VLAN4 DMZ

Source: 192.168.40.10

Destination: !RFC1918

Protocol: UDP

Destination Port: 123

NTP는 Network Time Protocol의 줄임말이며 시스템 시간을 동기화하는 기능

공격 로그는 시간이 중요하므로 NTP 허용은 필요한 설정

 

4번 룰은 외부 HTTPS 허용

Action: Pass.

Interface: VLAN4 DMZ

Source: 192.168.40.10

Source Port: any

Destination: !RFC1918

Protocol: TCP

Destination Port: 443


HTTPS는 업데이트, Docker 이미지 다운로드, 외부 저장소 접근, 외부 알림 전송에 필요할 수 있는 통신

외부 HTTPS 접속에서는 출발지 포트가 랜덤 포트이고 목적지 포트가 443번인 구조

따라서 Source Port를 443으로 잡는 것이 아니라 Destination Port를 443으로 잡아야 하는 설정

 

5번 룰은 외부 HTTP 허용이며 선택 사항

Action: Pass.

Interface: VLAN4 DMZ.

Source: 192.168.40.10.

Source Port: any.

Destination: !RFC1918.

Protocol: TCP.

Destination Port: 80.

Description: Allow HTTP outbound if needed.

HTTP 80번은 일부 업데이트 미러나 다운로드 과정에서 필요할 수 있는 포트임.

보수적으로 운영할 경우 평소에는 닫고 필요할 때만 임시로 허용하는 방식도 가능한 구조임.

 

6번 룰은 나머지 전체 차단

Action: Block

Interface: VLAN4 DMZ

Source: 192.168.40.10

Destination: any

Protocol: any

Log: Enable

기본 차단 동작이 있더라도 명시적 Block 룰을 마지막에 두면 로그 확인이 쉬운 구조

 

 

9. 최종 운영 요약

기존 서비스는 OPNsense에서 NPM으로 전달하는 구조

공격 관찰용 트래픽은 OPNsense에서 VLAN4 DMZ로 전달하는 구조

VLAN4에는 허니팟 서버만 단독 배치하는 구조

DMZ 서버에서 OPNsense 자체 주소,기존 LAN, 관리망, 사설 IP 대역으로 가는 통신은 차단하는 구조

DMZ 서버에서 인터넷으로 나가는 통신은 DNS, NTP, 필요한 HTTPS 정도만 허용하는 구조

관리자 접속은 WAN이 아니라 WireGuard VPN 또는 관리 VLAN에서만 허용하는 구조

WAN에서 관리 포트로 직접 들어오는 경로는 만들지 않는 구조

 

10. 핵심 정리

허니팟은 공격자를 관찰하기 위해 일부러 노출하는 장비이므로 기존 서비스망과 같은 공간에 두면 안 되는 장비

안전한 운영의 핵심은 공격자용 포트와 관리자용 포트를 분리하는 것

공격자용 포트는 WAN 포트포워딩으로 DMZ 서버에 유도하는 구조

관리자용 포트는 VPN 또는 관리망에서만 접근하게 하는 구조

DMZ 서버는 내부망과 OPNsense 관리 서비스로 이동하지 못하게 막는 구조

결론적으로 중요한 것은 포트포워딩 자체보다 VLAN 격리와 방화벽 정책

저작자표시 비영리 변경금지 (새창열림)

'Network' 카테고리의 다른 글

TCP 혼잡제어  (0) 2026.06.25
What is Socket with Vibe Coding  (0) 2026.06.19
MTR로 살펴보는 해외 웹사이트 네트워크 지연과 라우팅 경로 분석  (0) 2026.06.01
케이블을 하나하나 따라가며 랩실 랙 네트워크 구조 파악하기  (0) 2026.05.28
BGP Hijacking  (0) 2026.05.21
'Network' 카테고리의 다른 글
  • TCP 혼잡제어
  • What is Socket with Vibe Coding
  • MTR로 살펴보는 해외 웹사이트 네트워크 지연과 라우팅 경로 분석
  • 케이블을 하나하나 따라가며 랩실 랙 네트워크 구조 파악하기
heishooni@gmail.com
heishooni@gmail.com
Linux, Cloud, Network 핵심 이론과 실무 구축 과정을 기록합니다. 인프라 엔지니어를 지향하는 기술 블로그이자 트러블 슈팅 저장소입니다.
  • heishooni@gmail.com
    heishooni
    heishooni@gmail.com
  • 전체
    오늘
    어제
    • 분류 전체보기 N
      • Network N
      • Infra
      • 개인공부
        • network
        • OS
        • Java
        • Dokcer
        • Linux
        • 컴퓨터구조
      • TroubleShooting
      • Personal
  • 블로그 메뉴

    • 홈
    • 방명록
  • 공지사항

  • 인기 글

  • 최근 글

  • 링크

    • https://github.com/heishooni
    • https://hooni.nangman.cloud/
  • 태그

    네트워크 #network #CGNAT
    homelab
    hushlogin
    Last login
    ipsec
    CML
    opnsense
    WISOFT
    NangmanInfra
    network
    physical-layer
    T-pot
    troubleshooting
    Devian
    zsh
    Stateful
    터미널 꾸미기
    Infra
    Incident
    bgp hijacking
    KIRO
    hyperplane
    OS
    proxmox
    네트워크
    WireGuard
    reverse-proxy
    teleport
    AWS Summit
    개발자 설정
  • hELLO· Designed By정상우.v4.10.6
heishooni@gmail.com
T-Pot을 안전하게 운영하기 위한 DMZ 네트워크 설계
상단으로

티스토리툴바