WAF(웹 어플리케이션 방화벽)를 사용하지 마세요

• WAF 사용에 반대하는 사람이 많지 않아서 이 글을 씀. WAF에 대한 검색 결과들은 대부분 WAF 공급업체에서 작성된 것
• WAF는 인터넷 초기에 만들어졌고, 모든 HTTP 요청을 가로채고 수백 개의 정규 표현식을 평가하여 SQL, 쉘 코드 등과 유사한 요청을 차단함
• 사이버 보안 초기에는 WAF가 좋은 아이디어 처럼 보였지만, 오늘날 WAF는 그렇지 않음
• WAF의 성능 문제, 우회 가능성, 공격 벡터로서의 위험성, 높은 오진율 등으로 인해 현재는 더 나은 보안 기술이 존재함

WAF의 성능은 끔찍함

• WAF는 모든 요청에 대해 수백 개의 정규 표현식을 실행하여 성능 저하가 발생함
• WAF 사용 시 상당한 야의 추가 RAM이 필요하고 평균 업로드 시간, 요청 처리 속도, CPU 사용률이 높아지고, 오류성 차단도 발생

WAF는 쉽게 우회됨

• WAF와 공격자 간의 끊임없는 경쟁 속에서 공격자가 우위를 점함
• 복잡한 문법과 인코딩 기법을 사용하여 WAF 규칙을 우회하는 것이 가능
• 예를 들어, Log4shell 공격은 간단한 문자열 검사로 차단할 수 없으며, 공격자는 다양한 우회 기법을 사용할 수 있음(Log4J Lookup)
• 또한 공격 문자열에 8KB 정도의 쓸데없지만 무해한 문자를 채우면 WAF가 계속 램에 버퍼링 할 수 없어서 컷오프 되므로 쓸모 없어짐

WAF는 공격 벡터임

• 2019년에 CapitalOne은 WAF 구성 오류로 인해 1억 건의 신용 신청이 유출되는 사건이 발생
  • 공격자는 WAF를 속여 EC2 메타데이터 서비스에 요청을 보내 S3에서 민감한 파일을 읽을 수 있는 자격 증명을 전달한 것으로 알려짐
• 즉, WAF의 잘못된 구성으로 인한 보안 사고 발생 가능성이 있음
• 대부분의 WAF는 복잡하고 종종 폐쇄 소스로 작성되어 공격 표면이 넓어짐
  • 값비싼 "기업용" 제품이기 때문에 회사에서는 경쟁사보다 더 눈에 띄도록 불필요한 기능을 가득 채워 넣음
• 보안 제품에 대한 기본적인 보안 원칙이 종종 무시됨

WAF의 높은 오탐률

• 지난 20년 동안 오픈소스 WAF 규칙 세트는 최신 유형의 공격을 탐지하기 위해 상당히 확장됨. 독점 WAF 들도 동일한 작업을 수행하고 있을 것
• 이는 WAF를 실행하여 요청을 차단할 수 있는 문자열이 점점 더 많아지고 있음을 의미
• 이렇게 새로운 규칙이 나올때 마다 WAF 규칙 확장으로 오탐률 증가
• "차세대" WAF는 여러 요청을 확인하거나 IP 평판 시스템을 사용하여 이 문제를 해결한다고 주장
  • 위양성률(false positive rates)을 높일 수는 있겠지만, 오탐 문제를 완전히 해결할 수 없음
• 오탐으로 인해 사용자와 지원 팀이 명확한 해결 절차를 갖지 못할 수 있음

WAF의 대안

• 격리(Isolation): 시스템의 한 부분이 침해되어도 다른 부분에 영향을 미치지 않도록 하는 기술
  • 브라우저는 쿠키, 저장된 비밀번호, 기타 탭 등에 대한 임의 접근 권한이 없는 특수 샌드박스 프로세스 내에서 모든 코드를 실행하여 이를 수행
  • 마이크로서비스는 격리를 염두에 두고 설계되었지만 다양한 라이브러리와 언어를 사용하여 단일체로 수행할 수도 있음
• 불변성(Immutability): 읽기 전용 파일 시스템, 재부팅이 필요한 패키지 관리자, 추가만 가능한 백업 등을 통해 공격 범주 제거
• 정적 분석(Static Analysis): SQL 인젝션을 방지하기 위한 준비된 문장(prepared statements) 사용과 CI 파이프라인에서의 정적 분석을 통한 코드 검사
• 능력 기반 보안(Capability-based Security): 모든 API 엔드포인트가 데이터베이스와 파일 시스템에 무제한 접근 권한을 가질 필요가 없으며, 필요한 권한만 부여하는 방식을 도입

 

https://www.macchaffee.com/blog/2023/wafs/

Stop deploying web application firewalls