전 세계적인 오픈 소프트웨어 보안 프로젝트는 IoT, 시스템 소프트웨어 및 웹 애플리케이션 보안 분야에서 자유롭게 사용 가능한 기사, 방법론, 문서, 도구 및 기술을 생산하는 온라인 커뮤니티입니다. OWASP는 무료 및 공개 리소스를 제공합니다. 이는 The OWASP Foundation이라는 비영리 단체가 이끌고 있습니다. OWASP Top 10 – 2021은 40개가 넘는 파트너 기관의 데이터를 바탕으로 한 최근 연구 결과를 발표한 것입니다.
OWASP는 정기적으로 웹 애플리케이션의 취약점을 대상으로 하는 Top 10 취약성 보고서를 발표합니다.
이 게시물에서는 Apache APISIX API Gateway를 통해 이들 중 일부를 어떻게 수정할 수 있는지 설명하고자 합니다.
OWASP Top 10 2021
2021년 보고서에서는 다음과 같이 언급했습니다.
- A01:2021-접근 제어 손상
- A02:2021-암호화 실패
- A03:2021-삽입
- A04:2021-불안전한
- A05:2021-보안 설정 오류
- A06:2021-취약하고 오래된 구성요소
- A07:2021-식별 및 인증 실패
- A08:2021-소프트웨어 및 데이터 무결성 실패
- A09:2021-보안 로깅 및 모니터링 실패
- A10:2021-서버 측 요청 위조
자세한 내용은 전체 보고서를 확인하십시오.
취약점을 수정하는 것은 그 특성에 따라 달라집니다. 예를 들어, 취약하고 구형 구성 요소를 수정하는 것은 과정에 의존하며 버전 관리 및 구형 버전 퇴출에 대한 규율이 필요합니다. 그러나 일부는 기술적이며 반전 프록시 또는 API 게이트웨이에서 적절한 구성만 필요합니다. 예를 들면, 서버 측 요청 위조가 있습니다.
누구도 보안에 신경 쓰지 않습니다
보안은 민감한 주제입니다. 보안을 강화하는 것이 비즈니스에 가치를 주지 않기 때문입니다. 경력 지향적인 관리자들은 보안에 신경 쓰지 않을 것이며, 다음 연례 평가에서 회사의 이익을 X% 증가시킨 것을 과시할 수 없기 때문입니다. 보드가 보안을 진지하게 고려하지 않는 한, 아마도 아무도 신경 쓰지 않을 것입니다. 이러한 이유로 대부분의 조직은 확인란 기반 보안을 구현합니다. 즉, 타당한 부인이라고 합니다. 보안을 제대로 구현하고자 한다면, 이전 블로그 게시물 “보안을 위험으로 간주“에 몇 가지 생각을 적어두었습니다.
결국, 애플리케이션 보안에는 많은 예산이 할당되지 않을 것입니다. 따라서 우리는 이를 잘 알아야 하며 기존 구성 요소를 찾아야 합니다. 다행히 OWASP는 Top 10을 처리할 수 있는 즉시 사용할 수 있는 구성을 제공하며, 이는 코어 규칙 세트라는 구성을 통해 수정할 수 있습니다. 불행히도, 이는 ModSecurity를 대상으로 합니다.
ModSecurity, 종종 Modsec라고도 불리우는 것은 오픈 소스 웹 애플리케이션 방화벽(WAF)입니다. 처음에는 Apache HTTP Server의 모듈로 설계되었지만, 이후 다양한 플랫폼에서 초기 전송 프로토콜(HTTP) 요청 및 응답 필터링 기능과 다양한 보안 기능을 제공하도록 발전하였습니다. 플랫폼으로는 Apache HTTP Server, Microsoft IIS 및 Nginx가 포함됩니다. 이 소프트웨어는 Apache 라이선스 2.0에 따라 무료로 공개되어 있습니다.
이론적으로 Apache APISIX 구성을 통해 Nginx을 구성할 수 있지만, 더 간단한 방법이 있습니다.
OWASP 코어 규칙 집합 및 Coraza
코어 규칙 집합의 설명은 우리의 요구에 매우 관련이 있습니다:
OWASP® ModSecurity 코어 규칙 세트(CRS)는 ModSecurity 또는 호환되는 웹 애플리케이션 방화벽에 사용할 수 있는 일반적인 공격 감지 규칙 세트입니다. CRS는 넓은 범위의 웹 애플리케이션 공격으로부터 보호하면서 거짓 경보의 최소화를 목표로 합니다. CRS는 SQL 삽입(SQLi), 크로스 사이트 스크립팅(XSS), 로컬 파일 포함(LFI), 원격 파일 포함(RFI), PHP 코드 삽입, Java 코드 삽입, HTTPoxy, Shellshock, Unix/Windows 쉘 삽입, 세션 고정, 스크립팅/스캐너/봇 감지를 포함한 많은 일반적인 공격 범주로부터 보호를 제공합니다.
- 메타데이터/오류 누출
OWASP는 Coraza를 제공하는데, 이는 ModSecurity의 포트로서 Go 라이브러리 형태로 제공됩니다. Coraza Proxy Wasm은 Coraza를 기반으로 하며 프록시-wasm ABI를 구현하고 있으며, 이는 프록시용 일련의 Wasm 인터페이스를 명시합니다. 마지막으로, Apache APISIX는 프록시-wasm 통합을 제공합니다.
모두 함께 적용하기
요약해보겠습니다:
- OWASP는 상위 10개 웹 보안 취약점 목록을 제공합니다.
- 이를 핵심 규칙 세트를 통해 ModSecurity에 구현합니다.
- Coraza는 ModSecurity의 포트로서 프록시-wasm 구현으로 제공됩니다.
이러한 방식으로 Apache APISIX를 합리적이고 안전한 기본 설정으로 구성할 수 있습니다. 이제 해보죠.
가장 먼저: Coraza는 Apache APISIX 배포의 일부가 아닙니다. 그러나 Docker를 사용하여 여기에 쉽게 추가할 수 있습니다.
FROM apache/apisix:3.8.0-debian
ENV VERSION 0.5.0 #1
ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip #1
ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2
USER root #3
RUN <<EOF
apt-get install zip -y #4
unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm
rm $CORAZA_FILENAME
apt-get remove zip -y
chown -R apisix:apisix /usr/local/apisix/proxywasm
EOF
USER apisix #5
- 유지 보수를 쉽게 하기 위해 변수를 정의하세요
- Coraza Wasm 릴리스를 다운로드하세요.
- 최근 APISIX 버전에서 사용자는 보안을 강화하기 위해
apisix
입니다. 패키지를 설치해야 하므로root
로 전환해야 합니다. unzip
을 설치하고, 다운로드한 아카이브를 압축 해제하고, 아카이브를 삭제하고,unzip
을 제거하고, 추출된 폴더의 소유자를 변경하세요.- 다시 사용자
apisix
로 전환합니다.
다음 단계는 APISIX 자체를 Coraza Wasm 플러그인을 사용하도록 구성하는 것입니다.
wasm:
plugins:
- name: coraza-filter #1
priority: 7999 #2
file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3
- Wasm 코드에서 설정한 필터 이름
- 가장 높은 우선순위를 설정하여 다른 어떤 플러그인보다 먼저 실행되도록 합니다.
- 추출된 파일의 경로(위의
Dockerfile
참조)
마지막으로, 플러그인을 라우트에 할당하거나 모든 라우트에 적용되는 전역 규칙으로 설정할 수 있습니다. 저는 정적 설정을 사용하고 있습니다:
global_rules:
- id: 1
plugins:
coraza-filter: #1
conf:
directives_map: #2
default:
- SecDebugLogLevel 9 #3
- SecRuleEngine On #4
- Include @crs-setup-conf #5
- Include @owasp_crs/*.conf #6
default_directives: default #7
- 이제
coraza-filter
플러그인이 사용 가능하므로 구성합니다. - 구성을 정의합니다. 여기서는 단일 구성인
default
를 정의하지만, 여러 개를 정의하고 서로 다른 라우트에서 다른 구성을 사용할 수 있습니다. - 로그에서 무슨 일이 일어나는지 보려면 로그 레벨을 높입니다.
- 엔진을 켭니다.
- Coraza 설정을 사용합니다.
- 모든 규칙을 사용합니다. 더 세밀한 제어를 위해 원하는 규칙만 선택할 수도 있습니다.
- 위에서 정의한
default
구성을 사용합니다.
이제 설정을 테스트하기 위해 라우트를 정의하겠습니다. /get
으로 가는 라우트를 부르도록 하겠습니다:
curl localhost:9080?user=foobar
응답은 예상대로입니다:
{
"args": {
"user": "foobar"
},
"headers": {
"Accept": "*/*",
"Host": "localhost",
"User-Agent": "curl/8.4.0",
"X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204",
"X-Forwarded-Host": "localhost"
},
"origin": "192.168.65.1, 176.153.7.175",
"url": "http://localhost/get?user=foobar"
}
이제 쿼리 문자열에 JavaScript를 보내 보겠습니다. 이 요청이 서버측에서 예상되는 것은 아니므로 우리의 인프라는 이것으로부터 우리를 보호해야 합니다.
curl 'localhost:9080?user=<script>alert(1)</script>'
응답은 403 HTTP 상태 코드입니다. 로그를 살펴보면 다음과 같은 단서를 볼 수 있습니다:
Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"]
Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection
Coraza: Warning. Javascript method detected
Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1
Coraza가 작업을 완료했습니다!
결론
대부분의 기관은 보안을 위한 인센티브를 제공하지 않습니다. 따라서 우리는 이를 잘 다루어 기존 구성 요소를 최대한 활용해야 합니다.
Apache APISIX를 Coraza와 Core Ruleset를 사용하여 OWASP Top 10에 대항하여 강화할 수 있습니다.
더 나아가기
이 게시물의 전체 소스 코드는 GitHub에서 찾을 수 있습니다.
Source:
https://dzone.com/articles/hardening-apache-apisix-with-the-owasps-coraza-and