[번역] Iptables 및 Netfilter 구조에 대한 심층분석

해당 글은 원본 글; A Deep Dive into Iptables and Netfilter Architecture 을 번역하였습니다. top-down 방식으로 작성된 글 이므로, 아래로 내려갈 수록 자세한 설명을 확인 할 수 있습니다.

 

 

개요

방화벽(firewall)은 서버와 인프라 환경에서 프로젝트를 안전하게 관리하기 위해 중요한 요소이다. 리눅스 에코시스템에서 iptables 은 패킷 필터링 프레임워크인 netfilter 와 함께 방화벽 구성에 널리 쓰이는 도구이다. 하지만 이러한 구체적인 관리 도구들은 깊은 이해가 없는 사용자 혹은 관리자로 하여금 다루기 어려울 수 있다.

해당 문서에서는, 방화벽 정책을 구축해야 하는 니즈가 있는 사용자로 하여금 보다 iptables 에 대해서 심층적으로 이해할 수 있도록 한다. 그러기 위해 iptables 와 netfilter 가 협력하는 방식에 대해서 논의할 것이며, 어떻게 구성요소들이 연결되는지에 대해서 논의할 것이다.

Iptables 와 Netfilter 란 무엇인가?

우선 iptables 란 리눅스에서 주로 쓰이는 방화벽 툴로, 리눅스 커널의 네트워킹 스택에서 패킷 필터링 훅과 연계되어 동작한다. 이 패킷 필터링 훅이 netfilter 이다.

네트워크에 들어오는 모든 패킷들은 이러한 패킷 필터링 훅을 트리거하여 목적지까지 연결되어 동작할 수 있도록 한다. (자세한 방법은 아래에서 설명) iptables 와 관련된 커널 모듈은 들어온 패킷 트래픽이 규정된 방화벽 조건을 준수하는지 확인하기 위해 이러한 훅들을 등록한다.

Netfilter 훅

기본적으로 다섯개의 netfilter 훅이 존재한다. 그리고, 패킷이 스택을 통해 들어오면서 이러한 훅들에 등록된 커널 모듈들이 트리거 된다. 패킷이 트리거 하는 훅들은 해당 패킷이 어디서 왔는지 혹은 어디로 가는지, 목적지는 어디인지, 드롭 되어는 지 등에 따라 다르다.

다음은 네트워킹 스택에 정의된 다섯가지 훅들이다.

• NE_IP_PRE_ROUTING: 네트워킹 스택에 트래픽이 들어오면 해당 훅이 트리거 된다. 해당 훅은 트래픽이 어디로 갈지 정해지지 않은 상태에서 처리된다.
• NF_IP_LOCAL_IN: 들어오는 패킷이 로컬 시스템으로 목적지가 결정된 경우에 해당 훅을 트리거 한다.
• NF_IP_FORWARD: 들어오는 패킷이 다른 호스트 시스템으로 목적지가 결정된 경우에 해당 훅을 트리거 한다.
• NF_IP_LOCAL_OUT: 로컬에서 생성된 트래픽이 밖으로 나가는 경우에 네트워킹 스택에 들어오는 즉시 해당 훅을 트리거 한다.
• NF_IP_POST_ROUTING: 패킷이 유선으로 전송되기 직전에 포워드 쪽 혹은 로컬 아웃 쪽에서 들어온 패킷에 의해 트리거 한다.

위에 정의된 훅들에 커널 모듈을 등록하고자 할 경우에, 반드시 우선순위 번호를 지정해서 어떤 순서로 호출이 될 것인지를 정의해야 한다. 그래야 여러 모듈들이 훅에 등록되어 있을 때 결정된 순서로 연결되어 동작하는 것을 보장한다. 각 모듈은 차례대로 호출되어 패킷이 수행해야 하는 작업을 표시해 주어 netfilter 에 결과를 반환합니다.

Iptables 테이블과 체인

iptables 는 방화벽을 관리하기 위해 방화벽 룰을 테이블을 이용하여 관리한다. 이 테이블은 결정을 내리는데 사용되는 유형에 따라 분류된다. 예를 들어 네트워크 주소 변환에 관한 룰 이라면, nat 테이블에 저장될 것이다. 혹은, 룰이 특정 패킷을 목적지로 허락하기 위한 룰이라면, filter 테이블에 저장될 것이다.

iptables 에서의 테이블은 별도의 체인을 통해 연결되어 있다. 테이블이 각각의 일반적인 목적을 가진 룰들에 의해 정의되지만, 빌트-인 체인은 그들을 트리거 시키는 netfilter 훅들로 표현된다.

아래와 같이, 빌트-인 체인들은 netfilter 에서 확인했던 훅 들의 이름들과 연관되어 있다.

• PREROUTING: NF_IP_PRE_ROUTING 훅에 의해 트리거 된다.
• INPUT: NF_IP_LOCAL_IN 훅에 의해 트리거 된다.
• FORWARD: NF_IP_FORWARD 훅에 의해 트리거 된다.
• OUTPUT: NF_IP_LOCAL_OUT 훅에 의해 트리거 된다.
• POSTROUTING: NF_IP_POST_ROUTING 훅에 의해 트리거 된다.

netfilter hooks(ref: https://saysecurity.tistory.com/15)

체인은 패킷이 전달되는 경로에 대해서 사용자로 하여금 조절할 수 있도록 한다. 각 테이블은 여러 체인을 가질 수 있기 때문에, 여러 포인트로 영향을 줄 수 있다. 또한, 특정 타입에 대한 규칙은 특정 포인트에만 영향이 있기 때문에, 모든 테이블은 커널 훅에 대한 체인을 가지고 있지 않다.

netfilter 커널 훅이 다섯 개 밖에 없기 때문에, 각 테이블에 존재 하는 체인들은 각 훅에 등록된다. 예를 들어, PREROUTING 체인은 세개의 테이블에서 존재하고 해당 체인들은 연관된 NF_IP_PRE_ROUTING 훅에 등록되어 있을 때, 우선순위를 정해 어떤 테이블의 PREROUTING 먼저 시작될 것인지 정할 수 있다. 우선순위가 높은 체인 안에 있는 룰들이 모두 적용 되고 나서 다음 체인으로 넘어간다. 아래 에서 각 체인에 대한 구체적인 순서에 대해서 알아본다.

어떤 테이블이 가능한 상태인가?

다시 이전의 내용으로 돌아가서 iptables가 제공하는 각 테이블들에 대해서 알아본다. 이 테이블들은 패킷을 검사하기 위한 각각의 규칙(룰) 들에 대한 집합을 나타낸다.

• Filter 테이블: Filter 테이블은 iptables 에서 제일 많이 쓰이는 테이블 유형 중에 하나이다. Filter 테이블은 패킷이 목적지로 진행하게 할 것인지, 거절할것인지 에 대해서 결정하는데 쓰인다. 방화벽에서 쓰이는 용어로 “Filtering” 이라고 한다. 이 테이블은 방화벽에서 쓰이는 대부분의 기능들을 내포하고 있다.
• NAT 테이블: NAT 테이블은 말 그대로 네트워크의 주소를 변환하기 위한 목적으로 쓰인다. 패킷이 네트워크 스택으로 들어가면, 패킷의 출발지 혹은 목적지의 주소를 어떻게 바꿔야 할지 등을 명시한다. 이 테이블은 네트워크로 직접적인 연결이 불가능 할 때 쓰인다. (예를 들어, 패킷의 출발지가 사설 ip 이기 때문에 공공 ip 로 변환 후 전송 되는 경우)
• Mangle 테이블: Mangle 테이블은 패킷의 ip 헤더를 다양한 방식으로 수정하는 경우에 쓰인다. 예를 들어, 패킷의 TTL을 설정하여 패킷이 감당 가능한 네트워크 홉스의 갯수를 수정하는 경우들이 있다. 또한, 이 테이블은 다른 테이블 과 다른 네트워킹 툴들에 의해 추가 처리 될 수 있도록 내부 커널 마크 를 할 수 있다. 해당 마크는 실제 패킷에 영향을 주지 않지만, 패킷에 커널 표시 를 하는 정도로 표시된다.
• Raw 테이블: iptables 방화벽은 상태를 저장하는 stateful 한 툴로, 각 패킷들은 이전의 패킷과 연관되어 평가된다. 해당 연결 트래킹 기능은 netfilter 위에 존재하여 iptables 로 하여금 해당 패킷이 연결 되어 있거나 분리된 스트림 중에 하나거나, 관련 없는 패킷이거나 하는 정보를 확인 할 수 있다. 연결 트래킹 기능은 주로 패킷이 네트워크 인터페이스를 왔을 때 바로적용된다. raw 테이블 자체는 굉장히 목적이 단순하다. 해당 테이블은 단순히 연결 트래킹에 대한 정보를 마킹 하기 위하여 사용된다.
• Security 테이블: security 테이블은 SELinux 의 보안 을 설정하기 위하여 사용된다. 해당 마크는 각 패킷 혹은 각 연결 마다 적용된다.

각 테이블에 어떤 체인이 구현되는가?

지금까지 테이블과 각각의 체인들에 대해서 설명했다. 이제 각 테이블 에서 어떤 체인들이 가능한지 알아본다. 우선 같은 훅에 존재하는 체인들이 어떤 순서로 평가 되는지 에대서 얘기해보자. 예를 들어 세 개의 테이블이 모두 PREROUTING 체인을 가지고 있을 때, 어떤 순서로 평가될까?

아래 표는 각 iptables 의 테이블 들에서 가능한 체인 들에 대한 목록을 나타낸다. 예를 들어, raw 테이블에서는 PREROUTING 과 OUTPUT 체인을 모두 가지고 있는 것을 볼 수 있다. 또한, 위에서 아래로 표를 읽을 때는 체인에 연결된 netfilter 훅이 트리거 될 때 호출되는 순서를 볼 수 있다.

주의해야 할 점은, 아래 표시에서 순서를 명확하게 표시 하기 위해 NAT 테이블이 DNAT(destination) 과 SNAT(source) 으로 분리되었다는 점이다. 또한, 라우팅 결정이 내려지는 곳과 연결 트래킹이 설정되는 곳을 표시하였다.

패킷이 netfilter 훅을 트리거하면, 연관된 체인들이 해당 표의 위-아래 순서로 실행 될 것이다. 패킷이 트리거 한 훅 들은 해당 패킷이 들어오는 패킷인지 나가는 패킷인지에 따라 결정되고, 필터링을 통과했는지 등에 따라 달라진다.

어떤 이벤트는 테이블 체인을 스킵할 수 있다. 예를 들어, 보통 한 연결의 첫번째 패킷만 NAT 룰에 의해 평가 됩니다. 첫번째 패킷이 NAT 룰에 의해 적용되면 그 이후에 딸려오는 패킷들은 별 다른 평가 없이 바로 적용됩니다. 그렇기 때문에 첫번째 패킷 이후의 패킷 들은 NAT 체인을 스킵할 수 있습니다. 또한 NAT 에 의해 변경된 패킷에 대한 응답은 자연스럽게 다시 역변환 되어 들어옵니다.

체인 순회 순서(Chain Traversal Order)

만약 서버가 패킷이 어떤 경로로 가야하는지 알고, 해당 패킷이 방화벽 규칙을 통과했다고 가정할 때, 다음과 같은 순서로 체인이 돌아간다.

• 로컬 시스템으로 목적을 두는 패킷: PREROUTING -> INPUT
• 다른 시스템(호스트)로 목적을 두는 패킷: PREROUTING -> FORWARD -> POSTROUTING
• 로컬 시스템에서 생성된 패킷: OUTPUT -> POSTROUTING

위의 정보와 이전에 본 테이블의 정보를 합쳐보면, 로컬 시스템으로 목적을 두는 패킷은 첫번째로 raw, mangle, nat 테이블의 PREROUTING 체인을 먼저 간다는 것을 알 수 있다. 그리고 mangle, filter, security, nat 테이블의 INPUT 체인을 들어가 최종적으로 로컬 소켓으로 전송된다.

Iptables 규칙

규칙들은 특정 테이블의 특정 체인들에 의해 정의된다. 각 체인이 호출되면, 각 체인에 존재하는 규칙들이 순서에 맞게 하나씩 평가된다. 각각의 규칙들 즉 룰 들은 매칭되는 컴포넌트 혹은 액션 컴포넌트를 가지고 있다.

매칭(Matching)

규칙의 매칭 부분은 패킷들이 연관된 액션 들을 수행하기 위해 조건들을 만족하는 기준을 정한다.

매칭 시스템은 확장성 있고 유연한 시스템이다. 규칙들은 프로토콜 타입, 목적지, 출발지 소스 포트, 네트워크 등등에 일치하도록 구성될 수 있다. 이런 것들은 보다 복잡한 규칙 셋들을 만들어 다른 트래픽과 구별 할 수 있다.

타겟 (Targets)

타겟은 패킷이 규칙의 매칭 기준을 만족하였을 때 실행하는 액션이다. 타겟은 크게 두가지 범주로 나뉜다.

• 종료하는 타겟 (Terminating targets): 종료하는 타겟은 체인에 있는 평가를 종료 하고 netfilter 훅에 제어를 반환하는 기능을 수행한다. 반환되는 값에 따라, 훅이 패킷을 허락할 지 거절할지 다음 순서로 보낼지 결정한다.
• 종료하지 않는 타겟 (Non-Terminating targets): 종료하지 않는 타겟은 체인에서의 평가를 이어간다. 각 체인은 결과적으로 최종 결정을 전달해야 하지만, 종료하지 않는 타겟들은 미리 실행을 할 수 있다. (?)

규칙에 대한 각 타겟의 가용성은 컨텍스트에 따라 달라진다. 예를 들어, 테이블과 체인 유형은 타겟들을 가능하도록 할 수 있다. 규칙안에서 활성화된 확장 과 매칭 들은 또한 타겟의 가용성에 영향을 줄 수 있다.

사용자-정의 체인으로 이동(Jumping to User-Defined Chains)

위에서 종료하지 않는 타겟에 대해서 언급했는데, 이는 점프 타겟이라고 한다. 점프 타겟은 다른 체인에 대한 결과에 따른 액션 이라고 볼 수 있다. 위에서 netfilter 에서 사용하는 빌트-인 체인들에 대해서 얘기 했다. 하지만, iptables 또한 사용자 임의 목적으로 그들의 체인을 정의할 수 있다.

규칙 또한 사용자-정의 체인과 동일한 방식으로 정의될 수 있다. 다만 차이점은 사용자-정의 체인들은 규칙 에서 점핑을 통해 이동할 수 있다는 것이다.

사용자-정의 체인들은 체인의 확장 버전 처럼 동작한다. 예를 들어, 사용자-정의 체인에서 규칙 목록의 끝에 도착하거나 매칭 규칙에 의해 타겟이 반환된다면, 호출한 체인으로 다시 돌아간다.

Iptables 와 연결 트래킹

위 에서 연결 트래킹 에 대해서 언급 했다. 연결 트래킹은 iptables 로 하여금 패킷을 이어지는 패킷으로 볼 지 결정하게 한다. 연결 트래킹 시스템은 iptables 가 stateful 한 기능을 수행할 수 있도록 한다.

연결 트래킹은 패킷이 네트워킹 스택으로 들어오자 마자 적용된다. raw 테이블 체인과 기본적인 체크들이 이를 확인 하기 위한 수단으로 이용된다.

연결 트래킹에 의한 연결 트랙들은 아래 상태 중에 하나를 따른다.

• NEW, ESTABLISHED, RELATED, INVALID, UNTRACKED, SNAT, DNAT…

결론

iptables 와 netfilter 툴은 리눅스 서버에서 방화벽 솔루션을 위한 기본적인 시스템이다. netfilter 커널 훅은 시스템에 의해 패킷이 어떻게 조절되고 관리되는지를 조절하는데 유용하다. iptables 방화벽은 이러한 기능을 활용하여 정책 오구 사항을 커널에 전달하는 유연하고 확장 가능한 방법을 제공한다.