리눅스 방화벽 iptables 완전 분석: 넷필터 기반 패킷 제어의 원리와 실무적 함의

서버를 인터넷에 연결하는 순간부터 그 시스템은 무수한 접속 시도와 스캐닝, 그리고 잠재적 공격에 노출된다. 이때 어떤 연결을 받아들이고 어떤 것을 걸러낼지 결정하는 첫 번째 관문이 바로 방화벽이며, 리눅스 환경에서 가장 오랫동안 표준으로 쓰여 온 도구가 iptables이다. 이 글은 iptables가 어떤 구조 위에서 동작하는지, 테이블과 체인과 규칙이라는 계층이 실제로 무엇을 의미하는지, 그리고 실무에서 정책을 설계할 때 반드시 짚어야 할 기본 원리와 함정까지 체계적으로 정리한다.

 

 

 

 

 

 

 

 

▍ iptables의 정체: 넷필터 프레임워크의 사용자 인터페이스

 

iptables는 흔히 방화벽 그 자체로 불리지만, 엄밀히 말하면 리눅스 커널 내부에 내장된 넷필터(netfilter) 프레임워크를 제어하는 명령행 도구에 해당한다. 실제로 패킷을 검사하고 처리하는 실행 주체는 커널 공간의 넷필터이며, iptables는 관리자가 원하는 규칙을 이 프레임워크에 등록하고 조회하는 인터페이스로 볼 수 있다. 이러한 분리 구조는 성능과 안정성 측면에서 중요한 의미를 가진다. 규칙 판단이 커널 수준에서 이루어지기 때문에 사용자 프로그램을 거치지 않고도 매우 빠르게 패킷의 통과 여부를 결정할 수 있다.

 

넷필터는 패킷이 시스템의 네트워크 스택을 통과하는 여러 지점에 훅(hook)을 걸어 두고, 그 지점을 지나는 트래픽에 대해 등록된 규칙을 대조한다. iptables가 다루는 대상이 IPv4라는 점도 짚어 둘 필요가 있다. IPv6 트래픽을 제어하려면 ip6tables라는 별도의 도구를 사용하며, 두 도구는 구조가 거의 동일하지만 관리 대상 주소 체계가 다르다.

 

 

 

▍ 세 겹의 계층: 테이블, 체인, 규칙

 

iptables의 동작을 이해하는 핵심은 세 개의 계층 구조를 파악하는 데 있다. 가장 바깥은 특정 기능을 묶어 놓은 테이블이고, 그 안에 패킷 처리의 시점을 나타내는 체인이 존재하며, 각 체인에는 실제 판단 조건과 처리 방식을 정의한 규칙이 순서대로 담긴다. 관리자는 규칙을 자유롭게 추가하고 삭제할 수 있지만, 기본 테이블과 내장 체인 자체는 커널이 미리 정의해 둔 것이어서 임의로 없앨 수 없다.

 

 

 

▍ 테이블의 종류와 역할 구분

 

테이블은 방화벽이 제공하는 기능의 대분류에 해당한다. 각 테이블은 서로 다른 목적을 가지며, 어떤 작업을 하느냐에 따라 사용해야 할 테이블이 달라진다. 아래 표는 주요 테이블의 역할을 정리한 것이다.

 

 

 

 

테이블을 명시하지 않고 iptables 명령을 실행하면 filter 테이블이 기본값으로 적용된다. 일상적인 접근 통제 작업의 대부분은 이 filter 테이블 위에서 이루어지며, 주소 변환이 필요할 때만 nat 테이블을 별도로 지정한다.

 

 

 

▍ 체인: 패킷이 검사되는 위치

 

체인은 패킷이 시스템을 통과하는 흐름 속에서 규칙을 대조하는 지점을 뜻한다. filter 테이블에서 자주 다루는 세 가지 내장 체인은 다음과 같이 구분된다. INPUT은 이 시스템 자신을 목적지로 하여 들어오는 패킷을 검사하고, OUTPUT은 이 시스템이 출발지가 되어 밖으로 나가는 패킷을 다루며, FORWARD는 이 시스템을 단지 경유해 다른 곳으로 향하는 패킷을 처리한다. 라우터나 게이트웨이로 동작하는 서버라면 FORWARD 체인이 특히 중요해진다.

 

주소 변환을 담당하는 nat 테이블에서는 PREROUTING과 POSTROUTING이라는 별도의 체인이 등장한다. PREROUTING은 라우팅 결정이 내려지기 전에 목적지 주소를 바꿀 때, POSTROUTING은 라우팅 이후 출발지 주소를 바꿀 때 사용된다. 관리자는 필요에 따라 사용자 정의 체인을 만들어 관련 규칙을 그룹화할 수도 있으며, 이 경우 내장 체인에서 사용자 정의 체인으로 판단을 넘겨 관리의 복잡도를 낮출 수 있다.

 

 

 

 

 

 

▍ 규칙을 구성하는 명령 구조

 

iptables의 규칙은 일정한 문법을 따른다. 명령의 뼈대는 어떤 테이블에서, 어떤 동작을, 어떤 체인에, 어떤 조건으로, 어떻게 처리할지를 차례로 지정하는 방식이다. 실무에서 가장 빈번하게 쓰이는 동작 옵션은 규칙을 다루는 방법을 결정하며, 그 성격을 이해하면 정책 수정이 훨씬 명료해진다.

 

-A: 체인의 맨 끝에 규칙을 덧붙인다. 기존 규칙 뒤에 순차적으로 쌓인다.

 

-I: 지정한 위치에 규칙을 삽입한다. 위치를 생략하면 맨 앞에 들어간다.

 

-D: 규칙을 삭제한다. 규칙 내용을 그대로 적거나 번호로 지울 수 있다.

 

-L: 현재 등록된 규칙 목록을 출력한다.

 

-F: 해당 체인의 모든 규칙을 한꺼번에 초기화한다.

 

-P: 체인의 기본 정책을 설정한다.

 

규칙이 실제로 어떤 패킷을 대상으로 하는지는 매칭 조건으로 정의된다. 프로토콜을 지정하는 -p, 출발지 주소를 뜻하는 -s, 목적지 주소를 뜻하는 -d가 대표적이다. 포트 단위로 세밀하게 제어할 때는 --sport와 --dport를 함께 쓰며, 이때 반드시 프로토콜 옵션을 병기해야 한다. 어떤 인터페이스로 들어오고 나가는지를 구분하려면 -i와 -o를 활용한다.

 

 

 

▍ 타깃: 조건에 부합한 패킷의 운명

 

조건을 만족한 패킷을 어떻게 처리할지는 -j 뒤에 오는 타깃이 결정한다. 여기서 ACCEPT와 DROP, REJECT의 차이를 정확히 아는 것이 중요하다. ACCEPT는 패킷을 그대로 통과시킨다. DROP은 패킷을 조용히 버리며 상대에게 아무런 응답도 보내지 않는다. 반면 REJECT는 패킷을 버리되 거부되었다는 사실을 상대에게 명시적으로 알린다. 이 미묘한 차이는 보안 설계에서 실제로 의미를 가진다. DROP은 시스템의 존재 자체를 감추는 효과가 있어 스캐닝에 대한 정보 노출을 줄이지만, 상대측이 응답을 기다리며 시간을 소모하게 만드는 특성도 있다.

 

 

 

 

 

 

▍ 규칙의 적용 순서와 흔한 설계 오류

 

iptables 정책을 다룰 때 반드시 내면화해야 할 원칙은 규칙이 위에서 아래로 순차 대조된다는 점이다. 패킷이 어떤 규칙에 먼저 일치하면 그 규칙의 타깃이 즉시 실행되고, 이후 규칙은 검사되지 않는다. 어떤 규칙에도 걸리지 않은 패킷은 마지막으로 체인의 기본 정책을 따른다.

 

이 순서 개념을 간과하면 정책이 의도와 정반대로 작동하는 결과가 발생한다. 예를 들어 모든 패킷을 차단하는 규칙을 맨 위에 두고 그 아래에 특정 서비스를 허용하는 규칙을 배치하면, 트래픽이 첫 규칙에서 이미 차단되어 아래의 허용 규칙은 결코 도달하지 못한다. 그래서 실무에서는 좁고 구체적인 허용 규칙을 먼저 배치하고, 포괄적인 차단은 뒤쪽이나 기본 정책으로 처리하는 순서를 지킨다. -A로 규칙을 계속 덧붙이면 순서가 꼬이기 쉬우므로, 우선순위가 높은 규칙은 -I로 앞쪽에 삽입하는 방식이 자주 쓰인다.

 

 

 

▍ 기본 정책 전환 시의 주의점

 

보안을 강화하는 전형적인 접근은 화이트리스트 방식으로, INPUT 체인의 기본 정책을 DROP으로 바꾼 뒤 필요한 연결만 하나씩 허용하는 것이다. 다만 이 과정에는 실제로 자주 겪는 위험이 하나 있다. 원격 접속 중인 상태에서 아무런 허용 규칙 없이 기본 정책을 DROP으로 전환하면, 관리자 자신의 SSH 연결까지 끊어져 서버에 접근할 수 없게 되는 상황이 발생한다. 따라서 정책을 잠그기 전에 반드시 루프백 인터페이스와 기존 세션, 그리고 관리용 포트에 대한 허용 규칙을 먼저 확보해 두어야 한다.

 

 

 

▍ 상태 추적 기반의 지능적 필터링

 

단순히 출발지 주소나 포트만 보고 판단하는 방식에는 한계가 있다. 정상적인 통신은 대부분 양방향으로 오가는데, 나가는 요청에 대한 응답까지 일일이 규칙으로 허용하려면 정책이 지나치게 복잡해진다. 이를 해결하는 것이 연결 추적(connection tracking) 기능이다. conntrack 모듈은 시스템을 통과하는 연결의 상태를 기억하여, 새로 시작하는 연결인지 이미 확립된 연결의 일부인지 구분한다.

 

상태는 크게 몇 가지로 나뉜다. NEW는 새롭게 시작되는 연결의 첫 패킷을, ESTABLISHED는 이미 양방향 통신이 확인된 연결을, RELATED는 기존 연결과 연관되어 파생된 연결을 의미한다. 실무에서는 ESTABLISHED와 RELATED 상태를 우선 허용해 두는 규칙을 앞쪽에 배치한다. 이렇게 하면 이미 정상적으로 성립된 연결은 복잡한 재검사 없이 곧바로 통과하므로 성능이 개선되고, 관리자는 오직 새로 들어오는 연결에 대해서만 허용 여부를 고민하면 된다.

 

 

 

 

 

 

▍ 실무적 함의와 세심한 고려사항

 

iptables로 구성한 규칙은 기본적으로 메모리 위에서만 유지되는 임시 상태라는 점을 반드시 인지해야 한다. 시스템을 재부팅하면 저장하지 않은 규칙은 사라지므로, 배포판이 제공하는 저장 방식이나 서비스 설정을 통해 규칙을 영속화하는 절차가 별도로 필요하다. 이 단계를 빠뜨리면 재시작 이후 방화벽이 무방비 상태가 되거나, 반대로 잘못 저장된 정책 때문에 접속이 막히는 문제가 생길 수 있다.

 

또한 리눅스 배포판마다 방화벽을 관리하는 상위 도구가 다르다는 점도 함께 고려할 필요가 있다. 여러 배포판에서 firewalld나 ufw 같은 관리 계층을 기본으로 제공하는데, 이들은 결국 내부적으로 넷필터를 조작한다는 공통점을 가진다. 다만 이러한 상위 도구와 iptables 명령을 뒤섞어 사용하면 규칙이 충돌하거나 예기치 못한 순서로 정렬될 수 있으므로, 하나의 관리 방식을 일관되게 유지하는 편이 안전하다.

 

기술 흐름의 관점에서 보면, iptables의 후속으로 nftables가 등장하여 상당수 최신 배포판이 이를 기본 백엔드로 채택하는 방향으로 이동해 왔다. nftables는 여러 프로토콜을 하나의 체계로 통합하고 규칙 표현을 간결하게 다듬은 것으로 알려져 있다. 다만 이러한 전환의 정확한 채택 시점과 범위는 배포판과 버전에 따라 다르므로 단정하기 어렵다. 실제 현장에서는 여전히 iptables 문법을 호환 계층으로 지원하는 경우가 많아, iptables의 개념적 이해는 상당 기간 유효한 자산으로 남을 것으로 볼 수 있다.

 

 

 

▍ 결론: 원리를 아는 방화벽 설계가 안전을 만든다

 

지금까지 살펴본 것처럼 iptables는 단순한 차단 도구가 아니라, 넷필터라는 커널 프레임워크 위에서 테이블과 체인, 규칙이라는 계층을 통해 패킷의 흐름을 정교하게 통제하는 체계이다. 어떤 트래픽을 허용하고 어떤 것을 삭제할지는 주소와 포트, 그리고 연결 상태라는 조건을 어떻게 조합하느냐에 달려 있으며, 규칙의 순서와 기본 정책을 정확히 이해하는 것이 안정적인 방화벽의 출발점이 된다.

 

방화벽 정책을 처음 설계한다면, 원격 접속 경로를 먼저 확보한 상태에서 최소 권한 원칙에 따라 필요한 연결만 열어 두는 방식으로 접근하는 것이 바람직하다. 각 규칙이 어떤 시점에, 어떤 패킷에, 어떤 순서로 적용되는지를 스스로 설명할 수 있을 때 비로소 그 방화벽은 신뢰할 만한 보호막이 된다.