[리눅스 방화벽] iptables에서 firewalld로 전환 1년 후기

목차

• 왜 iptables에서 firewalld로 옮겼는가
• iptables와 firewalld 개념 비교
• 방화벽 마이그레이션 전에 먼저 점검한 것들
• 실전 구현: iptables에서 firewalld로 옮긴 방식
• 1. firewalld 상태 확인 및 시작
• 2. 기본 존과 허용 서비스 점검
• 3. 내부망 인터페이스를 별도 존으로 분리
• 4. 더 세밀한 예외는 rich rule로 처리
• 5. 검증 전까지 기존 정책을 바로 폐기하지 않기
• ⚠️ 실제로 겪었던 문제와 해결 과정
• 문제 1. runtime만 바꾸고 permanent를 빼먹음
• 문제 2. 인터페이스가 예상과 다른 zone에 붙음
• 문제 3. iptables 시절의 습관 때문에 구조가 더 꼬임
• 문제 4. 서비스 정의와 직접 포트 개방이 섞여 가독성이 떨어짐
• 검증: 전환 후 1년 운영하면서 본 변화
• iptables firewalld 비교: 1년 써보고 정리한 장단점
• 정리: 이런 분들께는 firewalld 전환을 추천합니다
• 자주 묻는 질문
• Q1. 기존 iptables 규칙을 그대로 옮기면 되나요?
• Q2. firewalld가 항상 더 좋은가요?
• Q3. 홈랩에도 쓸 만한가요?

[리눅스 방화벽] iptables에서 firewalld로 전환 1년 후기

운영 서버를 오래 만지신 분들이라면 한 번쯤은 iptables firewalld 비교를 고민해보셨을 겁니다. 저도 그랬습니다. 기존에는 익숙한 iptables 규칙(rule)으로만 버텼는데, 서비스가 늘고 홈랩까지 커지니까 관리 포인트가 점점 복잡해지더라고요. 그래서 1년 전부터 주요 리눅스 방화벽 정책을 firewalld로 옮겨서 운영했고, 오늘은 그 firewalld 후기를 경험 중심으로 정리해보려고 합니다. 처음엔 "이걸 굳이 왜 바꾸지?" 싶었는데, 실제로 써보니까 장점이 분명했고 반대로 불편한 점도 꽤 선명했어요.

특히 이번 글은 단순 기능 소개가 아니라, 방화벽 마이그레이션을 하면서 제가 어디서 삽질했는지, 어떤 서버에는 잘 맞고 어떤 서버에는 굳이 안 옮겨도 되는지까지 현실적으로 적어보겠습니다. 혹시 지금도 배포판 기본 방화벽을 끄고 iptables 스크립트만 직접 관리하고 계시다면, 이 글이 판단 기준이 될 거예요.

iptables에서 firewalld로 바꾸는 전체 흐름을 한눈에 보여주는 개요 이미지입니다.

왜 iptables에서 firewalld로 옮겼는가

제 경우 계기는 아주 단순했습니다. 규칙이 늘어날수록 사람이 실수하기 쉬워졌기 때문이거든요. iptables 자체가 나쁜 도구라는 뜻은 아닙니다. 오히려 굉장히 강력하고, 익숙해지면 빠릅니다. 다만 운영 기간이 길어질수록 이런 문제가 생기더라고요.

• 서버마다 규칙 파일 구조가 조금씩 달랐어요.
• 포트 하나 열 때도 저장 위치와 반영 방식이 서버마다 달랐어요.
• 임시 변경과 영구 변경이 섞여서, 재부팅 후 정책이 달라지는 일이 있었습니다.
• 새로운 팀원이 들어오면 규칙 읽는 데 시간이 꽤 걸렸어요.

반면 firewalld는 zone(존, 신뢰 수준별 정책 구역), service(서비스, 미리 정의된 포트/프로토콜 묶음), runtime/permanent(실행 중 설정/영구 설정) 개념이 있어 운영 언어가 훨씬 사람 친화적이더라고요. 저도 처음엔 이 추상화가 오히려 번거로울 줄 알았는데, 1년 써보니 일상 운영에서는 확실히 읽기 쉽고 설명하기도 편했어요.

iptables와 firewalld 개념 비교

쉽게 말해 iptables는 규칙을 직접 조립하는 방식에 가깝고, firewalld는 운영에 필요한 구조를 얹어서 관리하는 방식이라고 보면 돼요. 물론 내부적으로는 리눅스 패킷 필터링 체계인 Netfilter(넷필터, 커널 네트워크 필터링 프레임워크) 위에서 동작하는 거고요.

항목	iptables	firewalld
관리 방식	규칙 중심	존/서비스 중심
가독성	규칙이 많아지면 급격히 떨어짐	일반 운영자는 읽기 쉬움
즉시 반영	직접 명령 실행 필요	runtime 설정으로 빠르게 반영 가능
영구 반영	배포판별 저장 방식 차이 존재	permanent 개념이 비교적 명확
추상화 수준	낮음	높음
세밀한 제어	매우 강함	rich rule로 가능하지만 사고방식이 다름

여기서 중요한 포인트가 있습니다. firewalld가 iptables를 완전히 대체하는 느낌으로 접근하면 초반에 헷갈려요. 저도 처음엔 규칙 한 줄 한 줄을 그대로 옮기려다가 막혔거든요. 실제 firewalld 마이그레이션은 "현재 규칙을 그대로 복제"보다 "정책을 다시 모델링"하는 쪽이 훨씬 잘 돼요.

방화벽 마이그레이션 전에 먼저 점검한 것들

실제로 써보니까 전환 전에 이 단계가 제일 중요했어요. 여기 대충 넘어가면 나중에 SSH 잠기거나, 내부 서비스만 죽는 식으로 애매한 장애가 나옵니다.

1. 현재 오픈 포트 목록을 정리하세요.
2. 서버 역할을 분류합니다. 웹 서버, DB 서버, 점프 호스트(jump host), 홈랩 내부 노드처럼요.
3. 인터페이스별 신뢰 수준을 구분하세요. 예를 들어 외부망 NIC와 내부망 NIC가 같으면 안 돼요.
4. 기존 iptables 룰 중 예외 규칙을 따로 뽑으세요. 이 부분을 자주 놓칩니다.
5. 콘솔 접근 수단을 확보하세요. 원격 SSH만 믿고 바꾸는 건 위험해요.

저는 아래처럼 최소한의 체크리스트를 만들어 놓고 시작했습니다.

# 현재 리스닝 포트 확인
ss -tulpn

# 현재 iptables 규칙 확인
iptables -L -n -v
iptables -S

# 방화벽 관련 서비스 상태 확인
systemctl status firewalld
systemctl status iptables

# 네트워크 인터페이스 확인
ip addr
ip route

이 단계에서 제가 가장 크게 느낀 건, 오래된 서버일수록 "왜 있는지 아무도 모르는 규칙"이 꼭 있다는 점이에요. 진짜입니다. 저도 몇 개는 지우기 무서워서 한동안 주석만 달아뒀습니다 ㅎㅎ

실전 구현: iptables에서 firewalld로 옮긴 방식

이제 본론입니다. 아래 예시는 배포판 기본 패키지 구성이 있는 환경에서, SSH와 웹 서비스만 우선 허용하는 가장 보수적인 전환 흐름입니다. 실제 포트는 각자 환경에 맞게 바꾸시면 돼요.

1. firewalld 상태 확인 및 시작

sudo systemctl enable --now firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones

여기서 active zone(활성 존)이 예상과 다르면 바로 멈추셔야 해요. 저는 처음에 내부 브리지 인터페이스가 원치 않는 존으로 붙어서 한참 헤맸습니다.

2. 기본 존과 허용 서비스 점검

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-all

# SSH 허용
sudo firewall-cmd --permanent --add-service=ssh

# HTTP/HTTPS 허용
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# 특정 포트 직접 허용 예시
sudo firewall-cmd --permanent --add-port=8443/tcp

firewalld의 장점 중 하나가 바로 이 부분이에요. 서비스 이름으로 여는 규칙은 읽는 사람 입장에서 훨씬 직관적이거든요. 나중에 문서화할 때도 편하고요.

3. 내부망 인터페이스를 별도 존으로 분리

홈랩이나 사내 테스트망처럼 내부 트래픽이 많은 환경에서는 이 구성이 꽤 중요해요. 외부망과 내부망을 같은 존에 넣어버리면 정책이 너무 느슨해지거나, 반대로 필요 이상으로 빡빡해져요.

# 내부용 zone 생성
sudo firewall-cmd --permanent --new-zone=internal-lab

# 내부 인터페이스를 새 zone에 연결
sudo firewall-cmd --permanent --zone=internal-lab --add-interface=eth1

# 내부 zone에 필요한 서비스 허용
sudo firewall-cmd --permanent --zone=internal-lab --add-service=ssh
sudo firewall-cmd --permanent --zone=internal-lab --add-service=samba

# 설정 반영
sudo firewall-cmd --reload

제가 직접 해보니, 이 "존 설계"가 firewalld 운영 만족도를 거의 결정하더라고요. 규칙을 한 줄씩 옮기는 데 집중하지 말고, 어떤 네트워크를 어떤 신뢰 수준으로 볼지 먼저 정해야 해요.

외부망과 내부망을 zone으로 분리하는 실제 운영 구성을 설명하는 이미지입니다.

4. 더 세밀한 예외는 rich rule로 처리

iptables를 오래 쓰신 분들은 아마 이 지점이 제일 궁금하실 거예요. "그럼 복잡한 예외 규칙은 어떻게 하냐"는 거죠. firewalld에는 rich rule(리치 룰, 조건 기반 고급 규칙)이 있어서 이런 상황을 어느 정도 해결할 수 있어요.

# 특정 소스 대역에서만 9100/tcp 허용 예시
sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" port port="9100" protocol="tcp" accept'

sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rules

다만 솔직히 말씀드리면, 여기서부터는 다시 "추상화의 편안함"이 줄어들어요. 복잡한 제어가 많아질수록 iptables 사고방식으로 되돌아가거든요. 그래서 예외가 많은 서버라면 firewalld가 무조건 정답은 아니에요.

5. 검증 전까지 기존 정책을 바로 폐기하지 않기

저는 이 부분에서 예전에 크게 데인 적이 있어요. 한 번에 갈아엎지 마시고, 최소한 아래 순서로 검증하시는 걸 추천드립니다.

1. 콘솔 또는 대체 접속 경로 확보
2. 필수 서비스만 먼저 허용
3. 외부에서 SSH, HTTP, 모니터링 포트 접근 테스트
4. 내부망 서비스 통신 테스트
5. 재부팅 후 정책 유지 여부 확인

⚠️ 실제로 겪었던 문제와 해결 과정

이 섹션은 제 firewalld 후기에서 가장 현실적인 부분일 거예요. 문서만 보면 쉬워 보이는데, 막상 운영에 넣으면 생각보다 사소한 데서 걸려요.

문제 1. runtime만 바꾸고 permanent를 빼먹음

처음엔 이게 뭔가 싶었는데, 진짜 자주 실수해요. 테스트할 때는 잘 되는데 재부팅 후 다시 막히는 경우가 대표적이거든요.

# 현재 runtime 설정 확인
sudo firewall-cmd --list-all

# 영구 설정 확인
sudo firewall-cmd --permanent --list-all

해결은 단순해요. 운영 반영은 permanent 기준으로 넣고, 마지막에 reload로 일관성 있게 맞추는 습관을 들이면 돼요.

문제 2. 인터페이스가 예상과 다른 zone에 붙음

특히 가상화 호스트, 브리지, VLAN 환경에서는 이 문제가 꽤 잘 나와요. 서비스는 살아 있는데 접근 정책이 엉뚱하게 적용되더라고요.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-interfaces
sudo firewall-cmd --zone=internal-lab --list-interfaces

이럴 때는 인터페이스와 존 매핑을 먼저 의심하세요. 저도 포트 규칙만 계속 쳐다보다가 시간 많이 썼어요.

문제 3. iptables 시절의 습관 때문에 구조가 더 꼬임

이건 사람 문제인데 꽤 커요. 예전 방식대로 포트 단위 예외를 계속 덧붙이다 보면, firewalld의 장점이 사라져요. 결국 "왜 옮겼지?" 상태가 돼요. 실제로 저는 웹 서버, 점프 서버, 내부 스토리지 노드를 각각 다른 템플릿처럼 관리하면서 정리가 되기 시작했어요.

문제 4. 서비스 정의와 직접 포트 개방이 섞여 가독성이 떨어짐

가급적이면 잘 알려진 서비스는 service 단위로, 정말 필요한 예외만 포트 또는 rich rule로 두는 편이 좋았어요. 나중에 봐도 해석이 빠르거든요.

runtime/permanent 혼동과 zone 매핑 문제를 점검하는 트러블슈팅 상황을 담은 이미지입니다.

검증: 전환 후 1년 운영하면서 본 변화

제가 1년 정도 운영해보니, 가장 큰 변화는 정책 변경 속도보다 정책 이해 속도였어요. 방화벽은 한 번 만들고 끝이 아니라, 몇 달 뒤에 다시 읽고 수정해야 하잖아요. 그때 firewalld가 확실히 편했어요.

• 새 포트 허용 요청을 처리할 때 설명이 쉬워졌어요.
• 존 기반 구조 덕분에 내부망/외부망 정책을 분리하기 편했어요.
• 운영 문서와 실제 설정의 괴리가 줄었어요.
• 초기 적응만 지나면 반복 작업이 줄어들어요.

반대로 아쉬운 점도 있었어요.

• 아주 세밀한 예외가 많은 서버는 오히려 추상화가 답답할 수 있어요.
• 기존 iptables 문법에 익숙한 사람은 초반 생산성이 떨어질 수 있어요.
• 배포판과 환경에 따라 백엔드 동작 방식이 달라 보일 수 있어서, 내부 구조를 조금은 이해해야 해요.

결론적으로 말하면, 리눅스 방화벽을 팀 단위로 운영하거나, 서버 역할이 비교적 명확한 환경에서는 firewalld가 꽤 좋았어요. 반면 초고도 커스텀 규칙 위주의 장비성 서버라면 기존 방식이 더 맞을 수도 있어요.

# 최종 검증에 자주 쓴 명령들
sudo firewall-cmd --list-all
sudo firewall-cmd --list-services
sudo firewall-cmd --list-ports
sudo firewall-cmd --list-rich-rules
ss -tulpn

재부팅 테스트도 꼭 해보셔야 해요. 저는 검증의 마지막을 항상 "재부팅 후 SSH 접속, 웹 서비스 접속, 내부망 통신 확인"으로 끝냈어요. 귀찮아 보여도 이게 제일 확실하거든요. 드디어 됐다! 싶은 순간이 여기서 오더라고요.

포트 개방, 서비스 접근, 내부망 통신이 정상인지 검증하는 결과 화면을 표현한 이미지입니다.

iptables firewalld 비교: 1년 써보고 정리한 장단점

구분	좋았던 점	아쉬웠던 점
운영 편의성	zone/service 중심이라 설명과 인수인계가 쉬워요	개념을 익히기 전까지는 오히려 낯설 수 있어요
정책 변경	명령이 직관적이고 확인 명령도 잘 갖춰져 있어요	runtime/permanent 이원화는 초반 실수 포인트
가독성	역할별 정책이 잘 보여요	rich rule이 늘어나면 다시 복잡해져요
적합한 환경	일반 서버, 홈랩, 역할 분리된 운영 환경	극단적으로 복잡한 예외 중심 환경은 고민 필요

개인적으로는 방화벽 마이그레이션의 목적이 "더 강력한 방화벽"이 아니라 "더 읽기 쉬운 운영 체계"라면 firewalld가 좋은 선택이었어요. 이거 진짜 편하더라고요. 특히 여러 대를 비슷한 정책으로 운영할 때 더욱 그래요.

정리: 이런 분들께는 firewalld 전환을 추천합니다

• 서버 역할별로 방화벽 정책을 나누고 싶은 분
• 팀 단위로 읽기 쉬운 설정을 원하시는 분
• 홈랩에서 내부망과 외부망을 구분 운영하는 분
• 기존 iptables 스크립트가 너무 길어져 관리가 어려운 분

반대로 아래 경우는 조금 더 신중하게 보시는 게 좋아요.

• 매우 복잡한 조건 규칙을 많이 쓰는 환경
• 이미 안정적인 iptables 자동화 체계가 잘 굴러가는 환경
• 관리자가 모두 기존 방식에 매우 익숙한 소규모 고정 환경

저도 처음엔 헷갈렸는데, 1년 지나고 보니 핵심은 도구 자체보다 정책을 어떻게 구조화할지였어요. firewalld는 그 구조화를 돕는 쪽에 강점이 있었고요. 다음 글에서는 홈랩 기준으로 zone 설계 템플릿과 서비스별 기본 허용 정책을 따로 정리해볼 예정입니다. 이전 글에서 다뤘던 SSH 보안 강화와 함께 보시면 더 흐름이 잘 이어질 거예요.

iptables와 firewalld의 차이, 추천 환경, 운영 포인트를 요약한 비교 이미지입니다.

자주 묻는 질문

Q1. 기존 iptables 규칙을 그대로 옮기면 되나요?

가능한 부분도 있지만, 저는 권장하지 않아요. 서비스와 인터페이스 기준으로 다시 설계하는 편이 훨씬 깔끔했거든요.

Q2. firewalld가 항상 더 좋은가요?

그건 아니에요. 운영 팀의 숙련도와 규칙 복잡도에 따라 다르거든요. 단순히 최신처럼 보여서 바꾸기보다는, 읽기 쉬움과 유지보수성을 기준으로 보시는 게 좋아요.

Q3. 홈랩에도 쓸 만한가요?

충분히 쓸 만해요. 특히 내부망, 실험망, 외부 노출 구간을 분리해서 운영하신다면 zone 개념이 꽤 유용하거든요.

📚 함께 읽으면 좋은 글

• YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션
• iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드
• 컨테이너 없이 리눅스 네임스페이스로 프로세스 격리하기: 실제 사례 연구