FIREWALLD 차단 로그 확인 방법 및 리눅스 방화벽 설정 상세 더보기

서버 운영 및 보안 관리에서 방화벽(Firewall)은 외부의 악의적인 접근으로부터 시스템을 보호하는 가장 기본적인 수단입니다. 리눅스 환경에서는 주로 iptablesfirewalld와 같은 도구를 사용하여 방화벽을 관리합니다. 그중에서도 firewalld는 동적인 방화벽 관리를 지원하여 최근 많은 리눅스 배포판에서 기본으로 사용되고 있습니다. 보안 사고를 예방하거나 발생 후 원인을 분석하기 위해서는 방화벽이 차단한 트래픽에 대한 로그(Log)를 확인하는 것이 매우 중요합니다. 이 포스팅에서는 firewalld의 차단 로그를 어떻게 설정하고 확인하는지에 대한 구체적인 방법을 다루며, 리눅스 방화벽 설정을 더욱 상세하게 알아보겠습니다.

특히 2025년 현재, 서버 보안의 중요성이 더욱 강조됨에 따라 방화벽 로그 분석은 필수적인 관리 업무가 되었습니다. 이전 2024년에도 중요한 부분이었지만, 클라우드 환경의 복잡성 증가 및 사이버 공격의 지능화로 인해 실시간으로 방화벽 상태를 모니터링하고 로그를 분석하는 능력이 더욱 요구되고 있습니다. 이 정보를 통해 여러분의 리눅스 시스템 보안을 한 단계 끌어올리시길 바랍니다.

firewalld가 차단한 트래픽 로그를 확인하는 절차는 크게 로깅 규칙 설정로그 파일 확인의 두 단계로 나뉩니다. 기본적으로 firewalld는 차단(DROP)된 패킷에 대해 자동으로 로그를 남기지 않기 때문에, 관리자가 직접 로깅 규칙을 추가해야 합니다.

FIREWALLD 차단 로그 설정 방법 확인하기

firewalld에서 특정 트래픽의 차단 로그를 남기려면 iptablesLOG 타겟과 유사하게, firewalld의 ‘rich rule’ 기능을 사용해야 합니다. firewalld는 기본적으로 패킷을 DROP하거나 REJECT하지만, 해당 액션을 취하기 전에 먼저 로그를 남기도록 규칙을 설정할 수 있습니다. 로그 규칙은 영구적으로 적용하거나(--permanent), 현재 세션에만 임시로 적용할 수 있습니다.

가장 일반적인 시나리오는 특정 소스 IP나 서비스 포트에 대한 접근을 차단하면서 동시에 로그를 남기는 것입니다. 여기서는 예시로, ‘public’ 영역(Zone)에 들어오는 모든 차단 트래픽에 대해 로그를 남기는 방법을 설명합니다.

1. 로깅 규칙 추가:

아래 명령어는 ‘public’ 영역으로 들어오는 모든 패킷(rule family="ipv4")에 대해 로그 프리픽스(prefix)를 ‘FIREWALLD_DROP: ‘으로 설정하여 기록하도록 합니다. 그리고 이 규칙은 이후에 오는 DROP이나 REJECT 규칙보다 앞서 적용되어야 합니다.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule drop limit value="10/m" audit' sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule drop log prefix="FIREWALLD_DROP: " level="notice" limit value="10/m"'

2. 방화벽 재로딩:

--permanent 옵션을 사용했으므로, 변경 사항을 적용하기 위해 방화벽을 재로딩해야 합니다.

sudo firewall-cmd --reload

3. 로깅 확인:

이 규칙을 추가하면, ‘public’ 영역으로 들어오는 차단된 트래픽(예: 허용되지 않은 포트로의 접근)이 시스템 로그에 기록되기 시작합니다. 로그 위치는 다음 섹션에서 자세히 다룹니다.

FIREWALLD 차단 로그 파일 위치 및 확인 상세 더보기

firewalld의 차단 로그는 firewalld 자체에서 별도로 관리하는 파일이 아니라, 리눅스 시스템의 일반적인 커널 로그에 기록됩니다. 따라서 사용하는 리눅스 배포판 및 시스템 로깅 서비스(예: rsyslog, systemd-journald) 설정에 따라 로그가 저장되는 위치가 다를 수 있습니다. 대부분의 최신 리눅스 시스템에서는 systemd-journald를 사용하여 로그를 통합 관리합니다.

CentOS/RHEL, Fedora (systemd-journald 기반)

이러한 배포판에서는 journalctl 명령어를 사용하여 로그를 확인하는 것이 일반적입니다. 방화벽 로그는 커널에서 발생하므로 _TRANSPORT=kernel 필터 또는 -k 옵션을 사용합니다. 또한, 앞서 설정한 ‘FIREWALLD_DROP: ‘ 프리픽스를 이용하여 로그를 필터링할 수 있습니다. 로그 파일 확인은 보안 분석의 핵심 단계입니다.

# 커널 로그 전체 확인 (최신 로그부터) sudo journalctl -k
FIREWALLD_DROP 프리픽스가 포함된 로그만 필터링
sudo journalctl -k | grep "FIREWALLD_DROP:"
실시간으로 로그 확인 (모니터링 시 유용)
sudo journalctl -f

Debian, Ubuntu (rsyslog 또는 journald 기반)

전통적으로 rsyslog를 사용하는 시스템에서는 커널 로그가 /var/log/kern.log/var/log/messages 파일에 저장될 수 있습니다.

# /var/log/kern.log 파일 확인 sudo tail -f /var/log/kern.log | grep "FIREWALLD_DROP:"

만약 시스템이 systemd-journald를 사용한다면, 위에서 설명한 journalctl 명령어를 동일하게 사용할 수 있습니다.

특정 포트 및 IP 차단 및 로깅 예제 보기

앞서 모든 차단 트래픽에 대한 로깅 규칙을 설정했다면, 이제 특정 IP 주소나 포트에 대한 접근을 명시적으로 차단하는 규칙을 추가하여 로깅을 테스트해볼 수 있습니다. 이 과정은 특정 공격 IP를 블랙리스트에 올리거나, 보안 정책상 특정 서비스를 외부에서 접근하지 못하도록 할 때 유용합니다.

1. 특정 IP 주소 차단 및 로깅

예를 들어, 악성 접근이 의심되는 IP 주소 192.168.1.100으로부터의 모든 접근을 ‘public’ 영역에서 영구적으로 차단하는 규칙을 추가합니다.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" drop' sudo firewall-cmd --reload

이제 해당 IP에서 서버에 접근을 시도하면, 앞서 설정한 로깅 규칙에 의해 기록이 남고 이어서 DROP 규칙이 적용되어 트래픽이 차단됩니다. 특정 IP를 차단하는 것은 방화벽 관리의 기본입니다.

2. 특정 포트 차단 및 로깅

만약 SSH 포트 22번이 ‘public’ 영역에서 열려있지 않다고 가정하고, 해당 포트로의 접근 시도를 차단하고 로그를 남기도록 할 수 있습니다. (기본 firewalld 설정에서는 허용되지 않은 포트는 기본적으로 차단되므로, 로깅 규칙만으로도 충분합니다.)

만약 특정 포트를 명시적으로 차단하고 싶다면, 아래와 같이 reject 규칙을 사용할 수 있습니다. reject는 패킷을 거부했다는 응답을 보내므로, 공격자에게 포트가 닫혀있음을 알릴 수 있어 DROP보다 덜 안전할 수 있습니다.

# 예시: 특정 포트에 대한 접근 거부 및 로그 기록 sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" port port=80 protocol=tcp reject' sudo firewall-cmd --reload

FIREWALLD의 주요 개념과 고급 설정 확인하기

firewalld는 ‘zone(영역)’, ‘service(서비스)’, ‘port(포트)’, ‘rich-rule(고급 규칙)’ 등 다양한 개념을 사용하여 방화벽을 관리합니다. 이들 개념을 이해하는 것은 firewalld를 효율적으로 운영하는 데 필수적입니다.

  1. Zone (영역): 네트워크 인터페이스를 역할에 따라 분류하는 개념입니다. ‘public’, ‘home’, ‘internal’, ‘trusted’ 등 사전 정의된 영역이 있으며, 각 영역마다 다른 보안 수준을 적용할 수 있습니다. 예를 들어, ‘trusted’ 영역은 모든 트래픽을 허용합니다.
  2. Service (서비스): 특정 포트와 프로토콜의 조합을 미리 정의한 것입니다. ‘ssh’, ‘http’, ‘https’ 등이 있으며, 포트 번호를 직접 입력하지 않고도 방화벽을 설정할 수 있게 해줍니다.
  3. Rich Rule (고급 규칙): Zone, Service, Port 규칙보다 더 세밀한 조건(소스/목적지 IP, 로깅, 액션 등)을 설정할 때 사용됩니다. 이 포스팅에서 차단 로그를 설정할 때 사용한 것이 바로 Rich Rule입니다.

Rich Rule을 이용한 로깅 및 제한 (Limit)

앞서 사용된 limit value="10/m" 옵션은 분당 최대 10개의 로그만 기록하도록 제한하는 설정입니다. DoS 공격 등으로 인해 로그 파일이 급격히 커지는 것을 방지하기 위해 로깅에 제한을 두는 것은 매우 중요하며, 보안 로그 관리의 필수 요소입니다.

로그를 분석하여 공격 패턴을 파악하고, 이를 기반으로 fail2ban과 같은 자동화된 차단 도구를 연동하면 서버 보안을 더욱 강화할 수 있습니다. firewalld의 로그는 이러한 자동화 시스템의 주요 입력 소스가 됩니다.

FIREWALLD와 IPTABLES의 차이점 보기

리눅스 방화벽의 근간은 커널의 netfilter 모듈이며, iptablesfirewalld는 이 netfilter를 제어하는 사용자 공간의 도구입니다. 이 둘의 주요 차이점은 관리 방식에 있습니다.

구분 FIREWALLD IPTABLES
관리 방식 동적 관리 (Dynamic), Zone 기반 정적 관리 (Static), 체인 기반
규칙 적용 서비스 중단 없이 규칙 즉시 적용 가능 규칙 변경 시 전체 규칙을 플러시하고 재적용 필요 (서비스 중단 위험)
사용 편의성 Zone 개념으로 이해하기 쉬움, 서비스 이름을 사용 로우 레벨의 상세 제어, 복잡한 체인 구조
로그 Rich Rule을 통해 커널 로그에 기록 LOG 타겟을 사용, 커널 로그에 기록

firewalld는 동적으로 규칙을 추가, 수정, 삭제할 수 있어, 서버를 재시작하거나 네트워크 서비스를 중단할 필요 없이 방화벽 정책을 변경할 수 있다는 큰 장점이 있습니다. 이는 2025년 현재의 무중단 서비스 환경에 더욱 적합한 방식이라 할 수 있습니다. 따라서 firewalld를 통한 동적 관리는 최신 서버 관리 트렌드입니다.

FAQ 자주 묻는 질문

H3. Q1. firewalld 차단 로그를 설정했는데 로그 파일이 너무 빨리 커집니다. 어떻게 해야 하나요

A. 차단 로그를 설정할 때 limit value 옵션을 사용하여 기록 빈도를 제한할 수 있습니다. 예를 들어 limit value="10/m"은 분당 최대 10개의 로그만 기록하도록 제한합니다. 이는 DoS 공격 등으로 인한 로그 폭증을 방지하는 데 필수적입니다. 이미 설정된 규칙에 제한이 없다면, 해당 규칙을 삭제하고 제한을 포함한 새 규칙으로 교체해야 합니다.

H3. Q2. firewalld에서 특정 IP 주소의 접근을 영구적으로 차단하려면 어떻게 해야 하나요

A. --permanent 옵션을 사용하여 ‘rich rule’에 DROP 액션을 포함한 규칙을 추가하고, 방화벽을 재로딩(sudo firewall-cmd --reload)하면 됩니다. 예를 들어, 1.2.3.4 IP를 차단하려면 다음과 같이 명령합니다: sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="1.2.3.4" drop'.

H3. Q3. firewalld 로그는 어떤 정보가 포함되나요

A. firewalld의 로깅 규칙으로 기록되는 로그는 커널 로그 포맷을 따릅니다. 이 로그에는 일반적으로 ‘FIREWALLD_DROP:’과 같은 프리픽스, 그리고 차단된 트래픽의 소스/목적지 IP 주소, 소스/목적지 포트, 프로토콜(TCP/UDP 등), 네트워크 인터페이스 등의 상세 정보가 포함됩니다. 이 정보는 공격의 출처와 목표를 분석하는 데 사용됩니다.

H3. Q4. iptables를 사용하다 firewalld로 마이그레이션할 때 주의할 점은 무엇인가요

A. firewalld는 Zone 기반의 접근 방식을 사용하므로, iptables의 체인(Chain) 기반 규칙을 Zone 및 Rich Rule 기반으로 재구성해야 합니다. 특히 iptables의 기존 규칙이 firewalld의 기본 정책과 충돌하지 않도록 확인해야 하며, iptables 서비스를 완전히 비활성화하고 firewalld만 활성화해야 합니다.