secdev02/cyber-decoy실험적 유인 브로커
컨테이너화된 네트워크 디코이(허니팟)로, SSH, RDP 및 SMB를 광고하고, eBPF로 모든 인바운드 연결을 관찰하며, 각 세션을 격리된 디코이 컨테이너로 리버스 프록시합니다.
설계는 두 가지 관심사를 분리합니다:
이는 귀하가 소유하거나 모니터링할 권한이 있는 네트워크에서 무단 활동을 탐지하고 연구하기 위한 방어 도구입니다. 해당 권한이 있는 경우에만 배포하십시오.
flowchart TB
A["공격자 / 스캐너"]
subgraph host["디코이 호스트"]
direction TB
NIC["broker eth0<br/>게시됨: 22, 3389, 445"]
subgraph brk["broker 컨테이너"]
direction TB
E["eBPF TC 분류기<br/>모든 SYN 기록<br/>실제 소스 IP 확인"]
P["리버스 프록시<br/>백엔드에 CONNECT"]
L["구조화된 JSON 로그"]
end
subgraph dec["decoynet (내부, 호스트 경로 없음)"]
direction LR
S["ssh-decoy<br/>OpenCanary ssh<br/>포트 2222"]
D["rdp-decoy<br/>OpenCanary rdp<br/>포트 3389"]
M["smb-decoy<br/>Impacket SMB 서버<br/>포트 445"]
end
end
A --> NIC
NIC --> E
NIC --> P
E --> L
P --> S
P --> D
P --> M
총 4개의 컨테이너:
| 컨테이너 | 역할 | 네트워크 |
|---|---|---|
broker | 공용 전면 도어: eBPF 관찰 및 리버스 프록시 | edge + decoynet |
ssh-decoy | OpenCanary ssh 모듈 (실제 핸드셰이크, 자격 증명 캡처) | decoynet 전용 |
rdp-decoy | OpenCanary rdp 모듈 (NLA 모방, 사용자 이름 캡처) | decoynet 전용 |
smb-decoy | Impacket SimpleSMBServer (실제 SMB2/3, 인증 캡처) | decoynet 전용 |
디코이는 호스트 또는 외부 세계로의 경로가 없는 내부 Docker 네트워크(decoynet)에 있습니다. 브로커만이 디코이에 도달할 수 있습니다. 공격자가 디코이 내부에서 하는 어떤 것도 호스트 네트워크에 직접 도달할 수 없습니다.
브로커는 호스트에 포트 22, 3389 및 445를 게시하므로 인바운드 패킷은 브로커의 eth0에 도착합니다. 그런 다음 각 패킷에 대해 두 가지 작업이 발생합니다:
broker/bpf/decoy.bpf.c)은 이더넷, IP 및 TCP 헤더를 구문 분석하고 각 새 연결 시도(SYN 설정, ACK 지움)에 대해 conn_event를 링 버퍼에 기록합니다: 소스 IP 및 포트, 대상 포트, TCP 플래그, 포트가 광고된 서비스인지 여부. 패킷은 변경 없이 통과됩니다(TC_ACT_OK).CONNECT와 동등한 작업을 수행한 다음 양방향으로 바이트를 릴레이합니다.advertised_ports eBPF 맵은 시작 시 config.yaml에서 채워지므로 분류기는 프로브가 제공된 포트에 도달했는지 원치 않는 포트에 도달했는지 태그할 수 있습니다. 이를 통해 세 개의 포트만 프록시되더라도 수평 포트 스캔이 보이게 됩니다.
"모든 것이 열려 있다"고 광고하고 임의의 대상 포트를 브로커로 보내려면 분류기를 확장하여 대상 포트를 다시 쓰거나 TPROXY / bpf_sk_assign 리디렉션을 사용하십시오. 현재 버전은 패킷 경로를 그대로 유지하고 관찰에만 제한되며, 이는 더 안전한 기본값입니다.
cyber-decoy/
├── README.md
├── docker-compose.yml # 4-컨테이너 스택
├── docker-compose.override.yml # 로컬 macOS 개발: eBPF cap 없음, 포트 22 재매핑
├── Makefile # build / up / down / bpf 도우미
├── LICENSE
├── scripts/
│ └── setup.sh # 호스트 사전 점검
├── broker/
│ ├── Dockerfile # eBPF 오브젝트 + Go 바이너리 컴파일
│ ├── config.yaml # 광고된 서비스 (구성 가능)
│ ├── go.mod
│ ├── main.go # 진입점
│ ├── bpf/
│ │ └── decoy.bpf.c # eBPF TC 분류기
│ └── internal/
│ ├── config/config.go # 구성 로더
│ ├── proxy/proxy.go # TCP 리버스 프록시
│ └── bpf/loader.go # eBPF 로드 + 연결, 이벤트 스트리밍
└── decoys/ # 세 개 모두 OpenCanary 실행
├── ssh/
│ ├── Dockerfile
│ └── opencanary.conf # ssh 모듈, 포트 2222
├── rdp/
│ ├── Dockerfile
│ └── opencanary.conf # rdp 모듈, 포트 3389
└── smb/
├── Dockerfile # 단일 Python 프로세스, 비루트
├── smb_decoy.py # Impacket SimpleSMBServer + JSON 로깅
└── requirements.txt # impacket (고정됨)
docker-compose.override.yml을 사용하는 경우, !reset / !override 태그에 의존)sudo mount -t bpf bpf /sys/fs/bpf브로커 이미지는 빌드 아키텍처를 감지하고 일치하는 __TARGET_ARCH_* 매크로를 clang에 전달하므로 x86_64 및 aarch64(Apple Silicon, Graviton) 모두에서 빌드됩니다. gcc-multilib는 의도적으로 설치되지 않았습니다. 이는 x86 전용 패키지이며 arm64 후보가 없으며, 이를 포함하면 apt 종료 코드 100으로 arm64에서 빌드가 중단됩니다. eBPF 오브젝트를 컴파일하는 데는 clang 및 libbpf-dev만 있으면 됩니다.
macOS의 Docker Desktop은 호스트 커널이 아닌 LinuxKit VM 내부에서 컨테이너를 실행하므로 TC/TCX eBPF 연결은 일반적으로 작동하지 않습니다. 이는 치명적이지 않습니다. eBPF는 설계상 최선의 노력이므로 브로커는 ebpf disabled: attach failed를 기록하고 리버스 프록시와 세 개의 디코이가 정상적으로 실행되고 로그를 기록합니다. 로컬에서 전체 프록시 경로를 개발하고 테스트한 다음 Linux 호스트에 배포할 때 실제 eBPF 관찰을 얻을 수 있습니다.
docker-compose.override.yml은 자동으로 로드되어 이를 편리하게 만듭니다. eBPF 기능(VM에서 쓸모없음)을 제거하고 macOS의 자체 sshd가 22를 소유하므로 호스트 포트 22를 2022로 다시 매핑합니다.
docker compose up --build # 로컬 개발, override 적용됨
docker compose -f docker-compose.yml up -d # 실제 배포, override 우회
먼저 사전 점검을 실행하십시오:
./scripts/setup.sh
# 1. 네 개의 이미지 모두 빌드 (브로커 이미지 내에서 eBPF 오브젝트 컴파일)
make build
# 2. 스택 시작
make up
# 3. 어떤 일이 발생하는지 확인
make logs
그런 다음 다른 머신(또는 로컬호스트에서 연기 테스트)에서 프로브하십시오:
ssh -p 22 user@DECOY_HOST # SSH 디코이에 도달
nc DECOY_HOST 3389 # RDP 디코이에 도달
nc DECOY_HOST 445 # SMB 디코이에 도달
nc DECOY_HOST 8080 # 광고되지 않음: eBPF가 관찰, 프록시 없음
브로커는 eBPF 프로브 이벤트 및 프록시 세션에 대한 JSON을 발행합니다. 각 디코이는 OpenCanary JSON 이벤트를 발행합니다. 자격 증명이 도착하는 것을 보려면:
docker compose logs -f ssh-decoy | grep 4002
배너만 제공하는 스텁과 달리, ssh -p 22 user@DECOY_HOST는 이제 실제 키 교환을 완료하고 암호를 요구합니다. 모든 시도가 캡처됩니다. 서비스 핑거프린트가 버전 검색에서 유지되는지 확인하십시오:
nmap -sV -p 22,3389,445 DECOY_HOST
정리:
make down
서비스는 broker/config.yaml에 정의됩니다. 각 항목은 독립적으로 전환 가능하고 재매핑 가능합니다:
services:
- name: ssh
enabled: true
listen_port: 22
backend: ssh-decoy:2222
서비스를 추가하려면 여기에 항목을 추가하고, docker-compose.yml에서 포트를 게시하고, 디코이 컨테이너를 추가하십시오. 하나를 비활성화하려면 enabled: false로 설정하고(선택적으로 게시된 포트 제거)하십시오.
호스트 포트 22는 일반적으로 호스트의 실제 SSH 데몬이 사용합니다. 실험실의 경우 docker-compose.yml에서 게시된 쪽을 재매핑할 수 있습니다(예: "2022:22"). 스캐너를 거기로 지정하십시오.
세 디코이 모두 OpenCanary(Thinkst)를 실행하며, 각 컨테이너가 정확히 하나의 모듈을 활성화하도록 구성됩니다. 로그는 stdout에 JSON으로 발행되므로 docker compose logs 및 모든 SIEM 전달자가 추가 배관 없이 작동합니다.
| 컨테이너 | OpenCanary 모듈 | 수신 포트 | 실제 수행 작업 |
|---|---|---|---|
ssh-decoy | ssh | 2222 | twisted.conch를 통한 실제 SSH 키 교환. 모든 사용자 이름/암호 쌍을 캡처합니다. |
rdp-decoy | rdp | 3389 | NLA 지원 서버를 모방하고 항상 로그인 실패를 반환하며 mstshash 사용자 이름을 추출합니다. |
smb-decoy | Impacket | 445 | 순수 Python SMB2/3 서버. 미끼 공유를 제공하고 연결 및 NTLM 인증 시도를 JSON으로 로깅합니다. |
OpenCanary는 각 이벤트에 숫자 logtype을 태깅합니다. 여기서 볼 수 있는 것들:
| logtype | opencanary/logger.py의 상수 | 의미 |
|---|---|---|
| 1000 | LOG_BASE_BOOT | 데몬 시작 |
| 4000 | LOG_SSH_NEW_CONNECTION | SSH 연결 열림 |
| 4001 | LOG_SSH_REMOTE_VERSION_SENT | 클라이언트가 버전 문자열을 보냄 |
| 4002 | LOG_SSH_LOGIN_ATTEMPT | SSH 로그인 시도 (USERNAME 및 PASSWORD 포함) |
| 5000 | LOG_SMB_FILE_OPEN | SMB 파일 열림 (USER, SHARENAME, FILENAME 포함) |
| 14001 | LOG_RDP | RDP 연결 / 로그인 시도 |
캡처된 SSH 자격 증명은 다음과 같습니다:
{"dst_port": 2222, "logtype": 4002, "node_id": "decoy-ssh",
"src_host": "10.0.0.66", "src_port": 42958,
"logdata": {"USERNAME": "admin", "PASSWORD": "Passw0rd123"}}
이는 브로커 아키텍처의 직접적인 결과이며, 이러한 로그를 읽을 때 이해해야 할 가장 중요한 단일 사항입니다.
브로커는 공격자의 TCP 연결을 종료하고 디코이에 새로운 연결을 엽니다. 따라서 OpenCanary의 관점에서 클라이언트는 브로커입니다. 디코이 이벤트의 모든 src_host는 decoynet의 브로커 주소이며 실제 소스가 아닙니다.
실제 소스 IP는 여전히 캡처되지만 다른 위치에 있습니다: