스테이트풀 프로토콜 검사를 위한 스테이트풀 방화벽과 스테이트리스 방화벽의 이해

방화벽은 오랫동안 기업의 사이버 보안 전략의 기본 구성 요소였습니다. 수년에 걸쳐 대규모 제품 기능 추가 및 개선 작업을 거쳤습니다. 1994년으로 거슬러 올라가는 특별한 기능 중 하나는 상태 검사입니다.

상태 검사란 무엇인가요?

동적 패킷 필터링이라고도 하는 상태 검사란 방화벽이 네트워크 연결의 상태 및 컨텍스트에 따라 데이터 패킷을 필터링하는 것을 말합니다. 네트워크 연결에서 '상태'와 '컨텍스트'가 의미하는 바를 살펴보겠습니다.

상태

연결 상태를 파악하는 방법으로 두 엔드포인트 간의 네트워크 프로토콜 TCP 기반 통신을 사용해 보겠습니다. TCP에서는 할당 가능한 9개의 제어 비트 중 4개의 비트(SYN, ACK, RST, FIN)가 연결 상태를 제어하는 데 사용됩니다. 방화벽은 해당 연결 상태를 기반으로 정책을 적용할 수 있지만 연결 종료 후 방화벽을 통과하기 위해 남은 패킷, 재전송된 패킷 또는 지연된 패킷도 고려해야 합니다.

방화벽에서 상태 추적의 간단한 예를 살펴보겠습니다:

1. 클라이언트 애플리케이션이 3자 핸드셰이크를 사용하여 연결을 시작하면 TCP 스택은 SYN 플래그를 설정하여 연결 시작을 표시합니다. 이 플래그는 방화벽에서 새 연결을 나타내는 데 사용됩니다.
2. 서버는 SYN + ACK를 전송하여 연결에 응답하며, 이 시점에서 방화벽은 양쪽에서 패킷을 확인하여 내부 연결 상태를 ESTABLISHED로 승격합니다. TCP 관점에서 보면 클라이언트가 ACK로 응답을 보낼 때까지 연결이 완전히 설정되지 않은 상태입니다.
3. 마찬가지로 방화벽이 RST 또는 FIN+ACK 패킷을 감지하면 연결 상태를 삭제 대상으로 표시하고 향후 이 연결에 대한 모든 패킷을 삭제합니다.

의사 상태

모든 네트워킹 프로토콜이 TCP와 같은 상태를 가지는 것은 아닙니다. 예를 들어 UDP는 본질적으로 상태가 없는 매우 일반적으로 사용되는 프로토콜입니다. 이 프로토콜을 사용하는 애플리케이션은 애플리케이션 로직을 사용하여 상태를 유지하거나 로직 없이도 작동할 수 있습니다. UDP를 사용하는 인기 애플리케이션은 DNS, TFTP, SNMP, RIP, DHCP 등 몇 가지가 있습니다.

오늘날의 스테이트풀 방화벽은 이러한 프로토콜에 대해 '의사 상태'를 생성합니다. 예를 들어 방화벽은 DNS 요청과 같은 발신 패킷을 감지하면 소스 및 대상의 IP 주소와 포트를 사용하여 항목을 생성합니다. 그런 다음 이 연결 데이터와 연결 시간 초과 데이터를 사용하여 들어오는 패킷(예: DNS)이 응답할 수 있도록 합니다.

Context

연결 컨텍스트에는 다음과 같은 패킷과 관련된 메타데이터가 포함됩니다:

• 소스 및 대상 엔드포인트의 IP 주소 및 포트
• 유휴 연결 처리를 위한 마지막 패킷 수신 시간
• 패킷 길이
• 레이어 4 TCP 시퀀스 번호 및 플래그
• 조각화 및 재조립과 관련된 레이어 3 데이터로 조각화된 패킷의 세션 등을 식별합니다.

상태 저장 검사 대 상태 비저장 검사

상태 저장 방화벽과 상태 비저장 방화벽의 주요 차이점은 상태 저장 방화벽은 트래픽 및 데이터 패킷의 전체 컨텍스트를 분석하여 네트워크 연결 상태를 지속적으로 추적한다는 점입니다(즉, "상태 저장"). 대신 상태 비저장 방화벽은 연결의 전체 컨텍스트를 요구하지 않고 트래픽과 데이터 패킷을 분석합니다.

이제 상태 저장 방화벽과 상태 비저장 검사 방화벽에 대해 자세히 살펴보겠습니다.

무국적 방화벽

상태 비저장 방화벽은 어떻게 작동하나요?

그림 1을 통해 상태 비저장 방화벽의 내부 작동 방식을 이해할 수 있습니다. 상태 비저장 방화벽은 패킷의 프로토콜 헤더를 검사하여 인바운드 또는 아웃바운드 트래픽 데이터에 보안 정책을 적용합니다(1). OSI 계층 2에서 4까지 검사합니다. 검사 후 상태 비저장 방화벽은 이 정보를 정책 테이블(2)과 비교합니다. 여기에서 패킷을 허용, 거부 또는 재설정할 정책 조치(4.a & 4.b)를 결정합니다.

그림 1: 상태 비저장 방화벽에 대한 정책 결정을 보여주는 흐름도

상태 비저장 방화벽의 장점은 무엇인가요?

• 리소스 사용량이 적습니다: 정책 조회는 정적 패킷 데이터와 정책 테이블에서 수행되므로 조회에 필요한 CPU 및 메모리 리소스의 양이 적습니다. 이는 ACL(액세스 제어 목록)과 같은 기능을 사용하는 라우터 및 스위치와 같은 정적 정책 조회 장치에 효과적입니다.
• 지연 시간이 증가하지 않습니다: 추가 처리로 인해 오버헤드 지연 시간이 증가하지 않거나 간단히 말해 패킷의 회선 속도 처리가 최소화됩니다.

상태 비저장 방화벽의 단점은 무엇인가요?

• 제한된 필터링: 상태 비저장 방화벽은 제한된 필터링 기능을 제공하는 방화벽의 낮은 충실도 데이터만을 사용하여 결정을 내립니다.
• ACL 구성:이러한 디바이스에서 ACL을 구성하고 관리하는 작업은 소규모에서는 오류가 발생하기 쉽고 대규모에서는 거의 불가능합니다.

소규모 및 대규모 ACL 구성 및 관리의 어려움에 대해 설명해 드리겠습니다. 먼저 소규모 배포의 경우를 살펴보겠습니다.

• 상태 비저장 방화벽은 패킷이 속한 흐름에 관계없이 현재 패킷의 내용을 검사하여 정책 결정을 내리기 때문에 본질적으로 단방향성입니다. 정책을 정확하게 작성하려면 연결의 양쪽이 TCP와 같은 양방향 통신 프로토콜에 대해 화이트리스트에 등록되어 있어야 합니다. 하나의 연결을 정책화하기 위해 두 개의 규칙을 작성하는 것은 문제가 됩니다.
• 이제 각 트랜잭션에 대해 두 세트의 연결이 있고 데이터 연결에 연결 시간이 협상되었지만 포트를 알 수 없는 FTP와 같은 프로토콜을 생각해보면, 상태 비저장 방화벽이 이를 화이트리스트로 지정할 방법이 없습니다. 모든 애플리케이션에 대한 정책을 작성할 수 없기 때문에 보안에 큰 구멍이 생깁니다.
• 또 다른 사용 사례는 내부 호스트가 외부 인터넷에 대한 연결을 시작하는 경우입니다. 모든 응답 트래픽을 허용하도록 ACL을 사용하여 정책을 만들려면 어떻게 해야 하나요? 이 도구는 세밀한 정책 제어를 위해 만들어진 것이 아니며, 정책이 매우 세분화되고 방향성이 있는 마이크로 세분화 프레임워크에는 그다지 유용하지 않습니다.

이제 대규모 문제로 넘어가 보겠습니다.

• 잠시 이전 단락에서 설명한 모든 문제를 극복할 수 있는 요술 지팡이가 있다고 상상해 봅시다. 이 경우에도 스위치 또는 라우터 하드웨어의 TCAM(삼원 콘텐츠 주소 지정 가능 메모리)과 같은 리소스는 매우 제한적이어서 규모에 따라 TCAM 공간의 고갈로 인해 모든 애플리케이션에 대한 정책을 작성할 수 없습니다.
• 하드웨어 기반이 아닌 구현의 경우에도 ACL의 수는 많은 문제를 야기합니다. 예를 들어, 과거에 사용했던 제품은 광범위하게 구성된 ACL 시스템에서 효율적인 조회 테이블(위 그림 1의 정책 테이블)을 파싱하고 구축하는 데 30분 이상이 걸렸습니다. 그리고 이 프로세스는 하나의 규칙이 추가되거나 삭제될 때마다 트리거됩니다. 이러한 일상적인 작업으로 인해 다운타임이 발생하고 중요한 비즈니스에 영향을 미친다고 생각해보세요.

반사적 방화벽, 일명 반사적 ACL

IP 세션 필터링 ACL이라고도 하는 반사적 ACL은 반환 트래픽을 동적으로 화이트리스트에 추가하는 메커니즘입니다. 정책 결정의 대부분의 워크플로는 새 워크플로를 식별하고 자동화된 동적 상태 비저장 ACL 항목을 추가하는 메커니즘을 제외하고는 상태 비저장 방화벽과 유사합니다. 아래 워크플로 다이어그램을 통해 패킷의 수명을 살펴보겠습니다.

그림 2: 반사적 ACL에 대한 정책 결정을 보여주는 흐름도

반사적 ACL이 새 IP 아웃바운드 연결(그림 2의 6)을 감지하면 소스-대상 IP 주소와 포트를 반전시켜 동적 ACL 항목(7)을 추가합니다. 새로운 동적 ACL을 사용하면 반환 트래픽에 대해 유효성을 검사할 수 있습니다. 마찬가지로 반사적 방화벽은 양쪽에서 FIN 패킷, RST 패킷 또는 최종 시간 초과를 감지하면 동적 ACL을 제거합니다. 이렇게 하면 세션이 종료되거나 종료될 때 향후 모든 가짜 패킷이 삭제됩니다.

반사적 방화벽의 장점은 무엇인가요?

상태 비저장 방화벽에 비해 반사적 방화벽의 유일한 장점은 리턴 트래픽을 자동으로 화이트리스트에 추가할 수 있다는 점입니다. 이렇게 하면 역방향 ACL 규칙을 수동으로 작성하는 것을 방지할 수 있습니다.

반사적 방화벽의 단점은 무엇인가요?

반사적 ACL은 여전히 패킷 내의 정적 정보에 대해서만 작동합니다. 이를 도입한 이유는 역방향 트래픽에 대한 규칙을 작성한다는 측면에서 표준 ACL보다 한 단계 업그레이드된 기능을 제공하지만, 반사적 ACL을 우회하는 것이 간단하기 때문입니다. 반사적 방화벽은 상태 비저장 방화벽과 동일한 결함을 가지고 있습니다. 이를 테스트하는 한 가지 방법은 패킷을 조각화하여 반사적 ACL이 작동할 정보가 여러 패킷으로 분할되도록 하는 것입니다. 이렇게 하면 반사적 ACL이 개별 패킷의 허용 또는 차단을 결정할 수 없습니다. 반면 상태 저장 방화벽은 여러 패킷으로 분할된 전체 조각을 재조합한 다음 전체 세션에 대한 상태 + 컨텍스트 + 패킷 데이터를 기반으로 결정을 내릴 수 있습니다.

반사적 ACL의 또 다른 단점은 특정 종류의 애플리케이션에서만 작동한다는 점입니다. 예를 들어, 네트워크를 통해 파일을 전송하는 데 사용되는 매우 일반적인 애플리케이션인 FTP는 별도의 컨트롤 플레인 연결을 통해 전송에 사용할 데이터 포트를 동적으로 협상하는 방식으로 작동합니다. 반사적 ACL은 정적이므로 동일한 5-튜플을 사용하는 두 호스트 간의 양방향 연결만 화이트리스트에 추가할 수 있습니다. 따라서 FTP와 같은 애플리케이션은 지원할 수 없습니다.

스테이트풀 방화벽

상태 저장 방화벽은 방화벽 정책을 적용하기 위해 연결의 상태 및 컨텍스트에 따라 작동합니다. 상태 저장 방화벽의 내부 작동을 이해하려면 아래 흐름도를 참조하세요.

그림 3: 상태 저장 방화벽에 대한 정책 결정을 보여주는 흐름도

스테이트풀 방화벽은 어떻게 작동하나요?

1. 5-튜플 조회: 패킷이 방화벽에 도착하면(그림 3의 1), 플로우 또는 연결 테이블이라는 테이블에서 5-튜플(소스 IP, 소스 포트, 대상 IP, 대상 포트, 프로토콜)을 사용하여 플로우 조회를 시도하여 일치하는 것을 찾습니다(2). 이는 플로우 테이블이 아닌 정책 테이블에서 5-튜플 조회가 수행되는 상태 비저장 방화벽과는 다릅니다. 그림에 표시되지 않은 흐름 테이블 및 관련 테이블에는 이전에 표시된 모든 흐름의 상태+텍스트가 들어 있습니다.
2. 빠른 경로/데이터 플레인 처리: 항목이 발견되면 패킷은 빠른 경로, 즉 데이터 플레인 처리를 거칩니다. 간단한 고속 경로 처리에는 속도 검사, 조각화( & 재조립 기반 공격) 방지를 위한 계층 3 IP 위생 검사, 스푸핑, DOS 등과 같은 공격을 방지하기 위한 계층 4 위생 검사 등이 포함됩니다. 방화벽이 레이어 7 테스트를 수행할 수 있는 경우 애플리케이션 레이어 게이트웨이(ALG)라는 추가 필터를 거치게 됩니다. 모든 검사가 순조롭게 진행되면 패킷은 다음 홉으로 전달됩니다(3.b).
3. 느린 경로/제어판 처리: 플로우 조회 결과 미스(3.a)가 발생하면 패킷이 새 연결을 위한 것으로 가정하고 추가 정책 검사를 거쳐야 하며, 이 경로를 느린 경로 또는 제어판 처리라고 합니다. 제어 처리 경로에서 방화벽은 빠른 경로에서 수행하는 모든 작업을 확인할 뿐만 아니라 방화벽 정책에 따라 이 새 연결이 허용되는지 여부도 결정합니다.
4. 정책 조회: 그러면 방화벽이 연결의 상태 + 컨텍스트(5)를 사용하여 정책 조회를 수행합니다.
5. 정책이 일치하고 해당 정책에 대해 허용, 거부 또는 재설정 등의 조치가 지정된 경우 적절한 조치가 취해집니다(8.a 또는 8.b). 고급 상태 저장 방화벽은 어떤 종류의 콘텐츠 검사를 수행할지 지시할 수도 있습니다. 이를 고려하여 방화벽은 플로우 테이블(9)에 항목을 생성하여 해당 연결에 대한 후속 패킷이 제어 영역 처리를 피하고 더 빠르게 처리될 수 있도록 합니다.

스테이트풀 방화벽의 장점은 무엇인가요?

• 더 높은 보호: 상태 저장 방화벽은 흐름의 상태+ 컨텍스트를 고려하여 전체 프로토콜 검사를 제공하므로 추가적인 공격 표면을 제거하고 시스템의 취약성 관리를 강화합니다.
• 고급:스테이트풀 방화벽은 고급 애플리케이션 계층 방화벽 또는 게이트웨이를 위한 빌딩 블록 역할을 합니다.
• 구성 기능: 상태 저장 방화벽은 네트워크 흐름을 이해하고 흐름의 데이터 패킷을 식별할 수 있으므로 양방향 연결 또는 의사 상태 네트워킹 프로토콜에 대한 간단한 규칙 작성을 가능하게 합니다.
• 복잡한 프로토콜: 상태 저장 방화벽은 패킷 페이로드를 더 깊이 들여다볼 수 있으므로 런타임에 통신 포트와 프로토콜을 협상하는 복잡한 프로토콜을 이해하고 그에 따라 방화벽 정책을 적용할 수 있습니다. FTP, P2P 프로토콜 등과 같은 프로토콜을 생각해 보세요.
  

스테이트풀 방화벽의 단점은 무엇인가요?

• 처리 능력: 스테이트풀 방화벽은 더 많은 보안을 제공하기 위해 추가 검사를 수행하며, 이러한 다른 검사에는 CPU 사이클과 메모리 측면에서 더 많은 처리 능력이 필요합니다. 상태 저장 방화벽 설계자와 개발자들은 이 문제를 고민해 왔으며, 대부분의 최신 방화벽은 제어와 데이터 플레인 처리를 분리하는 최첨단 알고리즘 설계를 통해 이 문제를 극복하거나 줄여 거의 유사한 상태 저장 방화벽 성능을 달성하고 있습니다. 하지만 여기서는 상태 저장 방화벽에 비해 상태 저장 방화벽의 우위를 인정하겠습니다.
• 더 넓은 공격 표면: 상태 저장 방화벽은 코드 기반 공간이 더 크기 때문에 상태 비저장 방화벽에 비해 공격 표면이 더 클 수 있습니다. 간단한 구글 검색만으로도 수많은 예시를 찾을 수 있습니다. 시간이 지남에 따라. Linux 및 Windows와 같은 운영 체제에 내장된 방화벽과 같은 특정 유형의 방화벽은 실전 테스트를 거쳤으며 오늘날 엔터프라이즈급 스테이트풀 방화벽으로 사용되고 있습니다.

Conclusion

완벽한 방화벽은 존재하지 않습니다. 각 유형의 방화벽은 심층적인 방어 전략에서 각자의 위치를 차지합니다. 상태 비저장 방화벽은 거친 단위의 정책 적용이 적절한 곳에서는 도움이 될 수 있으며, 상태 저장 방화벽은 보다 세밀하고 심층적인 정책 제어와 네트워크 세분화 또는 마이크로 세분화가 필요한 곳에서 유용합니다.

오늘날 데이터 트래픽 검사 방화벽에는 상태 비저장형과 상태 저장형 프로토콜 검사 등 다양한 종류가 있습니다. 사용자 환경에 맞는 방화벽을 선택할 때 알아두어야 할 중요한 사항입니다.

이제 스테이트풀에 대한 기술적 이해를 갖추셨으니 다음 블로그 포스팅에서는 마이크로 세분화에 스테이트풀 방화벽이 중요한 이유와 세분화 벤더가 이를 수행해야 하는 이유에 대해 설명하겠습니다.

Learn more

방화벽 및 회사의 보안 전략과 관련된 기타 중요한 비즈니스 의사 결정에 대한 자세한 내용은 문의하세요.