구조를 위한 DDoS: 스트레스 및 부하 테스트를 수행하는 방법

Variti는 봇 및 DDoS 공격에 대한 보호 기능을 개발하고 스트레스 및 로드 테스트도 수행합니다. HighLoad++ 2018 컨퍼런스에서 우리는 다양한 유형의 공격으로부터 리소스를 보호하는 방법에 대해 이야기했습니다. 즉, 시스템의 일부를 격리하고, 클라우드 서비스와 CDN을 사용하고, 정기적으로 업데이트합니다. 하지만 전문업체 없이는 여전히 보호를 감당할 수 없습니다 :)

텍스트를 읽기 전에 짧은 초록을 읽을 수 있습니다. 컨퍼런스 웹사이트에서.
읽기를 좋아하지 않거나 단지 비디오를 보고 싶다면 스포일러 아래에 우리 보고서의 녹화본이 있습니다.

보고서의 비디오 녹화

많은 회사가 이미 부하 테스트를 수행하는 방법을 알고 있지만 모든 회사가 스트레스 테스트를 수행하는 것은 아닙니다. 일부 고객은 자신의 사이트가 고부하 시스템을 갖추고 있고 공격으로부터 잘 보호되기 때문에 무적이라고 생각합니다. 우리는 이것이 전적으로 사실이 아님을 보여줍니다.
물론 테스트를 수행하기 전에 고객으로부터 허가를 받고 서명 및 도장을 찍으며, 우리의 도움으로 누구에게도 DDoS 공격이 수행될 수 없습니다. 테스트는 리소스에 대한 트래픽이 최소화되고 액세스 문제가 클라이언트에 영향을 미치지 않을 때 고객이 선택한 시간에 수행됩니다. 또한 테스트 과정에서 항상 문제가 발생할 수 있으므로 고객과 지속적으로 연락하고 있습니다. 이를 통해 달성된 결과를 보고할 수 있을 뿐만 아니라 테스트 중에 내용을 변경할 수도 있습니다. 테스트가 완료되면 항상 발견된 단점을 지적하고 사이트의 약점을 제거하기 위한 권장 사항을 제공하는 보고서를 작성합니다.

우리가 일하는 방법

테스트할 때 봇넷을 에뮬레이트합니다. 우리는 네트워크에 없는 클라이언트와 작업하기 때문에 제한이나 보호 트리거로 인해 테스트가 첫 XNUMX분 내에 종료되지 않도록 하기 위해 하나의 IP가 아닌 자체 서브넷에서 로드를 공급합니다. 또한 상당한 부하를 생성하기 위해 상당히 강력한 자체 테스트 서버를 보유하고 있습니다.

가정하다

너무 많다고 좋은 것은 아니다
리소스에 장애를 가져올 수 있는 로드가 적을수록 좋습니다. 초당 하나의 요청 또는 분당 하나의 요청으로 사이트 작동을 중지할 수 있다면 정말 좋습니다. 왜냐하면 비열함의 법칙에 따라 사용자나 공격자가 우연히 이 특정 취약점에 빠지게 되기 때문입니다.

부분적인 실패가 완전한 실패보다 낫다
우리는 항상 시스템을 이기종으로 만드는 것을 권장합니다. 게다가 컨테이너화뿐만 아니라 물리적 수준에서도 분리하는 것이 좋습니다. 물리적으로 분리된 경우, 사이트에 문제가 발생하더라도 작동이 완전히 중단되지 않을 가능성이 높으며 사용자는 최소한 일부 기능에 계속 액세스할 수 있습니다.

좋은 아키텍처는 지속 가능성의 기초입니다
리소스의 내결함성과 공격 및 로드를 견딜 수 있는 능력은 설계 단계, 즉 노트북의 첫 번째 순서도를 그리는 단계에서 설정되어야 합니다. 치명적인 오류가 발생하면 나중에 수정하는 것이 가능하지만 매우 어렵기 때문입니다.

코드도 좋아야 하지만, 설정도 좋아야 합니다.
많은 사람들은 좋은 개발팀이 내결함성 서비스를 보장한다고 생각합니다. 좋은 개발팀은 정말 필요하지만, 좋은 운영, 좋은 DevOps도 있어야 합니다. 즉, Linux와 네트워크를 올바르게 구성하고, nginx에서 구성을 올바르게 작성하고, 제한을 설정하는 등의 전문가가 필요합니다. 그렇지 않으면 리소스가 테스트에서만 잘 작동하고 어느 시점에서는 프로덕션에서 모든 것이 중단됩니다.

부하 테스트와 스트레스 테스트의 차이점
부하 테스트를 통해 시스템 기능의 한계를 식별할 수 있습니다. 스트레스 테스트는 시스템의 약점을 찾는 것을 목표로 하며 이 시스템을 파괴하고 특정 부품의 고장 과정에서 시스템이 어떻게 작동하는지 확인하는 데 사용됩니다. 이 경우 일반적으로 스트레스 테스트가 시작되기 전에 고객은 부하의 성격을 알 수 없습니다.

L7 공격의 특징

우리는 일반적으로 부하 유형을 L7 및 L3&4 수준의 부하로 나눕니다. L7은 애플리케이션 수준의 로드이며 대부분 HTTP만 의미하지만 TCP 프로토콜 수준의 모든 로드를 의미합니다.
L7 공격에는 특정한 특징이 있습니다. 첫째, 애플리케이션에 직접 제공됩니다. 즉, 네트워크 수단을 통해 반영될 가능성은 거의 없습니다. 이러한 공격은 논리를 사용하므로 CPU, 메모리, 디스크, 데이터베이스 및 기타 리소스를 매우 효율적으로 소모하고 트래픽도 거의 발생하지 않습니다.

HTTP 홍수

어떤 공격의 경우 부하를 처리하는 것보다 생성하는 것이 더 쉽고 L7의 경우에도 마찬가지입니다. 공격 트래픽과 합법적인 트래픽을 구별하는 것이 항상 쉬운 것은 아니며 대부분 빈도로 구분할 수 있지만 모든 것이 올바르게 계획된 경우 공격이 발생한 위치와 합법적인 요청이 있는 위치를 로그에서 이해하는 것은 불가능합니다.
첫 번째 예로 HTTP Flood 공격을 생각해 보세요. 그래프는 이러한 공격이 일반적으로 매우 강력하다는 것을 보여줍니다. 아래 예에서는 최대 요청 수가 분당 600만 건을 초과했습니다.

HTTP Flood는 로드를 생성하는 가장 쉬운 방법입니다. 일반적으로 ApacheBench와 같은 일종의 부하 테스트 도구를 사용하여 요청과 대상을 설정합니다. 이러한 간단한 접근 방식을 사용하면 서버 캐싱이 발생할 가능성이 높지만 이를 우회하는 것은 쉽습니다. 예를 들어, 요청에 임의의 문자열을 추가하면 서버가 지속적으로 새로운 페이지를 제공하게 됩니다.
또한 로드를 생성하는 과정에서 사용자 에이전트를 잊지 마세요. 널리 사용되는 테스트 도구의 많은 사용자 에이전트는 시스템 관리자에 의해 필터링되며, 이 경우 로드가 백엔드에 도달하지 못할 수도 있습니다. 브라우저의 어느 정도 유효한 헤더를 요청에 삽입하면 결과를 크게 향상시킬 수 있습니다.
HTTP Flood 공격은 단순하지만 단점도 있습니다. 첫째, 부하를 생성하려면 많은 양의 전력이 필요합니다. 둘째, 이러한 공격은 탐지하기가 매우 쉽습니다. 특히 단일 주소에서 발생하는 경우 더욱 그렇습니다. 결과적으로 요청은 시스템 관리자 또는 공급자 수준에서 즉시 필터링되기 시작합니다.

검색 할 내용

효율성을 잃지 않고 초당 요청 수를 줄이려면 약간의 상상력을 발휘하고 사이트를 탐색해야 합니다. 따라서 채널이나 서버뿐만 아니라 데이터베이스나 파일 시스템과 같은 애플리케이션의 개별 부분도 로드할 수 있습니다. 계산기, 제품 선택 페이지 등 대규모 계산을 수행하는 사이트를 찾을 수도 있습니다. 마지막으로, 사이트에 수십만 줄의 페이지를 생성하는 일종의 PHP 스크립트가 있는 경우가 종종 있습니다. 또한 이러한 스크립트는 서버에 상당한 부하를 가해 공격 대상이 될 수 있습니다.

볼 곳

테스트하기 전에 리소스를 스캔할 때는 물론 사이트 자체를 먼저 살펴봅니다. 우리는 모든 종류의 입력 필드, 무거운 파일(일반적으로 리소스에 문제를 일으키고 작업 속도를 저하시킬 수 있는 모든 것)을 찾고 있습니다. Google Chrome 및 Firefox의 진부한 개발 도구가 여기에 도움이 되어 페이지 응답 시간을 보여줍니다.
하위 도메인도 검사합니다. 예를 들어, abc.com이라는 특정 온라인 상점이 있고 여기에는 admin.abc.com이라는 하위 도메인이 있습니다. 아마도 이는 권한이 있는 관리 패널일 가능성이 높지만 여기에 부하를 가하면 기본 리소스에 문제가 발생할 수 있습니다.
사이트에는 하위 도메인 api.abc.com이 있을 수 있습니다. 아마도 이것은 모바일 애플리케이션을 위한 리소스일 것입니다. 애플리케이션은 App Store 또는 Google Play에서 찾을 수 있으며, 특수 액세스 포인트를 설치하고, API를 분석하고, 테스트 계정을 등록할 수 있습니다. 문제는 사람들이 인증을 통해 보호되는 모든 것은 서비스 거부 공격으로부터 안전하다고 생각하는 경우가 많다는 것입니다. 아마도 인증은 최고의 CAPTCHA이지만 그렇지 않습니다. 10~20개의 테스트 계정을 만드는 것은 쉽지만 계정을 생성함으로써 복잡하고 위장되지 않은 기능에 액세스할 수 있습니다.
당연히 우리는 robots.txt와 WebArchive, ViewDNS에서 기록을 살펴보고 이전 버전의 리소스를 찾습니다. 때때로 개발자가 mail2.yandex.net을 출시했지만 이전 버전인 mail.yandex.net이 남아 있는 경우가 있습니다. 이 mail.yandex.net은 더 이상 지원되지 않으며 개발 리소스가 할당되지 않지만 데이터베이스를 계속 사용합니다. 따라서 이전 버전을 사용하면 백엔드의 리소스와 레이아웃 뒤에 있는 모든 것을 효과적으로 사용할 수 있습니다. 물론 항상 그런 것은 아니지만 우리는 여전히 이런 일을 꽤 자주 접합니다.
당연히 우리는 모든 요청 매개변수와 쿠키 구조를 분석합니다. 예를 들어 쿠키 내부의 JSON 배열에 일부 값을 덤프하고, 많은 중첩을 생성하고, 리소스가 비합리적으로 오랫동안 작동하도록 만들 수 있습니다.

검색 부하

사이트를 조사할 때 가장 먼저 생각나는 것은 데이터베이스를 로드하는 것입니다. 왜냐하면 거의 모든 사람이 검색을 하고 있고 불행히도 거의 모든 사람에게 데이터베이스가 제대로 보호되지 않기 때문입니다. 어떤 이유에서인지 개발자들은 검색에 충분히 주의를 기울이지 않습니다. 그러나 여기에는 한 가지 권장 사항이 있습니다. HTTP 플러드의 경우처럼 캐싱이 발생할 수 있으므로 동일한 유형의 요청을 수행해서는 안 됩니다.
데이터베이스에 대해 무작위 쿼리를 수행하는 것도 항상 효과적인 것은 아닙니다. 검색과 관련된 키워드 목록을 만드는 것이 훨씬 좋습니다. 온라인 상점의 예로 돌아가서, 사이트에서 자동차 타이어를 판매하고 타이어 반경, 자동차 유형 및 기타 매개변수를 설정할 수 있다고 가정해 보겠습니다. 따라서 관련 단어를 조합하면 데이터베이스가 훨씬 더 복잡한 조건에서 작동하게 됩니다.
또한 페이지 매김을 사용하는 것이 좋습니다. 검색에서 첫 번째 페이지보다 검색 결과의 두 번째 페이지를 반환하는 것이 훨씬 더 어렵습니다. 즉, 페이지 매김을 사용하면 로드를 약간 다양화할 수 있습니다.
아래 예는 검색 부하를 보여줍니다. 초당 XNUMX개의 요청 속도로 테스트한 첫 순간부터 사이트가 다운되어 응답하지 않는 것을 볼 수 있습니다.

검색이 없다면?

검색이 없다고 해서 사이트에 다른 취약한 입력 필드가 포함되어 있지 않다는 의미는 아닙니다. 이 필드는 인증일 수 있습니다. 요즘 개발자들은 레인보우 테이블 공격으로부터 로그인 데이터베이스를 보호하기 위해 복잡한 해시를 만드는 것을 좋아합니다. 이는 좋지만 이러한 해시는 많은 CPU 리소스를 소비합니다. 허위 인증이 대량으로 발생하면 프로세서 오류가 발생하고 결과적으로 사이트 작동이 중지됩니다.
댓글과 피드백을 위한 모든 종류의 양식이 사이트에 존재한다는 것은 매우 큰 텍스트를 그곳으로 보내거나 단순히 엄청난 홍수를 일으키는 이유입니다. 때때로 사이트에서는 gzip 형식을 포함한 첨부 파일을 허용합니다. 이 경우 1TB 파일을 가져와 gzip을 사용하여 수 바이트 또는 킬로바이트로 압축한 후 사이트로 보냅니다. 그런 다음 압축을 풀면 매우 흥미로운 효과가 나타납니다.

휴식 API

Rest API와 같은 인기 있는 서비스에 조금 주목하고 싶습니다. Rest API 보안은 일반 웹사이트보다 훨씬 어렵습니다. 비밀번호 무차별 대입 및 기타 불법 활동으로부터 보호하는 사소한 방법도 Rest API에서는 작동하지 않습니다.
Rest API는 데이터베이스에 직접 접근하기 때문에 깨지기 매우 쉽습니다. 동시에, 그러한 서비스의 실패는 비즈니스에 심각한 결과를 초래합니다. 사실 Rest API는 일반적으로 기본 웹사이트뿐만 아니라 모바일 애플리케이션 및 일부 내부 비즈니스 리소스에도 사용됩니다. 그리고 이 모든 것이 무너지면 단순한 웹사이트 장애의 경우보다 그 효과가 훨씬 더 강해집니다.

무거운 콘텐츠 로드 중

복잡한 기능이 없는 일반적인 단일 페이지 애플리케이션, 랜딩 페이지 또는 명함 웹사이트를 테스트하라는 제안을 받으면 우리는 무거운 콘텐츠를 찾습니다. 예를 들어 서버가 보내는 큰 이미지, 바이너리 파일, PDF 문서 등을 모두 다운로드하려고 합니다. 이러한 테스트는 파일 시스템을 잘 로드하고 채널을 방해하므로 효과적입니다. 즉, 서버를 다운시키지 않고 대용량 파일을 저속으로 다운로드하더라도 대상 서버의 채널만 막히게 되어 서비스 거부 현상이 발생하게 된다.
이러한 테스트의 예는 30RPS의 속도에서 사이트가 응답을 중지하거나 500번째 서버 오류를 생성했음을 보여줍니다.

서버 설정을 잊지 마세요. 어떤 사람이 가상 머신을 구입하고 거기에 Apache를 설치하고 기본적으로 모든 것을 구성하고 PHP 애플리케이션을 설치한 경우 아래에서 결과를 볼 수 있습니다.

여기서 로드는 루트로 이동하여 10RPS에 불과했습니다. 5분 정도 기다리니 서버가 다운되었습니다. 왜 넘어졌는지 완전히 알 수 없는 것은 사실이지만, 단순히 기억력이 너무 높아 반응을 멈췄을 뿐이라는 추측도 있다.

웨이브 기반

지난 30~40년 동안 웨이브 공격이 꽤 인기를 끌었습니다. 이는 많은 조직이 DDoS 보호를 위해 특정 하드웨어를 구입하기 때문에 발생하며, 공격 필터링을 시작하기 위해 통계를 축적하는 데 일정 시간이 필요합니다. 즉, 데이터를 축적하고 학습하기 때문에 처음 30~40초 동안은 공격을 필터링하지 않습니다. 따라서 이 XNUMX~XNUMX초 안에 사이트에서 많은 작업을 실행할 수 있으므로 모든 요청이 처리될 때까지 리소스가 오랫동안 유지됩니다.
아래 공격의 경우 10분 간격을 두고 새롭게 수정된 공격 부분이 도착했다.

즉, 방어팀이 학습하고 필터링을 시작했지만 공격의 완전히 다른 새로운 부분이 도착하고 방어팀이 다시 학습을 시작했습니다. 실제로 필터링 작동이 중지되고 보호 기능이 비활성화되며 사이트를 사용할 수 없게 됩니다.
Wave 공격은 정점에서 매우 높은 값이 특징이며, L7의 경우 초당 3만 또는 4만 요청에 도달할 수 있습니다. LXNUMX&XNUMX에 대해 이야기하면 수백 기가비트의 트래픽이 있을 수 있으며, 따라서 패킷으로 계산하면 수백 mpps가 될 수 있습니다.
이러한 공격의 문제점은 동기화입니다. 공격은 봇넷에서 발생하며 매우 큰 일회성 스파이크를 생성하려면 높은 수준의 동기화가 필요합니다. 그리고 이러한 조정이 항상 작동하는 것은 아닙니다. 때로는 출력이 일종의 포물선 피크로 나타나 다소 한심해 보입니다.

HTTP만으로는 안됨

L7의 HTTP 외에도 우리는 다른 프로토콜을 활용하는 것을 좋아합니다. 일반적으로 일반 웹사이트, 특히 일반 호스팅에는 메일 프로토콜과 MySQL이 눈에 띕니다. 메일 프로토콜은 데이터베이스보다 로드가 적지만 매우 효율적으로 로드될 수 있으며 결국 서버의 CPU에 과부하가 걸릴 수 있습니다.
우리는 2016 SSH 취약점을 통해 매우 현실적으로 성공했습니다. 이제 이 취약점은 거의 모든 사람에게 해결되었지만 이것이 SSH에 로드를 제출할 수 없다는 의미는 아닙니다. 할 수 있다. 엄청난 양의 승인이 발생하고 SSH가 서버의 거의 전체 CPU를 차지하며 초당 한두 개의 요청으로 인해 웹 사이트가 붕괴됩니다. 따라서 로그를 기반으로 한 이러한 한두 개의 요청은 합법적인 부하와 구별할 수 없습니다.
서버에서 열리는 많은 연결도 관련성을 유지합니다. 이전에는 Apache가 이 문제를 겪었지만 이제 nginx는 기본적으로 구성되는 경우가 많기 때문에 실제로 이 문제를 겪고 있습니다. nginx가 열어둘 수 있는 연결 수는 제한되어 있으므로 이 수의 연결을 열면 nginx는 더 이상 새 연결을 허용하지 않으며 결과적으로 사이트가 작동하지 않습니다.
테스트 클러스터에는 SSL 핸드셰이크를 공격하기에 충분한 CPU가 있습니다. 원칙적으로 실습에서 알 수 있듯이 봇넷도 때때로 이 작업을 수행하는 것을 좋아합니다. 한편으로는 Google 결과, 순위, 보안 때문에 SSL 없이는 할 수 없다는 것이 분명합니다. 반면 SSL에는 불행하게도 CPU 문제가 있습니다.

L3&4

L3&4 수준의 공격에 대해 이야기할 때 일반적으로 링크 수준의 공격에 대해 이야기합니다. 이러한 로드는 SYN 플러드 공격이 아닌 이상 거의 항상 합법적인 로드와 구별됩니다. 보안 도구에 대한 SYN 플러드 공격의 문제점은 규모가 크다는 것입니다. 최대 L3&4 값은 1,5-2 Tbit/s였습니다. 이런 종류의 트래픽은 오라클, 구글 등 대기업에서도 처리하기가 매우 어렵습니다.
SYN 및 SYN-ACK는 연결을 설정할 때 사용되는 패킷입니다. 따라서 SYN 플러드는 합법적인 로드와 구별하기 어렵습니다. 이것이 연결을 설정하기 위해 온 SYN인지 아니면 플러드의 일부인지 명확하지 않습니다.

UDP-플러드

일반적으로 공격자는 우리가 가지고 있는 능력을 갖고 있지 않으므로 증폭을 사용하여 공격을 조직할 수 있습니다. 즉, 공격자는 인터넷을 검색하여 예를 들어 하나의 SYN 패킷에 응답하여 세 개의 SYN-ACK로 응답하는 취약하거나 잘못 구성된 서버를 찾습니다. 대상 서버의 주소에서 소스 주소를 스푸핑함으로써 단일 패킷으로 전력을 XNUMX배로 증가시키고 트래픽을 피해자에게 리디렉션하는 것이 가능합니다.

증폭의 문제점은 감지하기 어렵다는 것입니다. 최근 사례로는 취약한 Memcached의 선정적인 사례가 있습니다. 또한 현재는 대부분 기본적으로 구성되어 있고 기본적으로 잘못 구성되어 있는 IoT 장치, IP 카메라가 많이 있으므로 공격자가 이러한 장치를 통해 공격하는 경우가 가장 많습니다.

어려운 SYN 홍수

SYN-flood는 아마도 개발자의 관점에서 가장 흥미로운 공격 유형일 것입니다. 문제는 시스템 관리자가 보호를 위해 IP 차단을 사용하는 경우가 많다는 것입니다. 더욱이 IP 차단은 스크립트를 사용하여 작업하는 시스템 관리자뿐만 아니라 불행히도 많은 돈을 주고 구입한 일부 보안 시스템에도 영향을 미칩니다.
이 방법은 공격자가 IP 주소를 교체하면 회사가 자체 서브넷을 차단하므로 재앙이 될 수 있습니다. 방화벽이 자체 클러스터를 차단하면 출력이 외부 상호 작용에 실패하고 리소스도 실패하게 됩니다.
또한 자신의 네트워크를 차단하는 것도 어렵지 않습니다. 고객 사무실에 Wi-Fi 네트워크가 있거나 다양한 모니터링 시스템을 사용하여 리소스 성능을 측정하는 경우 해당 모니터링 시스템의 IP 주소 또는 고객 사무실 Wi-Fi를 소스로 사용합니다. 결국 리소스는 사용할 수 있는 것으로 보이지만 대상 IP 주소는 차단됩니다. 따라서 회사의 신제품이 발표되는 HighLoad 컨퍼런스의 Wi-Fi 네트워크가 차단될 수 있으며 이로 인해 일정한 비즈니스 및 경제적 비용이 수반됩니다.
테스트 중에는 허용된 IP 주소로만 트래픽을 전송한다는 약정이 있기 때문에 외부 리소스와 함께 memcached를 통한 증폭을 사용할 수 없습니다. 따라서 시스템이 XNUMX~XNUMX개의 SYN-ACK로 하나의 SYN 전송에 응답할 때 SYN 및 SYN-ACK를 통한 증폭을 사용하고 출력에서 ​​공격은 XNUMX~XNUMX배로 증가합니다.

도구

L7 워크로드에 사용하는 주요 도구 중 하나는 Yandex-tank입니다. 특히 팬텀은 총으로 사용되며, 카트리지 생성 및 결과 분석을 위한 여러 스크립트가 있습니다.
Tcpdump는 네트워크 트래픽 분석에 사용되고, Nmap은 서버 분석에 사용됩니다. L3&4 수준에서 로드를 생성하기 위해 OpenSSL과 DPDK 라이브러리를 사용한 약간의 마법이 사용됩니다. DPDK는 Linux 스택을 우회하여 네트워크 인터페이스로 작업하여 효율성을 높일 수 있는 Intel의 라이브러리입니다. 당연히 우리는 L3&4 수준뿐만 아니라 L7 수준에서도 DPDK를 사용합니다. 왜냐하면 한 컴퓨터에서 초당 수백만 요청 범위 내에서 매우 높은 로드 흐름을 생성할 수 있기 때문입니다.
또한 특정 테스트를 위해 작성한 특정 트래픽 생성기와 특수 도구도 사용합니다. SSH의 취약점을 기억해 보면 위 세트는 악용될 수 없습니다. 메일 프로토콜을 공격하면 메일 유틸리티를 사용하거나 여기에 스크립트를 작성하면 됩니다.

조사 결과

결론적으로 나는 이렇게 말하고 싶다.

• 일반적인 부하 테스트 외에도 스트레스 테스트를 수행해야 합니다. 파트너의 하청업체가 로드 테스트만 수행한 실제 사례가 있습니다. 이는 리소스가 정상적인 부하를 견딜 수 있음을 보여주었습니다. 그런데 비정상적인 부하가 나타나 사이트 방문자가 리소스를 조금 다르게 사용하기 시작했고 그 결과 하청 업체가 누워있었습니다. 따라서 이미 DDoS 공격으로부터 보호받고 있더라도 취약점을 찾아볼 가치가 있습니다.
• 시스템의 일부 부분을 다른 부분과 분리해야 합니다. 검색이 있는 경우 이를 별도의 머신, 즉 Docker로도 이동해야 합니다. 검색이나 승인이 실패하더라도 최소한 무언가는 계속 작동하기 때문입니다. 온라인 상점의 경우 사용자는 계속해서 카탈로그에서 제품을 찾고, 애그리게이터에서 이동하고, 이미 승인된 경우 구매하거나 OAuth2를 통해 승인합니다.
• 모든 종류의 클라우드 서비스를 무시하지 마십시오.
• CDN을 사용하면 네트워크 지연을 최적화할 수 있을 뿐만 아니라 채널 고갈 및 단순히 정적 트래픽으로의 범람에 대한 공격으로부터 보호하는 수단으로도 사용할 수 있습니다.
• 전문적인 보호 서비스를 이용하는 것이 필요합니다. 채널 수준에서는 L3&4 공격으로부터 자신을 보호할 수 없습니다. 채널이 충분하지 않을 가능성이 높기 때문입니다. 또한 L7 공격은 매우 클 수 있으므로 맞서 싸울 가능성이 없습니다. 또한 소규모 공격 검색은 여전히 ​​특수 서비스, 특수 알고리즘의 특권입니다.
• 정기적으로 업데이트하세요. 이는 커널뿐만 아니라 SSH 데몬에도 적용됩니다. 특히 외부에 열려 있는 경우 더욱 그렇습니다. 원칙적으로 특정 취약점을 스스로 추적할 수 없기 때문에 모든 것을 업데이트해야 합니다.

출처 : habr.com