▲

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

 (macchaffee.com)
21P by xguru 6달전 | favorite | 댓글 5개
  • 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 엔드포인트가 데이터베이스와 파일 시스템에 무제한 접근 권한을 가질 필요가 없으며, 필요한 권한만 부여하는 방식을 도입
▲
devpain 6달전  [-]

nginx + naxsi 조합이면, 위의 몇가지에 해당사항은 없을것 같네요.
waf 룰셋을 서비스 개발자가 하는 방식으로 가져가야함.
보안전문가는 서비스에 대한 이해없이 보편적 설정을 하게 됨으로써, 높은 오탐률을 발생시키고, 요청에 따라 룰셋을 하나씩 삭제함으로써, WAF의 원래 기능을 상실하게 됨

답변달기
▲
nosookja 6달전  [-]

bypass나 오탐 부분에 대해서는 일부 동의하나 전반적으로 확실하지 않은 정보를 팩트마냥 나열되어 있는 느낌이 강합니다. 시간나면 원문내용도 봐야겠네요. 특히 CapitalOne 사례를 WAF의 문제로 집은 것은 원글 작성자가 WAF에 대한 이해도가 많이 부족한 것으로 보이네요. WAF는 취약점을 근본적으로 Mitigation 해주는 솔루션이 아닙니다. 코드에서 발생한 취약점은 코드에서 해결해야 하는 것이 올바른 해결이죠. 하지만 현실은 이렇지 못하기에 의심스러운 또는 악의적인 인풋을 앞단에서 검사할 적절한 무언가가 필요한겁니다. 이를 잘 운영하면 정말 좋은 칼이 되는거고 잘 운영하지 못하면 나를 다치게하는 칼이 되는법이죠. 도구의 양면성은 언제나 있는 면이지만 너무 안좋은 면만 부각시키는 주제 같네요.

답변달기
▲
xguru 6달전  [-]

해커뉴스 댓글에는 이에 대한 다양한 의견 및 반론들이 있습니다. 같이 참고하세요
https://news.ycombinator.com/item?id=38255004

답변달기
▲
composite 6달전  [-]

These “stop using X” articles are really pointless (and boring). They also misguide the people who have less experience in a particular field.
이러한 "X 사용을 중단하라"는 기사는 정말 무의미하고 지루합니다. 또한 특정 분야에 대한 경험이 적은 사람들에게 잘못된 정보를 제공하기도 합니다.

답변달기