지난 5편에서 절체 전 보안 기반(NTP·백업·GeoIP·ACME)을 깔았고, OPNsense는 4편에서 메인 방화벽으로 절체됐습니다. 이제 OPNsense는 공인 IP로 외부에 노출된 상태예요. 이번 편은 그 노출에 대응하는 능동 방어선 — Caddy(리버스 프록시), Suricata(IDS/IPS), 관리자 2FA(TOTP) — 와 원격 접속(OpenVPN/WireGuard, 사이트 간 IPsec)을 다룹니다. OPNsense 편을 마무리하는 글이고, 다음 편부터는 스위치(L2)로 넘어갑니다.
절체 후 작업의 순서 원칙
절체로 외부 노출이 시작됐으니, 이제 “탐지하고, 막고, 지키고, 안전하게 들어오는” 네 가지를 세웁니다. 순서에는 이유가 있어요. 참고로 IDS/IPS·리버스 프록시·VPN은 정보보안 직무 면접에서 단골로 나오는 주제라, 작은 사무실이나 홈랩에 직접 한 번 세워 보면 답변의 깊이가 확 달라집니다. 정보보안기사를 준비하는 분이라면 책으로만 보던 개념을 손으로 만져 보는 기회이기도 해요.
- 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)해요. 보안관제(SOC)·침해대응 직무를 노린다면 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·모바일이 있는 업무망과, 서버 서비스만 있는 서버망은 켜야 할 룰셋이 다릅니다. 예를 들어 서버 전용 구간에서는 모바일 멀웨어(mobile_malware) 룰을 제외하는 식으로 조정해요. 실제로 업무망은 ET Open + abuse.ch + 평판 룰을 폭넓게(약 28개), 서버망은 서버 특성에 맞춰(모바일 제외, 약 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 인증 후 관리망을 거치도록 하고, 운영망으로의 직접 외부 접근은 막아요.
사이트 간 연결: IPsec Site-to-Site
두 거점(예: 사무실과 원격지)을 IPsec Site-to-Site로 묶어, 관리·배포·모니터링·백업 등 모든 관리 트래픽을 관리망 경유로 통일할 수 있습니다. 운영망끼리는 차단하고 필요 시 인터넷 경유로만 통신하게 해, 사이트 간 운영 트래픽을 격리하는 식이에요.
IPsec에서 자주 막히는 지점이 라우팅입니다. 터널 너머 대역으로 트래픽을 보내려면 phase2(트래픽 셀렉터)에 해당 대역이 포함되거나 static route가 있어야 해요. 빠지면 사설 IP 요청이 기본 경로(WAN)로 잘못 나가 도달하지 못합니다.
현장 팁: 원격지는 초기 구축 때 관리망 접근 자체가 막막할 수 있습니다. 이럴 때는 현장의 공유기를 허브(브리지) 모드로 바꿔 관리망에 임시 접속 채널을 만들어 작업해요. 2편의 “임시 LAN”과 같은 발상 — 정식 경로가 서기 전까지의 백도어를 하나 확보해두는 것입니다.
OPNsense 편을 정리하며
여섯 편에 걸쳐 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 전환과 방화벽 룰의 최종 강화입니다. 이건 운영하며 데이터를 쌓은 뒤 천천히 조여가는 영역이에요. 여기까지 따라오셨다면 보안 직무 면접에서 “직접 IDS/IPS를 세워 봤다”고 당당히 말할 수 있는 경험치가 쌓인 셈입니다. 막히는 설정이나 오탐 처리 노하우가 있다면 누스쿨 커뮤니티에 공유해 주세요 — 같은 길을 걷는 분들에게 큰 힘이 됩니다.
이전 글: 네트워크 입문 – 05. OPNsense 보안 설정 ①: 절체 전 보안 기반 (NTP·백업·GeoIP·ACME)
다음 글: 네트워크 입문 – 07. Omada 백본 스위치: L2 VLAN과 트렁크 (SG3452X Standalone)
💬 댓글 0