FreeBSD PF 방화벽 설정, 접속 끊김 없이 안정적으로 적용하는 방법

FreeBSD PF 방화벽 설정 시 서버를 막 설치하고 SSH로 접속까지는 했는데, 방화벽을 켜려는 순간 가장 많이 멈추는 지점이 있습니다. 설정한 줄 잘못 넣으면 바로 접속이 끊길 수 있다는 점 때문입니다. 이 글에서는 SSH 연결을 유지하면서 PF 방화벽을 안전하게 적용하는 전체 흐름을 단계별로 정리합니다.

이 글에서 다루는 범위

PF 개념 이해 → 안전한 활성화 순서 → 기본 정책 설정 → 포트 제어 → 운영 중 실수 방지

1. PF 방화벽 구조를 먼저 이해해야 하는 이유

설정을 시작하기 전에 개념을 건너뛰면, 나중에 규칙이 꼬이는 경우가 많습니다. PF는 기본적으로 규칙 순서 기반 필터링이며 위에서 아래로 순차적으로 적용됩니다. 또한 기본 정책(default policy)을 어떻게 설정하느냐에 따라 전체 보안 수준이 달라집니다.

실제로 설정 파일을 작성하다 보면 “허용했는데 왜 막히지?”라는 상황이 자주 발생합니다. 이 경우 대부분은 상단 규칙에 의해 이미 차단된 상태인 경우가 많습니다.

즉, PF는 문법보다도 적용 순서 이해가 더 중요하게 작용하는 방화벽입니다. 여기서 갈리는 핵심은 “규칙 내용”보다 “위치”라는 점입니다.

2. FreeBSD에서 PF 활성화 전 체크 사항

방화벽을 켜기 전에 가장 먼저 확인해야 하는 것은 현재 접속 방식입니다. 특히 원격 SSH 접속 상태라면, 잘못 적용했을 때 바로 접속이 끊길 수 있습니다.

기본적으로 다음 설정을 /etc/rc.conf에 추가합니다.

pf_enable=”YES”
pf_rules=”/etc/pf.conf”

하지만 이 단계에서 바로 활성화하는 것은 위험할 수 있습니다. 실무에서는 설정 파일을 먼저 검증하고 나중에 적용하는 순서를 권장합니다.

많은 경우 “설정 작성 → 바로 enable” 순서로 진행하다가 접속이 끊깁니다. 놓치기 쉬운 포인트는 “활성화보다 검증이 먼저”라는 점입니다.

3. pf.conf 기본 설정 흐름

처음 pf.conf를 작성할 때 가장 헷갈리는 부분은 어디까지 허용할지 기준입니다. 기본 구조는 보통 모두 차단 → 필요한 것만 허용 방식으로 설정합니다.

예시 흐름은 다음과 같습니다.

block all
pass out all keep state
pass in proto tcp from any to any port 22 keep state

여기서 중요한 부분은 SSH 포트를 먼저 허용하는 것입니다. 설정 적용 직전에 이 규칙이 없으면 바로 접속이 끊길 수 있습니다.

겉으로는 간단해 보이지만 실제로는 허용 규칙을 어디에 두느냐에서 문제가 많이 발생합니다. 헷갈리기 쉬운 부분은 “허용은 했는데 적용 위치가 잘못된 경우”입니다.

4. 포트 허용과 차단 규칙 설정 방법

웹 서버나 서비스 운영을 시작하면 특정 포트를 추가로 열어야 하는 상황이 생깁니다. 이때 단순히 포트만 열기보다 접속 범위까지 고려하는 것이 중요합니다.

예를 들어 HTTP/HTTPS는 다음처럼 설정할 수 있습니다.

pass in proto tcp from any to any port {80, 443} keep state

하지만 관리용 포트(예: SSH)는 특정 IP만 허용하는 방식이 더 안전합니다. 실제로 운영 환경에서는 모든 포트를 공개하는 것보다 제한하는 방식이 기본입니다.

많은 사용자가 포트만 열고 끝내지만, 실제 보안은 접근 범위에서 갈립니다. 여기서 갈리는 핵심은 “열 것인가”보다 “누가 접근 가능한가”입니다.

5. 실제 운영에서 자주 막히는 지점

설정까지는 완료했는데 서비스가 정상 동작하지 않는 경우가 있습니다. 이 단계에서 가장 흔한 문제는 예상하지 못한 트래픽 차단입니다.

예를 들어 내부 통신이나 DNS 요청이 막혀 서비스가 느려지는 경우도 있습니다. 또한 로그를 확인하지 않으면 어떤 트래픽이 차단됐는지 알기 어렵습니다.

이럴 때는 pflog를 활용해 차단 로그를 확인하는 것이 도움이 됩니다. 대부분 문제는 규칙 부족이 아니라 보이지 않는 차단 때문에 발생합니다.

직접 확인해 보면 의외로 외부 공격보다 내부 통신 차단이 더 많이 발생합니다. 놓치기 쉬운 포인트는 “서비스 장애 원인이 방화벽일 수 있다”는 점입니다.

6. 적용 후 점검과 유지 관리 방법

설정을 적용한 후 바로 끝내는 경우가 많은데, 실제로는 이 단계가 더 중요합니다. 적용 이후에는 반드시 정상 동작 여부를 확인해야 합니다.

기본적으로 확인할 항목은 다음과 같습니다.

SSH 접속 유지 여부
웹 서비스 접속 가능 여부
외부 포트 스캔 결과
시스템 로그 확인

특히 서버를 재부팅했을 때도 동일하게 동작하는지 확인해야 합니다. 운영 환경에서는 재시작 이후 문제가 발생하는 경우가 꽤 많습니다.

대부분 설정 자체보다 검증을 생략해서 생기는 문제가 더 많습니다. 여기서 갈리는 핵심은 “설정 완료”가 아니라 “검증 완료”입니다.

FAQ

Q1. PF 적용하면 바로 서버가 안전해지나요?
기본적인 보호는 가능하지만, 설정 범위에 따라 효과는 크게 달라질 수 있습니다. 최소한 필요한 포트만 열려 있는지 점검하는 것이 중요합니다.

Q2. SSH 포트를 꼭 22번으로 유지해야 하나요?
반드시 그럴 필요는 없습니다. 다만 포트를 변경하더라도 해당 포트를 먼저 허용하지 않으면 접속이 끊길 수 있습니다.

Q3. pf.conf 수정 후 바로 적용해도 되나요?
가능하지만, 적용 전에 문법 검사와 설정 검토를 거치는 것이 안전합니다. 이 단계를 건너뛰는 경우 문제가 자주 발생합니다.

Q4. 모든 포트를 막는 것이 가장 안전한가요?
보안 측면에서는 맞지만, 서비스 운영에는 필요한 포트를 열어야 합니다. 무조건 차단보다는 목적에 맞는 허용이 중요합니다.

Q5. 로그는 꼭 확인해야 하나요?
문제가 발생했을 때 원인을 찾기 위해 거의 필수입니다. 특히 예상치 못한 차단을 발견하는 데 도움이 됩니다.

마무리

PF 설정은 단순히 켜는 것보다 순서와 검증 과정이 훨씬 중요합니다. 특히 처음 설정할 때는 SSH 연결 유지와 기본 허용 규칙을 우선으로 두는 것이 안전합니다.

지금 단계라면 무리하게 복잡한 규칙을 추가하기보다, 기본 차단 + 필요한 포트만 허용 구조부터 안정적으로 만드는 것을 권장합니다.

※ 안내

이 글은 일반적인 서버 운영 기준을 바탕으로 정리된 내용입니다. 실제 환경(클라우드, 네트워크 구조, 서비스 구성)에 따라 설정 방식과 필요조건은 달라질 수 있으므로 적용 전 반드시 본인 환경에 맞게 검토하시기 바랍니다.

댓글 남기기

광고 차단 알림

광고 클릭 제한을 초과하여 광고가 차단되었습니다.

단시간에 반복적인 광고 클릭은 시스템에 의해 감지되며, IP가 수집되어 사이트 관리자가 확인 가능합니다.