firewalld
파이어월디
는 방화벽 정책을 ·· 같은 관리 단위로 구성하는 데몬이다. 커널의 패킷 처리 기능을 대신하는 별도 네트워크가 아니라, 실제 백엔드 규칙을 관리하며 실행 중 설정과 영구 설정을 구분한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 인터페이스나 소스 주소를 신뢰 범주인 에 연결한다.
- 여러 포트·프로토콜을 정의로 묶어 관리한다.
- 변경과 저장을 분리해 방화벽 정책을 반영한다.
02어떤 순서로 동작하나
- 정책 입력
관리자가 ··와 연결할 인터페이스 또는 소스를 지정한다.
- 적용 범위 선택
명령이 을 바꾸는지 저장을 바꾸는지 구별하여 설정을 관리한다.
- 백엔드 규칙 반영
활성 정책이 커널 방화벽 규칙으로 표현되고 수신·전달 경로에서 사용된다.
- 패킷과 상태 관찰
인터페이스의 실제 , 적용 정책과 규칙 적중을 확인한다. reload로 설정을 다시 반영하는 경우 저장 상태와의 차이가 결과에 영향을 준다.
03먼저 알아둘 용어와 구성요소
- 은 인터페이스 또는 출발지와 정책을 연결한다. 같은 ssh 서비스 허용이라도 어떤 에 적용했는지, 실제 인터페이스가 그 에 속하는지에 따라 결과가 달라진다.
- 는 필요한 프로토콜·포트 등을 이름으로 묶어 표현하는 설정 단위이며 애플리케이션 를 시작하는 와는 다르다.
- 정책 객체는 사이의 전달 정책을 표현하는 데 사용할 수 있다.
- 은 현재 적용 중인 규칙 상태이고 는 다음 로드에 사용할 저장 상태다.
- --로 설정을 바꾸어도 즉시 커널 규칙에 반영되지 않으며 reload가 저장 구성을 불러온다. 반대로 변경을 저장하지 않으면 reload나 재부팅 때 없어질 수 있다.
- 출발지 제한 rich rule을 추가해도 같은 전체에 더 넓은 ssh 허용이 남아 있으면 원한 제한이 되지 않으므로 규칙 하나의 문법보다 전체 허용 집합을 보아야 한다.
Disabled 화면에서 알 수 있는 것과 정책 검증에 필요한 것
방화벽 서비스 상태와 상태를 분리하고, 정책의 허용·거부를 검증할 수 있는 실행 조건을 정한다.
실습 구성과 전제
- 두 화면 모두 getenforce가 Disabled를 반환하는 사례다. 이 상태의 서비스 성공으로 정책의 적절성을 입증할 수는 없다.
- 정책 실습을 재구성할 때에는 가 활성화된 별도 을 사용한다. 방화벽이나 를 끄는 절차를 해결책으로 삼지 않는다.
서로 다른 제어 장치의 상태를 나눈다
- systemctl status 는 방화벽 관리 서비스의 상태다. getenforce는 실행 상태를 보고하므로 두 출력은 독립된 제어 경계다.
- 관리 서비스가 inactive라는 사실만으로 커널의 모든 방화벽 규칙이 없다고 단정할 수 없다. 또한 Disabled는 Permissive와 다르다.
bashgetenforce sestatus systemctl status firewalld --no-pager상태 조회만 수행하는 예시이며 보안 기능을 변경하지 않는다.
원본 크기로 보기 ↗- firewalld는 Loaded disabled와 Active inactive (dead)로 표시된다.
- 그 아래 getenforce 결과는 Disabled로 나타나 방화벽 출력과 별도로 SELinux 상태를 알려 준다.
확인 기준상태를 firewall 서비스 상태로 대신 판단하지 않는다. 이 화면에는 접근 거부 기록이 없다.
Disabled와 Permissive의 증거 차이를 설명한다
- Disabled에서는 정책이 접근을 판정하는 상태가 아니다. Permissive에서는 정책을 로드한 채 거부될 요청을 기록하지만 강제 차단하지 않는다.
- 따라서 두 번째 화면의 Disabled는 첫 화면과 같은 상태 분류를 보일 뿐, 특정 파일의 레이블이나 allow 규칙이 올바르다는 결과는 아니다.
원본 크기로 보기 ↗- getenforce 명령 하나와 Disabled 응답이 보인다.
- 정책 타입, 파일 컨텍스트, AVC 기록은 이 화면에 표시되지 않는다.
확인 기준서비스가 열렸다는 결과만 남기지 말고, Enforcing·Permissive·Disabled 중 어떤 조건에서 시험했는지 기록한다.
활성화된 VM에서는 주체·객체·동작을 묶어 검증한다
- 웹 서버 의 도메인, 요청 파일의 타입, 요구한 read·open 같은 동작을 연결한다. 실패 시 AVC의 scontext·tcontext·tclass·denied 항목을 읽는다.
- 재구성 조회 결과에 레이블 차이가 보이면 영구 파일 컨텍스트 매핑과 실제 레이블을 확인한다. 임의 허용 규칙을 추가하기 전에 경로와 배포판 정책의 의도를 대조한다.
bashps -eZ | grep -E "httpd|nginx" ls -Zd /srv/lab-web ausearch -m AVC -ts recent가 활성화된 별도 실습 에서 컨텍스트와 최근 AVC를 읽는 예시다. 감사 로그 조회에는 권한이 필요할 수 있다.
확인 기준Disabled 환경에서 AVC가 없다는 사실은 허용 규칙의 증명이 아니다. Enforcing 환경의 실제 재현 요청과 시간 범위를 맞춰 확인한다.
실습에서 확인한 동작 원리
- 정책을 검증하려면 정책이 적용되는 모드와 실제 요청을 함께 제시해야 한다.
- 방화벽은 네트워크 경로, 는 와 객체 사이의 허용 동작을 다루므로 상태와 증거를 분리한다.
동작·명령 참고 문서
INPUT 규칙의 순서·기본 정책·카운터 읽기
SSH 허용과 FTP 거부 규칙, 기본 ACCEPT 정책, 별도 테이블을 패킷 처리 경로에 연결한다.
실습 구성과 전제
- 화면은 iptables로 조회한 규칙이다. 를 직접 관리하는 환경이나 다른 주소 패밀리의 규칙까지 모두 보여 주는 출력은 아니다.
- 기존 실습 호스트의 규칙을 조회하는 예시이며 원격 접속 중 규칙을 변경하는 작업은 포함하지 않는다.
호스트 자신에게 오는 패킷의 규칙을 읽는다
- INPUT 체인은 결정 후 이 호스트가 수신할 패킷에 적용된다. 첫 규칙은 목적지 포트 22를 ACCEPT하고, 다음 규칙은 목적지 포트 21을 REJECT한다.
- 위에서부터 조건을 비교하므로 앞 규칙의 매치와 판정이 중요하다. 이 화면의 기본 정책은 ACCEPT이며, 일치하지 않는 패킷을 묵시적으로 모두 거부하는 구성이 아니다.
bashsudo iptables -L INPUT -n -v --line-numbers sudo iptables -S INPUT현재 filter/INPUT의 표시 결과와 규칙 문법을 함께 조회한다.
원본 크기로 보기 ↗- 체인 머리의 policy ACCEPT와 두 규칙의 번호가 함께 보인다.
- 22번 포트 ACCEPT의 카운터는 2642 packets, 21번 포트 REJECT의 카운터는 0으로 표시된다.
확인 기준카운터가 0인 규칙은 관찰 구간에 매치된 패킷이 없다는 뜻이다. 대상 서비스가 살아 있는지나 다른 경로의 차단 여부는 알 수 없다.
NAT 테이블의 빈 목록을 별도로 해석한다
- -t 는 filter가 아닌 테이블을 선택한다. 빈 체인은 해당 조회에 표시할 주소 변환 규칙이 없다는 뜻이며 INPUT의 허용·거부 규칙을 지우지 않는다.
- 필터 판정과 연결의 주소 변환은 목적이 다르다. 첫 패킷으로 정한 매핑과 이후 연결 추적의 동작도 단순히 모든 패킷이 모든 규칙을 통과한다고 읽어서는 안 된다.
bashsudo iptables -t nat -L -n -v ss -lnt주소 변환 규칙과 애플리케이션의 리슨 상태를 다른 증거로 조회한다.
원본 크기로 보기 ↗- PREROUTING·INPUT·OUTPUT·POSTROUTING의 체인 머리가 나열된다.
- 각 체인 아래 실제 변환 규칙 행이 없고, 조회 명령은 -t nat를 사용한다.
확인 기준가 비어 있어도 서비스 리슨, INPUT 필터, 문제 때문에 접속이 실패할 수 있다.
한 번의 연결 시험을 카운터 변화와 대응시킨다
- 허용된 실습 클라이언트에서 지정 서비스에 한 번 연결하고 직전·직후 카운터를 비교한다. 22번 규칙 증가가 보이면 그 규칙을 지난 패킷이 있었다는 근거가 된다.
- 연결 성공은 수립과 애플리케이션 응답까지 봐야 한다. REJECT의 응답, 서버가 닫힌 포트에 보내는 RST, 경로 중간의 DROP은 서로 다른 실패 양상이다.
확인 기준시험한 시각·목적지·포트를 기록한다. 트래픽이 많은 환경에서는 카운터 차이 전부를 자신의 한 요청으로 단정하지 않는다.
실습에서 확인한 동작 원리
- 기본 정책은 체인 머리에서 읽고, 개별 규칙은 번호·조건·판정·카운터를 묶어 해석한다.
- 빈 테이블, 필터 허용, 서비스 실행은 각각 다른 계층의 상태다.
동작·명령 참고 문서
04예제로 따라가기
- SSH 를 public 에 허용해도 실제 인터페이스가 다른 에 연결돼 있으면 기대한 허용 경로와 다르다.
- 에만 포트를 열었다면 재시작·재적용 후 영구 설정을 불러오는 시점에 허용이 사라질 수 있다.
- 한 포트 규칙을 지워도 같은 포트를 허용하는 나 다른 정책이 남아 있으면 통신이 계속될 수 있다.
05혼동하기 쉬운 점과 확인 기준
- 현재 카운터와 ruleset은 상태다. 저장한 구성의 내용만으로 지금 적용 상태를 대체하지 않는다.
- 연결 거절은 해당 지점에서 소켓이 없거나 명시적인 거절 응답을 보낸 경우의 단서이며, 둘을 동일한 방화벽 차단으로 묶지 않는다. 먼저 ss로 실제 리스닝 주소와 프로토콜을 확인한다.
- 허용은 프로그램의 실행을 뜻하지 않고 포트·프로토콜 같은 정책 묶음을 뜻한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.