방화벽 구성: UFW, iptables와 보안 정책 설계

서버 경보 문자가 잠을 깨웠습니다. 어느 테스트 환경의 데이터베이스에서 비정상적인 스캔 트래픽이 감지된 것입니다. 서버에 접속해 보니 방화벽은 아예 꺼져 있었습니다. 서둘러 켜고 규칙 목록을 확인하자 여기저기서 추가한 테스트 설정으로 뒤죽박죽이었고, SSH 포트에는 속도 제한조차 없었습니다.

이 일은 현실적인 문제를 다시 깨닫게 했습니다. 많은 사람이 방화벽을 구성할 때 명령어 몇 개를 그대로 복사해 끝내거나, UFW와 iptables의 차이조차 모릅니다. 체계적인 보안 정책 설계는 더 말할 것도 없습니다. 이번 글에서는 이 주제를 제대로 살펴보겠습니다.

---

Linux 방화벽은 실제로 어떻게 동작할까

방화벽을 이야기하기 전에 자주 혼동하는 개념인 Netfilter부터 정리해야 합니다. 많은 사람이 iptables 자체가 방화벽이라고 생각하지만 정확하지 않습니다.

Netfilter는 Linux 커널의 네트워크 패킷 처리 프레임워크입니다. 커널 프로토콜 스택의 핵심 지점에 여러 개의 ‘훅(hooks)‘을 두며, 지나가는 모든 네트워크 패킷이 이 훅을 거칩니다. 여기에 차단, 수정, 기록 같은 처리 로직을 연결할 수 있습니다.

iptables, UFW, nftables 같은 도구는 사용자 공간에서 쓰는 구성 인터페이스일 뿐입니다. 이 도구로 작성한 규칙은 결국 Netfilter가 이해할 수 있는 형식으로 변환되어 커널에서 실행됩니다.

비유하자면 Netfilter는 도로 아래에 설치된 배관 밸브 시스템이고, iptables는 구형 수동 손잡이이며, UFW는 터치스크린이 달린 현대식 제어판입니다. 모두 밸브를 여닫을 수 있지만 조작 방식이 전혀 다릅니다.

사용자 공간 도구의 발전

Linux 방화벽 도구는 최근 몇 년 사이 많이 달라졌습니다.

• iptables: 2000년 무렵부터 사용된 전통적인 도구입니다. Netfilter를 직접 조작하므로 문법은 복잡하지만 기능이 강력합니다.
• nftables: 2014년에 도입된 iptables의 현대적인 대안입니다. 문법이 더 일관되고 성능도 뛰어나며, 최신 Ubuntu는 기본 백엔드로 사용합니다.
• UFW(Uncomplicated Firewall): Ubuntu가 2008년에 내놓은 단순화 도구입니다. 기반은 여전히 iptables/nftables지만 명령어가 놀라울 정도로 간단합니다.
• firewalld: Red Hat 계열 배포판의 동적 방화벽 관리 도구입니다. 연결을 끊지 않고 실행 중에 규칙을 수정할 수 있습니다.

이 글에서는 실제 운영에서 가장 많이 쓰이는 UFW와 iptables를 중점적으로 다룹니다. nftables가 더 현대적이기는 하지만 개념은 iptables와 통하므로 iptables를 익히면 nftables로 전환하기도 어렵지 않습니다.

---

UFW: 방화벽 구성을 간단하게

UFW가 인기 있는 이유

iptables를 사용해 본 사람이라면 규칙을 작성할 때 얼마나 조심스러워지는지 압니다. 매개변수 하나를 잘못 입력해 SSH 포트를 막고 서버 밖에 갇힐까 걱정하게 됩니다.

UFW의 설계 철학은 ‘단순함이 최우선’입니다. -A INPUT -p tcp --dport 22 -j ACCEPT처럼 외우기 어려운 문법 없이 명령어 하나로 포트를 열 수 있습니다.

비교해 보겠습니다.

iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW:

ufw allow ssh

차이가 분명합니다. UFW는 프로토콜, 상태 추적, IPv6 같은 세부 사항을 자동으로 처리합니다. 사용자는 ‘SSH를 허용하겠다’고 지정하기만 하면 됩니다.

기본 구성: 처음부터 시작하기

새 서버를 준비했다면 방화벽을 다음 순서로 구성합니다.

1단계: 기본 정책 설정

기본 정책은 ‘어떤 규칙과도 일치하지 않을 때 어떻게 처리할지’를 결정합니다. 보안의 기본 원칙은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽은 허용하는 것입니다.

sudo ufw default deny incoming   # 모든 인바운드 연결 거부
sudo ufw default allow outgoing   # 모든 아웃바운드 연결 허용

이렇게 하면 명시적으로 허용하지 않은 외부 요청은 들어올 수 없습니다. 번거롭다는 이유로 기본값을 allow로 설정하는 경우가 있는데, 그러면 서버는 누구나 드나들 수 있는 문 열린 집과 다르지 않습니다.

2단계: 필요한 포트 허용

여기에는 중요한 함정이 있습니다. 반드시 SSH를 먼저 허용한 뒤 방화벽을 활성화해야 합니다. 그렇지 않으면 원격 연결이 즉시 끊깁니다.

sudo ufw allow ssh        # SSH 허용(포트 22)
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

사용자 지정 SSH 포트(예: 2222)처럼 다른 서비스를 실행한다면 다음과 같이 설정합니다.

sudo ufw allow 2222/tcp

3단계: 방화벽 활성화

sudo ufw enable

시스템에 “This may disrupt existing ssh connections”라는 경고가 표시됩니다. 앞에서 allow ssh를 실행했다면 문제없으므로 y를 입력해 확인합니다.

4단계: 상태 확인

sudo ufw status verbose

출력은 대략 다음과 같습니다.

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Status: active가 보이면 방화벽이 적용된 것입니다.

고급 활용법: 구성을 더 안전하게

애플리케이션 프로필(App Profiles)

UFW에는 매우 유용한 App Profiles 기능이 있습니다. Nginx, Apache, OpenSSH처럼 많이 쓰는 서비스에는 미리 정의된 구성 파일이 제공됩니다.

사용 가능한 프로필을 확인합니다.

sudo ufw app list

출력에는 다음 항목이 포함될 수 있습니다.

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

애플리케이션 이름으로 포트를 바로 열 수 있습니다.

sudo ufw allow 'Nginx Full'

이 명령은 HTTP(80)와 HTTPS(443)를 동시에 허용하므로 규칙을 두 줄로 직접 작성할 필요가 없습니다.

속도 제한: 무차별 대입 공격 방어

SSH 포트는 무차별 대입 공격의 표적이 되기 쉽습니다. UFW에는 속도 제한 기능이 내장되어 있습니다.

sudo ufw limit ssh

이 규칙은 특정 IP가 30초 안에 6회를 초과해 연결을 시도하면 일시적으로 차단한다는 의미입니다. 단순한 allow ssh보다 훨씬 안전합니다.

특정 IP의 접근 제한

데이터베이스 관리 페이지를 회사 내부망에서만 열어야 하는 경우처럼 특정 IP만 서비스에 접근하도록 제한할 수 있습니다.

# 192.168.1.100만 MySQL에 접근하도록 허용
sudo ufw allow from 192.168.1.100 to any port 3306

# 특정 악성 IP 거부
sudo ufw deny from 203.0.113.100

로깅

방화벽 로그는 문제를 진단하는 데 핵심적인 자료입니다.

sudo ufw logging on
sudo ufw logging medium   # 로그 수준: low/medium/high

로그는 /var/log/ufw.log에 저장되며 형식은 대략 다음과 같습니다.

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

[UFW BLOCK]가 보이면 방화벽이 해당 요청을 차단했다는 뜻입니다.

UFW의 한계

UFW는 사용하기 쉽지만 한계도 있습니다.

• NAT와 포트 포워딩: 제한적으로 지원하며 복잡한 구성에는 여전히 iptables가 필요합니다.
• 복잡한 규칙 체인: 사용자 지정 체인이나 중첩 조건을 지원하지 않습니다.
• 내용 기반 필터링: HTTP 요청의 악성 Payload를 필터링하는 등의 작업은 할 수 없습니다.

요구 사항이 이 범위를 벗어나면 iptables로 전환해야 합니다.

---

iptables: 정밀 제어를 위한 강력한 도구

iptables 아키텍처 이해하기

iptables는 UFW보다 복잡하지만 기반 논리는 꽤 명확합니다. 핵심은 ‘테이블-체인-규칙’의 3단계 구조를 이해하는 것입니다.

테이블(Tables)

각 테이블은 서로 다른 유형의 작업을 처리합니다.

• filter 테이블(기본값): 패킷을 필터링하여 허용할지 거부할지 결정합니다.
• nat 테이블: 주소 변환(NAT)을 수행하여 소스 또는 대상 주소를 다시 씁니다.
• mangle 테이블: 패킷의 TOS, TTL 같은 메타데이터를 수정합니다.
• raw 테이블: 예외를 구성해 연결 추적을 우회합니다.

대부분의 환경에서는 filter 테이블만 사용하므로 여기에서도 기본적으로 이 테이블을 다룹니다.

체인(Chains)

체인은 순서대로 실행되는 규칙의 모음입니다. filter 테이블에는 다음과 같은 기본 체인이 있습니다.

• INPUT: 인바운드 패킷(대상 주소가 로컬 시스템)
• OUTPUT: 아웃바운드 패킷(소스 주소가 로컬 시스템)
• FORWARD: 전달 패킷(로컬 시스템은 중계 역할만 수행)
• PREROUTING: 라우팅 전에 처리
• POSTROUTING: 라우팅 후에 처리

일상적인 구성에서는 주로 INPUT과 OUTPUT을 사용하며, FORWARD는 라우터나 게이트웨이로 작동할 때 사용합니다.

규칙 일치 순서

규칙은 위에서 아래로 하나씩 확인하며, 처음 일치한 규칙의 동작을 즉시 실행하고 뒤의 규칙은 더 이상 검사하지 않습니다.

예를 들어 다음 규칙을 살펴보겠습니다.

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

192.168.1.100은 첫 번째 ACCEPT 규칙과 일치해 바로 허용되므로 두 번째 규칙은 확인하지 않습니다. 그러나 순서를 바꾸면 192.168.1.100이 첫 번째 DROP 규칙에 막혀 두 번째 규칙까지 도달하지 못합니다.

따라서 iptables 구성의 핵심 원칙은 구체적인 규칙을 앞에 두고 일반적인 규칙을 뒤에 두는 것입니다.

기본 문법 분석

iptables 명령의 기본 형식은 다음과 같습니다.

iptables -t 테이블명 -A 체인명 일치조건 -j 동작

자주 사용하는 옵션은 다음과 같습니다.

• -t: 테이블 지정(기본값은 filter이며 생략 가능)
• -A: 체인 끝에 규칙 추가(Append)
• -I: 지정 위치에 규칙 삽입(Insert)
• -D: 규칙 삭제(Delete)
• -L: 규칙 나열(List)
• -F: 모든 규칙 비우기(Flush)
• -P: 기본 정책 설정(Policy)

일치 조건

• -s: 소스 IP 주소(예: -s 192.168.1.100)
• -d: 대상 IP 주소
• -p: 프로토콜(tcp, udp, icmp)
• --sport: 소스 포트
• --dport: 대상 포트
• -i: 인바운드 네트워크 인터페이스(예: -i eth0)
• -o: 아웃바운드 네트워크 인터페이스
• -m state --state: 연결 상태 확인

동작(Target)

• ACCEPT: 패킷 허용
• DROP: 응답 없이 패킷 폐기
• REJECT: 거부하고 오류 메시지 반환
• LOG: 로그만 기록하고 차단하지 않은 채 다음 규칙 계속 확인
• RETURN: 현재 체인을 중단하고 상위 체인으로 복귀

실전 구성: 안전한 서버 방화벽

다음은 프로덕션 환경을 위한 전체 구성 절차입니다.

1단계: 기존 규칙 비우기

새 서버에도 기본 규칙이 있을 수 있으므로 먼저 정리합니다.

sudo iptables -F        # 모든 규칙 비우기
sudo iptables -X        # 모든 사용자 지정 체인 삭제
sudo iptables -t nat -F
sudo iptables -t mangle -F

2단계: 기본 정책 설정

UFW와 마찬가지로 인바운드 트래픽을 기본적으로 거부합니다.

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

3단계: 이미 설정된 연결 허용

이 규칙은 특히 중요합니다. 응답 트래픽과 이미 설정된 연결의 데이터가 통과하도록 허용합니다.

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

웹사이트에 접속할 때 보낸 요청은 OUTPUT(기본 ACCEPT)이고 웹사이트의 응답은 INPUT입니다. 이 규칙이 없으면 응답 패킷이 DROP되어 데이터를 받을 수 없습니다.

ESTABLISHED는 이미 설정된 연결을, RELATED는 FTP 데이터 연결 같은 관련 연결을 뜻합니다.

4단계: 필요한 포트 허용

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

5단계: ICMP 제한(선택 사항)

ICMP는 ping에서 사용하는 프로토콜입니다. 일부 보안 정책에서는 ping을 차단합니다.

# ping 허용
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# 또는 ping 거부
sudo iptables -A INPUT -p icmp -j DROP

6단계: 로그 기록

문제 해결을 위해 DROP 전에 LOG 규칙을 추가합니다.

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min은 로그가 폭증하지 않도록 분당 최대 5개만 기록합니다.

7단계: 마지막 DROP 규칙

기본 정책이 이미 DROP이지만 명시적으로 한 줄을 추가하면 더 분명합니다.

sudo iptables -A INPUT -j DROP

8단계: 규칙 저장

iptables 규칙은 기본적으로 영구 저장되지 않아 재부팅하면 사라집니다. Ubuntu/Debian에서는 iptables-persistent를 사용할 수 있습니다.

sudo apt install iptables-persistent
sudo netfilter-persistent save

또는 직접 저장합니다.

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # IPv6 규칙

규칙 상태 확인

sudo iptables -L -n -v --line-numbers

• -n: 숫자로 표시(도메인 이름을 해석하지 않아 더 빠름)
• -v: 상세 모드(패킷 수 표시)
• --line-numbers: 규칙 번호 표시

출력 예시는 다음과 같습니다.

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

---

UFW와 iptables: 무엇을 선택해야 할까

여기까지 읽어도 UFW와 iptables 중 무엇을 써야 할지 고민될 수 있습니다.

핵심 차이: 사용 편의성 vs 유연성

항목	UFW	iptables
명령어 간결성	매우 간단함(ufw allow ssh)	복잡함(iptables -A INPUT -p tcp --dport 22 -j ACCEPT)
학습 곡선	몇 시간이면 시작 가능	깊이 익히는 데 며칠에서 몇 주 필요
기반 메커니즘	iptables/nftables 사용	iptables 직접 조작
성능	동일(모두 Netfilter에 의존)	동일
NAT/포트 포워딩	기본 기능은 지원하지만 복잡한 환경에는 부족	완전히 지원
복잡한 규칙 체인	사용자 지정 체인 미지원	완전히 지원하며 다단계 중첩 가능
애플리케이션 구성	편리한 App Profiles 제공	규칙을 직접 작성해야 함
IPv6	자동 처리	ip6tables로 별도 구성 필요
스크립트 관리	수동 구성에 적합	스크립트를 이용한 대량 배포에 더 적합

성능에 관한 진실

iptables의 성능이 더 좋다고 생각하는 사람이 많지만 실제 기반 메커니즘은 완전히 같습니다. 모두 커널의 Netfilter가 처리합니다. 유일한 성능 차이는 규칙 수에서 생깁니다. 규칙이 많을수록 일치 여부 확인이 느려지지만 중소 규모 서버에는 영향이 크지 않습니다.

선택 기준

UFW를 권장하는 환경:

• VPS, 클라우드 서버, 독립 서버
• 웹 서비스와 API 서비스 배포
• NAT나 포트 포워딩 같은 복잡한 네트워크 요구 사항이 없는 경우
• iptables 문법을 배우고 싶지 않은 비전문 시스템 관리자
• 공격에 대한 긴급 대응처럼 빠른 보안 구성이 필요한 경우

iptables를 권장하는 환경:

• 게이트웨이, 라우터, VPN 서버
• NAT, 포트 포워딩, 로드 밸런싱이 필요한 경우
• 복잡한 규칙 체인과 다단계 조건 판단
• 수십 대의 서버를 스크립트로 관리하는 대규모 배포
• 패킷 내용, 속도, 시간을 기준으로 하는 고급 필터링
• 네트워크 구성을 전담하는 운영팀이 있는 경우

함께 사용해도 될까?

권장하지 않습니다. UFW와 iptables는 모두 같은 Netfilter 규칙을 조작하므로 함께 사용하면 충돌하기 쉽습니다.

예를 들어 iptables로 SSH 포트를 연 뒤 UFW로 SSH를 deny하면 마지막 규칙이 적용되어 서버 접속이 차단될 수 있습니다.

꼭 함께 사용해야 한다면 규칙 순서를 기억해야 합니다. UFW 규칙은 before.rules와 after.rules 사이에 위치하고, iptables로 직접 추가한 규칙은 UFW 기본 규칙에 의해 덮일 수 있습니다.

---

방화벽 보안 정책 설계의 핵심 원칙

도구에 익숙해지는 것은 첫 단계일 뿐입니다. 더 중요한 것은 합리적인 보안 정책을 설계하는 것입니다. 방화벽에 규칙 몇 개를 즉흥적으로 추가하면 허점이 곳곳에 생길 수 있습니다.

원칙 1: 기본 거부(Default Deny)

안전한 구성의 기반입니다.

핵심 개념: 명시적으로 허용하지 않은 것은 모두 거부합니다.

잘못된 접근은 ‘기본 허용’입니다. 모든 것을 먼저 열고 위험한 포트를 하나씩 닫는 방식에는 두 가지 문제가 있습니다.

1. 어떤 포트가 위험한지 모두 알 수 없습니다. 공격자는 65,535개 포트를 전부 스캔합니다.
2. 포트 하나만 빠뜨려도 보안 위험이 남습니다.

올바른 방법은 다음과 같습니다.

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

그런 다음 서비스에 반드시 필요한 포트만 허용합니다. 포트를 열 때마다 이 포트는 어디에 쓰이는지, 소스 IP를 제한할 수 있는지 확인해야 합니다.

원칙 2: 최소 권한 원칙

각 규칙은 한 가지 작업만 수행하고 허용 범위는 최대한 좁아야 합니다.

포트 허용:

• ❌ ufw allow 3306(전 세계 어디서나 MySQL에 연결 가능)
• ✅ ufw allow from 192.168.1.100 to any port 3306(특정 IP만 허용)

서비스 접근:

• ❌ 모든 내부 서비스 포트 허용
• ✅ 외부에 공개할 서비스(Web, API)만 허용하고, 내부 서비스는 사설망이나 VPN으로 접근

SSH 관리:

• ❌ ufw allow ssh(누구나 로그인 시도 가능)
• ✅ ufw allow from 회사IP to any port 22 + ufw limit ssh

원칙 3: 심층 방어(Defense-in-Depth)

방화벽은 만능이 아니라 첫 번째 방어선일 뿐입니다. 완전한 보안 체계에는 여러 방어 계층이 필요합니다.

1. 네트워크 계층 방화벽(UFW/iptables): 악성 트래픽 차단
2. 애플리케이션 계층 방화벽(WAF): SQL 인젝션, XSS 같은 HTTP 계층 공격 필터링
3. 호스트 계층 보호(SELinux/AppArmor): 프로세스 권한 제한
4. 침입 탐지(IDS/IPS): 비정상 동작 실시간 모니터링
5. 정기 감사: 로그 분석과 취약점 스캔

예를 들어 방화벽이 HTTP 80 포트를 허용하면 WAF가 HTTP 요청의 악성 Payload를 검사하고, SELinux가 웹 서버의 파일 접근 권한을 제한합니다. 공격자가 이 세 계층을 모두 통과해야 애플리케이션 계층에 도달하며, 그곳에서도 입력 검증과 권한 확인 같은 코드 보안이 기다리고 있습니다.

원칙 4: 네트워크 분할(Network Segmentation)

대규모 네트워크를 하나의 영역으로 운영해서는 안 됩니다. 목적에 따라 구역을 나눠야 합니다.

대표적인 분할 모델은 다음과 같습니다.

• DMZ(Demilitarized Zone): 웹 서버와 메일 서버처럼 외부에 공개되는 서비스
• 내부망 영역: 데이터베이스, 내부 서비스, 사무 네트워크
• 관리 영역: 운영 관리, 모니터링, 로그

네트워크 분할의 장점은 다음과 같습니다.

1. 장애 격리: DMZ가 침해되어도 공격자가 내부망으로 진입하려면 또 하나의 방어선을 넘어야 합니다.
2. 확산 제한: 한 영역에서 웜이 퍼져도 영역 사이의 방화벽이 확산을 막습니다.
3. 세분화된 권한: 영역에 따라 사용자 접근 권한을 다르게 지정할 수 있습니다.

iptables로 네트워크를 분할할 때는 FORWARD 체인이 핵심입니다.

# DMZ에서 내부망으로: 데이터베이스 접근만 허용
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

원칙 5: 정기 감사와 업데이트

방화벽 구성은 한 번으로 끝나는 작업이 아닙니다.

규칙 검토:

• 매월 점검: 만료된 규칙이 있는지 확인합니다. 테스트 포트를 닫지 않고 남겨 두었을 수 있습니다.
• 분기별 평가: 서비스가 달라진 뒤에도 포트 개방이 타당한지 검토합니다.
• 연간 재구성: 중복 규칙을 정리하고 성능을 최적화합니다.

로그 분석:

• 매주 방화벽 로그를 확인합니다. 어떤 IP가 왜 차단되었는지 살펴봅니다.
• 비정상 트래픽 알림을 설정해 임계값을 넘으면 자동으로 통지합니다.
• 로그에서 공격 출처를 추적해 해당 위험에 맞게 보안을 강화합니다.

변화에 대응:

• 새 서비스 출시: 보안 위험을 먼저 평가한 뒤 포트를 엽니다.
• 공격 발생: 규칙을 조정하고 악성 IP를 차단하며 속도 제한을 추가합니다.
• 서비스 변경: 필요 없는 규칙을 삭제해 공격 표면을 줄입니다.

---

프로덕션 환경 구성 실전: 흔한 함정 피하기

안전한 구성 절차

1단계: 테스트 환경에서 검증

프로덕션 서버에서 새 규칙을 바로 시험하지 마세요. 먼저 테스트 VM이나 개발 환경에서 구성하고 문제가 없는지 확인한 뒤 프로덕션에 적용합니다.

2단계: SSH 비상 통로 확보

구성 전에 SSH 포트가 열려 있는지 확인합니다. 사용자 지정 포트를 사용한다면 다음과 같이 설정합니다.

# UFW
ufw allow 2222/tcp  # 사용자 지정 SSH 포트

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

3단계: 포트를 단계적으로 허용

모든 포트를 한 번에 열지 마세요. 가장 핵심적인 SSH를 먼저 허용해 로그인이 되는지 확인하고, 그다음 웹 포트와 다른 서비스 포트를 차례로 엽니다.

4단계: 구성 변경 기록

방화벽 규칙을 수정할 때마다 다음 정보를 기록합니다.

• 수정 시간
• 수정 내용
• 수정 이유
• 검증 결과

Git으로 규칙 구성 파일을 관리하거나 문서로 기록할 수 있습니다.

흔한 오류와 해결 방법

오류 1: SSH 접속 차단

증상: 방화벽을 활성화하자 SSH 연결이 끊기고 다시 서버에 접속할 수 없습니다.

원인: SSH 포트를 먼저 허용하지 않았거나 규칙 순서가 잘못되어 ACCEPT보다 DROP이 앞에 있습니다.

예방:

1. 구성 전에 현재 SSH 포트를 확인합니다.
2. ufw allow ssh를 먼저 실행하고 ufw enable을 실행합니다.
3. iptables에서는 SSH 규칙이 DROP 앞에 있는지 확인합니다.

긴급 대응:

• VPS: 서비스 제공자의 관리 콘솔로 로그인해 SSH를 우회합니다.
• 클라우드 서버: 서비스 제공자가 제공하는 “Recovery Mode” 또는 “Rescue System”을 사용합니다.
• 물리 서버: 로컬에서 로그인합니다.

오류 2: 잘못된 규칙 순서

증상: 특정 포트에 ACCEPT 규칙을 추가했는데도 연결되지 않습니다.

원인: 규칙 순서 때문에 앞에 있는 DROP이 먼저 일치했습니다.

진단:

iptables -L -n -v --line-numbers

규칙 번호를 확인하고 ACCEPT가 DROP보다 앞에 있는지 살펴봅니다.

해결:

# 잘못된 위치의 규칙 삭제
iptables -D INPUT 3

# 올바른 위치에 삽입
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

오류 3: 구성이 영구 저장되지 않음

증상: 재부팅하면 방화벽 규칙이 모두 사라집니다.

원인: iptables 규칙은 기본적으로 메모리에만 존재하므로 재부팅하면 초기화됩니다.

해결:

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

UFW는 기본적으로 영구 저장되므로 추가 처리가 필요 없습니다.

오류 4: IPv6 누락

증상: IPv4는 정상인데 IPv6로는 접속할 수 없습니다.

원인: iptables는 IPv4만 구성하며 IPv6에는 ip6tables가 필요합니다.

해결:

# IPv6 규칙(IPv4와 유사)
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# 저장
sudo ip6tables-save > /etc/iptables/rules.v6

UFW는 IPv6를 자동으로 처리하므로 별도 구성이 필요 없습니다.

문제 해결 방법

방화벽 구성에 문제가 생기면 다음 순서로 진단합니다.

1. 방화벽 상태 확인

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

방화벽이 활성화되어 있고 규칙이 올바른지 확인합니다.

2. 포트 연결 테스트

# 외부에서 테스트
telnet server_ip 22
nc -zv server_ip 80

# 로컬에서 테스트
sudo netstat -tulnp | grep :22

3. 방화벽 로그 확인

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

차단된 요청 기록이 있는지 살펴봅니다.

4. 일시적으로 비활성화해 진단

# UFW
sudo ufw disable

# iptables
sudo iptables -F

비활성화한 뒤 연결을 테스트하여 방화벽 문제인지 서비스 자체의 문제인지 확인합니다.

주의: 방화벽을 비활성화하면 서버가 완전히 노출됩니다. 진단을 마치면 즉시 복구하세요.

---

정리: 방화벽 보안 체계 구축하기

지금까지 살펴본 핵심 내용을 정리하겠습니다.

도구 선택

• 단순한 환경: UFW로 충분하며 몇 분 안에 간편하게 구성할 수 있습니다.
• 복잡한 환경: iptables가 더 유연하며 게이트웨이, NAT, 고급 필터링에 적합합니다.
• 혼용 금지: 한 가지 도구를 선택해 일관되게 관리하고 규칙 충돌을 피하세요.

구성 원칙

• 기본 거부: 모든 인바운드 트래픽을 거부하고 필요한 포트만 허용합니다.
• 최소 권한: 각 규칙의 범위를 최대한 좁히고 소스 IP를 제한합니다.
• 심층 방어: 방화벽은 첫 번째 계층일 뿐이며 WAF, SELinux와 함께 여러 방어 계층을 구성합니다.
• 네트워크 분할: DMZ, 내부망, 관리 영역을 격리합니다.
• 정기 감사: 매월 규칙을 점검하고 분기마다 평가하며 매년 재구성합니다.

실전 핵심 사항

• SSH 먼저 허용: 방화벽을 구성하기 전에 SSH 포트에 접근할 수 있는지 확인합니다.
• 규칙 순서: iptables 규칙은 구체적인 것부터 일반적인 것 순서로 배치해야 합니다.
• 영구 저장: iptables 규칙을 저장해 재부팅 후 자동으로 불러오게 합니다.
• IPv6 구성: iptables는 ip6tables를 별도로 구성해야 하지만 UFW는 자동으로 처리합니다.
• 테스트 환경 검증: 프로덕션에 적용하기 전에 테스트 환경에서 먼저 시험합니다.
• 로그 보존: 방화벽 로그를 활성화하고 비정상 트래픽을 정기적으로 분석합니다.

다음 학습 주제

방화벽과 서버 보안을 더 깊이 배우고 싶다면 다음 주제를 살펴보세요.

• nftables: 문법이 더 일관되고 성능이 뛰어난 iptables의 현대적인 대안
• firewalld: 실행 중 규칙 수정을 지원하는 동적 방화벽 관리 도구
• WAF 구성: Nginx ModSecurity, Cloudflare WAF
• 침입 탐지: Fail2ban(무차별 대입 공격 자동 차단), OSSEC
• SELinux/AppArmor: 호스트 계층 권한 제어

방화벽 구성은 서버 보안의 기본입니다. UFW와 iptables 사용법을 익히고 보안 정책 설계 원칙을 이해하면 서버가 누구나 드나드는 문 열린 집처럼 방치되는 일을 막을 수 있습니다. 새벽 세 시에 경보 문자로 잠에서 깨는 일도 줄어들 것입니다.

---

참고 자료

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Difference Between ufw vs. nftables vs. iptables - Baeldung on Linux
• Firewall Design Principles In Network Security - Fortinet
• Linux Firewall: Configuration, Tools, Best Practices - TuxCare
• Ubuntu Community Help Wiki - UFW