* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(pfSense 홈랩 방화벽 ㉑)
방화벽을 운영하다 보면 '왜 이게 막혔지/열렸지' 하는 순간이 온다. 그때 답은 항상 로그에 있다. pfSense는 무슨 일이 있었는지 꽤 상세히 남기는데, 읽는 법을 알면 문제 해결 시간이 확 줄어든다. 이번 편이 그 ‘읽는 법’ — pfSense 로그 보는 법의 전부다.
방화벽 로그 읽기
Status > System Logs > Firewall에 차단·허용 기록이 실시간으로 쌓인다. 각 줄은 시각, 어느 인터페이스에서, 어떤 규칙이, 어떤 출발지→목적지를, 막았는지/통과시켰는지 보여준다. 빨간 표시가 차단이다. 여기서 'X 아이콘'을 누르면 그 트래픽을 허용하는 규칙을 바로 만들 수도 있어서, 트러블슈팅이 편하다.
기본적으로 pass 규칙은 로그를 안 남긴다. 특정 규칙이 언제 걸리는지 추적하고 싶으면, 그 규칙 편집 화면에서 Log 옵션을 켜면 된다. 단, 모든 규칙에 로깅을 켜면 로그가 폭주하니 필요한 것만 켠다.
실시간으로 보기
| 도구 | 메뉴 경로 | 보는 것 |
|---|---|---|
| Traffic Graphs | Status > Traffic Graph | 인터페이스별 실시간 대역폭 + 호스트별 사용량 |
| States | Diagnostics > States | 현재 열린 연결(상태 테이블) |
| pfTop | Diagnostics > pfTop | 연결을 트래픽 순으로 정렬 |
| Monitoring | Status > Monitoring | 시간대별 그래프(과거 추이) |
홈랩이 커지면 로그를 pfSense 안에만 두기 아깝다. 원격 syslog로 내보내면 별도 로그 서버(예: Graylog)에서 장기 보관·검색·알림을 걸 수 있다. 재부팅해도 로그가 남고, 여러 장비 로그를 한곳에서 보게 된다.
직접 해보기
- 규칙 하나에 로깅을 켜고, 해당 트래픽을 발생시켜 방화벽 로그에 뜨는지 본다.
- Traffic Graphs로 실시간 대역폭을, States로 열린 연결을 관찰한다.
- 차단 로그에서 X 아이콘으로 허용 규칙을 즉석에서 만들어 본다.
✅ 확인 — 방화벽 로그에서 특정 차단·허용을 찾아 '어느 규칙이 왜'를 읽어낼 수 있으면 성공이다. 이 능력이 앞으로 모든 트러블슈팅의 기본기다.
로그 한 줄 뜯어읽기
방화벽 로그 한 줄엔 꽤 많은 게 담긴다 — 시각 / 인터페이스(WAN·LAN) / 동작(pass·block) / 프로토콜 / 출발지 IP:포트 → 목적지 IP:포트. 읽는 법은 ‘언제 어느 문에서 누가 어디로 가려다 어떻게 됐나’다. 같은 출발지 IP가 반복되면 스캐너일 수 있고, 내가 기대한 통신이 block으로 찍히면 규칙 순서를 의심한다. 실제 WAN 차단 로그 한 줄을 표로 해부하면 이렇다.
| 항목 | 예시 값 | 해석 |
|---|---|---|
| Action | block (빨간 X) | 허용 규칙에 안 걸려 차단 |
| Interface | WAN | 인터넷 쪽 문 |
| Rule | Default deny rule IPv4 | 기본 차단 규칙(내 규칙 아님) |
| Source | 198.51.100.83:55712 | 낯선 외부 호스트 |
| Destination | 203.0.113.20:23 | 공인 IP의 23번(텔넷) |
| Proto | TCP:S | TCP SYN — 연결 시도 |
한 문장으로 — “낯선 호스트가 텔넷 포트를 두드렸고, 허용 규칙이 없어 기본 차단이 막았다.” 텔넷(23)은 봇넷 단골이라 전형적인 자동 스캔 — 방화벽이 일한다는 증거다. 방화벽 로그 분석의 절반은 이런 ‘정상 소음’과 ‘봐야 할 줄’을 가려내는 안목이다. 잘 되던 통신이 TCP:A로 block에 찍히면 대부분 만료 상태의 잔여 패킷이라 장애가 아닐 때가 많다.
흔한 상황 3가지 — 진단 흐름
① “뭔가 차단된 것 같은데 뭔지 모르겠다”
- 문제를 재현하고 Status > System Logs > Firewall에서 그 시각의 block 줄을 찾는다.
- 상단 깔때기 아이콘(Advanced Log Filter) → Source에 기기 IP → Apply.
- 규칙명이 Default deny rule이면 허용 누락 — 목적지 옆 ➕(Easy Rule)로 허용 후 정리. 내 규칙이면 순서·조건 재확인.
- pfBlockerNG·Suricata의 차단은 여기 안 뜬다 — 패키지 로그도 확인.
✅ 성공 기준 — block 줄에서 규칙명을 읽어냈고, 허용 후 차단이 더 안 쌓이면 된다.
② “이 기기가 대체 뭘 하는지 보고 싶다”
- Advanced Log Filter에 Source = 기기 IP.
- 목적지 IP·포트 패턴을 본다 — DNS(53)·NTP(123)·443은 평범한 생존 신호.
- 안 잡히면 pass 로깅이 꺼진 것 — 허용 규칙에 Log를 잠깐 켠다(끝나면 끈다).
- 현재 연결은 Diagnostics > States에서 IP 필터.
✅ 성공 기준 — “평소 이 서버·이 포트” 기준선을 만들면 성공. 벗어난 줄이 곧 이상 징후다.
③ “인터넷이 갑자기 느리다”
- Status > Traffic Graph — WAN 그래프가 회선 한계에 붙었는지, 옆 호스트 목록에서 어느 내부 IP가 얼마나 쓰는지.
- Diagnostics > pfTop을 bytes로 정렬해 최상위 연결을 짚는다.
- Diagnostics > States에서 그 IP 필터, 급하면 상태 삭제(kill).
- 반복되면 트래픽 셰이핑(QoS)으로.
✅ 성공 기준 — “누가 어디로 얼마나”를 숫자로 지목하면 성공이다.
노이즈 줄이기 — 다 기록하지 않기
차단 로그가 너무 많아 정작 중요한 게 묻히는 건 흔한 문제다. WAN에 쏟아지는 인터넷發 스캔 차단은 대부분 무해한 배경소음이다. 기본 차단 규칙의 로그를 끄거나, 시끄러운 특정 소스를 조용히 차단(로그 off)하는 규칙을 위에 두면 로그가 깔끔해진다. ‘봐야 할 것만 남기기’가 로그 운영의 핵심이다.
스위치는 Status > System Logs > Settings에 있다. Log firewall default blocks를 끄면 배경소음 로그가 사라지지만 공격 시도의 흔적도 안 남는 트레이드오프 — 처음엔 켜서 평상시 소음을 익힌 뒤 끄는 걸 권한다. 평소를 모르면 이상도 못 알아본다. 로그 파일 크기·보관 개수(순환 기준)도 여기서 조절한다 — 키우면 오래 소급하지만 소형 SSD 용량·수명과 맞바꾼다.
장기 보관·원격 전송 — syslog
pfSense 로그는 링 버퍼라 오래되면 덮인다. 보안 분석이나 장기 추적이 필요하면 Status > System Logs > Settings에서 원격 syslog 서버(예: Graylog 같은 로그 수집기)로 전송한다. 그러면 재부팅해도 로그가 남고, 여러 장비의 로그를 한곳에서 볼 수 있다.
거창한 수집기 없이 리눅스 VM의 rsyslog면 된다. pfSense 쪽은 Settings 맨 아래 Remote Logging Options — Enable Remote Logging 체크, Remote log servers에 192.168.10.50:514, Contents는 Firewall Events부터. 받는 쪽은 이게 전부다.
# /etc/rsyslog.d/10-pfsense.conf
module(load="imudp")
input(type="imudp" port="514")
if $fromhost-ip == "192.168.10.1" then {
action(type="omfile" file="/var/log/pfsense.log")
stop
}수신 서버 방화벽에서 514/udp 개방만 잊지 말자. ✅ 확인 — rsyslog 재시작 후 tail -f /var/log/pfsense.log에 이벤트가 흐르고, pfSense 재부팅 후에도 로그가 남아 있으면 성공.
대시보드·알림으로 감시
로그를 매번 들여다볼 순 없으니, pfSense 대시보드 위젯(인터페이스 상태·게이트웨이·트래픽 그래프)으로 한눈에 본다. 이상 징후를 놓치기 싫으면 Notifications(이메일·텔레그램 등)를 설정해, 게이트웨이 다운 같은 사건을 즉시 통보받는다. Monitoring 그래프로 트래픽 추세까지 보면, ‘무슨 일이 벌어지는지’를 늘 손안에 두게 된다.
보안 기능을 붙일수록 관리 접속 자체의 보안도 중요해진다. 다음 편은 웹GUI를 HTTPS로 감싸고 내부 인증서(CA)를 만드는 이야기다.
🔧 현장에서 — 이 로그가 진짜 장애인지부터 판단하라
Apache SSL 로그에 AH02007 SSL handshake interrupted · AH01998 abortive shutdown이 반복적으로 찍힌 적이 있다. 처음엔 SSL 설정이나 인증서를 의심할 상황이었는데, 접속 Source와 발생 패턴을 보니 Load Balancer/Health Check가 Connection을 열었다가 Handshake 완료 전에 끊는 경우였다. 즉 모든 handshake interrupted가 실제 장애를 뜻하는 건 아니었다.
교훈 — 운영 로그는 메시지 자체보다 누가·언제·어떤 주기로 접속했나를 같이 봐야 한다.
자주 묻는 질문 (FAQ)
방화벽 로그는 어디서 보나요?
Status → System Logs → Firewall에서 실시간 차단·허용 내역을 봅니다. 어떤 규칙이 트래픽을 처리했는지 추적할 수 있습니다.
차단 로그가 너무 많아요.
인터넷 배경 스캔이라 대부분 정상입니다. 잡음은 해당 규칙의 로깅을 끄고 중요한 규칙만 로그를 남기면 깔끔합니다.
pfSense 로그는 얼마나 오래 보관되나요?
로컬 로그는 파일 크기 기준 순환이라 오래된 것부터 덮입니다. 장기 보관은 Settings의 원격 syslog로 별도 서버(rsyslog·Graylog)에 쌓는 것이 정석입니다.
답글 남기기