애플리케이션에서 멈출 수 없는 공격

다양한 HTTP 기반 공격은 애플리케이션에서 예방할 수 있습니다(예방해야 합니다). OWASP Top 10은 모든 애플리케이션에서 탐지하고 예방할 수 있는 공격 기술의 대표적인 예입니다. 정적 및 동적 분석과 침투 테스트를 비롯한 다양한 도구를 사용하면 이러한 취약점이 프로덕션에 진입하지 못하도록 할 수 있습니다. 물론, 이러한 보안 테스트는 사용자가 접근할 수 있는 스위치(또는 비트)를 뒤집기 전 마지막 단계로 남겨두는 것이 아니라 CI/CD 프로세스의 왼쪽으로 옮겨져야 합니다 . 

개발에서 발견된 모든 잠재적 취약점을 제거했더라도 애플리케이션은 여전히 위험에 노출되어 있습니다. 그 이유는 일부 공격은 애플리케이션에서 감지할 수 없기 때문입니다. (실제로 감지할 수 없다는 말은 전혀 불가능하다는 뜻입니다.) 실제로 공격이 애플리케이션에 도달할 때는 이미 너무 늦었습니다.

물론 제가 말하는 것은 애플리케이션 계층(HTTP) DDoS 공격에 대한 것입니다. 아시다시피, HTTP 프로토콜 자체를 악용하여 애플리케이션의 모든 컴퓨팅 및 메모리를 빨아들여 합법적인 사용자가 사용할 수 없도록 만드는 흡혈귀 같은 놈들이죠.

HTTP DDOS 공격에는 기본적으로 빠른 공격과 느린 공격, 플러드 공격과 드레인 공격의 두 가지 유형이 있습니다.

홍수 공격

플러딩을 기반으로 한 HTTP DDoS 공격은 앱이 HTTP 요청을 수락하고 이에 응답해야 한다는 사실을 이용합니다. 그게 그들의 짓이잖아요, 그렇죠? 그렇죠. 그리고 그 요청이 얼마나 빨리 들어오는지에 관계없이 그렇게 합니다. 몇 분 또는 몇 초 만에 해당 서버의 리소스가 고갈될 만큼 빠른 속도로 요청이 들어오더라도 서버는 응답을 시도합니다. 모든 앱(사실 모든 기기, 서비스, 시스템 등)에는 더 이상 열 수 없게 되기 전까지 언제든지 열어 둘 수 있는 TCP 연결 수에 상한이 있습니다. 상한값에 도달하면 이후의 모든 요청은 무시됩니다. 사용자는 브라우저나 앱이 시스템에서 지정한 대기 시간이 지날 때까지 기다린 다음, 연결할 수 없어서 사과하는 "연결 시도 중..."이라는 무해한 상태를 경험합니다.

이런 종류의 공격은 너무 빨리 발생할 수 있으므로(따라서 "플래시 플러드"라는 비유가 있습니다) 수요를 충족시키기 위해 확장할 수 있는 시스템의 능력을 능가합니다. 이런 시나리오에서는 자동 크기 조정조차 도움이 되지 않습니다. 앱의 새 인스턴스를 프로비저닝하고 시작하는 데 걸리는 시간이 공격을 통해 기존 인스턴스의 모든 리소스를 제거하는 데 걸리는 시간보다 길기 때문입니다.

드레인 공격

반대인 배수 공격은 동일한 작업을 수행하지만 앱이 필요 이상으로 오랫동안 연결을 열어 두도록 강제합니다. 이 기능은 다이얼업을 사용하는 척하여 앱에서 실제로 수신할 수 있는 속도가 아닌 초당 몇 방울의 데이터를 전송합니다. 이렇게 하면 연결이 더 오래 지속되고, 충분한 연결로 이를 수행하면 기본적으로 플러딩 공격과 동일한 상황, 즉 리소스 고갈에 직면하게 됩니다.

이러한 공격은 애플리케이션 내부에서는 감지할 수 없습니다. 왜 그럴까요? 해당 애플리케이션에서 이러한 요청은 모두 합법적인 요청입니다. 모두 잘 구성된 HTTP 기반 데이터 요청이며, 하루에 수천 번 정도 답변할 가능성이 높습니다. HTTP 헤더나 페이로드에는 요청의 불법적 성격을 나타내는 플래그가 없습니다. 이 애플리케이션은 네트워크나 더 광범위한 환경(특히 모든 열려 있는 연결의 마스터 목록을 유지 관리하는 서버의 세션 테이블)에 대한 가시성이 없기 때문에 이러한 요청 뒤에 있는 악의적인 의도를 전혀 알지 못합니다. 저는 멀티스레드 환경에서 스레드, 프로세스, 데이터의 변동성에 대한 기술적 세부 사항과 강의를 생략하고 "다른 요청의 처리에 대한 가시성 없음"에 대해서만 말씀드리겠습니다.

말할 것도 없이, 애플리케이션 자체에서는 주어진 요청이 더 큰 공격(플러딩)의 일부인지 아닌지, 또는 해당 요청의 동작이 알려진 기능과 일치하지 않는지(드레이닝) 확인할 방법이 없습니다.

구조의 대리인

두 가지 모두에 가시성을 제공 하는 것은 애플리케이션의 업스트림(앞)에 있는 프록시입니다. 프록시는 부하 분산을 수행하고 있을 가능성이 높기 때문에 현재 처리 중인 요청 수와 클러스터(또는 원하는 경우 풀)에 있는 앱 중 하나로 요청을 보내야 하기 때문에 들어오는 요청 수에 주의를 기울여야 하기 때문입니다.

또한 응답을 어디로 보내야 하는지 알아야 하므로 클라이언트와 해당 네트워크 연결에 대한 정보를 알아야 합니다( 일반적으로 앱으로 전송되는 정보는 클라이언트 IP 주소뿐이며, 그 이상은 없습니다 ). 애플리케이션과는 달리, 플러딩과 드레인 공격을 모두 감지하고 앱의 리소스를 흡혈하기 전에 막을 수 있는 가시성을 갖추고 있습니다.

그렇기 때문에 WAF(웹 애플리케이션 방화벽) 또는 고급 로드 밸런서와 같은 프록시 기반 서비스가 오늘날의 애플리케이션 보안 전략에서 중요한 역할을 하는 것입니다. 이들은 공격을 나타내는 비정상적인 행동을 감지할 수 있는 가시성과 수단을 갖추고 있으며, 마늘과 뱀파이어처럼 이를 격퇴할 수 있기 때문입니다.

그리고 이러한 전통적인 "네트워크" 서비스가 필연적으로 애플리케이션 아키텍처의 일부가 되어야 하기 때문에 DevOps 접근 방식이 범위를 넓히고 원래 애플리케이션에 자연스럽게 끌리는 서비스(예: 앱 보안 및 확장성(로드 밸런싱))를 더 포함하는 것이 논리적입니다.

애플리케이션은 모든 공격을 막을 수 없으며, 특히 애플리케이션에서 사용할 수 없는 수준의 가시성이 필요한 공격의 경우 더욱 그렇습니다. 그러나 웹 앱 보안 및 로드 밸런싱과 같은 애플리케이션 관련 서비스와 함께 작동하면 보다 포괄적인 공격을 감지하고 격퇴하여 중단 및 침해를 줄일 수 있는 수단을 제공할 수 있습니다.