nunogrl.com - security

Homelab Network Overview

2024-08-01T00:00:00+01:00

My homelab network is designed to provide a secure, efficient, and self-hosted environment for various automation, development, and personal infrastructure needs. This setup prioritizes network segmentation, security, and performance optimization, while being flexible enough to scale or adapt for experimentation.

Problem & Solution

Problem: I needed a reliable and secure environment for automation, CI/CD testing, Git hosting, and local infrastructure— without relying on cloud platforms or exposing services to the internet.

Additionally, the solution had to run on low-powered, repurposed hardware with minimal overhead and support remote access, internal DNS resolution, and segmented security domains.

Solution: I architected a network centered around an OpenWRT-based router with VLAN segmentation, isolated zones for each function, and layered services:

Tailscale provides secure access to internal services, even when offsite.
Cloudflare Tunnel allows for secure access to internal services from the internet.
AdGuard Home filters DNS-based ads and trackers at the router level.
TinyDNS + BIND handle authoritative DNS within the homelab.
Traefik serves as the reverse proxy using a wildcard cert via DNS verification.
Prometheus + Grafana provide observability for all infrastructure nodes.
A D-Link 3782 router is used as a wireless bridge to isolate the IoT network.

The OpenWRT router also provides wireless access to mobile and personal devices, which are segmented into their own VLAN. These include laptops, phones, and tablets used for managing or testing infrastructure services.

For mobile devices, Syncthing is used to selectively back up content to the NAS. While backups are not fully automated, this gives more control over what is stored. I am considering adding a backup option to Dropbox for external redundancy.

The entire infrastructure is provisioned via Ansible playbooks, which manage deployment and configuration across the environment. These playbooks live on an internal Git server and may be shared publicly in the future.

The system emphasizes modularity, resilience, and observability, ensuring that each component is isolated but observable.

Full Network Topology (Combined)

flowchart TD %% ingress egress Internet --> Router Router -->|VPN: Site2Site| VPNCloudflare Router -->|VPN: host| VPNTailscale %% DNS Router -.-> AdGuard AdGuard -.-> BIND BIND -.-> TinyDNS %% Traefik --> Router %% Traefik --> IoT_Bridge %% Prometheus --> NAS %% Prometheus --> Server1 %% Prometheus --> CIService %% Prometheus --> Router %% Grafana --> Prometheus Router ==>|VLAN: NAS| NAS Router ==>|VLAN: Dev| Server1 Router ==>|VLAN: CI| Zeus Router ==>|VLAN: IoT| IoT_Bridge Router ==>|VLAN: WiFi| Wireless_Clients IoT_Bridge -->|Wireless| IoT_Devices %%subgraph rproxy [reverse proxy] %% Traefik --> GitServer %% Traefik --> CIService %% Traefik --> Grafana %% Traefik --> Syncthing %% Traefik --> Portainer %% Traefik --> Prometheus %% Traefik --> NASUI %% Traefik --> binrepo %% end %% description VPNCloudflare((VPN fa:fa-lock cloudflared tunnel)) VPNTailscale((VPN fa:fa-lock tailscale server )) Router{{Router}} IoT_Bridge{{IoT Bridge}} Internet(((Internet fa:fa-cloud))) %% NASUI([homepage fab:fa-docker]) %% GitServer([git fab:fa-docker]) %% CIService([CIService fab:fa-docker]) %% Grafana([grafana fab:fa-docker]) %% Portainer([Portainer fab:fa-docker]) %% Traefik([traefik fab:fa-docker]) %% Syncthing([Syncthing fab:fa-docker]) %% Prometheus([Prometheus fab:fa-docker]) %% binrepo([Binary Repo fab:fa-docker]) Server1[Raspberry Pi] %% styles classDef default fill:#f9f,stroke:#333,stroke-width:1px; classDef net fill:#fff; classDef hardware fill:#f96; classDef dns fill:#AFF; classDef container fill:#EF0; classDef vpn fill:#EF0; classDef network fill:#CCCCCC; Internet:::net VPNCloudflare:::vpn VPNTailscale:::vpn AdGuard:::dns BIND:::dns TinyDNS:::dns Router:::network IoT_Bridge:::network NAS:::hardware Server1:::hardware Zeus:::hardware Wireless_Clients:::hardware IoT_Devices:::hardware %% NASUI:::container %% GitServer:::container %% CIService:::container %% binrepo:::container %% Grafana:::container %% Portainer:::container %% Traefik:::container %% Syncthing:::container %% Prometheus:::container

This shows how DNS resolution, secure access, proxy routing, and monitoring interconnect.

Layered Views (Progressive Breakdown)

VPN

%% styles classDef default fill:#f9f,stroke:#333,stroke-width:1px; classDef net fill:#fff; classDef vpn fill:#EF0; classDef network fill:#CCCCCC; flowchart TD Internet -->|VPN: Cloudflare| VPNCloudflare Internet -->|VPN: Tailscale| VPNTailscale subgraph cf [cloudflare VPN tunnels] InternetCF -.-> |https ingress|cloudflare cloudflare -.-> |http|vaultvpn cloudflare{{cloudflare pulsingminds}} cloudflare --- Londonvpn cloudflare --- hetznervpn cloudflare --- vaultvpn end Londonvpn((VPN fa:fa-lock London Tunnel)) hetznervpn((VPN fa:fa-lock Hetzner Tunnel)) vaultvpn((VPN fa:fa-lock vault Tunnell)) InternetCF(((Internet fa:fa-cloud))) InternetCF:::net cloudflare:::network Londonvpn:::vpn hetznervpn:::vpn vaultvpn:::vpn InternetTS --- tailscale tailscale{{Tailscale}} tailscale --- Londonts tailscale --- magits tailscale --- capricets tailscale --- mobilets end Londonts((VPN fa:fa-lock London Tunnel _route propagation_)) magits((VPN fa:fa-lock Hetzner Tunnel)) capricets((VPN fa:fa-lock laptop Tunnell)) mobilets(((VPN fa:fa-lock mobile Tunnel))) InternetTS(((Internet fa:fa-cloud))) tailscale:::network Londonts:::vpn magits:::vpn capricets:::vpn mobilets:::vpn

DNS Resolution Flow

flowchart TD Client --> AdGuard AdGuard --> BIND BIND -.-> I BIND -.-> L BIND --> TinyDNS BIND -.-> LXC L((Local network)) I((Internet)) LXC((LXC_Containers))

Traefik Reverse Proxy Flow

flowchart TD Internet -->|DNS Challenge| Traefik Traefik --> GitServer Traefik --> Grafana Traefik --> CIService Traefik --> binRepo Traefik --> Syncthing Traefik --> Portainer Traefik --> RouterUI Traefik --> NASUI Traefik --> IoT_Bridge

Prometheus Monitoring Flow

flowchart TD Prometheus --> NAS Prometheus --> Server1 Prometheus --> CIService Prometheus --> Router Prometheus --> IoT_Bridge Grafana --> Prometheus

Each layer can be inspected individually or in combination via Grafana dashboards and log collectors. This layered view mirrors how the infrastructure is designed, monitored, and interacted with.

Enforcing GPG-Signed Commits in Git

2024-03-21T00:00:00+00:00

🚀 Problem & Solution

📌 Context / Backstory

In our collaborative development environment, we discovered that Git's flexibility allows commits under any name and email. This became a security concern when we realized that GitHub identifies users by email, not SSH keys.

sequenceDiagram participant Alice participant Bob participant GitHub Alice->>GitHub: Commit signed with alice@example.com (GPG signed) GitHub->>GitHub: Shows "Verified" commit from Alice Bob->>GitHub: Commit using alice@example.com (no signature) GitHub->>GitHub: Shows commit as from "Alice" (Unverified) Note over GitHub: GitHub matches commits by email, not by SSH or true identity.

⚠️ The Problem

Anyone with repository access can spoof another contributor's identity
Commit history could be manipulated without detection
No cryptographic proof of commit authenticity
GitHub's user identification relies solely on email addresses

💡 The Solution

We implemented mandatory GPG-signed commits, which:

Cryptographically verify commit authenticity
Prevent identity spoofing
Create traceable commit history
Integrate with GitHub's verification system

👥 Who This Helps

Security-conscious development teams
Open-source project maintainers
Regulated environments requiring audit trails
Organizations needing verified commit history

⚙️ Technical Implementation

Let's visualize the GPG signing workflow:

flowchart LR C[Commit] -->|Sign| G[GPG Key] G -->|Verify| GH[GitHub] subgraph "Local System" C G end subgraph "Remote" GH end style GH fill:#f96,stroke:#333 style G fill:#9f6,stroke:#333

1️⃣ Setting Up GPG Keys

# Generate a new GPG key
gpg --full-generate-key

# List your keys
gpg --list-secret-keys --keyid-format=long

2️⃣ Configuring Git

# Configure Git to use your GPG key
$ git config --global user.signingkey <YOUR_KEY_ID>
$ git config --global commit.gpgsign true
$ git config --global gpg.program gpg

3️⃣ GitHub Integration

Export your public GPG key:

$ gpg --armor --export <YOUR_KEY_ID>

Add the key to your GitHub account settings

4️⃣ Enforcing Signed Commits

In GitHub repository settings:

Navigate to Settings > Branches
Add branch protection rule
Enable "Require signed commits"

🛠️ Troubleshooting & Debugging

GPG signing fails: Check gpg-agent configuration
GitHub doesn't show "Verified": Ensure GPG key is added to GitHub
CI/CD issues: Set up proper GNUPGHOME environment
Smart card/YubiKey: Verify proper card reader access

🔁 Optimizations & Best Practices

Use GPG subkeys instead of master keys
Implement regular key rotation
Set up separate signing keys for different contexts
Use environment isolation in CI/CD pipelines
Consider hardware security keys (YubiKey) for key storage

✅ Conclusion & Takeaways

GPG-signed commits provide a robust security layer for Git workflows, ensuring: - Verified commit authenticity - Protected repository history - Clear accountability - Compliance with security best practices

💬 Comments & Next Steps

How do you handle commit verification in your organization? Share your experience or ask questions below!

Password Store with GPG and Git

2024-03-21T00:00:00+00:00

🚀 Problem & Solution

📌 Context / Backstory

We needed a secure way to manage passwords and secrets across multiple servers and team members. Commercial password managers were either too complex, costly, or required external services we wanted to avoid.

⚠️ The Problem

Managing secrets across systems and teams presents several challenges:

Keeping passwords secure yet accessible
Tracking changes and maintaining history
Sharing secrets securely between team members
Avoiding dependency on external services

💡 The Solution

We implemented password-store with GPG encryption and Git integration, providing:

Secure GPG encryption for all secrets
Git-based version control and distribution
Fully local operation with no external dependencies
Command-line interface for automation

👥 Who This Helps

System administrators managing multiple servers
DevOps teams handling shared credentials
Security-conscious users wanting local password management
Teams needing version-controlled secrets

⚙️ Technical Implementation

Let's visualize the password-store workflow:

1️⃣ Generating GPG Keys in Batch Mode

For automated environments:

cat > gpg-server-key.conf <<EOF
%no-protection
Key-Type: default
Subkey-Type: default
Name-Real: Server Automation Key
Name-Email: server@example.com
Expire-Date: 0
%commit
EOF

gpg --batch --generate-key gpg-server-key.conf

2️⃣ Setting Up the Environment

export PASSWORD_STORE_GPG_OPTS="--armor"
export GNUPGHOME=/etc/password-store/.gnupg
export PASSWORD_STORE_DIR=/etc/password-store/store

3️⃣ Initializing the Password Store

mkdir -p "$GNUPGHOME" "$PASSWORD_STORE_DIR"
chmod 700 "$GNUPGHOME" "$PASSWORD_STORE_DIR"
pass init server@example.com

4️⃣ Git Integration

cd "$PASSWORD_STORE_DIR"
git init
git add .
git commit -m "Initial password store"
git remote add origin git@example.com:secrets.git
git push -u origin main

🛠️ Troubleshooting & Debugging

Ensure proper GPG key permissions (700 for directories, 600 for files)
Verify GPG recipient when encryption fails
Check Git remote access rights for sync issues
Monitor Git conflicts when multiple users update simultaneously

🔁 Optimizations & Alternatives

Consider using GPG agent for improved key handling
Implement Git hooks for pre-commit validation
Use Git branches for testing password updates
Consider pass extensions for additional features

✅ Conclusion & Takeaways

Using GPG with password-store provides a flexible, secure, and lightweight method for managing secrets across machines. With Git integration, you get version history, team sharing, and distributed backup—without compromising security.

💬 Comments & Next Steps

How do you manage shared secrets in your infrastructure? Share your experience or ask questions below!

Managing Multiple Git Configurations

2020-08-31T10:00:00+01:00

Introduction

When working with Git across different contexts (personal projects, work repositories), it's crucial to maintain separate configurations to ensure commits are made with the correct identity and settings. This guide demonstrates how to set up and manage multiple Git configurations effectively.

"My dotfiles"

Warning

Using incorrect Git credentials can lead to commits being associated with the wrong identity, which may expose personal email addresses in work repositories or vice versa.

Configuration Structure

flowchart TD A[~/.gitconfig] --> B[~/.gitconfig-personal] A --> C[~/.gitconfig-work] B --> D[Personal Repos] C --> E[Work Repos]

Primary Configuration

The main ~/.gitconfig file serves as the entry point for Git's configuration:

[includeIf "gitdir:~/src/*"]
  path = ~/.gitconfig-work

[includeIf "gitdir:~/src/sandbox/*"]
  path = ~/.gitconfig-personal

[includeIf "gitdir:~/Documents/*"]
  path = ~/.gitconfig-personal

[includeIf "gitdir:~/src/"]
  path = ~/Documents/git-work-precommit

[commit]
  gpgsign = true

[alias]
  lg1 = log \
          --graph \
          --abbrev-commit \
          --decorate \
          --format=format:'%C(bold blue)%h%C(reset) - \
              %C(bold green)(%ar)%C(reset) \
              %C(white)%s%C(reset) %C(dim white)- \
              %an%C(reset)%C(bold yellow)%d%C(reset)' \
          --all
  lg2 = log \
          --graph \
          --abbrev-commit \
          --decorate \
          --format=format:'%C(bold blue)%h%C(reset) - \
              %C(bold cyan)%aD%C(reset) \
              %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''\
              %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' \
          --all

  lg = !"git lg1"
  diffc = diff --color-words=.

  meld = difftool --tool=meld -y
  meldd = difftool --dir-diff --tool=meld
  meldbase = !git meld $(git merge-base origin/master HEAD)
  review = !git fetch $1 $2 && git checkout FETCH_HEAD && git meldbase && true

[core]
  editor = vim

Personal Git Configuration

Create ~/.gitconfig-personal for personal projects:

[user]
    name = Nuno Leitao
    email = example@example.com
    signingkey = 1234ABCD

Work Git Configuration

Create ~/.gitconfig-work for work-related projects:

[user]
    name = Nuno Leitao
    email = example@acme.com
    signingkey = 1234ABCD

GPG Key Configuration

The same GPG key can be used for both configurations:

 $ gpg -K
 /home/nuno/.gnupg/pubring.kbx
 -----------------------------
 sec   rsa4096 2018-05-09 [SC] [expires: 2022-05-09]
       123456789ABCDEFG56780000123456781234ABCD
 uid           [ultimate] Nuno Leitao <example@example.com>
 uid           [ultimate] Nuno Leitao <example@acme.com>
 uid           [ultimate] [jpeg image of size 10099]
 ssb   rsa4096 2018-05-09 [E] [expires: 2022-05-09]

Note

The GPG key is associated with multiple email addresses, allowing it to sign commits for both personal and work accounts.

Key Considerations

Tip

Always verify the active Git configuration before starting work on a new repository
Use git config --list to check current settings
Consider adding repository-specific configurations for special cases

Common Issues

Wrong Email in Commits

If you notice commits with incorrect email:

$ git commit --amend --author="Nuno Leitao <correct@email.com>"
$ git push --force  # Use with caution!

Verifying Configuration

Check active configuration:
```
$ git config --list --show-origin
```

nunogrl.com - security

Homelab Network Overview

Problem & Solution

Full Network Topology (Combined)

Layered Views (Progressive Breakdown)

VPN

DNS Resolution Flow

Traefik Reverse Proxy Flow

Prometheus Monitoring Flow

Enforcing GPG-Signed Commits in Git

🚀 Problem & Solution

📌 Context / Backstory

⚠️ The Problem

💡 The Solution

👥 Who This Helps

⚙️ Technical Implementation

1️⃣ Setting Up GPG Keys

2️⃣ Configuring Git

3️⃣ GitHub Integration

4️⃣ Enforcing Signed Commits

🛠️ Troubleshooting & Debugging

🔁 Optimizations & Best Practices

✅ Conclusion & Takeaways

💬 Comments & Next Steps

Password Store with GPG and Git

🚀 Problem & Solution

📌 Context / Backstory

⚠️ The Problem

💡 The Solution

👥 Who This Helps

⚙️ Technical Implementation

1️⃣ Generating GPG Keys in Batch Mode

2️⃣ Setting Up the Environment

3️⃣ Initializing the Password Store

4️⃣ Git Integration

🛠️ Troubleshooting & Debugging

🔁 Optimizations & Alternatives

✅ Conclusion & Takeaways

💬 Comments & Next Steps

Managing Multiple Git Configurations

Introduction

Configuration Structure

Primary Configuration

Personal Git Configuration

Work Git Configuration

GPG Key Configuration

Key Considerations

Common Issues

Further Reading