방화벽의 원리와 정책 설계

방화벽이 필요한 이유

방화벽(Firewall)은 네트워크 경계에서 트래픽을 통제하는 보안 장비다. 내부 네트워크와 외부 인터넷 사이에 위치해서 들어오고 나가는 모든 패킷을 검사하고, 허가된 것만 통과시킨다.

 

쉽게 말해 건물 정문의 보안 요원이다. 들어오는 사람마다 신분을 확인하고, 출입 권한이 있는 사람만 통과시킨다.

서버를 인터넷에 연결하는 순간을 떠올려보자. 전 세계 누구나 그 서버에 접근을 시도할 수 있다. 실제로 몇 분 안에 자동화된 봇들이 포트 스캔을 시작한다. SSH 무차별 대입 공격, 웹 취약점 스캔, 랜섬웨어 전파 시도가 24시간 끊임없이 들어온다. 방화벽 없이 서버를 운영하는 건 현실적으로 불가능하다.

패킷 필터링의 동작 원리

패킷과 헤더 정보

네트워크 통신은 패킷 단위로 이루어진다. 웹사이트 하나를 로드하는 것도 수백 개의 패킷이 오간다.

각 패킷에는 헤더가 붙는다. 헤더에는 다음 정보가 들어있다.

• 출발지 IP 주소: 패킷을 보낸 호스트
• 목적지 IP 주소: 패킷이 가려는 호스트
• 출발지 포트: 송신 프로그램의 포트 번호
• 목적지 포트: 수신 서비스의 포트 번호
• 프로토콜: TCP, UDP, ICMP 등
• TCP 플래그: SYN, ACK, FIN 등 연결 상태 정보

방화벽은 이 정보를 보고 패킷을 통과시킬지 차단할지 결정한다.

5-Tuple 매칭

방화벽이 패킷을 판단하는 기준을 5-Tuple이라고 한다.

1. Source IP
2. Destination IP
3. Source Port
4. Destination Port
5. Protocol

사내 PC(192.168.1.100)에서 구글(172.217.25.46)에 접속하는 상황을 보자.

출발지 IP: 192.168.1.100
목적지 IP: 172.217.25.46
출발지 포트: 54321 (동적 할당)
목적지 포트: 443 (HTTPS)
프로토콜: TCP

방화벽은 이 5가지를 정책 테이블과 대조한다. "192.168.1.0/24에서 외부로 나가는 TCP 443 트래픽 허용" 같은 정책이 있으면 통과시킨다.

출발지 포트는 클라이언트 OS가 49152~65535 범위에서 랜덤하게 할당한다. 브라우저 탭을 여러 개 열면 각각 다른 출발지 포트를 쓴다. 그래야 응답 패킷을 어느 탭으로 보낼지 구분할 수 있다.

Stateless vs Stateful

Stateless 방화벽

Stateless는 각 패킷을 독립적으로 검사한다. 이전에 뭐가 지나갔는지 기억하지 않는다.

 

다시 말해 패킷 하나 들어오면 헤더만 보고 정책과 매칭한다. 끝이다. 레스토랑 입구에서 손님 한 명씩 신분증만 확인하는 상황을 떠올려보자. "이 사람 아까 들어갔던 일행 중 한 명인가?" 같은 건 모른다. 그냥 지금 이 사람만 본다.

 

빠르고 단순하다. 상태 테이블을 유지할 필요가 없어 메모리를 적게 쓴다. 하지만 치명적인 약점이 있다.

 

TCP는 연결 지향 프로토콜이다. 정상 통신은 SYN → SYN-ACK → ACK 순서로 핸드셰이크가 일어난다. Stateless 방화벽은 이 흐름을 이해하지 못한다. 갑자기 날아온 ACK 패킷이 정상 연결의 일부인지, 공격자가 조작한 패킷인지 구분 못 한다.

 

더 큰 문제는 응답 트래픽 처리다. 내부에서 외부로 연결을 시작하면 응답이 돌아온다. 이 응답을 받으려면 외부에서 내부로 들어오는 트래픽을 허용해야 한다.

정책 1: 내부 → 외부, TCP 443 허용 (요청)
정책 2: 외부 → 내부, TCP 443 허용 (응답)  

정책 2가 문제다. 외부에서 내부로 들어오는 모든 443 트래픽을 허용하게 된다. 공격자가 443 포트로 공격을 보내도 막을 수 없다. "정상 응답인지 공격인지" 구분할 방법이 없다.

Stateful 방화벽

Stateful은 연결 상태를 추적한다. 패킷이 어떤 세션의 일부인지 기억한다.

 

동작 과정

1. 내부 PC가 외부 서버로 SYN 패킷 전송 (연결 요청)
2. 방화벽이 이 연결을 State Table에 기록
3. 외부 서버에서 SYN-ACK 패킷이 도착
4. 방화벽이 State Table을 확인: "이건 2번에서 기록한 연결의 응답이네"
5. 별도의 Inbound 허용 정책 없이도 패킷 통과

호텔 프런트를 떠올려보자. 투숙객이 외출했다가 돌아오면 "아, 305호 손님이시네요" 하고 확인한다. 밖에서 갑자기 들어온 사람은 투숙 기록이 없으니 막는다. Stateful 방화벽도 똑같다.

 

핵심은 내부에서 시작된 연결에 대한 응답만 자동으로 허용한다는 것이다. 외부에서 무작위로 들어오는 공격 패킷은 State Table에 해당 세션이 없으므로 차단된다.

 

관리자는 Outbound 정책만 설정하면 된다. Inbound 응답 트래픽은 자동 처리된다. 보안성과 편의성을 동시에 잡는다.

Fortigate 같은 UTM은 기본적으로 Stateful이다. 정책을 만들 때 "Established" 상태의 트래픽이 자동으로 허용되는 게 바로 이 때문이다.

 

State Table은 메모리에 저장된다. 각 세션마다 출발지/목적지 IP, 포트, 프로토콜, 연결 시작 시각, 마지막 패킷 시각 등을 기록한다. 수만 개의 동시 연결을 추적하면 메모리를 많이 쓴다. DDoS 공격자들은 이를 악용해서 대량의 연결 요청을 보내 State Table을 가득 채운다. State Exhaustion 공격이라고 한다.

방화벽 세대의 발전

1세대: 패킷 필터

1980년대 후반에 등장한 최초 방화벽이다. Stateless 방식으로 IP, 포트, 프로토콜만 보고 판단한다.

쉽게 말해 우편물의 겉봉투만 보고 통과시킬지 결정하는 것이다. 안에 뭐가 들었는지는 모른다.

 

라우터의 ACL(Access Control List)이 대표적이다. 지금도 라우터나 L3 스위치의 ACL은 이 방식이다. 간단한 필터링에는 충분하지만 현대 공격을 막기엔 부족하다.

2세대: Stateful 방화벽

1990년대 중반에 등장했다. 연결 상태 추적 기능이 추가됐다.

다시 말해 대화의 맥락을 이해하기 시작했다. "이 패킷이 처음 들어온 연결인가? 아니면 진행 중인 연결의 일부인가?"를 판단한다.

 

Cisco ASA, Juniper SRX, Check Point 등 전통적인 엔터프라이즈 방화벽이 여기 속한다. State Table 관리, 세션 타임아웃, NAT 같은 기능이 추가됐다. 현재까지도 방화벽의 핵심 기능이다.

3세대: 차세대 방화벽 (NGFW)

2000년대 중반부터 등장한 애플리케이션 방화벽이다. 포트 번호만 보는 게 아니라 애플리케이션 자체를 식별한다.

왜 필요했을까? 전통 방화벽은 "80 포트 = HTTP, 443 포트 = HTTPS"라고 가정한다. 하지만 실제로는 어떤 프로그램이든 원하는 포트를 쓸 수 있다.

 

택배 상자를 떠올려보자. 겉에 "책"이라고 적혀있어도 실제로 뭐가 들었는지는 열어봐야 안다. 악성코드를 443 포트로 통신하게 만들면 전통 방화벽은 "HTTPS 트래픽이니까 괜찮겠지" 하고 통과시킨다.

 

NGFW는 패킷 내용(페이로드)까지 분석한다. DPI(Deep Packet Inspection) 기술로 "이게 진짜 HTTPS냐? 아니면 다른 프로토콜을 위장한 거냐?"를 판단한다.

 

Fortigate는 이 세대의 UTM이다. HTTP, SSH 같은 프로토콜뿐 아니라 YouTube, Facebook, Tor, BitTorrent 같은 구체적인 애플리케이션까지 식별한다. "YouTube는 점심시간만 허용", "Tor는 전면 차단" 같은 세밀한 제어가 가능하다.

 

추가로 IPS, 안티바이러스, 웹 필터링, SSL 인스펙션 등 여러 보안 기능을 통합한다. 그래서 UTM(Unified Threat Management)이라고 부른다.

방화벽 정책 설계 원칙

최소 권한 원칙

필요한 것만 허용하고 나머지는 전부 차단한다. 보안 정책의 가장 기본 원칙이다.

 

웹서버를 운영하는 예를 들자. 80(HTTP), 443(HTTPS) 포트만 외부에 개방한다. SSH(22), MySQL(3306) 같은 관리 포트는 특정 관리자 IP에서만 접근 가능하게 한다.

 

"일단 다 열어두고 나중에 막자"는 최악의 접근이다. 한번 열어주면 닫기 어렵다. 사용자들이 익숙해져서 닫으면 항의한다. 처음부터 최소한만 허용해야 한다.

Deny by Default

방화벽의 기본 정책은 항상 "거부"여야 한다.

두 가지 접근을 비교해보자.

 

나쁜 방식: Allow by Default

- 알려진 악성 IP 차단
- 위험한 포트 차단  
- 나머지 전부 허용

문제는 "내가 모르는 위협"은 못 막는다는 것이다. 새로운 공격 기법, 제로데이 취약점, 알려지지 않은 악성 IP는 모두 통과한다.

 

좋은 방식: Deny by Default

- 필요한 서비스만 명시적으로 허용
- 나머지 전부 차단

Fortigate는 기본적으로 Deny by Default다. 정책을 하나도 안 만들면 모든 트래픽이 차단된다. 관리자가 명시적으로 허용 정책을 만들어야만 통신이 된다. 정책 리스트 맨 끝에 보이지 않는 "Implicit Deny All" 규칙이 있다고 보면 된다.

 

정책 순서 (First Match Wins)

방화벽 정책은 위에서 아래로 순차 평가된다. 패킷이 들어오면 정책 1번부터 검사하고, 매칭되는 정책을 찾으면 즉시 적용하고 멈춘다.

 

쉽게 말해 서류함을 위에서부터 뒤지는 것과 같다. 찾는 서류를 발견하면 그 즉시 멈춘다. 아래에 더 중요한 서류가 있어도 못 본다.

 

잘못된 정책 순서

정책 1: 내부 전체 → 인터넷, 모든 서비스 허용
정책 2: 특정 PC(192.168.1.50) → 인터넷, 웹만 허용
정책 3: 악성 IP(1.2.3.4) → 내부, 전체 차단

192.168.1.50 PC는 정책 1에 먼저 매칭되므로 정책 2는 절대 실행 안 된다. 모든 서비스에 접근 가능하다. 악성 IP도 마찬가지로 정책 1이나 2에 걸리면 정책 3은 무의미해진다.

 

올바른 정책 순서

정책 1: 악성 IP → 내부, 전체 차단 (블랙리스트 최우선)
정책 2: 특정 PC → 인터넷, 웹만 허용 (제한적 허용)
정책 3: 내부 전체 → 인터넷, 일반 서비스 허용 (광범위 허용)
정책 4: (암묵적) 나머지 전부 차단

원칙은 간단하다: 구체적이고 제한적인 정책을 위에, 일반적이고 광범위한 정책을 아래에.

Fortigate에서 정책은 드래그로 순서를 바꿀 수 있다. Hit Count를 보면 각 정책이 몇 번 매칭됐는지 나온다. 특정 정책의 Hit Count가 계속 0이면 위쪽 정책에 가려져서 실행 안 되고 있을 가능성이 크다.

 

명확한 정책 명명

정책이 수십, 수백 개로 늘어나면 관리가 힘들다. 6개월 뒤에 "이 정책 왜 만들었지?" 하고 헤맨다.

추천하는 명명 규칙은, 

[출발지]-[목적지]-[서비스]-[목적]

예시:
- Internal-Internet-Web-General
- DMZ-DB-MySQL-AppServer  
- Admin-Jump-SSH-Management
- Block-Malicious-1.2.3.4

Fortigate는 각 정책에 Comment를 달 수 있다. 날짜, 요청자, 목적을 기록해두면 나중에 정책 리뷰할 때 도움이 된다. 나는 날짜/요청자(혹은 생성자) 정도만 적어두는 편이다.

 

Fortigate 실무 정책 설계

Zone 기반 설계

인터페이스를 Zone으로 그룹화하면 관리가 편하다. Zone은 비슷한 보안 수준의 네트워크 영역을 묶은 것이다.

 

다시 말해 건물을 구역별로 나누는 것과 같다. 1층은 누구나 출입 가능, 2층은 직원만, 3층은 임원만. 각 구역마다 보안 등급이 다르다.

 

일반적인 Zone 구성은, (다음에 다뤄보도록 하겠다)

- Internal: 내부 사용자 네트워크 (신뢰도 높음)
- DMZ: 외부 공개 서버 (신뢰도 중간)
- External: 인터넷 (신뢰도 낮음)
- Management: 네트워크 장비 관리 (신뢰도 높음)

 

Zone 간 트래픽 정책은, 

Internal → External: 허용 (인터넷 사용)
Internal → DMZ: 제한 허용 (필요한 서비스만)
External → DMZ: 매우 제한 (공개 서비스만)
External → Internal: 기본 거부 (VPN 등 예외만)
DMZ → Internal: 기본 거부 (중요!)

마지막 규칙이 중요하다. DMZ 웹서버가 해킹당해도 내부로 침투하지 못하게 막는다. DMZ는 "희생 구역"이다. 공격을 받더라도 내부까지는 못 들어오게 격리한다.

 

NAT와 방화벽 정책

Fortigate에서 헷갈리는 부분이 NAT와 방화벽 정책의 관계다.

 

Destination NAT (DNAT)

외부에서 내부 서버로 접근할 때 쓴다. 공인 IP의 특정 포트로 들어온 요청을 내부 사설 IP로 전달한다.

예: 웹서버 공개
외부: 203.0.113.10:443 → 내부: 192.168.1.100:443

회사 대표번호를 떠올려보자. 외부에서 02-1234-5678로 전화하면 내부 직원 내선번호로 연결된다. DNAT도 똑같다.

 

Fortigate 설정 -

1. Virtual IP(VIP) 생성: 203.0.113.10:443 → 192.168.1.100:443 매핑
2. 방화벽 정책 생성: External → DMZ, 목적지를 VIP로 지정, HTTPS 허용

주의할 점: VIP 만들었다고 자동으로 통신되지 않는다. 방화벽 정책으로 허용해줘야 한다. NAT는 "주소 변환 규칙"이고, 방화벽 정책은 "허용/차단 규칙"이다. 둘은 독립적이다.

 

Source NAT (SNAT)

내부에서 외부로 나갈 때 출발지 IP를 방화벽 공인 IP로 바꾼다. 이래야 인터넷 서버가 응답을 어디로 보낼지 안다.

내부: 192.168.1.100 → 인터넷
변환 후: 203.0.113.10 → 인터넷

학교에서 단체로 소풍 갈 때를 생각해보자. 학생들이 뿔뿔이 흩어지면 찾기 힘들다. 그래서 같은 모자를 씌운다. 외부에서 보면 "저 학교 학생들"로 인식된다. SNAT도 내부 IP들을 하나의 공인 IP로 묶어서 내보낸다.

 

Fortigate에서는 정책에서 "Enable NAT" 체크박스를 켜면 자동으로 SNAT 처리된다. Outbound 인터페이스의 IP로 변환된다.

 

애플리케이션 제어

Fortigate의 강력한 기능 중 하나가 애플리케이션 제어다. 포트만 보는 게 아니라 실제 애플리케이션을 식별한다.

- YouTube: 근무시간 차단, 점심시간만 허용
- Facebook: 마케팅팀만 허용
- Tor: 전면 차단 (익명화 도구)
- BitTorrent: 전면 차단 (대역폭 과다 사용)
- Dropbox: IT팀 승인받은 사용자만

설정 방법

1. Security Profiles > Application Control에서 프로필 생성
2. 애플리케이션별로 Allow/Monitor/Block 설정
3. 방화벽 정책에 프로필 적용

주의할 점은 SSL/TLS로 암호화된 트래픽은 애플리케이션 식별이 제한된다. SNI(Server Name Indication)나 인증서 정보로 일부 식별 가능하지만 완벽하지 않다. 완전한 식별을 원하면 SSL Inspection을 켜야 하는데, 이건 성능 영향이 크고 프라이버시 이슈가 있다.

 

IPS와 안티바이러스

Fortigate는 방화벽뿐 아니라 IPS(침입 방지)와 안티바이러스 기능도 있다.

 

IPS (Intrusion Prevention System)

알려진 공격 패턴(시그니처)을 탐지하고 차단한다. SQL Injection, XSS, Buffer Overflow 같은 공격을 막는다.

쉽게 말해 범죄자의 몽타주를 가지고 있는 것이다. 패킷을 보고 "이거 알려진 공격 패턴이네" 하면 즉시 차단한다.

Security Profiles > Intrusion Prevention
- Protect Client: 내부 사용자 보호 (브라우저 취약점 등)
- Protect Server: 서버 보호 (웹 공격 등)

서버 보호 정책에는 "Protect Server" 프로필을 적용한다. 사용자 인터넷 접속 정책에는 "Protect Client" 프로필을 적용한다.

 

안티바이러스

파일 전송 시 악성코드를 탐지한다. HTTP, FTP, SMTP, POP3, IMAP 프로토콜을 검사한다.

Security Profiles > AntiVirus
- Flow-based: 빠르지만 일부만 검사
- Proxy-based: 느리지만 전체 검사

대용량 파일은 성능 문제가 있다. 100MB 파일을 다운받을 때마다 방화벽이 전체를 스캔하면 속도가 느려진다. 파일 크기 제한을 설정하거나, 신뢰할 수 있는 사이트는 예외 처리한다.

 

SSL Inspection

HTTPS 트래픽은 암호화되어 있어 내용을 볼 수 없다. 악성코드가 HTTPS로 통신하면 방화벽이 탐지 못 한다.

SSL Inspection을 켜면 방화벽이 중간에서 HTTPS 연결을 복호화한다. 내용을 검사하고 다시 암호화해서 전달한다. Man-in-the-Middle 방식이다.

1. 클라이언트 → 방화벽: HTTPS 연결 (방화벽 인증서)
2. 방화벽이 트래픽 복호화해서 검사
3. 방화벽 → 서버: HTTPS 연결 (원래 인증서)

택배를 중간에서 열어보는 것과 같다. 내용물을 확인하고 다시 포장해서 보낸다. 받는 사람은 중간에 누가 열어봤는지 모를 수 있다.

 

클라이언트는 방화벽의 인증서를 신뢰해야 한다. 회사 CA 인증서를 클라이언트에 배포해야 브라우저 경고가 안 뜬다.

 

주의사항 -

• 성능 영향이 크다. CPU 사용률이 크게 올라간다.
• 프라이버시 이슈가 있다. 모든 HTTPS 통신을 볼 수 있다.
• 금융, 의료 사이트는 예외 처리한다.
• 인증서 피닝을 쓰는 앱은 작동 안 될 수 있다.

로깅과 모니터링

 

정책을 만들었으면 실제로 잘 작동하는지 확인해야 한다.

 

로그 설정

정책 편집 > Logging Options
- All Sessions: 모든 세션 로깅 (권장)
- Security Events: 차단/경고만 로깅

중요한 정책은 All Sessions로 로깅한다. 나중에 문제 생겼을 때 추적할 수 있다. 일반 사용자 인터넷 접속 같은 건 Security Events만 로깅해도 된다.

 

모니터링 방법

Log & Report > Forward Traffic: 허용된 트래픽
Log & Report > Blocked Traffic: 차단된 트래픽
Dashboard > Top Applications: 어떤 앱을 많이 쓰나
Dashboard > Top Threats: 어떤 공격이 많이 들어오나

주기적으로 확인할 것

• Blocked Traffic 급증: 공격받고 있을 수 있다
• 이상한 시간대 트래픽: 내부 감염 가능성
• Hit Count 0인 정책: 불필요한 정책이거나 순서 문제

 

정책 리뷰와 정리

방화벽 정책은 시간이 지나면 쌓인다. "일단 급하니까 허용해줘" 하면서 만든 임시 정책들이 방치된다. 주기적으로 정리해야 한다.

 

분기별 정책 리뷰

1. Hit Count 확인: 사용 안 되는 정책 찾기
2. 담당자 확인: 퇴사자 정책 정리
3. 중복 정책 병합
4. 만료된 임시 정책 삭제

정책을 삭제하기 전에 먼저 Disable 처리한다. 2주 정도 지켜보고 문제없으면 삭제한다. 바로 삭제하면 "어? 갑자기 안 되는데요?" 하는 전화가 온다.

 

변경 관리

- 정책 변경 전 백업
- 변경 사항 문서화  
- 테스트 후 적용
- 롤백 계획 준비

Fortigate는 설정을 파일로 백업할 수 있다. 중요한 변경하기 전에 백업 떠놓는다. 잘못되면 복구하면 된다.

실전 시나리오

시나리오 1: 웹서버 DMZ 배치

웹서버를 인터넷에 공개해야 한다. 어떻게 정책을 설계할까?

 

네트워크 구성

인터넷 --- Fortigate(WAN) --- Fortigate(DMZ) --- 웹서버(192.168.100.10)
                      |
                Fortigate(LAN) --- 내부 PC

 

필요한 정책

1. 인터넷 → 웹서버: HTTP(80), HTTPS(443) 허용
   - DNAT 설정: WAN IP → 192.168.100.10
   - IPS 프로필 적용: Protect Server
   - 안티바이러스 프로필 적용
   
2. 웹서버 → 인터넷: HTTP(80), HTTPS(443) 허용
   - 외부 API 호출, 패키지 업데이트용
   - SNAT 적용
   
3. 관리자 PC → 웹서버: SSH(22) 허용
   - 출발지를 관리자 IP로 제한
   - 로그 반드시 기록
   
4. 웹서버 → 내부: 기본 거부
   - DMZ 해킹 시 내부 침투 차단

 

시나리오 2: 재택근무 VPN

재택근무자가 사내 네트워크에 접속해야 한다.

 

VPN 설정

1. SSL-VPN 설정
   - 포트: 10443 (기본 443은 웹서버가 씀)
   - 인증: AD 연동 또는 로컬 계정
   - IP 풀: 192.168.200.0/24
   
2. VPN → 내부: 필요한 서비스만 허용
   - 파일서버(SMB 445)
   - 사내 웹(HTTP 80)
   - 이메일(SMTP, IMAP)
   - 전체 허용 X
   
3. VPN → 인터넷: Split Tunnel 고려
   - Full Tunnel: 모든 트래픽이 회사 경유 (보안 좋음, 속도 느림)
   - Split Tunnel: 사내 접속만 VPN 경유 (보안 약함, 속도 빠름)

재택근무자 PC는 관리 밖이다. 악성코드 감염될 수 있다. VPN 접속 시 단말 보안 검사를 하는 게 좋다. Fortigate는 FortiClient EMS로 단말 상태를 확인할 수 있다.

 

시나리오 3: 내부 세그먼트 분리

내부 네트워크도 보안 수준별로 나눈다.

 

세그먼트 구성

- 일반 사용자: 192.168.1.0/24
- 개발팀: 192.168.10.0/24
- 서버: 192.168.100.0/24
- 게스트: 192.168.254.0/24

 

세그먼트 간 정책

일반 사용자 → 서버: 웹(80, 443)만 허용
개발팀 → 서버: 웹, SSH, DB 허용
게스트 → 서버: 전면 차단
게스트 → 내부: 전면 차단

회의실에 게스트 WiFi 놓을 때 반드시 세그먼트를 분리한다. 방문자 노트북이 내부 네트워크에 접근하면 안 된다.

 

자주 하는 실수

실수 1: Any-Any-Any 정책

"일단 급하니까 다 열어줘" 하면서 만드는 정책

출발지: Any
목적지: Any
서비스: All
동작: Allow

이건 방화벽을 끈 것과 같다. 절대 하면 안 된다.

실수 2: 너무 광범위한 포트 허용

"포트를 모르겠어서" 1-65535 전체를 허용한다. 필요한 포트만 정확히 열어야 한다. 모르면 찾아봐야 한다.

실수 3: 관리 포트를 인터넷에 노출

SSH(22), RDP(3389), Telnet(23) 같은 관리 포트를 인터넷에 그냥 연다. 무차별 대입 공격의 표적이 된다.

관리 포트는:

• VPN으로만 접근
• 특정 IP로 제한
• 포트 번호 변경 (권장하지 않지만 보조 수단)
• 2FA 인증 적용

실수 4: 로그를 안 봄

정책 만들고 끝이 아니다. 로그를 봐야 뭐가 차단되고 뭐가 허용되는지 안다. 이상 징후도 로그에서 먼저 보인다.

실수 5: 백업을 안 함

설정 바꾸다가 꼬이면 복구가 어렵다. 변경 전에 백업을 떠놓는다.

마무리

방화벽 정책 설계는 단순히 트래픽을 허용/차단하는 것이 아니다. 네트워크 구조를 이해하고, 데이터 흐름을 파악하고, 보안 요구사항을 정리하고, 사용자 편의성까지 고려해야 한다. 핵심 원칙은 다음과 같다.

• 최소 권한: 필요한 것만 허용
• 기본 거부: 명시적 허용 외 모두 차단
• 정책 순서: 구체적인 것을 위에
• Zone 분리: 보안 수준별로 네트워크 나누기
• 로깅과 모니터링: 정책이 잘 작동하는지 확인

Fortigate로 실무를 해봤으면 이 내용이 더 와닿을 것이다. UTM은 방화벽, IPS, 안티바이러스, 애플리케이션 제어를 한 번에 설정할 수 있어 편하지만, 그만큼 설정할 게 많고 복잡하다.

 

처음엔 정책 몇 개로 시작한다. 시간이 지나면서 요구사항이 추가되고 정책이 늘어난다. 주기적으로 정리하지 않으면 스파게티가 된다. 방화벽 관리는 한 번 설정하고 끝이 아니라 계속 유지보수하는 것이다.