방화벽

1. 정의

• 네트워크 중간에 위치해서 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어서 허용하거나 차단하는 장비
• 방화벽은 네트워크 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 엔진이 나오게 됨

방화벽 동작 방식

1. 장비에 패킷이 들어오면 우선 세션 상태 테이블을 확인
2. 조건에 맞는 세션 정보가 세션 테이블에 있을 때 포워딩 테이블을 확인(라우팅 ARP 포 함)
3. 조건에 맞는 세션 정보가 세션 테이블에 없을 때 방화벽 정책을 확인
4. 방화벽 정책은 맨 위의 정책부터 확인해 최종 정책까지 확인한 후 없을 때 암시적인 거부(implicit Denial) 규칙을 참고해 차단됨
5. 허용 규칙이 있으면 내용을 세션 테이블에 적어 넣음
6. 포워딩 테이블을 확인(라우팅, ARP 포함)
7. 조건에 맞는 정보가 포워딩 테이블에 있을 때 적절한 인터페이스로 패킷을 포워딩
8. 조건에 맞는 정보가 포워딩 테이블에 없을 때 패킷을 폐기

• 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 기능을 사용하지 않는 추세