TL; DR. 이 기사에서는 12.4가지 인기 Linux 배포판에서 기본적으로 작동하는 강화 체계를 살펴봅니다. 각각에 대해 기본 커널 구성을 가져와 모든 패키지를 로드하고 첨부된 바이너리의 보안 체계를 분석했습니다. 고려되는 배포판은 OpenSUSE 9, Debian 6.10, CentOS, RHEL 7 및 14.04뿐만 아니라 Ubuntu 12.04, 18.04 및 XNUMX LTS입니다.

결과는 스태킹 카나리아 및 위치 독립적 코드와 같은 기본 방식조차 아직 모든 사람이 채택하지 않는다는 것을 확인시켜 줍니다. 출판 후 XNUMX월에 주목을 받은 스택 충돌과 같은 취약점으로부터 보호하는 경우 컴파일러의 상황은 더욱 악화됩니다. 시스템 취약점에 대한 정보. 그러나 모든 것이 그렇게 절망적인 것은 아닙니다. 상당수의 바이너리가 기본 보호 방법을 구현하며 그 수는 버전마다 늘어납니다.

검토 결과 OS 및 애플리케이션 수준에서 Ubuntu 18.04에 가장 많은 보호 방법이 구현되었으며 Debian 9가 그 뒤를 잇는 것으로 나타났습니다. 반면 OpenSUSE 12.4, CentOS 7 및 RHEL 7도 기본 보호 체계 및 스택 충돌 방지를 구현합니다. 훨씬 더 조밀한 기본 패키지 세트를 사용하면 훨씬 더 광범위하게 사용됩니다.

소개

고품질 소프트웨어를 확보하는 것은 어렵습니다. 정적 코드 분석 및 동적 런타임 분석을 위한 수많은 고급 도구와 컴파일러 및 프로그래밍 언어 개발의 상당한 진전에도 불구하고 최신 소프트웨어는 여전히 공격자가 지속적으로 악용하는 취약점으로 어려움을 겪고 있습니다. 레거시 코드를 포함하는 생태계에서는 상황이 더욱 악화됩니다. 그러한 경우, 우리는 악용 가능한 오류를 찾아야 하는 영원한 문제에 직면할 뿐만 아니라 엄격한 이전 버전과의 호환성 프레임워크에 의해 제한됩니다. 이는 종종 제한적이거나 더 나쁘게는 취약하거나 버그가 있는 코드를 보존해야 합니다.

여기서 프로그램을 보호하거나 강화하는 방법이 활용됩니다. 일부 유형의 오류는 예방할 수 없지만 예방하거나 방지함으로써 공격자의 삶을 더욱 어렵게 만들고 부분적으로 문제를 해결할 수 있습니다. 운영 이러한 오류. 이러한 보호는 모든 최신 운영 체제에서 사용되지만 방법은 복잡성, 효율성 및 성능면에서 크게 다릅니다. ASLR 완전한 보호를 위해 CFI и ROP. 이 기사에서는 기본 구성에서 가장 널리 사용되는 Linux 배포판에서 어떤 보호 방법이 사용되는지 살펴보고 각 배포판의 패키지 관리 시스템을 통해 배포되는 바이너리의 속성도 살펴보겠습니다.

CVE 및 보안

우리는 모두 "올해 가장 취약한 응용 프로그램" 또는 "가장 취약한 운영 체제"와 같은 제목의 기사를 본 적이 있습니다. 일반적으로 다음과 같은 취약점에 대한 총 레코드 수에 대한 통계를 제공합니다. CVE(공통 취약점 및 노출), 에서 얻은 국가 취약점 데이터베이스(NVD) 부터 NIST 및 기타 소스. 이후 이러한 애플리케이션 또는 OS는 CVE 수에 따라 순위가 지정됩니다. 안타깝게도 CVE는 문제를 추적하고 공급업체와 사용자에게 알리는 데 매우 유용하지만 소프트웨어의 실제 보안에 대해서는 거의 언급하지 않습니다.

예를 들어 지난 XNUMX년 동안 Linux 커널과 가장 널리 사용되는 XNUMX가지 서버 배포판(Ubuntu, Debian, Red Hat Enterprise Linux 및 OpenSUSE)에 대한 총 CVE 수를 생각해 보세요.

그림. 1

이 그래프는 우리에게 무엇을 말해주는가? CVE 수가 많다는 것은 한 배포판이 다른 배포판보다 더 취약하다는 것을 의미합니까? 대답이 없습니다. 예를 들어, 이 기사에서는 Debian이 OpenSUSE 또는 RedHat Linux에 비해 더 강력한 보안 메커니즘을 갖고 있지만 Debian에는 더 많은 CVE가 있다는 것을 알 수 있습니다. 그러나 이것이 반드시 보안 약화를 의미하는 것은 아닙니다. CVE가 존재하더라도 취약점이 존재하는지 여부를 나타내지는 않습니다. 착취당하다. 심각도 점수는 방법을 나타냅니다. 아마도 그러나 궁극적으로 악용 가능성은 영향을 받는 시스템에 존재하는 보호 기능과 공격자의 리소스 및 능력에 따라 크게 달라집니다. 게다가 CVE 보고서가 없다는 사실은 다른 보고서에 대해 아무 말도 하지 않습니다. 등록되지 않았거나 알 수 없음 취약점. CVE의 차이는 테스트에 할당된 리소스나 사용자 기반 규모 등 소프트웨어 품질 이외의 요인으로 인해 발생할 수 있습니다. 이 예에서 Debian의 CVE 수가 더 많다는 것은 단순히 Debian이 더 많은 소프트웨어 패키지를 제공한다는 것을 의미할 수 있습니다.

물론 CVE 시스템은 적절한 보호를 생성할 수 있는 유용한 정보를 제공합니다. 프로그램 실패의 원인을 더 잘 이해할수록 가능한 악용 방법을 식별하고 적절한 메커니즘을 개발하는 것이 더 쉬워집니다. 탐지 및 대응. 그림에서. 2는 지난 XNUMX년 동안 모든 배포판의 취약점 카테고리를 보여줍니다(출처). 대부분의 CVE는 서비스 거부(DoS), 코드 실행, 오버플로, 메모리 손상, 정보 유출(탈출) 및 권한 상승과 같은 범주에 속한다는 것이 즉시 명백해졌습니다. 많은 CVE가 다양한 범주에서 여러 번 계산되지만 일반적으로 동일한 문제가 해마다 지속됩니다. 이 기사의 다음 부분에서는 이러한 취약점의 악용을 방지하기 위해 다양한 보호 체계의 사용을 평가할 것입니다.

그림. 2

작업

이 기사에서 우리는 다음 질문에 답하려고 합니다.

• 다양한 Linux 배포판의 보안은 무엇입니까? 커널 및 사용자 공간 애플리케이션에는 어떤 보호 메커니즘이 존재합니까?
• 시간이 지남에 따라 배포 전반에 걸쳐 보안 메커니즘 채택이 어떻게 바뀌었나요?
• 각 배포판에 대한 패키지 및 라이브러리의 평균 종속성은 무엇입니까?
• 각 바이너리에는 어떤 보호 기능이 구현되어 있나요?

분포 선택

대부분의 경우 다운로드 수가 실제 설치 수를 나타내지 않기 때문에 배포 설치에 대한 정확한 통계를 찾는 것이 어려운 것으로 나타났습니다. 그러나 Unix 변종은 서버 시스템의 대부분을 구성합니다(웹 서버의 경우 69,2%, 통계 W3techs 및 기타 소스), 점유율은 지속적으로 증가하고 있습니다. 따라서 연구를 위해 우리는 플랫폼에서 바로 사용할 수 있는 배포판에 중점을 두었습니다. Google 클라우드. 특히 우리는 다음 OS를 선택했습니다.

배포/버전
핵심
짓다

OpenSUSE 12.4
4.12.14-95.3-기본값
#1 SMP 5년 06월 00일 수요일 48:2018:63 UTC(8a29dXNUMX)

데비안 9(확장)
4.9.0-8-amd64
#1 SMP 데비안 4.9.130-2 (2018-10-27)

6.10 CentOS에
2.6.32-754.10.1.el6.x86_64
#1 SMP 15년 17월 07일 화요일 28:2019:XNUMX UTC

7 CentOS에
3.10.0-957.5.1.el7.x86_64
#1 SMP 1년 14월 54일 금요일 57:2019:XNUMX UTC

Red Hat Enterprise Linux 서버 6.10(산티아고)
2.6.32-754.9.1.el6.x86_64
#1 SMP 21년 15월 08일 수요일 21:2018:XNUMX EST

Red Hat Enterprise Linux 서버 7.6(마이포)
3.10.0-957.1.3.el7.x86_64
#1 SMP 15년 17월 36일 목요일 42:2018:XNUMX UTC

우분투 14.04(트러스티 타르)
4.4.0–140-일반

#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…

우분투 16.04(제니얼 제루스)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP 7년 09월 59일 금요일 47:2018:XNUMX UTC

우분투 18.04(바이오닉 비버)
4.15.0–1026-gcp
#27-Ubuntu SMP 6년 18월 27일 목요일 01:2018:XNUMX UTC

표 1

분석

기본 커널 구성과 각 배포판의 패키지 관리자를 통해 즉시 사용할 수 있는 패키지 속성을 살펴보겠습니다. 따라서 우리는 불안정한 저장소(예: Debian '테스트' 미러)의 패키지와 타사 패키지(예: 표준 미러의 Nvidia 패키지)를 무시하고 각 배포판의 기본 미러의 패키지만 고려합니다. 또한 사용자 정의 커널 컴파일이나 보안 강화 구성은 고려하지 않습니다.

커널 구성 분석

우리는 다음을 기반으로 분석 스크립트를 적용했습니다. 무료 kconfig 검사기. 명명된 배포판의 기본 보호 매개변수를 살펴보고 이를 다음 목록과 비교해 보겠습니다. 핵심 자위대 프로젝트 (KSPP). 각 구성 옵션에 대해 표 2에서는 원하는 설정을 설명합니다. 확인란은 KSSP 권장 사항을 준수하는 배포판을 위한 것입니다(용어 설명은 다음 참조). 여기에; 향후 기사에서는 이러한 보안 방법 중 얼마나 많은 방법이 등장했는지, 그리고 이러한 보안 방법이 없을 때 시스템을 해킹하는 방법을 설명할 것입니다.

일반적으로 새 커널은 기본적으로 더 엄격한 설정을 갖습니다. 예를 들어 6.10 커널의 CentOS 6.10 및 RHEL 2.6.32에는 다음과 같은 최신 커널에 구현된 중요한 기능이 대부분 부족합니다. SMAP, 엄격한 RWX 권한, 주소 무작위화 또는 copy2usr 보호. 표에 있는 많은 구성 옵션은 이전 버전의 커널에서는 사용할 수 없으며 실제로 적용할 수 없다는 점에 유의해야 합니다. 이는 적절한 보호가 부족하다는 의미로 표에 여전히 표시되어 있습니다. 마찬가지로 특정 버전에 구성 옵션이 없고 보안상 옵션을 비활성화해야 하는 경우 이는 합리적인 구성으로 간주됩니다.

결과를 해석할 때 고려해야 할 또 다른 사항: 공격 표면을 증가시키는 일부 커널 구성은 보안에도 사용될 수 있습니다. 이러한 예로는 uprobes 및 kprobes, 커널 모듈, BPF/eBPF가 있습니다. 우리는 위의 메커니즘을 사용하여 실질적인 보호를 제공하는 것을 권장합니다. 왜냐하면 이러한 메커니즘은 사용하기가 쉽지 않고 악의적인 행위자가 이미 시스템에 발판을 마련했다고 가정하기 때문입니다. 그러나 이러한 옵션이 활성화된 경우 시스템 관리자는 남용을 적극적으로 모니터링해야 합니다.

표 2의 항목을 더 자세히 살펴보면 최신 커널이 정보 유출 및 스택/힙 오버플로와 같은 취약점 악용을 방지하기 위한 여러 옵션을 제공한다는 것을 알 수 있습니다. 그러나 가장 최근에 널리 사용되는 배포판조차도 아직 더 복잡한 보호 기능(예: 패치 포함)을 구현하지 않았습니다. 보안) 또는 코드 재사용 공격에 대한 최신 보호(예: 코드에 대한 R^X와 같은 체계와 무작위화의 조합). 설상가상으로 이러한 고급 방어 기능도 전체 범위의 공격을 방어하지 못합니다. 따라서 시스템 관리자는 런타임 악용 탐지 및 방지 기능을 제공하는 솔루션으로 스마트 구성을 보완하는 것이 중요합니다.

애플리케이션 분석

당연히 배포판마다 패키지 특성, 컴파일 옵션, 라이브러리 종속성 등이 다릅니다. 관련 종속성이 적은 배포판 및 패키지(예: Ubuntu 또는 Debian의 coreutils) 차이점을 평가하기 위해 사용 가능한 모든 패키지를 다운로드하고 해당 콘텐츠를 추출하고 바이너리와 종속성을 분석했습니다. 각 패키지에 대해 종속된 다른 패키지를 추적하고 각 바이너리에 대해 종속성을 추적했습니다. 이 섹션에서는 결론을 간략하게 요약합니다.

배포판

모든 배포판에 대해 총 361개의 패키지를 다운로드했으며 기본 미러에서 패키지만 추출했습니다. 소스, 글꼴 등과 같은 ELF 실행 파일이 없는 패키지는 무시했습니다. 필터링 후 총 556개의 바이너리를 포함하는 129개의 패키지가 남았습니다. 배포판에 걸친 패키지 및 파일의 배포는 그림 569에 나와 있습니다. 삼.

그림. 3

배포판이 현대적일수록 더 많은 패키지와 바이너리가 포함되어 있다는 것을 알 수 있으며 이는 논리적입니다. 그러나 Ubuntu 및 Debian 패키지에는 CentOS, SUSE 및 RHEL보다 더 많은 바이너리(실행 파일과 동적 모듈 및 라이브러리 모두)가 포함되어 있어 Ubuntu 및 Debian의 공격 표면에 잠재적으로 영향을 미칠 수 있습니다(숫자는 모든 버전의 모든 바이너리를 반영한다는 점에 유의해야 합니다). 즉, 일부 파일은 여러 번 분석됩니다.) 이는 패키지 간의 종속성을 고려할 때 특히 중요합니다. 따라서 단일 패키지 바이너리의 취약성은 취약한 라이브러리가 이를 가져오는 모든 바이너리에 영향을 미칠 수 있는 것처럼 생태계의 많은 부분에 영향을 미칠 수 있습니다. 시작점으로 다양한 운영 체제의 패키지 간 종속성 수 분포를 살펴보겠습니다.

그림. 4

거의 모든 배포판에서 패키지의 60%에는 최소 10개의 종속성이 있습니다. 또한 일부 패키지에는 훨씬 더 많은 수의 종속성(100개 이상)이 있습니다. 역방향 패키지 종속성에도 동일하게 적용됩니다. 예상대로 몇 가지 패키지가 배포판의 다른 많은 패키지에서 사용되므로 선택된 소수의 취약점은 위험이 높습니다. 예를 들어 다음 표에는 SLES, Centos 20, Debian 7 및 Ubuntu 9에서 최대 역방향 종속성 수가 포함된 18.04개의 패키지가 나열되어 있습니다(각 셀은 패키지 및 역방향 종속성 개수를 나타냄).

표 3

흥미로운 사실. 분석된 모든 OS는 x86_64 아키텍처용으로 구축되었으며 대부분의 패키지에는 x86_64 및 x86으로 정의된 아키텍처가 있지만 그림 5에 표시된 것처럼 패키지에는 종종 다른 아키텍처에 대한 바이너리가 포함되어 있습니다. XNUMX.

그림. 5

다음 섹션에서는 분석된 바이너리의 특징을 살펴보겠습니다.

바이너리 파일 보호 통계

최소한 기존 바이너리에 대한 기본 보안 옵션 세트를 탐색해야 합니다. 여러 Linux 배포판에는 이러한 검사를 수행하는 스크립트가 함께 제공됩니다. 예를 들어 Debian/Ubuntu에는 이러한 스크립트가 있습니다. 그의 작품의 예는 다음과 같습니다.

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

스크립트는 XNUMX가지를 확인합니다. 보호 기능:

• PIE(Position Independent Executable): ASLR이 커널에서 활성화된 경우 무작위화를 달성하기 위해 프로그램의 텍스트 섹션을 메모리에서 이동할 수 있는지 여부를 나타냅니다.
• 스택 보호: 스택 충돌 공격으로부터 보호하기 위해 스택 카나리아를 활성화할지 여부입니다.
• Fortify Source: 안전하지 않은 함수(예: strcpy)가 보다 안전한 함수로 대체되고 런타임에 확인된 호출이 확인되지 않은 해당 함수(예: __memcpy_chk 대신 memcpy)로 대체되는지 여부입니다.
• 읽기 전용 재배치(RELRO): 실행이 시작되기 전에 재배치 테이블 항목이 트리거되는 경우 읽기 전용으로 표시되는지 여부입니다.
• 즉시 바인딩: 프로그램 실행이 시작되기 전에 런타임 링커가 모든 이동을 허용하는지 여부(이는 전체 RELRO와 동일)

위의 메커니즘으로 충분합니까? 불행하게도. 위의 모든 방어를 우회할 수 있는 방법이 알려져 있지만, 방어가 강할수록 공격자의 기준이 높아집니다. 예를 들어, RELRO 우회 방법 PIE 및 즉시 바인딩이 적용되는 경우 적용하기가 더 어렵습니다. 마찬가지로, 전체 ASLR은 작동하는 익스플로잇을 생성하기 위해 추가 작업이 필요합니다. 그러나 정교한 공격자들은 이미 그러한 보호를 충족할 준비가 되어 있습니다. 그들의 부재는 본질적으로 해킹 속도를 높일 것입니다. 따라서 이러한 조치가 필요하다고 간주되는 것이 필수적입니다. 최소한의.

우리는 문제의 배포판에서 얼마나 많은 바이너리 파일이 다음 방법과 다른 세 가지 방법으로 보호되는지 연구하고 싶었습니다.

• 실행 불가능한 비트(NX) 스택 힙 등과 같이 실행 가능하지 않아야 하는 영역에서의 실행을 방지합니다.
• RPATH/RUNPATH 일치하는 라이브러리를 찾기 위해 동적 로더가 사용하는 실행 경로를 나타냅니다. 첫 번째는 의무적 모든 최신 시스템의 경우: 이 기능이 없으면 공격자가 페이로드를 메모리에 임의로 쓰고 있는 그대로 실행할 수 있습니다. 두 번째로, 잘못된 실행 경로 구성은 여러 가지 문제를 일으킬 수 있는 신뢰할 수 없는 코드를 도입하는 데 도움이 됩니다(예: 권한 상승과 다른 문제).
• 스택 충돌 보호는 스택이 다른 메모리 영역(예: 힙)과 겹치게 하는 공격으로부터 보호합니다. 최근 악용 사례를 고려하면 시스템 힙 충돌 취약점, 우리는 이 메커니즘을 데이터 세트에 포함하는 것이 적절하다고 느꼈습니다.

그럼 더 이상 고민하지 말고 숫자로 넘어가겠습니다. 표 4와 5에는 각각 다양한 배포판의 실행 파일과 라이브러리 분석 요약이 포함되어 있습니다.

• 보시다시피 NX 보호는 드문 경우를 제외하고 모든 곳에서 구현됩니다. 특히 CentOS, RHEL 및 OpenSUSE에 비해 Ubuntu 및 Debian 배포판에서는 사용률이 약간 낮다는 점을 알 수 있습니다.
• 스택 카나리아는 여러 곳에서 누락되었으며, 특히 이전 커널이 포함된 배포판에서는 더욱 그렇습니다. Centos, RHEL, Debian 및 Ubuntu의 최신 배포판에서 일부 진전이 보이고 있습니다.
• Debian 및 Ubuntu 18.04를 제외하고 대부분의 배포판은 PIE 지원이 좋지 않습니다.
• OpenSUSE, Centos 7 및 RHEL 7에서는 스택 충돌 보호가 약하고 다른 것에서는 사실상 존재하지 않습니다.
• 최신 커널을 사용하는 모든 배포판은 RELRO를 일부 지원하며 Ubuntu 18.04가 선두를 달리고 Debian이 XNUMX위를 차지합니다.

이미 언급한 대로 이 표의 측정항목은 모든 버전의 바이너리 파일에 대한 평균입니다. 최신 버전의 파일만 보면 숫자가 달라집니다(예: PIE 구현을 통한 데비안 진행). 더욱이, 대부분의 배포판은 일반적으로 통계를 계산할 때 바이너리에 있는 몇 가지 함수의 보안만 테스트하지만, 우리의 분석은 강화된 함수의 실제 비율을 보여줍니다. 따라서 5개 기능 중 50개 기능이 바이너리로 보호된다면, 강화되는 기능의 0,1%에 해당하는 10점의 점수를 부여하겠습니다.

표 4. 그림 3에 표시된 실행 파일의 보안 특성 XNUMX (전체 실행 파일 수에 대한 해당 기능의 구현 비율)

표 5. 그림에 표시된 라이브러리의 보안 특성 3 (전체 라이브러리 수 대비 관련 기능 구현 비율)

그럼 진전이 있는 걸까요? 분명히 있습니다. 이는 개별 분포에 대한 통계에서 볼 수 있습니다(예: 데비안), 위의 표에서도 마찬가지입니다. 그림의 예로서 그림 6은 Ubuntu LTS 5의 세 가지 연속 배포판에서 보호 메커니즘의 구현을 보여줍니다(스택 충돌 방지 통계는 생략했습니다). 버전이 거듭될수록 점점 더 많은 파일이 스택 카나리아를 지원하며, 완전한 RELRO 보호 기능이 탑재된 바이너리도 점점 더 많아지고 있습니다.

그림. 6

불행하게도 다양한 배포판에 있는 다수의 실행 파일에는 여전히 위의 보호 기능이 없습니다. 예를 들어, Ubuntu 18.04를 보면 ngetty 바이너리(getty 대체), mksh 및 lksh 쉘, picolisp 인터프리터, nvidia-cuda-toolkit 패키지(GPU 가속 애플리케이션에 널리 사용되는 패키지)를 볼 수 있습니다. 기계 학습 프레임워크 등) 및 klibc -utils. 마찬가지로 mandos-client 바이너리(암호화된 파일 시스템으로 시스템을 자동으로 재부팅할 수 있는 관리 도구)와 rsh-redone-client(rsh 및 rlogin의 재구현)는 SUID 권한이 있지만 NX 보호 없이 제공됩니다. (. 또한 여러 suid 바이너리에는 스택 카나리아(예: Xorg 패키지의 Xorg.wrap 바이너리)와 같은 기본 보호 기능이 부족합니다.

요약 및 결론

이 기사에서는 최신 Linux 배포판의 여러 보안 기능을 강조했습니다. 분석에 따르면 최신 Ubuntu LTS 배포판(18.04)은 Ubuntu 14.04, 12.04 및 Debian 9와 같이 상대적으로 새로운 커널을 사용하는 배포판 중에서 평균적으로 가장 강력한 OS 및 애플리케이션 수준 보호를 구현하는 것으로 나타났습니다. 그러나 조사된 배포판 CentOS, RHEL 및 우리 세트의 OpenSUSE는 기본적으로 더 밀집된 패키지 세트를 생성하며 최신 버전(CentOS 및 RHEL)에서는 Debian 기반 경쟁사(Debian 및 Ubuntu)에 비해 스택 충돌 방지 비율이 더 높습니다. CentOS와 RedHat 버전을 비교하면 버전 6에서 7까지 스택 카나리아 및 RELRO 구현이 크게 향상되었지만 평균적으로 CentOS에는 RHEL보다 더 많은 기능이 구현되어 있습니다. 일반적으로 모든 배포판은 PIE 보호에 특별한 주의를 기울여야 하며, Debian 9 및 Ubuntu 18.04를 제외하고는 데이터 세트의 바이너리 중 10% 미만에서 구현됩니다.

마지막으로, 조사를 수동으로 수행했지만 사용 가능한 보안 도구가 많이 있다는 점에 유의해야 합니다(예: 리니 스, 호랑이, 허블), 분석을 수행하고 안전하지 않은 구성을 방지하는 데 도움이 됩니다. 불행하게도 합리적인 구성으로 강력한 보호를 제공한다고 해도 악용이 없음을 보장할 수는 없습니다. 그렇기 때문에 우리는 다음을 보장하는 것이 중요하다고 굳게 믿습니다. 안정적인 실시간 모니터링 및 공격 방지, 착취 패턴에 중점을 두고 이를 방지합니다.

출처 : habr.com