Guides on nuteo.info

CrowdSec: collaborative intrusion prevention

Mon, 03 Aug 2026 00:00:00 +0000

CrowdSec: collaborative intrusion prevention

fail2ban works, but it’s solo — every server sees the same SSH brute-force attempts independently. CrowdSec fixes that: when one server bans an IP, all CrowdSec users benefit from the shared blocklist.

Install

# CrowdSec engine
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
apt install -y crowdsec

# Caddy bouncer (rejects bad IPs at the reverse proxy level)
apt install -y crowdsec-caddy-bouncer

CrowdSec auto-detects running services and activates parsers. For a stock setup, it will parse SSH, Caddy, and Nginx logs out of the box.

Setting up a VPS for production: the 2026 playbook

Mon, 03 Aug 2026 00:00:00 +0000

Setting up a VPS for production

Every time I set up a new VPS, I do the same dance: patch it, lock it down, deploy Docker, set up backups. This guide is the playbook — every step I actually run, in order.

0. Pre-flight

Before I SSH in for the first time, I always:

Set the hostname in the cloud console
Add my SSH key (not password!)
Note the public IPv4 and private IP (if VPC)
Create a DNS A record pointing to the public IP

1. First 60 seconds

apt update && apt upgrade -y
apt install -y ufw fail2ban unattended-upgrades curl wget git htop vim
timedatectl set-timezone Asia/Bangkok

Set timezone first. Logs mean nothing without correct timestamps.

Uptime monitoring with Uptime Kuma

Mon, 03 Aug 2026 00:00:00 +0000

Uptime monitoring with Uptime Kuma

Uptime Kuma is the self-hosted alternative to UptimeRobot / Pingdom. It’s a single Docker container, has a beautiful UI, and supports every monitor type I actually need.

Deploy

# docker-compose.yml
version: "3.8"
services:
 uptime-kuma:
 image: louislam/uptime-kuma:1
 container_name: uptime-kuma
 restart: unless-stopped
 volumes:
 - uptime_data:/app/data
 - /var/run/docker.sock:/var/run/docker.sock:ro
 ports:
 - "127.0.0.1:3001:3001" # Bind to localhost only
volumes:
 uptime_data:

Then expose it via Caddy on a private subdomain (e.g. status.internal.example.com) behind your WireGuard VPN.

WireGuard VPN for admin access

Mon, 03 Aug 2026 00:00:00 +0000

WireGuard VPN for admin access

Once your VPS is in production, you don’t want to expose admin UIs (Grafana, Netdata, internal tools) to the public internet. WireGuard gives you a private tunnel to your VPS — only clients with the right keys can reach those services.

Server setup

apt install -y wireguard

# Generate server keys
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key

# Server config
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = $(cat /etc/wireguard/server_private.key)
# Forward traffic from VPN clients
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# admin-laptop
PublicKey = <client_public_key>
AllowedIPs = 10.10.10.2/32
EOF

# Enable IP forwarding
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

systemctl enable --now wg-quick@wg0

# Open firewall
ufw allow 51820/udp comment 'WireGuard'

Client setup (macOS, Linux, iOS, Android)

For each client: