Skip to content

BaffledJimmy/NebulaPOC

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 
 
 

Repository files navigation

NebulaPOC - Nebula Mesh Networking for Red Team Operations

This project demonstrates Nebula mesh networking for offensive security use cases, showing how to establish encrypted overlay networks across network boundaries. Based on the concepts from Ideas for Meshed and Resilient Implant Communications.

Labs Overview

Lab Description Key Feature
Lab 1 External Lighthouse External operator access, socat proxy for isolated nodes
Lab 2 Internal Lighthouse Dynamic discovery, unprivileged lighthouse on DMZ
Lab 3 Air-Gap Bridge Store-and-forward C2, auto-reconnection

Prerequisites

Required Software

  • AWS CLI with configured credentials (aws configure)
  • Terraform >= 1.0
  • Ansible >= 2.9
  • SSH client

SSH Key Setup

The labs require an SSH key pair for EC2 access. Create one at ~/.ssh/nebula-lab:

# Generate SSH key pair (if you don't have one)
ssh-keygen -t ed25519 -f ~/.ssh/nebula-lab -N "" -C "nebula-lab"

# Verify the key exists
ls -la ~/.ssh/nebula-lab*
# Should show: nebula-lab (private) and nebula-lab.pub (public)

Note: The Terraform configurations expect the key at ~/.ssh/nebula-lab. If you use a different path, update variables.tf in each lab.

Quick Start

# 1. Clone the repository
git clone https://github.com/BaffledJimmy/NebulaPOC.git
cd NebulaPOC

# 2. Generate SSH key (if needed)
ssh-keygen -t ed25519 -f ~/.ssh/nebula-lab -N "" -C "nebula-lab"

# 3. Deploy a lab (example: Lab 1)
cd labs/lab1-external-lighthouse/terraform
terraform init && terraform apply -auto-approve

# 4. Wait for instances to initialize
sleep 60

# 5. Configure with Ansible
cd ../ansible && ansible-playbook -i inventory.ini site.yml

# 6. Run tests
ansible-playbook -i inventory.ini ../tests/test-connectivity.yml

# 7. Destroy when done
cd ../terraform && terraform destroy -auto-approve

Lab Comparison

Aspect Lab 1 (External) Lab 2 (Internal) Lab 3 (Air-Gap)
Lighthouse External (internet) Internal (DMZ) Internal (DMZ)
Discovery Static + socat Dynamic Dynamic
External Traffic Yes Minimal Minimal
Operator OpsBox (external) OpsBox (external) OpsBox (external)
Use Case External C2 Post-exploitation Air-gap bridge
Special Feature unsafe_routes Unprivileged relay Store-and-forward

Key Concepts

TUN Interface Nuance (Critical!)

  • ICMP pings work to ALL nodes - even without TUN (Nebula protocol-level)
  • TCP connections only work to nodes WITH TUN - this is the true test
  • Nodes with tun.disabled: true can relay but cannot route traffic

Node Roles

Role TUN Description
Lighthouse Optional Peer discovery service
Relay Optional Forwards traffic for NAT traversal
OpsBox Required Operator workstation with mesh access
Implant Required Target nodes with full mesh routing

unsafe_routes

Route traffic to non-Nebula hosts through a gateway node:

tun:
  unsafe_routes:
    - route: 192.168.100.0/24
      via: 10.50.10.20  # Gateway node

Nebula IP Addressing (All Labs)

Nebula IP Lab 1 Lab 2 Lab 3
10.50.10.5 lighthouse1 - -
10.50.10.6 opsbox1 opsbox1 opsbox
10.50.10.10 relay relay (LH) relay (LH)
10.50.10.20 isolated1 isolated1 mobile-node
10.50.10.21 isolated2 isolated2 -

Documentation

  • AI_UP_TO_SPEED.md - Comprehensive technical context for AI assistants
  • diagrams.md - Mermaid architecture diagrams
  • Individual lab READMEs in each lab directory

Acknowledgments

  • Slack Nebula - The mesh networking tool
  • Concepts inspired by state-level implant architectures (see blog post)

About

Repo to the corresponding blog post about implant P2P communications.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published