본문 바로가기
네트워크 (LAN,WAN)

FortiGate 기반 접근 차단 및 프로토콜별 차단 사유 안내 설계 표준안

by 날으는물고기 2025. 12. 30.

FortiGate 기반 접근 차단 및 프로토콜별 차단 사유 안내 설계 표준안

728x90

FortiGate에서 “서버까지 절대 연결되지 않도록(=FortiGate에서 세션 종단)” 차단하면서, 가능한 범위 내에서 사용자에게 차단 사유를 안내하고, SSH처럼 안내가 원천적으로 어려운 트래픽은 운영/UX로 보완하는 “완전한(종합적·체계적) 방안”입니다.

300x250
  • HTTP/HTTPS: FortiGate가 Proxy(또는 Decrypt) 기반으로 서버로 보내기 전에 차단하고, Block Page(Replacement Message)로 사유 안내까지 가능
  • SSH(및 일반 TCP): 서버 미연결 차단은 100% 가능, 다만 “차단 사유를 실시간으로 사용자에게 보여주는 것”은 구조적으로 불가사전 고지(배너/가이드) + 차단코드 기반 Helpdesk/SIEM 조회 체계로 완성

요구사항 설계 목표

목표 1: 서버까지 연결되지 않음(Zero-Contact)

  • FortiGate에서 정책 매칭 시 즉시 Deny/Block
  • “연결 시도 자체”를 FortiGate가 끝내야 함

목표 2: 사용자 혼란 최소화(안내/이의제기 동선)

  • 가능한 프로토콜은 “화면 안내”
  • 불가능한 프로토콜은 “사전 안내 + 코드 기반 문의/조회”

목표 3: 보안 정보 노출 최소화

  • 사용자 화면에는 구체 조건(EDR 미설치/정책명/Rule ID/탐지명) 비노출
  • 대신 참조코드(차단코드)만 노출하고, 내부 시스템에서 상세 원인 조회

전체 아키텍처

A. 트래픽 경로(개념)

Client  ──(HTTP/HTTPS/SSH)──>  FortiGate  ─X─>  Server
                           (여기서 종단 차단)

B. 구성요소(기능 레이어)

  1. Firewall Policy (Deny/Allow+UTM)
  2. Inspection Mode (Proxy 기반 권장)
  3. Web Filter / Application Control / IPS / ZTNA posture 조건
  4. SSL/SSH Inspection (HTTPS 안내가 필요하면 Decrypt 고려)
  5. Replacement Message(차단 페이지) (HTTP/HTTPS 안내 핵심)
  6. 로그/분석 (FortiAnalyzer 또는 SIEM)
  7. 차단코드 운영체계 (Helpdesk FAQ, 자동 티켓 등)

HTTP(80): “완전 가능” (서버 미연결 + 안내페이지)

구현 원리

  • FortiGate가 HTTP 요청을 Proxy 방식으로 처리하면서
    서버로 보내기 전에 차단하고, Block Page를 사용자에게 반환

FortiGate 설정 포인트(운영 관점)

  • Inspection Mode: Proxy + Web Filter 프로파일도 Proxy로 맞춤
  • Web Filter / App Control / Policy 기반 차단 시 Replacement Message를 커스터마이징

사용자 안내 문구(권장 템플릿)

(정책 노출 없이, 사용자 행동을 “교정”하는 문구)

예시 화면 문구
  • 제목: 접근이 차단되었습니다
  • 본문
    • 내부 보안 정책 조건을 충족하지 않아 요청이 차단되었습니다.
    • 확인: 사내 인증 상태 / 허용 네트워크 / 단말 보안 상태
    • 문의: 헬프데스크(내선 xxxx) 또는 보안팀
    • 참조 코드: FG-HTTP-25012-014

“차단코드” 포함 이유

  • 사용자에게는 코드만 보여주고
  • 헬프데스크/보안팀은 그 코드로 SIEM/FortiAnalyzer에서 즉시 원인 조회

HTTPS(443): “가능(조건부)” (서버 미연결 + 안내페이지)

HTTPS는 두 단계로 나뉩니다.

카테고리/도메인 수준 차단 (Decrypt 없이도 일부 가능)

  • 인증서/도메인 정보만으로 특정 사이트를 막는 경우(일부 기능)
  • 단, 세부 URL/정책 조건에 따른 정교한 안내는 한계가 있습니다.
  • Fortinet 측에서도 HTTPS 웹 필터링이 Deep Inspection 없이도 가능한 경우가 있음을 언급합니다.

“정확한 안내 페이지”까지 원하면 → SSL Deep Inspection 권장

  • FortiGate가 TLS를 복호화해야 “웹 요청 단위”로 Block Page를 안정적으로 보여주기 쉬움
  • 단말에 FortiGate CA 배포가 전제(조직 단말이라면 보통 가능)

설정 포인트

  • SSL/SSH Inspection Profile: deep-inspection 적용
  • Web Filter/App Control 정책 차단 시 FortiGuard Block Page(Replacement Message) 커스터마이징

HTTPS 운영 보안 체크

  • 예외목록 필수: 금융/개인 민감 사이트, 개인정보 처리 사이트 등
  • 사용자 화면에는 URL/정책명/탐지명을 과하게 노출하지 말고 “조건 미충족” 수준으로 추상화

SSH(22): “서버 미연결은 완전 가능, 사유 안내는 구조적으로 불가”

FortiGate에서 서버 미연결 차단은 100% 가능

  • SSH는 TCP 세션이므로 FortiGate 정책에서 Deny하면 서버에 도달하지 않습니다.

그런데 “차단 사유 안내를 화면에 표시”는 불가능에 가깝다

  • SSH에는 브라우저처럼 “차단 페이지”를 렌더링할 UI가 없습니다.
  • FortiGate가 TCP 세션을 끊는 방식은 보통:
    • Drop(무응답) 또는
    • Reset(RST로 즉시 종료)

UX 개선: Deny 시 “즉시 끊기(Reset)” 권장

  • Drop은 사용자가 타임아웃을 기다려야 해서 불만/문의가 폭증합니다.
  • FortiGate는 Deny 정책에 대해 TCP RST를 보내는 옵션을 제공합니다.
CLI 예시(정책 단위, Deny 즉시 종료)
config firewall policy
    edit <deny_policy_id>
        set action deny
        set send-deny-packet enable
        set logtraffic all
    next
end
  • send-deny-packet enable → Deny 시 RST로 즉시 종료되는 형태(사용자 체감 개선)

“사유 안내”를 완성하는 핵심: 차단코드 + 운영 동선

SSH는 실시간 안내가 어렵기 때문에, “완전한 방안”은 운영 설계로 완성됩니다.

차단코드 표준(권장)

사용자에게는 오직 차단코드만 확인하게 만들고, 원인 분석은 내부에서.

예시 포맷
FG-[PROTO]-[DOMAIN]-[YYMMDD]-[SEQ]

예:
FG-HTTP-WEB-251230-001
FG-HTTPS-ZTNA-251230-003
FG-SSH-ACCESS-251230-021

코드 ↔ 내부 원인 매핑(예시)

차단코드 사용자 화면/안내 내부 원인(로그/정책)
FG-HTTPS-ZTNA-… “보안 조건 미충족” ZTNA posture fail(EDR 미가동/OS 미준수 등)
FG-SSH-ACCESS-… “접속 실패(문의코드)” 소스존 불일치/허용 IP 아님/시간대 제한
FG-HTTP-WEB-… “접근 차단” WebFilter category block

중요: “EDR 미설치” 같은 직접 사유는 사용자 화면에 쓰지 말고, 내부 운영자가 코드로 확인하도록 분리

안내 메시지(Replacement Message) 커스터마이징 실전

FortiGate는 System → Replacement Messages에서 차단 페이지 HTML을 커스터마이징 할 수 있습니다.

권장 HTML(간단형 예시)

(브랜드/문의/코드 포함. 정책 정보는 숨김)

<html>
<head><meta charset="utf-8"><title>접근 차단</title></head>
<body style="font-family: sans-serif; margin: 40px;">
  <h2>접근이 차단되었습니다.</h2>
  <p>본 요청은 내부 보안 정책 조건을 충족하지 않아 차단되었습니다.</p>

  <h3>확인 사항</h3>
  <ul>
    <li>사내 인증 상태(SSO/VPN)</li>
    <li>허용된 네트워크 구간(사내/승인된 VPN)</li>
    <li>단말 보안 상태(보안 에이전트 동작 여부)</li>
  </ul>

  <h3>문의</h3>
  <p>헬프데스크: 내선 1234 / 보안팀: security@company.com</p>

  <p><b>참조 코드:</b> FG-HTTPS-ZTNA-251230-003</p>
</body>
</html>

실제로는 FortiGate가 제공하는 변수/토큰을 활용해 URL/카테고리/시간 등을 일부 표시할 수 있지만, 정보 노출 최소화를 위해 “코드만” 남기는 방식이 가장 안전합니다.

SSH는 “사전 고지 + 표준 문구”로 완성 (현실적 완전안)

서버 배너(사전 고지) — 강력 추천

FortiGate에서 차단되면 배너가 보이지 않을 수 있지만, 최소한 “정책 존재”를 조직에 상시 인지시키는 효과가 큽니다.

Linux SSH 배너 설정
# /etc/ssh/sshd_config
Banner /etc/issue.net
# /etc/issue.net
본 시스템은 내부 보안 정책에 따라 접근이 제한됩니다.
정책 미충족 시 방화벽에서 연결이 차단될 수 있습니다.
문의: 헬프데스크(내선 1234) / security@company.com

사용자 가이드(FAQ) 문구 예시

  • “SSH 접속이 안될 때”
    • 사내 VPN 연결 확인
    • 접속 허용 IP인지 확인
    • 업무 시간/승인 시간대 여부
    • 차단코드가 있다면 전달(없으면 접속 시각/소스 IP 전달)

운영/감사까지 포함한 “완전한 프로세스”

운영 흐름(권장)

  1. 사용자: 차단 페이지(HTTP/HTTPS)에서 차단코드 확인
    • SSH는 코드 확인이 어려우므로 “접속 시각/소스IP” 제공 유도
  2. 헬프데스크: 코드로 FortiAnalyzer/SIEM에서 조회
  3. 보안팀: 정책 예외/접근승인/단말조치 결정
  4. 재발 방지: FAQ/가이드 업데이트, 코드 매핑 테이블 유지

보안 점검 포인트(체크리스트)

  • 서버에 패킷이 “정말” 안 가는지 검증(패킷캡처/서버 로그)
  • Deny 정책에서 send-deny-packet 사용으로 UX 개선(SSH)
  • Replacement Message에 내부 정책/탐지명/룰ID 노출 금지
  • HTTPS Decrypt 예외정책(민감 사이트) 존재
  • 차단코드 ↔ 내부 원인 매핑 문서화(감사 대응)

상황별 “정답 조합” (바로 적용용)

케이스 A: 사내 웹/업무 SaaS를 강력 통제 + 안내까지

  • HTTPS Deep Inspection + Proxy 정책
  • Web Filter/App Control/ID기반 조건
  • Block Page 커스터마이징(코드 포함)

케이스 B: SSH는 무조건 FortiGate에서 끊고, 문의는 최소화

  • Deny 정책 + send-deny-packet enable로 즉시 종료
  • 내부 위키 “SSH 접속 실패 점검 가이드” 고정
  • (가능하면) 허용 대상은 별도 Jump/Bastion으로 유도

실무 산출물

  1. 차단코드 표준 + 매핑 테이블(초안)
  2. HTTP/HTTPS Replacement Message HTML 최종본(브랜딩 포함)
  3. FortiGate 정책 템플릿(deny/allow+utm, proxy/flow 분리)
  4. SSH 접속 실패 사용자 가이드(사내 공지용)
728x90
그리드형(광고전용)

댓글