[pfSense] 19. pfBlockerNG : pfSense로 광고·악성 도메인·지역 IP 차단하기

* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

(pfSense 홈랩 방화벽 ⑲)

pfSense를 방화벽 '장비'로 끌어올리는 첫 패키지가 pfBlockerNG다. 기기마다 광고 차단 앱을 깔 필요 없이, 네트워크 길목에서 광고·추적·악성 도메인을 통째로 걸러 준다. 집 안 모든 기기가 자동으로 혜택을 본다.

Table of Contents

두 개의 축 — DNSBL과 IP

DNSBL(도메인 차단) — DNS Resolver와 연동해, 광고·악성 도메인 조회가 오면 진짜 IP 대신 0.0.0.0을 돌려줘 연결을 끊는다(싱크홀).
IP 차단 — 알려진 악성 IP나 특정 국가 IP 목록(피드)을 받아 방화벽에서 통째로 막는다. URL Table Alias의 실전 활용이다.

graph TD
  Q[기기의 도메인 조회] --> B{광고/악성 목록?}
  B -->|예| S[0.0.0.0 반환 · 차단]
  B -->|아니오| R[정상 IP 반환]

설정 흐름

System > Package Manager에서 pfBlockerNG를 설치하고 마법사를 돌린다. DNSBL을 켜고, 광고 차단으로 유명한 피드(예: 공개 광고·추적 도메인 목록)를 추가한다. 그다음 'Force Update'로 목록을 내려받으면 적용된다. IP 차단은 GeoIP 데이터를 받아 국가 단위로 켤 수 있는데, 너무 광범위하게 막으면 정상 서비스까지 끊기니 처음엔 로그만 남기는 모드로 시작하는 걸 권한다.

직접 해보기

pfBlockerNG 설치 → DNSBL 활성 → 광고 도메인 피드 하나 추가 → Force Update.
클라이언트에서 광고 도메인을 조회해 0.0.0.0이 오는지 확인한다.
대시보드의 pfBlockerNG 위젯에서 차단 건수가 올라가는지 본다.

# 광고 도메인이 싱크홀되는지 확인 (0.0.0.0 이면 차단됨)
$ nslookup ads.example.com 192.168.10.1

✅ 확인 — 광고 도메인 조회가 0.0.0.0으로 막히고 차단 카운터가 오르면 성공이다. DNSBL과 IP 차단이 각각 어느 계층에서 막는지 구분해 보자.

설정 흐름 — DNSBL 켜기

순서가 있다. pfBlockerNG 설치 → DNS Resolver(Unbound) 연동 켜기 → 광고·추적 피드 추가 → 스케줄로 자동 업데이트 → 적용. DNSBL은 Unbound가 켜져 있어야 동작하니 7편의 DNS가 전제다. 그리고 기기들이 pfSense DNS를 실제로 써야 효과가 난다 — 이 조건이 안 맞으면 아무리 막아도 광고가 그대로다.

피드 고르기 — 과하면 오작동

블록리스트를 너무 공격적으로 넣으면 멀쩡한 사이트·앱이 깨진다(오탐, false positive). 광고·추적 위주의 검증된 리스트로 시작하고, 문제가 생기면 화이트리스트로 예외를 둔다. ‘많이 막을수록 좋다’가 아니라 ‘필요한 만큼’이다. 리포트에서 무엇이 막혔는지 보며 조정하는 게 정석이다.

지역 차단(GeoIP)과 IP 피드

IP 축은 국가 단위 차단(GeoIP)이나 알려진 악성 IP 목록을 방화벽에서 통째로 막는다. 예컨대 내 서비스에 특정 국가만 허용하거나 차단할 수 있다. 단 GeoIP DB(MaxMind 등)는 별도 등록(무료 라이선스 키)이 필요할 수 있다. 국가 차단은 강력하지만 정상 트래픽까지 막을 수 있으니 신중하게 적용한다.

효과 확인과 튜닝 — DoH 함정

pfBlockerNG의 Reports/Alerts에서 얼마나, 무엇이 차단됐는지 본다. 광고가 그대로라면 → 기기가 pfSense DNS를 안 쓰거나, 리스트 문제다. 특히 요즘 브라우저·앱의 DNS over HTTPS(DoH)는 이 차단을 우회하니, 필요하면 DoH를 막는 규칙도 함께 건다. 한 번 켜고 끝이 아니라, 리포트를 주기적으로 보며 다듬는 게 이 도구를 제대로 쓰는 법이다.

도메인·IP 목록으로 '아는 나쁜 놈'을 막았다면, 다음 편은 모르는 공격을 잡는 침입 탐지, Suricata다.

🔧 현장에서 — 방화벽을 조인 뒤 WordPress Jetpack이 끊겼다

Cloudflare/방화벽 정책을 강화한 이후 WordPress Jetpack 통신이 차단됐다. Jetpack은 일반 방문 외에도 XML-RPC · REST API · admin-ajax · 외부 서버 통신을 쓴다. 전체 방화벽을 풀지 않고, Jetpack이 필요로 하는 Endpoint와 Source만 제한적으로 허용했다. 필요할 땐 Jetpack 서비스의 ASN/IP 범위를 pfBlockerNG Alias로 관리했다.

교훈 — 외부 서비스를 허용할 땐 전체 허용이 아니라 서비스 → Endpoint → IP/ASN 순으로 최소 범위만 열어라. (이 블로그도 실제로 이렇게 운영한다)

자주 묻는 질문 (FAQ)

pfBlockerNG로 광고를 차단할 수 있나요?

네, DNSBL로 광고·추적·악성 도메인을 네트워크 전체에서 차단합니다. 기기마다 차단 앱을 깔 필요가 없습니다.

특정 국가 IP를 막을 수도 있나요?

GeoIP 기능으로 국가 단위 IP 대역을 차단·허용할 수 있습니다. 다만 오탐으로 정상 서비스가 막힐 수 있어 주의가 필요합니다.