네트워크 중간에 위치해서 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어서 허용하거나 차단하는 장비
방화벽은 네트워크 3,4계층에서 동작하며 세션을 인지하는 상태 기반 엔진으로 동작
2. 초장기 방화벽
SPI 엔진이 없었음
초기 방화벽에서는 패킷의 인과관계를 확인하지 못하고 장비에 등록된 정책만으로 단순히 패킷을 필터링 했음
패킷의 세션 정보나 방향성과 상관없이 순수하게 방화벽에 설정된 정책에 따라 동작하는데 이러한 방식을 스테이트리스 또는 패킷 필터 방화벽이라고 함
패킷이 인입되면 해당 패킷이 방화벽에 설정된 정책에 일치하는지 확인을 하는데 이때 참고하는 조건을 5-Tuple
5-Tuple, Source IP, Destination IP, Protocol No, Source Port, Destination Port
방화벽에 일치된 정책이 있으면 해당 정책에 따라 그 패킷을 허용하거나 차단
방화벽 정책
출발지
목적지
서비스포트
접근 여부
10.0.0.1
20.0.0.1
443
허용
ANY
ANY
ANY
불가
지정된 구간에서 간단한 정책을 정의할 때는 큰 문제가 없는데 인터넷 통신과 같이 불특정 다수 기반의 정책을 할 때는 복잡
패킷 단위의 필터링 이므로 5-Tuple 이외의 3, 4 계층 헤더를 변조해서 공격하면 적절한 방어가 불가능
패킷 필터링 자체는 이후에 나온 방화벽 엔진들보다 부하가 적고 간단히 동작으로 네트워크 장비에서 사용되거나 현대적인 이부 방화벽에서도 특수한 기능을 위해서 사용
패킷 필터링 엔진
기존 패킷 필터 방화벽이 상태값없이 순수하게 정책만으로 제어하던 한계를 극복하기 위해서 개발된 것이 Stateful Inspection Firewall
패킷 필터는 가볍고 빠르지만 인터넷과 같이 불특정 다수와 통신할 때는 정책 관리가 어려움
통신은 대부분 양방향으로 이루어지는데 패킷 필터 엔진은 통신의 양방향성을 인지하지 못하고 단순하게 패킷이 조건과 일치하는지만 확인합니다.
내부 사용자가 외부의 특정 웹페이지에 접속할 때 3웨이 핸드셰이크를 거친 후 HTTP 요청과 응답 과정을 거침
패킷 필터 방화벽에서 이런 트래픽을 처리하기 위해 정책을 선언하려면 목적지가 불특 정 다수의 웹이 될 수 있으므로 외부로 나가는 목적지에 대해서는 모든 패킷을 허용해야 함
이렇게 정책을 설정하면 내부에서 외부 웹사이트로 나갈 수는 있지만 외부에서 내부로 들어오는 응답에 대한 정책이 없으므로 정상적인 통신이 되지 않음
응답에 대한 정책을 설정해야 한다면 외부의 웹사이트는 불특정이므로 출발지가 모든 IP여야 하고 목적지 서비스 포트는 내부에서 외부 호출 시 랜덤 포트를 지정하므로 마찬가지로 모든 포트가 되어야 하는데 이런 정책 설정은 보안상 매우 취약하므로 설정 하면 안됨
이런 문제 때문에 패킷 상태를 인지해 패킷의 인과 관계를 파악할 수 있는 상태 기반 SPI 엔진이 나오게 됨
방화벽 동작 방식
장비에 패킷이 들어오면 우선 세션 상태 테이블을 확인
조건에 맞는 세션 정보가 세션 테이블에 있을 때 포워딩 테이블을 확인(라우팅 ARP 포 함)
조건에 맞는 세션 정보가 세션 테이블에 없을 때 방화벽 정책을 확인
방화벽 정책은 맨 위의 정책부터 확인해 최종 정책까지 확인한 후 없을 때 암시적인 거부(implicit Denial) 규칙을 참고해 차단됨
허용 규칙이 있으면 내용을 세션 테이블에 적어 넣음
포워딩 테이블을 확인(라우팅, ARP 포함)
조건에 맞는 정보가 포워딩 테이블에 있을 때 적절한 인터페이스로 패킷을 포워딩
조건에 맞는 정보가 포워딩 테이블에 없을 때 패킷을 폐기
SPI 엔진을 가진 방화벽은 세선 인지 기능이 있어 단순히 5-튜플 조건만 확인하는 것이 아니라 OSI 3, 4 계층의 세부적인 필드도 함께 확인
TCP 컨트롤 플래그에 따라 동작 방식이 변하거나 시퀀스와 ACK 번호가 갑자기 변경되는 것을 인지해 세션 탈취 공격을 일부 방어할 수 있는데 이것이 TCP Anti-Replay 기능
세션을 추가로 인지하고 세션 테이블에 저장하므로 세션을 로깅하기 쉬운데 대부분의 방벽은 통신 전체의 세션을 로그로 저장할 수 보안 사고 시 이런 세션 로그를 기반으로 어떤 통신에 문제가 있었는지 판단
ALG
방화벽은 패킷 필터 엔진보다 헤더 정보를 상세히 확인하고 세션을 인지할 수 있지만 애플 리케이션 헤더 정보를 인지할 수 없음
세션 방화벽 등장 이전에 개발된 고대 프로토콜은 방화벽과 같은 세션 장비를 고려하지 못 해 통신 중간에 방화벽이 있으면 정상적인 통신이 불가능한 경우가 발생하는데 가장 대표적 인 프로토콜이 FTP
FTP는 컨트롤 프로토콜과 데이터를 보내는 데이터 프로토콜이 분리되어 동작하는데 FTP는 컨트롤 프로토콜과 데이터 프로토콜이 반대로 세션을 맺으므로 방화벽이 FTP 프로토콜을 이해해 동작하지 않으면 정상적인 서비스가 불가능
세션 기반으로 동작하는 방화벽은 세션의 방향성이 매우 중요한데 FRP Active Mode에서는 초기 접속 방향과 반대로 데이터 프로토콜이 동작하므로 방화벽을 통과하지 못했는데 이 문제를 해결하기 위해서 FTP 통신 방식을 패시브 모드로 변경해서 해결
그러나 패시브 모드 자체를 제공하지 못하는 컴포넌트가 있을 수 있고 이미 개발된 애플리케 이션 변경이 불가능한 경우도 있음
방화벽에서 FTP 액티브 모드를 통과시키기 위해 애플리케이션 프로토콜을 확인하고 필요에 따라 세션을 인지해 포트를 자동으로 열어주는데 이것이 ALG(Application Layer Gateway) 기능
ALG 기능은 PAT(Port Address Translation) 기능이 동작하는 방화벽에서 PAT를 정상적으로 통과하지 못하는 프로토콜들을 자동으로 인지해 애플리케이션 정보를 변경해주거나 세션 테이블을 만들어주는 작업을 수행
FTP ALG 기능이 동작하려면 패킷이 방화벽을 지나갈 때 방화벽이나 해당 패킷이 참조되는 정책에 ALG 기능이 활성화되어 있어야 함
최근 대부분의 애플리케이션이 이런 방화벽이나 NAT(Network Address Translation) 를 고 려해 개발되고 있고 STUN(Session Traversal Utilities for NAT) 과 같은 홀 펀칭(Hole Punching) 기술들도 많이 발전해 오래된 프로토콜을 제외하면 ALG 기능을 사용하지 않는 추세