ufw enable 후 SSH 끊김? 잠긴 서버 긴급 복구 + 안전 설정법

지금 막 sudo ufw enable을 쳤더니 터미널이 멈추고 재접속이 안 되나요? 당황하지 마세요. 거의 모든 경우 복구할 수 있습니다. 지금 당장 막혔다면 → 아래 "3. 긴급 복구 시나리오별 처방"부터 읽으세요. 이미 복구했고 재발 방지가 궁금하다면 "4. 안전한 ufw 셋업"으로 바로 가세요.

VPS와 클라우드 셀프호스팅이 흔해지면서, 서버 운영을 막 시작한 분들이 가장 자주 겪는 사고가 바로 방화벽 자물쇠(self-lockout) 입니다. "보안 좀 챙기자"는 마음으로 방화벽 한 줄 켰을 뿐인데, 정작 본인이 서버에서 쫓겨나는 거죠. 이 글은 두 갈래로 구성됩니다. (1) 지금 막힌 서버에 다시 들어가는 법, (2) 다시는 이런 일이 없도록 ufw를 켜는 올바른 순서.

왜 ufw enable이 내 SSH를 끊는가 — 멘탈모델

ufw(Uncomplicated Firewall)는 켜는 순간 기본 정책을 적용합니다. 기본값은 다음과 같습니다.

# ufw의 기본 정책 (특별히 바꾸지 않았다면 이 상태)
default deny incoming     # 들어오는 연결은 전부 차단
default allow outgoing    # 나가는 연결은 전부 허용

핵심은 default deny incoming 입니다. ufw enable을 실행하는 순간, 명시적으로 허용 규칙(allow)이 없는 모든 인바운드 트래픽이 차단됩니다. 22번 포트(SSH)도 예외가 아니에요. 그러니 SSH allow 규칙 없이 enable하면 새로운 SSH 접속 시도가 전부 막히는 게 정상 동작입니다.

그런데 왜 "지금 열려 있는 창"은 살아 있을까? — 골든타임

여기서 중요한 포인트. 방금 enable을 쳤는데도 현재 터미널이 완전히 죽지 않고 멈춘 듯 살아 있는 경우가 있습니다. 이건 리눅스 커널의 연결 상태 추적(conntrack) 덕분입니다. ufw 기본 규칙에는 보통 이미 맺어진(ESTABLISHED) 연결을 유지하는 룰이 포함되어 있어, enable 직전에 이미 연결된 세션은 잠시 더 유지될 수 있습니다.

즉, 지금 살아 있는 그 SSH 창이 당신의 골든타임입니다. 새 창을 열려고 시도하지 말고(어차피 막힙니다), 지금 열려 있는 창에서 즉시 allow 규칙을 추가하면 별다른 복구 작업 없이 끝납니다.

긴급 복구 시나리오별 처방

(A) 세션이 아직 살아 있을 때 — 가장 행복한 경우

기존 터미널이 멈춘 듯해도 명령이 먹는다면, 바로 SSH를 허용하세요.

# OpenSSH 프로파일로 허용 (가장 권장)
sudo ufw allow OpenSSH

# 또는 포트로 직접 허용
sudo ufw allow 22/tcp

# 적용 확인
sudo ufw status

Status: active와 함께 22번/OpenSSH가 ALLOW로 보이면 끝입니다. 반드시 현재 창을 닫기 전에 새 터미널로 재접속이 되는지 확인하세요. 안 된다면 (B)로 갑니다.

(B) 이미 완전히 잠겼을 때 — 클라우드 콘솔로 우회 진입

SSH가 전혀 안 되면, SSH가 아닌 다른 경로로 OS에 직접 접근해서 ufw를 끄면 됩니다. 클라우드별 경로는 아래 표를 참고하세요.

콘솔로 OS 셸에 들어왔다면, 잠금을 푸는 명령은 단 한 줄입니다.

# 방화벽을 통째로 비활성화 (긴급 복구용)
sudo ufw disable

이제 다시 일반 SSH로 접속한 뒤, 아래 "4. 안전한 셋업" 순서대로 allow를 먼저 넣고 다시 켜면 됩니다.

rescue / 비상 부팅 모드로 들어가야 할 때

콘솔 로그인조차 안 되는 상황이라면(예: SSH 키만 쓰고 콘솔 비밀번호가 없는 경우), 제공사의 rescue 모드(복구 부팅) 로 부팅합니다. 그러면 원래 디스크가 별도 마운트 포인트(예: /mnt)로 붙습니다.

# rescue 환경에서 원래 루트 디스크가 /mnt 에 마운트됐다고 가정
sudo chroot /mnt /bin/bash
ufw disable
exit
# 이후 정상 부팅으로 재기동

(C) 비표준 포트를 쓰는데 22만 허용해서 잠긴 경우

SSH를 2222 같은 비표준 포트로 운영하면서, 무심코 ufw allow 22/tcp만 넣고 enable한 경우입니다. 실제 듣고 있는 포트는 2222인데 방화벽은 22만 열어둔 상황이죠. 콘솔로 들어가 실제 포트를 확인하고 그 포트를 허용하세요.

# SSH 데몬이 실제로 어떤 포트를 듣는지 확인
sudo ss -tlnp | grep ssh
grep -i port /etc/ssh/sshd_config

# 실제 포트(예: 2222) 허용
sudo ufw allow 2222/tcp

다시는 안 막히는 안전한 ufw 셋업

복구했다면 이제 제대로 켤 차례입니다. 핵심은 순서입니다.

⚠️ 절대 순서를 바꾸지 마세요 ① SSH 포트 allow → ② ufw enable enable을 먼저 하면 그 즉시 막힙니다. 특히 2222 등 비표준 포트를 쓴다면 enable 전에 반드시 그 포트를 allow 하세요. 이 한 줄 순서가 self-lockout의 99%를 막아줍니다.

# ✅ 올바른 순서
sudo ufw allow OpenSSH        # (비표준 포트면) sudo ufw allow 2222/tcp
sudo ufw enable               # 여기서 "기존 SSH 끊길 수 있다"는 경고가 떠도 allow를 넣었으면 안전

규칙 진단과 정리

# 규칙을 번호와 함께 보기 (진단의 기본)
sudo ufw status numbered

# 잘못 넣은 규칙은 번호로 삭제 (위에서 확인한 번호 사용)
sudo ufw delete 3

status numbered는 규칙이 꼬였을 때 가장 먼저 봐야 할 명령입니다. 번호가 바뀔 수 있으니 삭제는 항상 직전에 다시 status로 번호를 확인하고 진행하세요.

보안 강화 — 특정 IP만 허용 + brute-force 완화

SSH를 전 세계에 열어두는 대신, 본인 IP만 허용하거나 무차별 대입 공격을 완화할 수 있습니다.

# 특정 IP에서만 22번 SSH 허용 (사무실/집 고정 IP일 때 강력 추천)
sudo ufw allow from 203.0.113.5 to any port 22 proto tcp

# brute-force 완화: 30초에 6회 이상 연결 시 자동 차단
sudo ufw limit ssh

💡 실무 경험 한마디: 처음엔 allow from <내 IP>로 묶고 싶은 마음이 굴뚝같지만, 유동 IP 환경이거나 모바일 테더링으로 접속할 일이 있다면 본인이 또 잠깁니다. 저는 항상 "콘솔 복구 경로가 확실히 동작하는지" 먼저 테스트한 뒤에 IP 제한을 겁니다. 안전망 없이 잠그지 마세요. 고정 IP가 아니라면 limit ssh + 키 인증만으로도 충분히 단단합니다.

ufw 켜기 전 5초 체크리스트

1. SSH 실제 포트를 안다 (ss -tlnp | grep ssh)
2. 그 포트를 enable 전에 allow 했다
3. 콘솔(시리얼/VNC) 복구 경로가 실제로 동작하는지 안다
4. enable 후 현재 창을 닫기 전에 새 창으로 재접속을 확인한다
5. 클라우드 보안그룹에서도 해당 포트가 열려 있는지 확인한다

자주 묻는 질문 (FAQ)

Q. Docker 컨테이너 포트를 열었더니 ufw로 막아도 외부에 노출됩니다. 왜죠? A. Docker는 ufw를 거치지 않고 iptables의 NAT 체인을 직접 조작하기 때문입니다. 그래서 -p 0.0.0.0:8080:80처럼 포트를 퍼블리시하면 ufw deny가 있어도 외부에 뚫립니다. 해결책은 ① 포트를 127.0.0.1:8080:80처럼 로컬에만 바인딩하거나, ② chaifeng/ufw-docker 같은 도구로 /etc/ufw/after.rules에 DOCKER-USER 체인 규칙을 추가해 ufw가 도커 트래픽까지 통제하게 만드는 것입니다. "ufw status가 깨끗한데 포트가 열려 있다"면 십중팔구 Docker가 범인입니다.

Q. sudo ufw allow ssh가 "could not find a profile" 같은 식으로 안 먹혀요. A. allow ssh/allow OpenSSH는 이름→포트 매핑에 의존합니다. ssh는 /etc/services의 22번 매핑을, OpenSSH는 /etc/ufw/applications.d의 애플리케이션 프로파일을 참조해요. 이 매핑이 없거나 손상됐으면 이름이 안 먹힙니다. 가장 확실한 방법은 포트 번호로 직접 지정하는 것입니다: sudo ufw allow 22/tcp. 비표준 포트라면 당연히 sudo ufw allow 2222/tcp로 쓰세요.

Q. 클라우드 보안그룹(Security Group)이 있는데 ufw도 또 켜야 하나요? A. 둘은 역할이 다릅니다. 보안그룹/네트워크 방화벽은 인스턴스 "바깥"의 클라우드 계층에서, ufw는 OS "안"의 호스트 계층에서 동작합니다. 다층 방어(defense in depth) 관점에서 둘 다 두는 게 좋지만, 그만큼 양쪽 모두 해당 포트를 열어야 통신됩니다. SSH가 안 될 때는 ufw뿐 아니라 보안그룹의 인바운드 규칙도 함께 점검하세요. 한쪽만 열고 다른 쪽이 막혀 있으면 연결되지 않습니다.

방화벽 사고는 무섭지만, 원리를 알면 5초면 예방할 수 있습니다. "allow 먼저, enable 나중" 이 한 문장만 기억하세요. 지금 막 복구하셨다면, 위 안전 셋업 명령을 그대로 적용해 다시는 같은 일이 없도록 마무리하시길 바랍니다.