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. 구성요소(기능 레이어)
- Firewall Policy (Deny/Allow+UTM)
- Inspection Mode (Proxy 기반 권장)
- Web Filter / Application Control / IPS / ZTNA posture 조건
- SSL/SSH Inspection (HTTPS 안내가 필요하면 Decrypt 고려)
- Replacement Message(차단 페이지) (HTTP/HTTPS 안내 핵심)
- 로그/분석 (FortiAnalyzer 또는 SIEM)
- 차단코드 운영체계 (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 전달)
운영/감사까지 포함한 “완전한 프로세스”
운영 흐름(권장)
- 사용자: 차단 페이지(HTTP/HTTPS)에서 차단코드 확인
- SSH는 코드 확인이 어려우므로 “접속 시각/소스IP” 제공 유도
- 헬프데스크: 코드로 FortiAnalyzer/SIEM에서 조회
- 보안팀: 정책 예외/접근승인/단말조치 결정
- 재발 방지: 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으로 유도
실무 산출물
- 차단코드 표준 + 매핑 테이블(초안)
- HTTP/HTTPS Replacement Message HTML 최종본(브랜딩 포함)
- FortiGate 정책 템플릿(deny/allow+utm, proxy/flow 분리)
- SSH 접속 실패 사용자 가이드(사내 공지용)
728x90
그리드형(광고전용)
댓글