5편에서 절체 전 보안 기반(NTP·백업·GeoIP·ACME)을 깔았고, OPNsense는 4편에서 메인 방화벽으로 절체됐습니다. 이제 OPNsense는 공인 IP로 외부에 노출된 상태입니다. 이번 편은 그 노출에 대응하는 능동 방어선 — Caddy(리버스 프록시), Suricata(IDS/IPS), 관리자 2FA(TOTP) — 와 원격 접속(OpenVPN/WireGuard, 사이트 간 IPsec)을 다룹니다. 시리즈의 마지막 편입니다.
절체 후 작업의 순서 원칙
절체로 외부 노출이 시작됐으니, 이제 “탐지하고, 막고, 지키고, 안전하게 들어오는” 네 가지를 세웁니다. 순서에는 이유가 있습니다.
- Caddy — 외부 공개 서비스를 443 단일 진입점으로 통제
- Suricata — 들어오는 트래픽을 탐지(IDS) → 검증 후 차단(IPS)
- Insight(NetFlow) — 트래픽 흐름을 기록해 가시성 확보 (위험 0)
- TOTP — 관리자 로그인 2단계 인증
- VPN — 외부 원격 접속. 가장 마지막. 다른 방어선이 안정된 뒤에 노출
마지막 원칙이 핵심입니다. VPN은 외부에 직접 노출되는 입구라, GeoIP·Suricata 같은 다른 방어선이 자리 잡은 뒤 맨 나중에 여는 게 안전합니다. 문제가 생겼을 때 원인을 격리하기도 쉽습니다.
GeoIP가 “어느 나라에서 왔는지”로 거른다면, Suricata는 “어떤 행동을 하는지”로 거릅니다. 둘은 보완 관계입니다. 절체 직후 GeoIP 차단 로그가 쌓이는지(
Firewall → Log Files → Live View) 먼저 확인하고 넘어가면 좋습니다.
1. Caddy — 443 단일 진입점 리버스 프록시
외부 공개 서비스(홈페이지, 관리 콘솔, 각종 웹 UI)를 인터넷에 하나씩 포트로 여는 건 위험합니다. Caddy는 모든 외부 HTTPS 요청을 443 한 점으로 받아, 도메인별로 내부 백엔드에 분배하는 리버스 프록시입니다. Nginx Proxy Manager(NPM)와 가장 비슷하면서, 자동화가 한 발 더 들어가 있습니다.
Caddy가 해주는 것:
- 자동 SSL: Let’s Encrypt/ZeroSSL에서 인증서를 자동 발급·갱신(HTTP-01/DNS-01/TLS-ALPN-01).
- 자동 HTTPS 리다이렉트: 모든 HTTP를 HTTPS로.
- 접근 제어: Basic Auth, mTLS(Client Auth), IP ACL.
- 인증서 통합: 발급 인증서가 OPNsense Trust에 임포트되어 대시보드에 표시.
기본 설정 흐름
System → Firmware → Plugins → os-caddy 설치
Services → Caddy Web Server → General → Enable
Services → Caddy → Reverse Proxy → Domains (예: app.example.com)
→ Handlers (업스트림: 192.168.x.x:8080)
Firewall → Rules → WAN 에 80, 443 허용도메인을 추가하고 핸들러에서 업스트림(내부 서버:포트)을 지정하면, 외부 app.example.com 요청이 SSL 종단 후 내부 백엔드로 전달됩니다.
함정 ①: OPNsense GUI와 80/443 포트 충돌
OPNsense 자체 GUI(lighttpd)가 80포트로 HTTP→HTTPS 리다이렉트를 하고 있으면, Caddy가 80을 못 잡고 죽습니다. 해결:
System → Settings → Administration
- Web GUI TCP port: 8443 로 변경
- "Disable web GUI redirect rule" 체크 (lighttpd가 80을 놓게)이렇게 GUI를 8443으로 빼면 Caddy가 80/443을 점유하고, 필요하면 vpn.example.com → https://10.0.92.1:8443 식으로 관리 GUI 자체도 Caddy 뒤에 둘 수 있습니다. 포트 점유는 셸에서 확인합니다.
sockstat -4 -l | grep ':80' # 80이 비었는지
service caddy onestart # Caddy 기동
sockstat -4 -l | grep -E ':80 |:443 ' # 80/443 점유 확인함정 ②: DNS Rebind / HTTP_REFERER 차단
리버스 프록시 뒤에서 OPNsense GUI에 접근하면 DNS Rebind Check나 HTTP_REFERER 검사에 막힐 수 있습니다. System → Settings → Administration의 “Alternate Hostnames” 필드에 사용할 도메인을 공백/콤마로 구분해 등록하면(와일드카드 불가) 두 검사를 모두 통과합니다. DNS Rebind 체크박스 자체를 끄는 것보다 이 방법이 안전합니다.
2. Suricata — IDS/IPS
Suricata는 OPNsense에 내장되어 별도 설치 없이 활성화만 하면 됩니다. 시그니처 룰셋과 패킷을 대조해 위협을 탐지(IDS)하거나 차단(IPS)합니다.
Services → Intrusion Detection → Administration안전한 순서: 룰셋 먼저 → IDS로 시작
룰셋을 먼저 받아야 합니다. Enable부터 하면 대조할 룰이 없어 의미가 없습니다.
① Download 탭에서 룰셋 선택 — 무료 핵심 조합:
- ET Open (
emerging-*카테고리) — 필수 - abuse.ch (
feodotracker,sslblacklist,sslipblacklist,threatfox,urlhaus) — 악성 IP/도메인 평판 - ET 평판/차단 IP 계열 (
botcc,ciarmy,compromised,drop,dshield등)
체크 후 Download & Update Rules. 첫 다운로드는 룰이 수만 건이라 5~10분 걸립니다.
② Settings에서 IDS로 활성화 (룰 다운로드 후):
| 항목 | 값 | 비고 |
|---|---|---|
| Enabled | ✅ | |
| IPS mode | ❌ 끄기 | 처음엔 IDS(탐지만). 1~2주 후 전환 |
| Promiscuous mode | ❌ | VLAN 환경 불필요 |
| Interfaces | WAN | 외부 트래픽 1차 방어, CPU 부하 최소 |
Save → Apply.
왜 처음엔 IDS인가, 그리고 VoIP 주의
IPS 모드를 처음부터 켜면 false positive로 정상 트래픽까지 drop되어 운영 사고가 납니다. 1~2주 IDS로 돌리며 Alerts 탭을 관찰하고, 오탐을 Suppress 처리한 뒤 IPS로 전환하는 게 정석입니다.
특히 IP 전화(VoIP)가 있다면 반드시 통화 테스트를 하세요. 이 프로젝트에서도 Suricata를 켠 뒤 외부/내부 통화로 음질·끊김을 확인했습니다. 만약 통화에 문제가 생기면 즉시 Settings → Enabled 해제 → Apply로 30초 안에 원복되고, 그 다음 어느 룰이 문제인지 찾아 그 룰만 Suppress하면 됩니다.
환경에 맞춘 룰셋
사용자 PC·모바일이 있는 본사망과, 서버 서비스만 있는 IDC망은 켜야 할 룰셋이 다릅니다. 예를 들어 서버 전용 구간(IDC)에서는 모바일 멀웨어(mobile_malware) 룰을 제외하는 식으로 조정합니다. 실제로 본사는 ET Open + abuse.ch + 평판 룰을 폭넓게(약 28개), IDC는 서버 특성에 맞춰(모바일 제외, 약 27개) 다르게 적용했습니다.
검증 팁: Alerts가 0건이어도 당황하지 마세요. 트래픽이 들어와야 채워집니다. 서비스가 정상 가동(우상단 상태등 초록)이고
Rules탭에 룰이 수만 건 차 있으면 IDS는 정상입니다. 디스크·CPU도 함께 봅니다(룰셋 200~500MB, 평상시 CPU 30% 미만 권장).
3. Insight (NetFlow) — 트래픽 가시성
Reporting → Insight (NetFlow)Insight는 트래픽 흐름을 기록·시각화만 하고 차단 같은 동작은 하지 않는, 위험이 전혀 없는 작업입니다. 어떤 IP가 트래픽을 많이 쓰는지, 어떤 포트로 통신하는지, 시간대별 패턴이 어떤지를 보여줍니다.
이게 중요한 이유는 방화벽 룰을 좁힐 때 근거 데이터가 되기 때문입니다. “이 통신을 막아도 되나?”를 추측이 아니라 실제 흐름으로 판단할 수 있습니다. WAN과 주요 VLAN을 수집 대상으로 켜두면 됩니다.
4. TOTP — 관리자 2단계 인증
외부 노출이 시작되면 관리자 계정 보호가 중요해집니다. TOTP(Google Authenticator 등)로 관리 로그인에 2단계 인증을 겁니다.
System → Access → Servers → (Local + Timebased OTP 서버 추가)
System → Access → Users → 관리자에 OTP seed 발급 → 인증 앱에 QR 등록
System → Settings → Administration → Authentication 에 OTP 서버 지정솔직한 운영 노트: 이 프로젝트에서 TOTP는 한 사이트에서 보류한 적이 있습니다. 2FA는 분명히 권장 사항이지만, 잠금(lockout) 위험과 운영 편의 사이에서 조직이 판단할 영역이기도 합니다. 다만 운영 서버가 있는 관리망이라면 선택이 아니라 필수에 가깝게 보는 게 맞습니다. 도입한다면, 백업 관리자 계정·복구 수단을 먼저 확보해 자기 자신을 잠그는 사고를 막으세요.
5. VPN — 원격 접속과 사이트 간 연결 (맨 마지막)
다른 방어선이 안정된 뒤, 마지막으로 외부 원격 접속을 엽니다.
원격 근무용: OpenVPN vs WireGuard
| WireGuard | OpenVPN | |
|---|---|---|
| 설정 | 단순(키 페어 + 엔드포인트) | 복잡(CA·인증서) |
| 성능 | 우수(속도·배터리) | 상대적으로 낮음 |
| 인증 | 정적 키 | 인증서·LDAP·2FA 등 다양 |
| 사용자 관리 | 약함 | 세밀 |
소규모 팀이면 WireGuard로 충분합니다. 반면 사용자별 권한 분리, LDAP/2FA 같은 엔터프라이즈 인증이 필요하면 OpenVPN이 유리합니다. 이 프로젝트에서는 OpenVPN을 LDAP 인증 기반(UDP 1194)으로 구성하고, 권한 그룹(관리자/일반)을 나눴습니다. OpenVPN 인증서에는 5편에서 ACME로 발급한 도메인 인증서를 활용했습니다.
OpenVPN은 UDP라 Caddy 같은 HTTP 리버스 프록시로 프록싱할 수 없습니다. 그래서 인증서를 ACME Client로 별도 발급해 Trust 저장소에 넣고, VPN 엔드포인트는 공인 IP(또는 전용 도메인)로 직접 노출하는 구조가 정석입니다.
VPN 대역 미리 예약
VPN 클라이언트에 줄 전용 대역을 미리 잡아두면 방화벽 설계가 깔끔합니다. 이 프로젝트는 10.0.99.0/24를 VPN용으로 예약하고 용도별로 쪼갰습니다.
10.0.99.0/28 Admin VPN (관리망 전체 접근)
10.0.99.16/28 Dev VPN (개발망만)
10.0.99.32/27 User VPN (재택 사용자)이렇게 분리하면 “관리자 VPN은 관리망까지, 사용자 VPN은 제한된 곳만” 같은 정책을 방화벽에서 대역 단위로 명확히 걸 수 있습니다. 외부에서 운영 접속은 VPN 인증 후 관리망(MGHQ)을 거치도록 하고, PRHQ·PRDC·MGDC로의 직접 외부 접근은 막습니다.
사이트 간 연결: IPsec Site-to-Site
본사(HQ)와 데이터센터(IDC)를 IPsec Site-to-Site로 묶어, 관리·배포·모니터링·백업 등 모든 관리 트래픽을 관리망(MGHQ ↔ MGDC) 경유로 통일했습니다. 운영망끼리(PRHQ ↔ PRDC)는 차단하고 필요 시 인터넷 경유로만 통신하게 해, 사이트 간 운영 트래픽을 격리했습니다.
IPsec에서 자주 막히는 지점이 라우팅입니다. 터널 너머 대역으로 트래픽을 보내려면 phase2(트래픽 셀렉터)에 해당 대역이 포함되거나 static route가 있어야 합니다. 빠지면 사설 IP 요청이 기본 경로(WAN)로 잘못 나가 도달하지 못합니다.
현장 팁: IDC 같은 원격지는 초기 구축 때 관리망 접근 자체가 막막할 수 있습니다. 이 프로젝트에서는 현장의 공유기를 허브(브리지) 모드로 바꿔 관리망(MGDC)에 임시 접속 채널을 만들어 작업했습니다. 2편의 “임시 LAN”과 같은 발상 — 정식 경로가 서기 전까지의 백도어를 하나 확보해두는 것입니다.
시리즈를 마치며
여섯 편에 걸쳐 OPNsense로 중소 규모 네트워크를 처음부터 구축하는 과정을 정리했습니다.
- 1편 하드웨어·설치 — Intel NIC, ZFS Mirror, Web UI 접속 전까지
- 2편 Interface/VLAN — 트렁크 한 포트에 VLAN 6개, 게이트웨이 부여
- 3편 DHCP·방화벽 — Kea 충돌 회피, Alias, 관리망부터 점진 격리
- 4편 NAT·WAN 절체 — 2단계 무중단 절체와 롤백
- 5편 절체 전 보안 — NTP·백업·GeoIP·ACME
- 6편 절체 후 방어선 — Caddy·Suricata·TOTP·VPN (이번 편)
관통하는 원칙은 둘이었습니다. 위험 없는 작업부터, 통신을 끊을 수 있는 것은 뒤로. 그리고 내 접속을 끊지 않는 순서로. 상용 UTM 한 대에 묶여 있던 기능을, 오픈소스 한 대로 망분리·IDS·리버스 프록시·VPN·사이트 연동까지 통합하면서도, 전환기의 통신 단절을 최소화하는 게 목표였습니다.
남은 과제(안정화 트랙)도 적어둡니다. CrowdSec(커뮤니티 IP 평판 차단), API+Ansible(운영 자동화), Telegraf+Grafana(대시보드), 그리고 IDS→IPS 전환과 방화벽 룰의 최종 강화입니다. 이건 운영하며 데이터를 쌓은 뒤 천천히 조여가는 영역입니다.
