애플리케이션에서 막을 수 없는 공격

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

다양한 HTTP 기반 공격은 애플리케이션에서 방지할 수 있으며, 반드시 방지해야 합니다. OWASP Top 10은 모든 애플리케이션 내부에서 탐지하고 방지할 수 있는 공격 기법의 대표적인 예입니다. 정적·동적 분석과 침투 테스트를 비롯한 다양한 도구를 활용하면 이러한 취약점이 프로덕션 환경까지 넘어가지 않도록 막을 수 있습니다. 물론 이를 위해서는 이러한 보안 테스트를 CI/CD 프로세스의 초기 단계로 전환해야 하며 사용자가 접근할 수 있도록 스위치(정확히는 비트)를 켜기 직전의 마지막 단계로 미뤄서는 안 됩니다.

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

물론 제가 말하는 것은 애플리케이션 계층(HTTP) DDoS 공격입니다. 아시다시피 HTTP 프로토콜 자체를 악용해 애플리케이션에서 사용 가능한 컴퓨팅 자원과 메모리를 모조리 빨아들임으로써 정상적인 사용자가 이용할 수 없게 만드는 흡혈귀 같은 공격이죠.

HTTP DDoS 공격은 기본적으로 두 가지 유형으로 나뉩니다. 빠른 공격과 느린 공격, 즉 플러드 공격과 자원 고갈 공격입니다.

플러드 공격

플러딩 기반 HTTP DDoS 공격은 애플리케이션이 HTTP 요청을 받아 응답하도록 설계되어 있다는 점을 악용합니다. 그게 애플리케이션의 본래 역할이니까요. 따라서 애플리케이션은 요청에 응답합니다. 요청이 아무리 빠른 속도로 들어와도 마찬가지입니다. 서버에서 사용할 수 있는 리소스가 몇 분, 심지어 몇 초 만에 고갈될 정도로 요청이 몰려와도 응답을 시도합니다. 모든 애플리케이션(사실상 모든 장치, 서비스, 시스템 등)에는 동시에 열어 둘 수 있는 TCP 연결 수에 상한이 있으며, 이 한도에 도달하면 더 이상 새 연결을 열 수 없습니다. 상한에 도달한 이후의 요청은 모두 무시됩니다. 사용자는 브라우저나 앱이 시스템에서 지정한 대기 시간이 끝날 때까지 기다린 뒤 연결할 수 없다는 메시지를 표시하는 동안, 별문제 없어 보이는 “연결 시도 중…” 상태를 보게 됩니다.

이러한 유형의 공격은 매우 빠르게 밀려올 수 있어(그래서 ‘돌발 홍수’에 비유합니다) 수요에 맞춰 시스템을 확장할 수 있는 능력을 넘어섭니다. 이 경우에는 자동 확장조차 도움이 되지 않습니다. 앱의 새 인스턴스를 프로비저닝하고 실행하는 데 걸리는 시간보다 공격이 기존 인스턴스의 모든 리소스를 고갈시키는 데 걸리는 시간이 더 짧기 때문입니다.

드레인 공격

반대로 드레이닝 공격은 동일한 목적을 달성하지만, 앱이 필요 이상으로 오랫동안 연결을 유지하도록 강제하는 방식을 사용합니다. 실제로 수신할 수 있는 속도보다 훨씬 느리게, 마치 전화 접속을 사용하는 것처럼 앱에서 초당 극소량의 데이터만 받아 갑니다. 이렇게 하면 연결이 더 오래 지속되며, 충분히 많은 연결에 이 방식을 적용하면 결국 플러딩 공격과 사실상 동일한 상황, 즉 리소스 고갈에 이르게 됩니다.

이 두 공격은 모두 애플리케이션 내부에서는 탐지할 수 없습니다. 애초에 어떻게 탐지할 수 있겠습니까? 애플리케이션의 관점에서 이러한 요청은 모두 정상적입니다. 모두 올바른 형식을 갖춘 HTTP 기반 데이터 요청이며, 애플리케이션이 하루에도 수천 번씩 응답하는 요청일 가능성이 높습니다. HTTP 헤더나 페이로드 어디에도 해당 요청의 악의적인 성격을 나타내는 표시는 없습니다. 애플리케이션은 네트워크나 더 광범위한 환경, 특히 열려 있는 모든 연결의 전체 목록을 관리하는 서버의 세션 테이블을 들여다볼 수 없기 때문에 이러한 요청에 숨겨진 악의적인 의도를 전혀 알아차리지 못합니다. 스레드, 프로세스, 멀티스레드 환경에서의 데이터 변동성에 관한 기술적인 세부 사항과 장황한 설명은 생략하고, 단지 “다른 요청의 처리 과정을 볼 수 없다”는 점만 짚고 넘어가겠습니다.

요컨대 애플리케이션 자체로는 특정 요청이 더 큰 규모의 공격(플러딩)의 일부인지, 또는 해당 요청의 동작이 알려진 기능 범위를 벗어나는지(드레이닝)를 판단할 방법이 없습니다.

프록시가 해결사로 나서다

이 두 가지를 모두 파악할 수 있는 것은 애플리케이션의 업스트림(앞단)에 위치한 프록시입니다. 프록시는 아마도 부하 분산을 수행하고 있을 것이므로, 현재 처리 중인 요청 수와 새로 들어오는 요청 수를 모두 주시해야 합니다. 이러한 요청을 클러스터(원한다면 풀이라고 해도 됩니다) 내 애플리케이션 중 하나로 보내야 하기 때문입니다.

또한 응답을 어디로 보내야 하는지 알아야 하므로 클라이언트와 해당 네트워크 연결에 대한 정보도 알고 있습니다(일반적으로 앱에 전달되는 정보는 클라이언트 IP 주소뿐이며, 그 외에는 아무것도 전달되지 않습니다). 애플리케이션과 달리, 프록시는 플러딩 공격과 드레이닝 공격을 모두 탐지하는 데 필요한 가시성을 갖추고 있으며, 이러한 공격이 앱의 리소스에 흡혈귀처럼 이빨을 박기 전에 차단할 수 있습니다.

그렇기 때문에 WAF(웹 애플리케이션 방화벽)나 고급 로드 밸런서와 같은 프록시 기반 서비스는 오늘날의 애플리케이션 보안 전략에서 핵심적인 역할을 합니다. 이러한 서비스는 공격의 징후인 비정상적인 동작을 탐지할 수 있는 가시성과 수단을 갖추고 있으며, 마늘로 흡혈귀를 물리치듯 공격을 격퇴할 수 있기 때문입니다.

그리고 전통적으로 ‘네트워크’ 서비스로 여겨지던 이러한 서비스는 필연적으로 애플리케이션 아키텍처의 일부가 되어야 하므로, DevOps 접근 방식이 그 범위를 넓혀 애초부터 자연스럽게 애플리케이션과 밀접하게 연계되는 서비스까지 포괄하는 것이 합리적으로 보입니다. 여기에는 애플리케이션 보안과 확장성(부하 분산) 등이 포함됩니다.

애플리케이션만으로는 모든 공격을 막을 수 없습니다. 특히 애플리케이션 자체로는 확보할 수 없는 수준의 가시성이 필요한 공격은 더욱 그렇습니다. 하지만 웹 애플리케이션 보안 및 부하 분산처럼 애플리케이션과 밀접한 서비스와 연계하면 더 광범위한 공격을 탐지하고 차단하여 서비스 중단과 보안 침해를 줄일 수 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물