🔒 보안

방화벽

Firewall

네트워크 트래픽을 필터링하는 보안 장치. 인바운드/아웃바운드 규칙으로 접근 제어. 허가되지 않은 접근을 차단하고 신뢰할 수 있는 트래픽만 허용하여 네트워크를 보호합니다.

📖 상세 설명

방화벽(Firewall)은 네트워크 보안의 첫 번째 방어선으로, 신뢰할 수 있는 내부 네트워크와 신뢰할 수 없는 외부 네트워크(주로 인터넷) 사이의 트래픽을 모니터링하고 제어하는 보안 시스템입니다.

"방화벽"이라는 이름은 건축에서 유래했습니다. 건물에서 화재가 번지는 것을 막는 내화벽처럼, 네트워크 방화벽은 악성 트래픽이 내부 네트워크로 침투하는 것을 막습니다. 1988년 모리스 웜(Morris Worm) 사건 이후 네트워크 보안의 필요성이 대두되면서 최초의 상용 방화벽이 등장했습니다.

방화벽의 핵심 원리

네트워크 보안 아키텍처

🌐 인터넷
신뢰할 수 없는 영역
⬇️
🔥 방화벽
트래픽 필터링
⬇️
🖥️ DMZ
웹 서버, 메일 서버
⬇️
🏢 내부 네트워크
사내 시스템, DB

OSI 계층과 방화벽

L7 애플리케이션 WAF, NGFW - HTTP, SQL, 악성코드 검사
L6 표현 SSL/TLS 복호화 (NGFW)
L5 세션 -
L4 전송 상태 기반 방화벽 - TCP/UDP 포트 기반
L3 네트워크 패킷 필터링 - IP 주소 기반
L2 데이터 링크 MAC 필터링 (스위치)
L1 물리 -

🔥 방화벽 유형

패킷 필터링 방화벽

OSI L3-L4 (네트워크/전송)

IP 주소, 포트 번호, 프로토콜을 기준으로 개별 패킷을 검사하고 차단합니다. 가장 기본적인 형태입니다.

✓ 빠른 속도 ✗ 상태 비인식

상태 기반 검사 방화벽

OSI L3-L4 (상태 추적)

연결 상태를 추적하여 합법적인 세션에 속하는 패킷만 허용합니다. 현재 가장 일반적인 형태입니다.

✓ 동적 규칙 ✗ L7 미검사

애플리케이션 게이트웨이

OSI L7 (애플리케이션)

프록시 서버로 동작하며 애플리케이션 프로토콜(HTTP, FTP 등)의 내용까지 검사합니다.

✓ 심층 검사 ✗ 성능 저하

차세대 방화벽 (NGFW)

OSI L3-L7 (통합)

기존 방화벽 + IPS + 애플리케이션 인식 + SSL 검사 + 위협 인텔리전스를 통합한 최신 솔루션입니다.

✓ 통합 보안 ✗ 고비용

방화벽 비교표

유형 검사 수준 성능 보안 수준 사용 사례
패킷 필터링 IP, 포트 매우 높음 기본 라우터 ACL
상태 기반 연결 상태 높음 중간 일반 기업
WAF HTTP/SQL 중간 높음 (웹) 웹 애플리케이션
NGFW L3-L7 전체 중간 매우 높음 엔터프라이즈

💻 코드 예제

#!/bin/bash
# Linux iptables 방화벽 설정 예제

# 기본 정책: 모든 INPUT 거부, OUTPUT 허용
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# 로컬호스트 허용
iptables -A INPUT -i lo -j ACCEPT

# 확립된 연결 허용 (상태 기반)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH 허용 (포트 22, 특정 IP만)
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT

# HTTP/HTTPS 허용 (모든 IP)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# MySQL 허용 (내부 네트워크만)
iptables -A INPUT -p tcp --dport 3306 -s 192.168.0.0/16 -j ACCEPT

# ICMP (ping) 제한 (초당 1회)
iptables -A INPUT -p icmp --icmp-type echo-request \
    -m limit --limit 1/second -j ACCEPT

# 나머지 모두 로깅 후 거부
iptables -A INPUT -j LOG --log-prefix "DROPPED: "
iptables -A INPUT -j DROP
# Ubuntu UFW (Uncomplicated Firewall) 설정
# iptables의 간편한 래퍼

# UFW 활성화
sudo ufw enable

# 기본 정책 설정
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH 허용 (기본 포트)
sudo ufw allow ssh
# 또는 특정 포트 지정
sudo ufw allow 22/tcp

# 웹 서버 허용
sudo ufw allow 'Nginx Full'
# 또는
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 특정 IP에서만 MySQL 허용
sudo ufw allow from 192.168.1.0/24 to any port 3306

# 특정 IP 완전 차단
sudo ufw deny from 203.0.113.100

# 포트 범위 허용
sudo ufw allow 6000:6007/tcp

# 상태 확인
sudo ufw status verbose

# 규칙 번호로 삭제
sudo ufw status numbered
sudo ufw delete 3
# Terraform으로 AWS Security Group 정의
# 클라우드 방화벽의 대표적인 예

resource "aws_security_group" "web_server" {
  name        = "web-server-sg"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id

  # 인바운드 규칙: HTTP/HTTPS 허용
  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # SSH는 VPN/배스천에서만 허용
  ingress {
    description     = "SSH from bastion"
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    security_groups = [aws_security_group.bastion.id]
  }

  # 아웃바운드: 모든 트래픽 허용
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "web-server-sg"
    Environment = "production"
  }
}

# DB용 Security Group (웹 서버에서만 접근)
resource "aws_security_group" "database" {
  name   = "database-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    description     = "MySQL from web servers"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.web_server.id]
  }
}

💬 실무 대화 예시

주니어: 개발 서버에 SSH 접속이 안 돼요. 방화벽 문제인 것 같은데 어떻게 확인하죠?
시니어: 먼저 `telnet 서버IP 22`로 포트가 열려있는지 확인해봐. 연결 안 되면 방화벽 문제야. 서버에서 `iptables -L -n`이나 `ufw status`로 현재 규칙 확인하고.
주니어: 확인해보니 SSH 포트가 열려있지 않네요. 열어도 될까요?
시니어: 모든 IP에 열면 안 돼. 사무실 IP나 VPN IP만 허용하고, fail2ban 설치해서 무차별 대입 공격도 막아야 해. 클라우드면 Security Group에서 소스 IP를 제한해.
주니어: 아웃바운드도 제한해야 하나요?
시니어: 보안 수준에 따라 달라. 일반적으로는 HTTP/HTTPS, DNS 정도만 허용해. 만약 서버가 해킹당해도 외부로 데이터 유출하거나 C2 서버 연결하는 걸 막을 수 있거든.

⚠️ 주의사항

⚠️ 규칙 순서가 중요하다

방화벽 규칙은 위에서 아래로 순차적으로 적용됩니다. 상위에 있는 규칙이 먼저 매칭되므로, 구체적인 규칙을 먼저, 일반적인 규칙을 나중에 배치해야 합니다. 실수로 상단에 전체 차단 규칙을 넣으면 이후 규칙이 무시됩니다.

⚠️ 자신을 잠그지 마라 (Lock-out)

원격 서버에서 방화벽 설정 시, 현재 SSH 연결을 차단하는 규칙을 적용하면 서버에 접속할 수 없게 됩니다. 항상 SSH 규칙을 먼저 확보하고, 테스트 후 적용하세요. 클라우드에서는 콘솔 접속이 가능하지만, 온프레미스는 물리적 접근이 필요합니다.

⚠️ 방화벽만으로는 부족하다

방화벽은 허용된 포트로 들어오는 악성 트래픽(SQL Injection, XSS 등)을 막지 못합니다. 웹 애플리케이션은 WAF, 코드 레벨 보안, 정기적인 취약점 점검이 함께 필요합니다. 방화벽은 보안의 한 레이어일 뿐입니다.

⚠️ 로깅과 모니터링은 필수

방화벽 로그를 수집하고 분석하지 않으면 공격 시도를 탐지할 수 없습니다. 차단된 트래픽 로그를 SIEM에 전송하고, 비정상 패턴을 알림으로 설정하세요. 사후 분석에도 로그가 반드시 필요합니다.

📋 실제 사례

🔴 Capital One 데이터 유출 (2019)

AWS 방화벽(Security Group) 설정 오류로 1억 명 이상의 고객 데이터가 유출되었습니다. 공격자는 잘못 구성된 WAF를 통해 메타데이터 서비스에 접근, IAM 자격증명을 탈취하여 S3 버킷 데이터를 유출했습니다.

💡 교훈: 최소 권한 원칙 적용, 정기적인 구성 감사, SSRF 방어 필수

🔴 MongoDB 랜섬웨어 공격 (2017)

기본 설정으로 인터넷에 노출된 수만 대의 MongoDB 서버가 랜섬웨어 공격을 받았습니다. 방화벽 없이 27017 포트가 전 세계에 공개되어 있었고, 인증도 비활성화된 상태였습니다.

💡 교훈: 데이터베이스 포트는 절대 인터넷에 공개하지 말 것, 기본 포트 변경, 인증 필수

🔴 SSH 무차별 대입 공격

인터넷에 공개된 SSH(22번 포트)에 분당 수백 번의 로그인 시도가 발생합니다. 약한 비밀번호를 사용하면 몇 시간 내에 뚫릴 수 있으며, 이후 봇넷에 편입되거나 암호화폐 채굴에 악용됩니다.

💡 교훈: SSH 포트 변경, IP 화이트리스트, 키 기반 인증, fail2ban 사용

🧠 이해도 퀴즈

상태 기반(Stateful) 방화벽의 핵심 장점은 무엇인가요?

패킷의 내용(payload)까지 검사할 수 있다
연결 상태를 추적하여 응답 트래픽을 자동으로 허용한다
SQL Injection 같은 애플리케이션 공격을 막는다
암호화된 트래픽을 복호화하여 검사한다

🔗 관련 용어

📚 학습 자료