Iptables와 Netfilter의 아키텍처

방화벽(firewall)은 트래픽을 필터링하고 개인 데이터에 대한 원치 않거나 권한이 없는 액세스를 차단하여 네트워크를 보호하는 보안 장치(하드웨어/소프트웨어)입니다. 적절한 방화벽을 갖추는 것은 서버와 인프라를 보호하는 데 중요합니다. 원치 않는 트래픽을 차단할 뿐만 아니라 악성 소프트웨어가 시스템을 감염시키는 것도 막을 수 있습니다.

리눅스 생태계에서 iptables는 리눅스 커널의 netfilter 프레임워크와 인터페이스하는 대중적인 방화벽입니다. 대부분의 현대 리눅스 시스템에는 이러한 도구들이 기본 탑재되어 있습니다. 이러한 시스템을 최대한 활용하려면 아키텍처를 이해하는 것이 필수적입니다. 그렇지 않으면 신뢰할 수 있는 방화벽 정책을 개발하는 것이 매우 까다로울 수 있습니다. 복잡한 구문이나 프레임워크 내의 상호 연관된 부분 등을 생성하는 결과를 초래할 수 있습니다.

본 가이드는 아키텍처를 깊이 있게 다루어, iptables 를 통해 자체 방화벽 정책을 만들어야 하는 사용자들을 도울 것입니다. 또한 iptables 가 netfilter 와 어떻게 인터페이스하고 다양한 구성 요소들이 어떻게 결합하는지 살펴볼 것입니다.

Iptables와 Netfilter

리눅스에서 iptables 방화벽은 가장 일반적인 방화벽입니다. 이는 리눅스 커널의 네트워킹 스택에 있는 패킷 필터링 훅과 인터페이스함으로써 작동합니다. 이러한 커널 훅들을 통틀어 netfilter 프레임워크라고 부릅니다.

시스템의 모든 수신/송신 패킷은 스택을 통과하면서 이러한 훅을 트리거합니다. 따라서 이러한 훅에 등록된 프로그램은 주요 지점에서 트래픽과 상호 작용할 수 있습니다. 마지막으로, iptables 와 관련된 커널 모듈이 이러한 훅에 연결되어 지정된 방화벽 규칙을 적용합니다.

Netfilter 훅

프로그램이 연결할 수 있도록 다섯 가지의 서로 다른 netfilter 훅이 존재합니다. 패킷이 스택을 통과함에 따라, 이 훅들은 자신에게 등록된 커널 모듈을 트리거합니다. 트리거 조건은 패킷 방향(수신/송신), 패킷 목적지, 이전 지점에서 패킷이 드롭/거부되었는지 여부 등과 같은 조건에 따라 달라집니다.

다음은 네트워크 스택에서 잘 정의된 다양한 지점을 나타내는 훅들입니다:

• NF_IP_PRE_ROUTING: 이 훅은 모든 수신 트래픽에 의해 트리거됩니다. 트리거는 패킷의 목적지에 대한 라우팅 결정이 내려지기 전에 발생합니다.

• NF_IP_LOCAL_IN: 이 훅은 수신 패킷을 라우팅한 후에 트리거됩니다. 또한 패킷의 목적지가 로컬 시스템이어야 합니다.

• NF_IP_FORWARD: 이 훅 역시 수신 패킷을 라우팅한 후에 트리거됩니다. 단, 패킷이 다른 호스트로 라우팅되어야 하는 경우에 트리거됩니다.

• NF_IP_LOCAL_OUT: 모든 로컬 아웃바운드 트래픽은 네트워크 스택에 도달하는 즉시 이 훅을 트리거합니다.

• NF_IP_POST_ROUTING: 이 훅은 라우팅이 이루어진 후, 패킷이 전송선로(wire)에 도달하기 전에 모든 송신/전송 트래픽에 의해 트리거됩니다.

이러한 훅에 등록하려는 커널 모듈은 우선순위 번호를 제공해야 합니다. 이 값은 훅이 트리거되었을 때 모듈이 호출되는 순서를 결정하는 데 도움이 됩니다. 이러한 메커니즘을 통해 여러 모듈(서로 다른 모듈 또는 동일한 모듈의 여러 복사본)이 결정론적인 순서로 각 훅에 연결할 수 있습니다. 각 모듈은 패킷을 처리한 후 netfilter 프레임워크에 결정을 반환합니다.

Iptables의 테이블과 체인

규칙을 정리하기 위해 iptables 방화벽은 테이블을 사용합니다. 테이블은 규칙이 내리는 결정의 유형에 따라 규칙을 분류합니다. 예를 들어, 규칙이 NAT(네트워크 주소 변환)를 다루는 경우 해당 규칙은 nat 테이블에 배치됩니다. 마찬가지로, 규칙이 패킷의 목적지 허용/거부 여부를 결정하는 경우 filter 테이블에 추가됩니다.

각 iptables 테이블 내부에서 규칙은 별도의 “체인”으로 한 번 더 구성됩니다. 테이블이 보유하고 있는 규칙의 유형을 나타내는 반면, 체인은 규칙을 트리거하는 netfilter 훅을 설명합니다. 간단히 말해, 체인은 규칙이 평가되는 시점을 결정합니다.

다음은 iptables의 내장 체인입니다.. 흥미롭게도, 체인 이름은 관련된 netfilter 훅의 이름과 일치합니다:

관리자는 체인을 사용하여 패킷 전달의 어느 단계에서 규칙이 평가될지 결정할 수 있습니다. 각 테이블에는 여러 체인이 포함되어 있으므로 처리 과정의 여러 지점에서 영향력을 확장할 수도 있습니다. 특정 결정은 네트워크 스택의 특정 지점에서만 의미가 있습니다. 따라서 모든 테이블이 각 커널 훅에 등록된 체인을 갖는 것은 아닙니다.

The netfilter 프레임워크는 5개의 커널 훅만 제공합니다. 따라서 여러 테이블의 체인이 각 훅의 지점에 등록됩니다. 예를 들어, 세 개의 체인이 PREROUTING 체인을 가지고 있다면, 이는 NF_IP_PRE_ROUTING 훅에 등록됩니다. 이들 각각은 각 테이블의 PREROUTING 체인이 호출되는 순서를 결정하는 우선순위를 제공해야 합니다. 가장 높은 우선순위를 가진 PREROUTING 체인이 가장 먼저 평가되고, 그다음으로 높은 우선순위를 가진 체인이 두 번째로 평가되는 식입니다.

iptables 테이블

한 걸음 물러서서 iptables가 제공하는 테이블을 살펴보겠습니다. 앞서 언급했듯이, 각 테이블은 패킷 평가를 위해 관심 영역별로 구성된 서로 다른 규칙 세트를 나타냅니다.

• filter 테이블

In iptables에서 filter 테이블은 가장 대중적인 테이블 중 하나입니다. 이 테이블은 패킷이 목적지까지 계속 진행하도록 허용할지 여부를 결정하는 데 사용됩니다. 방화벽 용어로 이 프로세스를 패킷 “필터링”이라고 합니다.

사람들이 방화벽에 대해 이야기할 때 (대부분) 언급하는 것은 바로 filter 테이블의 기능입니다.

• nat 테이블

이 테이블은 NAT를 규제하는 규칙을 구현합니다. 패킷이 네트워크 스택에 들어올 때, 이 테이블에 정의된 규칙은 패킷의 출발지/목적지 주소를 수정하는 방법을 결정하여 패킷의 라우팅 및 모든 응답 트래픽에 영향을 미칩니다.

종종 nat 테이블은 직접 액세스할 수 없는 네트워크로 패킷을 라우팅하는 데 사용됩니다.

• mangle 테이블

이 테이블은 다양한 방식으로 패킷의 IP 헤더를 수정하는 규칙을 가집니다. 예를 들어, 패킷이 버틸 수 있는 유효한 네트워크 홉 수를 늘리거나 줄여 패킷의 TTL(Time to Live) 값을 수정할 수 있습니다. 또한, mangle 테이블은 유사한 방식으로 다른 IP 헤더를 수정할 수 있습니다.

이 테이블은 또한 다른 테이블과 네트워크 도구가 추가 처리를 위해 감지할 수 있도록 패킷에 내부 커널 “마크”를 지정할 수 있습니다. 이 마크는 실제 패킷을 건드리지 않고 대신 커널의 패킷 표현에 마크를 추가합니다.

• raw 테이블

The iptables 방화벽은 상태 저장(stateful) 방식이므로, 패킷이 이전 패킷과의 관계 맥락에서 평가됨을 의미합니다. netfilter 프레임워크 위에서 개발된 연결 추적 기능은 iptables 가 패킷을 개별적이고 무관한 패킷의 흐름이 아니라 진행 중인 연결 또는 세션의 일부로 볼 수 있도록 합니다. 일반적으로 연결 추적 로직은 패킷이 네트워크 인터페이스에 도달한 직후에 적용됩니다.

The raw 테이블은 매우 좁게 정의된 기능을 제공합니다. 이 테이블의 유일한 목적은 연결 추적을 제외하기 위해 패킷을 마킹하는 메커니즘을 제공하는 것입니다.

• security 테이블

The security 테이블은 패킷에 내부 SELinux 보안 컨텍스트 마크를 지정합니다. 이는 결과적으로 SELinux(또는 SELinux 보안 컨텍스트를 해석하는 다른 앱)가 패킷을 처리하는 방식에 영향을 미칩니다.

SELinux 마크는 패킷당 또는 연결당 기준으로 적용될 수 있습니다.

각 테이블에 구현된 체인

지금까지 테이블과 체인에 대해 별도로 이야기했습니다. 이제 각 테이블에서 어떤 체인을 사용할 수 있는지 알아볼 시간입니다. 이 주제는 동일한 훅에 등록된 체인의 평가 순서에 대한 논의로 확장됩니다. 예를 들어, 세 개의 테이블에 PREROUTING 체인이 있다면 어떻게 될까요? 이들의 평가 순서는 어떻게 될까요?

다음으로 아래 표를 살펴보십시오. 이는 각 iptables 테이블 내에서 사용할 수 있는 체인을 나타냅니다.

왼쪽에서 오른쪽으로 읽을 때, 어떤 테이블에 어떤 체인이 포함되어 있는지를 설명합니다. 예를 들어, raw 테이블은 PREROUTING 및 OUTPUT 체인을 모두 가집니다. 위에서 아래로 읽을 때, 관련된 netfilter 훅이 트리거될 때 각 체인이 호출되는 순서를 설명합니다.

참고로 nat 테이블은 순서를 더 명확히 하기 위해 DNAT 작업(패킷의 목적지 변경)과 SNAT 작업(패킷의 출발지 변경)으로 분할되었습니다. 또한 이 표에는 라우팅 결정이 내려지고 연결 추적이 활성화되는 지점도 표시되어 있습니다.

패킷이 트리거할 훅(열)은 패킷의 특성(수신/송신), 내려진 라우팅 결정, 그리고 패킷이 필터링 기준을 충족하는지 여부에 따라 달라집니다.

처리 중에 특정 이벤트로 인해 테이블의 체인을 건너뛸 수 있습니다. 예를 들어, 연결의 첫 번째 패킷만 nat 테이블에 설명된 NAT 규칙에 따라 평가됩니다. 동일한 연결의 후속 패킷은 추가 평가 없이 동일한 nat 결정이 적용됩니다. NAT 연결에 대한 응답에는 올바른 라우팅을 위해 역방향 NAT 규칙이 자동으로 적용됩니다.

체인 탐색 순서

서버가 패킷 라우팅 규칙을 알고 있고 방화벽 규칙이 전송을 허용한다고 가정할 때, 다음 흐름은 서로 다른 경로가 어떻게 탐색되는지 나타냅니다:

• 로컬 시스템을 대상으로 하는 수신 패킷: PREROUTING >> INPUT

• 다른 호스트를 대상으로 하는 수신 패킷: PREROUTING >> FORWARD >> POSTROUTING

• 로컬에서 생성된 패킷: OUTPUT >> POSTROUTING

결론적으로, 지금까지 논의한 모든 정보를 종합해 보면, 로컬 시스템을 대상으로 하는 모든 수신 패킷은 PREROUTING 체인(대상 테이블: raw, mangle, 및 nat 테이블)에서 평가됩니다. 그런 다음, 최종적으로 로컬 소켓에 도달하기 전에 INPUT 체인(대상 테이블: mangle, filter, security, 및 nat 테이블)을 거치게 됩니다.

Iptables 규칙

The iptables 방화벽 규칙은 특정 테이블의 특정 체인 내에 배치됩니다. 체인이 호출되면 해당 패킷은 체인의 각 규칙에 따라 평가됩니다. 각 규칙은 일치하는 구성 요소와 작업 구성 요소의 두 가지 구성 요소로 이루어집니다.

• 매칭

규칙의 매칭 부분은 지정된 작업(또는 “타겟”)이 실행되기 전에 패킷이 충족해야 하는 조건을 지정합니다.

매칭 시스템은 놀라운 유연성을 제공합니다. 이 기능은 iptables 확장의 도움을 받아 확장할 수도 있습니다. 프로토콜 유형, 출발지/목적지 주소, 출발지/목적지 포트, 출발지/목적지 네트워크, 입력/출력 인터페이스, 헤더, 연결 상태 및 기타 기준에 따라 패킷을 매칭하도록 규칙을 작성할 수 있습니다. 또한 규칙은 이러한 조건들의 조합을 가질 수 있으므로, 서로 다른 트래픽을 구분하기 위한 복잡한 규칙 세트를 만들 수 있습니다.

• 타겟

타겟은 패킷이 규칙의 매칭 기준을 충족할 때 취하는 작업입니다. 일반적으로 타겟은 두 가지 그룹으로 나뉩니다:

• • 종료 타겟: 체인 내에서의 평가 프로세스를 종료하고 제어권을 netfilter 훅으로 반환합니다. 반환된 값에 따라 훅은 패킷이 계속 진행하도록 허용하거나 드롭합니다.

  • 비종료 타겟: 타겟이 작업을 수행하고 체인에서의 평가가 계속됩니다. 각 체인은 최종 종료 결정을 거쳐야 하지만, 그 전에 얼마든지 비종료 타겟이 실행될 수 있습니다.

규칙 내에서 각 타겟의 가용성은 컨텍스트에 따라 달라집니다. 예를 들어, 체인 및 테이블 유형이 타겟의 가용성에 영향을 미칠 수 있습니다. 다른 가능한 요인으로는 규칙에서 활성화된 확장 및 일치하는 절이 있습니다.

사용자 정의 체인

비종료 타겟의 특별한 클래스인 점프 타겟도 있습니다. 점프 타겟은 추가 처리를 위해 평가가 한 체인에서 다른 체인으로 이동할 때 수행되는 작업입니다. 지금까지 우리는 다음과 밀접하게 연결된 내장 체인에 대해 이야기했습니다. netfilter 호출하는 훅입니다. 하지만, iptables 또한 관리자가 사용자 정의 체인을 생성할 수 있도록 허용합니다.

사용자 정의 체인의 규칙도 내장 체인의 규칙과 유사합니다. 주요 차이점은 사용자 정의 체인은 규칙에서 해당 체인으로 “점프”해야만 도달할 수 있다는 것입니다. 사용자 정의 체인은 어떤 netfilter 훅과도 연결되어 있지 않기 때문입니다.

사용자 정의 체인은 원래 이를 호출한 체인의 확장으로 생각할 수 있습니다. 예를 들어, 사용자 정의 체인에서 규칙 목록의 끝에 도달하거나 일치하는 규칙이 RETURN 타겟을 실행하면 평가가 다시 호출 체인으로 돌아갑니다. 흥미롭게도 사용자 정의 체인은 평가를 다른 사용자 정의 체인으로 “점프”시킬 수도 있습니다.

이 기능은 더 나은 조직화를 위한 토대를 마련하고 강력한 분기를 위해 필요한 프레임워크를 제공합니다.

연결 추적

우리가 raw 테이블 및 연결 상태 일치 기준에 대해 논의할 때, 우리는 netfilter 프레임워크 위에 구현된 연결 추적 시스템에 대해 논의했습니다. 이 기능은 iptables 가 진행 중인 연결의 컨텍스트에서 패킷을 볼 수 있도록 합니다. 또한 연결 추적 시스템은 iptables에 “상태 저장”(stateful) 작업을 수행하는 데 필요한 기능을 제공합니다.

패킷이 네트워킹 스택에 들어온 직후 연결 추적이 적용됩니다. raw 테이블 체인과 몇 가지 기본적인 무결성 검사는 패킷을 연결과 연결하는 데 들어가는 모든 로직입니다.

시스템은 기존 연결 세트와 비교하여 각 패킷을 검사합니다. 필요한 경우 시스템은 기존 연결의 상태를 업데이트하거나 새 연결을 생성합니다. raw 테이블 체인에서 NOTRACK 타겟으로 표시된 패킷은 추가 연결 추적 루틴을 우회합니다.

• 사용 가능한 상태

연결 추적 시스템에 의해 추적되는 연결에는 다음 상태 중 하나가 할당됩니다.

• • NEW : 기존 연결과 관련이 없지만 첫 번째 패킷으로서 유효하지 않은 것은 아닌 패킷이 도착하면, 이 레이블과 함께 새로운 연결이 시스템에 추가됩니다. 이는 연결 지향 프로토콜(예: TCP)과 비연결형 프로토콜(예: UDP) 모두에 적용됩니다.

  • ESTABLISHED: 연결 상태가 NEW 에서 ESTABLISHED로 업데이트되는 것은 반대 방향으로부터 유효한 응답을 받았을 때입니다. TCP 연결의 경우, 이는 SYN/ACK을 의미합니다. UDP 및 ICMP 트래픽의 경우, 이는 원래 패킷의 출발지와 목적지가 바뀐 응답을 의미합니다.

  • RELATED: 연결의 일부는 아니지만 기존에 확립된 연결과 관련된 패킷은 RELATED 로 레이블이 지정됩니다. 이는 헬퍼 연결(예: FTP 데이터 전송 연결) 또는 다른 프로토콜의 연결 시도에 대한 ICMP 응답을 의미할 수 있습니다.

  • INVALID: 확립된 연결의 일부가 아니거나, 새 연결을 여는 데 부적절한 것으로 간주되거나, 식별할 수 없거나, 라우팅할 수 없는 등의 패킷은 INVALID.

  • UNTRACKED: 패킷은 추적을 우회하기 위해 UNTRACKED로 레이블이 지정될 수 있습니다. 이는 raw 테이블 체인에서 타겟으로 지정된 경우입니다.

  • SNAT: NAT 작업에 의해 출발지 주소가 수정될 때 설정되는 가상 상태를 의미합니다. 이는 응답 패킷에서 출발지 주소가 변환되도록 연결 추적 시스템에 의해 처리됩니다.

  • DNAT: 다음과 유사합니다. SNAT, 이는 NAT 작업에 의해 목적지 주소가 수정될 때의 가상 상태를 나타냅니다. 연결 추적 시스템은 응답 패킷을 라우팅할 때 목적지 주소를 다시 원래대로 변환할 수 있도록 이를 처리합니다.

연결 추적 시스템이 추적하는 이러한 상태를 통해 관리자는 연결 수명 주기의 특정 시점을 대상으로 하는 구체적인 규칙을 작성할 수 있습니다. 이는 더 철저하고 안전한 규칙을 만드는 데 필요한 기능을 제공합니다.

마치며

리눅스에서 netfilter 프레임워크와 iptables 방화벽은 대부분의 방화벽의 기초 역할을 합니다. netfilter 훅은 네트워킹 스택과 충분히 가까워 시스템에서 처리되는 패킷을 강력하게 제어할 수 있습니다. 이러한 기능을 활용하여 iptables 방화벽은 정책 요구 사항을 커널에 전달하는 유연한 방법을 제공합니다.

이 가이드는 netfilter 프레임워크 및 iptables 방화벽의 내부 구조를 심도 있게 다룹니다. 또한 연결 추적 시스템에 대해서도 설명합니다. 이러한 부분들이 어떻게 서로 맞물려 돌아가는지 이해하면, 이를 더 잘 활용하여 더 강력하고 안전한 서버 환경을 구축할 수 있습니다.

마지막으로, 이 가이드에서는 내부 작동 방식을 다루었지만, 이를 실제로 적용하려면 iptables 설정하기 가이드를 확인해 보세요. 또한, UFW 방화벽이 iptables를 어떻게 더 단순화하는지 확인할 수 있습니다. 아울러, iptables 방화벽 규칙을 조회하고 삭제하는 방법을 배우는 것도 유용할 것입니다..

즐거운 컴퓨팅 되세요!