infra
Platform

모듈 맵

[Infra Ops] 네트워크 방화벽 정책과 요청서 작성 실무

0 / 52 완료

펼치기
0 / 52 완료0%

Infra-ops · 22 / 52

[Infra Ops] 네트워크 방화벽 정책과 요청서 작성 실무

Inbound/Outbound 방화벽 정책, IP/Port/Protocol 기준 정의, 방화벽 오픈 요청서 작성, 테스트 확인 방법까지 — 인프라 엔지니어가 매일 처리하는 방화벽 업무 실무

🚨INCIDENT ALERT
HIGH

신규 서비스 'order-api' 배포 D-1, 개발팀에서 급하게 연락이 왔습니다. "WAS에서 DB로 연결이 안 돼요. 로컬에서는 됐는데 서버에 올리니 타임아웃이 납니다." 원인을 추적하니 방화벽 정책이 없었습니다. 네트워크팀에 요청해야 하는데 어떤 정보를 줘야 하는지, 확인은 어떻게 해야 하는지 막막합니다.

이 모듈은 방화벽 오픈 요청서를 정확하게 작성하고, 오픈 후 직접 테스트하는 실무 절차를 익히는 것이 목표입니다.

이번 챕터에서 배울 것
  • 1Inbound/Outbound 방화벽 정책의 방향과 기준을 설명할 수 있다
  • 2방화벽 오픈 요청서 5가지 필수 항목을 빠짐없이 작성할 수 있다
  • 3telnet, nc, curl로 방화벽 오픈 여부를 직접 테스트할 수 있다
  • 4firewalld, iptables로 OS 레벨 방화벽 상태를 확인하고 설정할 수 있다
  • 5포트는 열렸는데 연결이 안 되는 상황에서 바인딩 문제를 진단할 수 있다

방화벽 기본 개념

💡개념

Stateful vs Stateless, 그리고 Zone 기반 정책

방화벽을 처음 다룰 때 가장 많이 혼란스러운 것이 방향입니다. "이 포트를 열어달라"고 요청할 때 Inbound인지 Outbound인지 틀리면 네트워크팀이 잘못된 정책을 설정합니다. 방향을 결정하기 전에 방화벽이 어떻게 동작하는지부터 이해해야 합니다.

방화벽 존 구조 — Public/DMZ/Private/DB 존 분리와 접근 정책

방화벽 Inbound/Outbound 트래픽 흐름

Stateful vs Stateless:

구분동작실무 활용
StatefulTCP 연결 상태를 추적해 응답 트래픽 자동 허용대부분의 상용 방화벽 (AWS Security Group, 방화벽 어플라이언스)
Stateless패킷 개별 검사, 응답도 별도 규칙 필요iptables 기본 설정, 라우터 ACL

Stateful 방화벽은 Inbound 정책을 열면 그에 대한 응답(Outbound)은 자동으로 허용됩니다. AWS Security Group이 대표적입니다. 반면 iptables를 Stateless로 사용하면 양방향 모두 규칙을 추가해야 합니다.

Zone 기반 정책 (온프레미스 표준):

[인터넷]
    ↓
[외부 방화벽] — Untrust Zone (외부)
    ↓
[DMZ] — 공개 서비스 (웹서버, Reverse Proxy)
    ↓
[내부 방화벽] — Trust Zone (내부)
    ↓
[내부망] — WAS, DB, 배치 서버

Zone 간 트래픽은 기본 차단, 명시적 허용 규칙만 통과합니다. 방화벽 오픈 요청은 이 Zone 간 이동 경로를 기준으로 작성합니다.

💡개념

Inbound vs Outbound — 실무 구분 기준

네트워크팀에 방화벽 오픈을 요청했는데 "방향이 잘못됐다"는 답변이 돌아왔습니다. WAS에서 DB로 연결해야 하는데 Inbound로 요청했는지 Outbound로 요청했는지 헷갈립니다. 방향을 틀리면 네트워크팀도 정책을 잘못 설정하고, 배포 당일에 "연결 안 된다"는 장애로 이어집니다.

방화벽 정책의 방향은 항상 "기준 서버(또는 방화벽) 관점에서" 정의합니다.

방향트래픽 흐름실무 예시
Inbound외부 → 서버 (들어오는 트래픽)사용자 브라우저 → 웹서버 80/443, WAS → DB 3306
Outbound서버 → 외부 (나가는 트래픽)WAS → 외부 결제 API, 서버 → yum 저장소 80
[WAS 서버 10.10.1.5]  →  TCP 3306  →  [DB 서버 10.10.3.10]

DB 서버 방화벽 관점:
  Inbound: 출발지 10.10.1.5, 목적지 10.10.3.10:3306 — 허용 필요

WAS 서버 방화벽 관점:
  Outbound: 출발지 10.10.1.5, 목적지 10.10.3.10:3306 — 허용 필요

Stateful 방화벽이라면 DB 서버의 Inbound 정책만 오픈하면 응답은 자동 허용됩니다. 온프레미스 환경에서는 보통 양방향 모두 명시적으로 요청해야 하는 경우가 많으므로, 요청서에 두 방향을 모두 기재하는 것이 안전합니다.

방화벽 오픈 요청서 작성

💡개념

5가지 필수 항목과 실제 요청서 예시

"DB 서버 방화벽 열어주세요"라고 슬랙에 메시지를 보냈더니 "출발지 IP가 어디예요? 포트는요? 만료일은요?" 질문이 이어집니다. 필요한 정보를 빠뜨리면 추가 문의가 오가며 시간이 낭비되고, 오픈 범위가 불명확하면 보안 감사에서 지적됩니다. 요청서 작성 포맷을 익혀두면 이 왕복을 없앨 수 있습니다.

방화벽 오픈 요청서는 네트워크팀이 정책을 설정하는 기준 문서입니다. 5가지 항목이 빠지면 추가 문의가 오거나, 너무 넓은 범위로 설정되어 보안 문제가 생깁니다.

필수 5가지 항목:

항목예시주의사항
출발지 IP/대역10.10.1.0/24 (WAS 서버 대역)/32 단일 IP보다 대역(/24)으로 명시하면 서버 증설 시 추가 요청 불필요
목적지 IP/대역10.10.3.10 (DB 서버 단일)DB는 IP 고정이므로 /32 단일 IP 명시
포트/프로토콜TCP 3306 (MySQL)UDP가 필요한 경우 별도 명시 (DNS=53/UDP, NTP=123/UDP)
서비스 목적신규 서비스 'order-api' DB 연결구체적일수록 감사(Audit) 시 유리
요청 기한/만료일2026-05-30 요청 / 만료: 없음(상시)임시 연결은 만료일 필수, 상시는 명시

실제 방화벽 오픈 요청서 예시:

[방화벽 오픈 요청]
────────────────────────────────────────
요청자   : 홍길동 (order-api 개발팀)
요청일   : 2026-05-30

[정책 1] WAS → DB (Inbound on DB / Outbound on WAS)
  출발지  : 10.10.1.0/24 (WAS 서버 대역)
  목적지  : 10.10.3.10/32 (DB 서버 - MySQL Primary)
  포트    : TCP 3306
  목적    : 신규 서비스 order-api DB 연결
  만료    : 없음 (상시)

[정책 2] 모니터링 서버 → WAS (Inbound on WAS)
  출발지  : 10.10.5.20/32 (Prometheus 서버)
  목적지  : 10.10.1.0/24 (WAS 서버 대역)
  포트    : TCP 8080
  목적    : 메트릭 수집 (/actuator/prometheus)
  만료    : 없음 (상시)
────────────────────────────────────────

자주 사용하는 포트 레퍼런스:

포트프로토콜서비스
22TCPSSH
80TCPHTTP
443TCPHTTPS
8080TCPHTTP Alt (WAS)
3306TCPMySQL
5432TCPPostgreSQL
6379TCPRedis
27017TCPMongoDB
5672TCPRabbitMQ
9200TCPElasticsearch
9092TCPKafka
53UDP/TCPDNS
123UDPNTP

방화벽 테스트 방법

1nc와 telnet으로 포트 오픈 확인

방화벽 오픈 요청을 보낸 후, 실제로 트래픽이 통하는지 직접 검증해야 합니다. nc(netcat)와 telnet은 TCP 연결 가능 여부를 빠르게 테스트하는 도구입니다. 방화벽 오픈 직후 첫 확인에 씁니다.

로컬 터미널
# nc (netcat) — 권장. -z: 연결만 테스트, -v: 상세 출력
nc -zv 10.10.3.10 3306

# 성공 시 출력:
# Connection to 10.10.3.10 3306 port [tcp/mysql] succeeded!

# 실패 시 출력:
# nc: connect to 10.10.3.10 port 3306 (tcp) failed: Connection refused
# 또는
# nc: connect to 10.10.3.10 port 3306 (tcp) timed out  ← 방화벽 차단

# telnet — 구형 서버에도 대부분 설치됨
telnet 10.10.3.10 3306
# 성공: Connected to 10.10.3.10. / 실패: Connection refused 또는 타임아웃

# 여러 포트 한 번에 확인
for port in 3306 5432 6379; do
  nc -zv 10.10.3.10 $port 2>&1 | grep -E "succeeded|failed|timed"
done

# HTTP 서비스 확인은 curl
curl -m 5 http://10.10.1.10:8080/health
# -m 5: 5초 타임아웃 (방화벽 차단이면 타임아웃으로 5초 기다림)

Connection refused vs 타임아웃 — 의미 차이:

결과의미
Connection refused포트에 도달했으나 서비스가 없음 (방화벽은 통과)
Connection timed out방화벽이 패킷을 DROP (응답 없음)
Connected / succeeded방화벽 통과 + 서비스 바인딩 확인
nc -zv 10.10.3.10 3306
🔍실행 후 확인할 것
  • nc -zv 성공 시 'succeeded' 메시지가 출력됐는가
  • 타임아웃(방화벽 차단)과 Connection refused(서비스 없음)를 구분했는가
  • HTTP 서비스는 curl -m 5로 응답 코드를 확인했는가
  • 여러 포트를 반복문으로 한 번에 확인했는가
2OS 레벨 방화벽 확인 및 설정

네트워크 방화벽(어플라이언스)과 별개로, 서버 OS에도 방화벽이 있습니다. 네트워크 방화벽을 열었어도 OS 방화벽이 차단하면 연결이 안 됩니다.

로컬 터미널
# ── firewalld (CentOS/RHEL 7+ 기본) ────────────────────
# 현재 상태 확인
sudo firewall-cmd --list-all

# 출력 예시:
# public (active)
#   target: default
#   interfaces: eth0
#   services: dhcpv6-client ssh
#   ports: 8080/tcp

# 포트 영구 오픈 (--permanent 없으면 재시작 시 초기화)
sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

# 포트 제거
sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent
sudo firewall-cmd --reload

# ── iptables (구형 서버, Ubuntu 등) ─────────────────────
# 현재 규칙 확인
sudo iptables -L -n --line-numbers

# INPUT 체인에 포트 허용 추가
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

# 규칙 저장 (재시작 후에도 유지)
sudo service iptables save
# 또는
sudo iptables-save > /etc/sysconfig/iptables

# ── ufw (Ubuntu 기본) ────────────────────────────────────
sudo ufw status verbose
sudo ufw allow 8080/tcp
sudo ufw deny 23/tcp
sudo firewall-cmd --list-all
🔍실행 후 확인할 것
  • firewall-cmd --list-all 출력에 ports 항목이 보이는가
  • --permanent 옵션을 빠뜨리지 않았는가 (빠지면 재시작 시 사라짐)
  • iptables -L -n 결과에 추가한 ACCEPT 규칙이 보이는가
  • OS 방화벽 설정 후 nc -zv로 다시 테스트해 확인했는가

트러블슈팅

원인: nc는 TCP 포트 오픈만 확인합니다. DB가 127.0.0.1에만 바인딩되어 있으면 로컬에서는 접속되지만, 외부 IP로 오는 연결은 거부합니다.

로컬 터미널
# DB 서버에서 바인딩 주소 확인
sudo ss -tlnp | grep 3306
# 출력 예시 (문제 상황):
# LISTEN  0  128  127.0.0.1:3306  0.0.0.0:*  users:(("mysqld",...))
#                 ↑ 로컬호스트만 바인딩 — 외부 연결 불가

# 정상 상태:
# LISTEN  0  128  0.0.0.0:3306  0.0.0.0:*  users:(("mysqld",...))

# MySQL 바인딩 주소 변경
sudo vim /etc/my.cnf
# [mysqld] 섹션에서:
# bind-address = 127.0.0.1  → bind-address = 0.0.0.0 으로 변경

sudo systemctl restart mysqld

# 변경 후 재확인
sudo ss -tlnp | grep 3306

DB를 0.0.0.0으로 열면 DB 서버의 모든 인터페이스에서 접근 가능해집니다. 반드시 DB 레벨 계정 권한(GRANT)도 함께 확인해 특정 WAS IP에서만 접속하도록 제한해야 합니다.

원인: 네트워크 방화벽 외에 OS 레벨 iptables/firewalld가 추가로 차단하고 있거나, SELinux 컨텍스트가 네트워크 접근을 제한하는 경우입니다.

서버 터미널
# 1. OS 방화벽 상태 확인
sudo systemctl status firewalld
sudo firewall-cmd --list-all

# firewalld가 활성화되어 있다면 해당 포트 오픈 여부 확인
sudo firewall-cmd --query-port=3306/tcp
# no → 포트가 차단 중

# 2. iptables 직접 확인 (firewalld 우회해 iptables 규칙 직접 추가된 경우)
sudo iptables -L INPUT -n --line-numbers | grep 3306

# 3. SELinux 확인 (CentOS/RHEL)
sestatus
# SELinux status: enabled 이면 컨텍스트 확인
sudo ausearch -m avc -ts recent | grep 3306
# AVC denied 로그가 있으면 SELinux가 차단

# SELinux 포트 허용
sudo semanage port -a -t mysqld_port_t -p tcp 3306

# 임시 확인 (SELinux permissive 모드로 전환, 운영 금지)
sudo setenforce 0
nc -zv target-ip 3306
sudo setenforce 1
💼
실무 맥락
현업 패턴

실제 업무에서 이 지식이 쓰이는 상황:

방화벽 오픈 요청은 단발성 작업이 아닙니다. 신규 서비스 배포, 외부 기관 API 연동, 모니터링 에이전트 추가, DR 환경 구성 등 매번 반복됩니다. 실무에서 이 절차를 빠르게 처리하는 사람이 배포 속도를 결정합니다.

전체 절차 요약 (현장에서 쓰는 루틴):

로컬 터미널
# 1. 요청서 작성 → 네트워크팀 전달 (슬랙/티켓)
# [필수] 출발지, 목적지, 포트/프로토콜, 목적, 만료일

# 2. 오픈 완료 확인 후 — 즉시 테스트
nc -zv db-server 3306
curl -m 5 http://was-server:8080/health

# 3. OS 방화벽도 확인 (네트워크 방화벽과 별개)
sudo firewall-cmd --list-all
sudo iptables -L -n | grep 3306

# 4. 애플리케이션 연결 테스트
# DB 연결이라면 직접 mysql client로 확인
mysql -h db-server -u appuser -p -e "SELECT 1"

자주 발생하는 커뮤니케이션 실수:

  • 포트 번호 없이 "DB 서버 열어주세요" 요청 → 어떤 포트인지 모르므로 다시 문의
  • 출발지를 단일 IP로 요청했다가 서버 증설 시 추가 요청 발생 → 대역(/24)으로 요청
  • 만료일 없이 임시 연결 요청 → 감사 시 불필요한 정책으로 지적

다음 모듈에서는 폐쇄망 환경에서 Proxy와 NAT를 이용해 외부 기관과 통신하는 구조를 다룹니다.

지식 확인

퀴즈 — 4문제

Q1

Inbound와 Outbound 방화벽 정책의 기준으로 올바른 것은?

Q2

방화벽 오픈 요청 시 반드시 포함해야 할 5가지 정보로 올바른 것은?

Q3

telnet target-ip 3306 실행 결과 'Connected to target-ip' 메시지가 나왔다. 이것이 의미하는 것은?

Q4

nc -zv db-server 3306 이 'succeeded'를 반환했는데 애플리케이션에서 DB 연결이 안 된다. 가장 먼저 확인해야 할 것은?

0 / 4 답변

🧪 실습으로 확인하기

Nginx 설치 및 기동

초급

Linux 서버에 Nginx를 설치하고 systemd 서비스로 등록하여 80포트에서 응답하는 상태까지 만든다.

30📋 3단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

infra-ops입문 · 50
[Infra Ops] RESTful API 구조와 curl/Postman 테스트 실무
인프라 서비스 운영 트랙 계속
linux입문 · 30
[Linux] 개발자가 왜 리눅스 서버와 커맨드라인을 반드시 배워야 하는가
Linux 트랙 시작점