패스틀리(Fastly), NGWAF 소개

포스팅 하는 내용의 출처는 아래의 블로그임을 알려드립니다. 이번에는 아래 내용의 블로그를 번역해서 포스팅하도록 하겠습니다. 

https://qiita.com/AtsushiFukuda/items/16b143a849d442d182da

Fastly 次世代 (Signal Sciences) WAF について - Qiita

 

NG WAF에 대해서

Fastly의 차세대 WAF (이하 NG-WAF)는 CDN등의 Edge Cloud Platform 를 제공하는 Fastly가 2020년에 매수한 Signal Sciences사의 솔루션을 베이스로 해서 멀티 클라우드 환경에 대응한 종합형의 Web Application Firewall (WAF) 솔루션 입니다.

이번 포스팅에서는 Fastly NG-WAF의 특징 및 아키텍처, 도입 방법에 대해서 소개해 드리도록 하겠습니다.

 

Fastly NG-WAF의 특징

Fastly NG-WAF는 이하와 같은 특징을 가지고 있습니다.

 

• CDN이나 클라우드 환경에 얽매이지 않은 풍부한 도입 옵션
• 독자적인 공격에 대한 감지 방식을 도입하여 오탐율이 현저히 낮으므로 거의 WAF 튜닝이 불필요하기 때문에
  빠르고 손쉽게 WAF를 도입하는 것이 가능함
• 다루기 쉬운 직관적인 관리기능을 가지고 있는 대쉬보드 기능을 제공함 

위와 같은 특징으로 인하여 종래의 WAF의 과제였던 복수 환경에서 운영되고 있는 시스템의 보호나 도입 후의 WAF룰 튜닝을 위한 운영의 부담에 걸리는 문제를 해결한 솔루션이라고 소개드릴 수 있습니다.

 

이에 더하여 여러가지 OWASP TOP10의 해당하는 SQLi나 XSS와 같은 공격 뿐만 아니라, Custom Rule 이나 고도의 Rate Limit 기능을 사용하는 것으로 Account TakeOver나 Bot으로 인한 과다한 액세스등에도 대응하는 것이 가능합니다.

 

아키텍처

Fastly NG-WAF는 도입 방식에 따르지만 주로 아래 3개의 컴퍼넌트로 구성됩니다.

• Module
• Agent
• Cloud Engine

 

Module

Module은 웹 서버나 애플리케이션에 Plug-in 으로써 인스톨 합니다. 클라이언트로부터 리퀘스트를 받고, Agent쪽으로 정보를 전송 합니다.

 

Agent

Agent는 애플리케이션 실행 환경에 인스톨합니다. Module로 부터 전송받은 Request를 확인하고, Block / Allow / Signal을 부여하는등 판단을 실행하여, 그 결과를 Module로 반환 합니다.

 

Agent에는 하나 더 추가적인 역할이 있습니다. 나중에 이야기드릴 Cloud Engine과 약 30초 마다 비동기로 통신을 실행하여, Request를 처리한 결과의 데이터를 송신합니다. 또한 Cloud Engine쪽에서 보내어지는 새로운 Rule등에 대한 정보도 받습니다.

 

Cloud Engine

Cloud Engine은 Agent로 부터 보내어진 데이터나 공격에 대한 정보를 확인하여 Agent에 룰의 추가나 설정 변경등을 실행합니다. Cloud Engine에는 Web UI또는 API를 토해서 액세스 합니다.

복수의 서로 다른 로케이션의 Agent로 부터 보내진 정보를 수집, 전송하는 것으로 분산된 애플리케이션 환경에 대해서도 각 Agent에 공통의 정보를 제공합니다. 더욱이 Slack이나 Datadog등 과 같은 외부 툴과의 연계 설정도 하는 것이 가능합니다.

 

이 아키텍처에 따른 포인트로써는 아래와 같은 항목들이 있습니다.

 

• 신속한 처리
  공격의 감지나 Block등의 판단은 애플리케이션 환경에 인스톨 되어 있는 Agent가 실행합니다. 처리는 로컬환경에서 완결되기 때문에 추가되는 레이턴시를 통상적으로 1 - 2ms 정도로 최소한으로 유지하는 것이 가능합니다. 
  
  
• Failover 
  Module이 Agent로 부터 지정된 시간내에 응답을 못 받았을 시에는 감지 활동을 중단하고 리퀘스트 처리가 계속 됩니다. 타임아웃값에 대해서는 변경이 가능합니다만, 디펄트 값으로는 100ms 입니다.
  
  
• 단일 관리 콘솔
  전체의 Agent는 단일한 Cloud Engine으로 관리 됩니다. 그렇기 때문에 복수의 애플리케이션이나 복수의 클라우드 혹은 서로 다른 로케이션에 전개되어 있는 애플리케이션도 단일한 WebUI에서 통합해서 관리하는 것이 가능합니다.

도입 옵션

이어서 Fastly NG-WAF의 도입 옵션에 대해서 소개드리도록 하겠습니다. 대표적인 도입옵션으로는 아래와 같은 방법이 있습니다.

 

• Module-Agent 인스톨
• Cloud WAF
• Edge Deployment

Module-Agent 인스톨 

 

가장 일반적이고 추천되는 도입 옵션 입니다. Module-Agent를 애플리케이션이 설치 되어 있는 환경에 인스톨 합니다.

Nginx, Apache, IIS등의 Web서버 및 Java등의 프로그램 언어용의 Module이나 Kubernates등의 컨테이너환경에 인스톨하는 옵션등 여러가지 인스톨 옵션이 준비되어 있습니다.

인스톨 하는 순서 및 이용 가능한 옵션은 아래의 페이지를 참고해 주시길 바랍니다.

 

https://docs.fastly.com/en/ngwaf/about-deploying-the-next-gen-waf#module-agent-installation-process

About deploying the Next-Gen WAF

 

 

Reverse Proxy Mode

Web서버나 애플리케이션 환경에 Module을 인스톨 하는 것이 어려운 경우, Agent를 Reverse Proxy mode로 실행할 수 있습니다. 이 경우에 Module을 인스톨 할 필요가 없습니다. Request는 Agent를 경유해서 Web/애플리케이션 서버에 도착합니다. Origin환경에 인스톨 해야 하는 옵션이기 때문에 Core형태의 도입 방법중의 하나라고 말씀드릴 수 있습니다.

https://docs.fastly.com/en/ngwaf/configuring-agent-reverse-proxy-deployments

Configuring agent reverse proxy deployments

 

Edge Deployment

패스틀리의 Edge Cloud Platform 상에 NG-WAF를 실행합니다. 이 도입옵션을 사용하기 위해서는 패스틀리의 CDN을 이용하는 것이 전제가 되어야 합니다만, Origin환경에 Agent등의 인스톨이 필요하지 않습니다.

 

독자적인 공격 감지 메커니즘

SmartParse

Fastly NG-WAF에서는  SmartParse라고 불리는 독자적인 메커니즘으로 공격의 가능성이 있는 Request를 감지 합니다.

정규표현식의 패턴 매칭의 방법에 의존하는 기존의 WAF에서는 오탐지나 정상적인 트래픽을 Block하는 것을 방지하기 위한 장기적인 룰의 튜닝이 필요합니다.

 

SmartParse에서는 각 Request의 Context(맥락) 와 실행 방법을 평가하여, Request에 악질 혹은 이상한 Payload가 없는지를 판단합니다. SmartParse에 의해서, 룰의 튜닝이 거의 필요 없게 되어서, 구현 후에 거의 바로 위협에 대한 감지를 시작 할 수 있습니다.

 

SQLi나 XSS에 의한 Injection 공격에서는, 신뢰할 수 없는 Data가 Command 및 Query의 일부로서 인터프리터에 송신 됩니다.  SmartParse는 리퀘스트 파라메터를 분석해서 코드가 실제로 실행 가능한거를 판단 후, 그 결과를 토큰화 합니다. 토큰화된 리퀘스트의 표현은 실행시에 분석되서 SQLi나 XSS를 비롯한 OWASP Top 10의 Injection 공격을 포함한 공격을 감지 합니다. 그 방법은 Signature 베이스의 감지 어프로치에 비교해서도 오탐지의 비율이 현저히 낮고, 훨씬 더 빠릅니다.

 

SmartParse 감지 방법

  

정규표현식에 의존해 오탐지가 많아서 Block mode로 이용되는 것이 적은 기존의 WAF에 비해서, Fastly NG-WAF에서는 90%이상의 유저가 Block mode로 이용하고 있습니다.

 

Custom Rule

Fastly NG-WAF에서는 SQLi나 XSS와 같은 OWASP Top 10 공격의 감지나 Block 뿐만 아니라, Custom Rule을 작성해서 그 밖의 공격을 감지 하는 것이 가능합니다. Rule을 사용해서 Web 애플리케이션이나 비지니스 로직의 고유의 임계값을, Rate제한, 자동 Block, Alert Trigger를 NG-WAF 콘솔에서 설정하는 것이 가능합니다.

 

또한, Rule에 취약점 패치를 적용해서, 애플리케이션과 동일한 권한으로 실행되는 라이브러리, Flamework, 그 밖의 소프트웨어 모듈등, 구식으로 되어버린 컨포넌트나 위험에 처한 컴포넨트에 대처하는 것도 가능합니다. 각각의 사이트의 Rule(Site Rule) 뿐만 아니라, 복수의 사이트에 횡단적으로 이용 가능한 Global Rule(Corp Rule)도 작성하는 것이 가능합니다.

 

 

Block의 조건

Fastly NG-WAf는 정규표현에 매칭하는 수신 리퀘스트를 즉석에서 차단하는 기존의 어프로치가 아닌 SmartParse로 감지, 시간 베이스의 임계값, 리퀘스트와 레스폰스에 대한 이상감지 데이를 조합한 정보에 기반하여 블록할지를 판단합니다.

 

구체적으로는 특정 IP로부터 일정 기간내에 임계치를 넘는 공격이 감지되면 그 IP는 일정기간(디펄트는 24시간) 블록의 대상이 됩니다. 그 IP가 블록이 되는 대상이 되는 것을 Flag되었다고 이야기 합니다.

 

그리고, 리퀘스트가 블록 되는 것은 Flag된 IP로 부터의 리퀘스트에 공격 시그널이 감지 되었을 때 뿐입니다.

Flag되어 있는 IP라도 공격 시그널이 감지 되지 않은 리퀘스트는 블록되지 않고 정상적으로 처리가 계속 됩니다.

이것은  특정 IP의 배후에 복수의 유저가 존재하고, 한명의 악의를 품은 유저의 행동으로 다른 유저가 서비스를 이용 못하게 하는 것을 방지하기 위한 것입니다.

 

또는 수신된 리퀘스트에 공격 시그널이 포함되어 있는 경우, 프라이버시한 정보를 제외한  리퀘스트 정보가 Cloud Engine에 송신 됩니다.

 

Cloud Engine는 독자의 Network Learning Exchange(NLX) 를 통해서, 그 밖의 고객의 Agent를 포함해서 디플로이된 전체의 Agent로 부터 공격 데이터를 수집하고 있습니다.

 

Customize가능한 임계값을 기반으로 잠재적인 공격자로 부터의 충분한 악의적인 행위가 확인되면, 그 유저에 Block Flag를 세웁니다. 이 방법으로 인해 높은 정확도로 감지가 가능하게 되어 여러가지 공격에 대해서 보다 넓게 Context가 제공 됩니다.

 

끝으로 

길은 글 끝까지 읽어 주셔서 감사합니다. 다음에는 보다 자세한 여러 공격 상황에 대처라는 NG-WAF의 설정 방법에 대해서 포스팅하도록 하겠습니다.