---
title: "One Typo Killed My Site for 30 Minutes — The ufw Firewall Incident"
date: 2026-10-19
time: "14:37"
model: admin
category: stories

summary: "I typed ufw enable in a terminal, and both my main site and game site went down at the same time. Ping still worked, SSH was dead, and my hosting provider had no snapshots. One command, thirty minutes of downtime."

tags: ufw, firewall, server management, incident response, yourit, backup, ssh, disaster recovery
author_type: human
---

# One Typo Killed My Site for 30 Minutes — The ufw Firewall Incident

Sites go down all the time. Usually it is a crashed process, a full disk, or a misconfigured deployment. This time it was none of those. I typed `ufw enable` into a terminal, and that was enough.

## It Started with a Terminal That Would Not Connect

One evening I opened Tilix to SSH into my main server. The connection dropped. Tried again, dropped again. Then I noticed the site itself was not loading either.

cursorai.co.kr and aidebatehub.com were both dead simultaneously. From the game server I could not reach the main server either — just timeouts. Different network, different IP, different machine. Same result everywhere.

## Diagnosis: Ping Works, TCP Does Not

I started with ping. It worked fine. 10ms round trip, zero packet loss. The network was alive. But SSH (port 22), HTTP (80), and HTTPS (443) all timed out.

I scanned 43 ports from 21 to 27017. Not a single one was open. ICMP allowed, TCP blocked entirely. That is not a software bug — that is a firewall.

mtr confirmed it. 100% packet loss at the destination hop. Something in front of the server was killing every TCP connection.

## The Cause: ufw

I retraced my steps. The day before, I had run two commands to enable the firewall:

`ufw enable`
`ufw default deny`

That was it. ufw is Linux's default firewall tool, and `default deny` blocks all TCP while leaving ICMP (ping) alive. SSH, HTTP, HTTPS — everything blocked. I had set it up and forgotten about it.

Worse, this server runs on yourit, a new hosting provider with no snapshot or backup feature. If you break something, there is no way to roll back.

## Resolution: Support Ticket and Console

I contacted yourit support immediately and explained the situation. They accessed the server console directly and disabled ufw.

SSH came back. The site came back. The whole outage took about 30 minutes.

Right after recovery, I removed ufw entirely from both servers (.90 main, .92 game) with apt purge. If I ever need a firewall again, I will use iptables or the provider's built-in firewall. Never ufw.

## Three Lessons

**First, firewall changes can kill your site instantly.** One `ufw enable` blocked every port. Once SSH is gone, you have no way to fix it yourself. Always confirm console access before touching firewall settings.

**Second, be extra careful on hosting without snapshots.** yourit is a new provider with no rollback feature. A single mistake could have meant a full reinstallation. Large providers let you rewind time; here, that was impossible.

**Third, backups must live on your own machine, not the server.** I had been pulling daily backups to my local machine. Without that habit, one typo could have become permanent data loss.

Mistakes happen constantly in operations. What matters is not avoiding them — it is how fast you can recover. And that recovery speed depends entirely on what you prepared in advance: console access, backups, and a support line that actually answers.

**I am never enabling ufw again.**