[웹 방어 레시피] 1장, 애플리케이션 요새화

첫 단계는 반드시 보호해야 하는 현재 웹 애플리케이션을 분석하고 방어 능력을 향상시키는 '애플리케이션 요새화'다.

 

[ 레시피 1-1, 실시간 애플리케이션 프로파일링 ]

이 레시피는 예상되는 요청의 특징에 대한 학습된 프로파일을 만들기 위해 ModSecurity의 루아 API를 이용해 HTTP 트랜잭션을 분석하는 방법을 보여준다.

 

예상되는 요청의 속성에 대한 레시피

 

이 절에서는 우리의 웹 애플리케이션에 대해 입력 값 검증 화이트리스트 또는 보안 모델을 동적으로 생성하는 방법을 개념적으로 보여준다. 생성된 이후에는 외부의 보안 계층을 통해 애플리케이션의 중요한 요소에 대한 규칙을 적용하고, 정책을 위반하는 비정상적인 요청을 식별할 수 있게 한다. 이 레시피는 각각의 애플리케이션 자원에 대해 다음과 같은 요청을 식별할 수 있도록 실제 웹 사용자의 트랜잭션을 프로파일링 하는 방법을 보여준다.

 

• 요청 방법
• 매개 변수의 수 (최소/최대 범위)
• 매개변수명
• 매개변수 길이(최소/최대 범위)
• 매개변수 유형

      - 플래그 (/path/to/foo.php?param)

      - 숫자 (/path/to/foo.php?param=1234)

      - 알파벳 (/path/to/foo.php?param=abcd)

      - 알파벳 + 숫자 (/path/to/foo.php?param=abcd1234)

      - 이메일 (/path/to/foo.php?param=foo@bar.com)

      - 경로 (/path/to/foo.php?param=/dir/file.txt)

      - URL (/path/to/foo.php?param=http://somehost/dir/file.txt)

      - SafeText (/path/to/foo.php?param=some_data-12)

 

노트 입력 값 검증을 위한 외부 계층이 필요한 이유는 현실적으로 공격자에게 맞춤형 브라우저의 플러그인을 이용하든, 클라우드 측 웹 프락시를 이용하든 웹 브라우저의 보안 제어를 우회하는 것은 간단한 작업이다. 이러한 도구를 사용해 공격자는 클라이언트 측 보안 코드를 쉽게 우회하고 브라우저에 전송되는 어떤 HTTP 데이터도 조직할 수 있다.

영구 저장소 생성

 

ModSecurity를 통해 자원당 영구 저장소를 활용하고 다수의 요청 및 클라이언트에서 오는 데이터를 상호 연관시킬 수 있다. 요청의 초기 단계에서 RESOURCE 영구 저장소 매커니즘을 초기화하는 것을 통해 이 작업을 수행한다.

 

initcol:resource 액션은 비슷한 이름을 가진 자원과의 충돌을 방지하기 위해 매크로 확장된 REQUEST_HEADERS:Host와 REQUEST_FILENAME 변수를 수집 키로 사용한다. 두 개의 setvar 액션은 프로파일할 트랜잭션의 수와 집행 목록에 추가하기 전에 일치해야 하는 횟수를 결정하는 데 사용한다.

 

후처리 프로파일링

 

프로파일링 분석이 미치는 잠재적인 지연 가능성을 최소화하길 원하므로 HTTP 응답이 이미 클라이언트로 전달된 이후에 후처리 단계에서 실행된다. 우리는 트랜잭션을 프로파일링하기로 결정하기 전에 악성적인 입력값이 없는 깨끗한 트랜잭션만을 보고 있음을 보증하기 위해 몇 가지 보안 검사를 수행한다.

 

→ 학습된 프로파일 내에 공격 데이터가 포함되지 않길 원하므로 이는 중요한 작업이다.

 

< 데이터를 프로파일링하지 않기를 원하는 네 가지 유형의 트랜잭션 시나리오 >

 

• HTTP의 응답 코드가 404라면 자원은 존재하지 않는 것이다. 이 경우라면 프로파일링을 건너뛰는 것뿐만 아니라 자원 키를 지워 영구 저장소도 지운다. setvar:!resource.KEY를 통해 수행 가능하다.
• HTTP의 응답 코드가 400번대 또는 500번대라면 애플리케이션이 트랜잭션에서 무엇인가 문제가 있다고 보고한 경우며, 이때도 프로파일링 하지 않을 것이다. 
• OWASP Modsecurity CRS는 이상 징후 점수를 이용할 수 있다. 우리는 트랜잭션의 이상 징후 점수를 확인할 수 있다. 만약 점수가 0이 아닌 다른 값이라면 프로파일링을 건너뛸 것이다.
• 마지막으로 적당히 많은 수의 트래픽을 확인했고 이미 집행 단계인 경우 프로파일링을 건너뛴다.

위와 같은 모든 사전 검사를 통과한다면 SecRuleScript 지시자에 의해 호출되는 appsensor_request_exception_profile.lua 스크립트를 사용해 요청 속성에 대한 실제적인 프로파일링 단계로 이동한다.

 

테스트 예시

 

author=Joe+Smith& email=joe%40email.com& url=http%3A%2F%2Fwww.mywebsite.com%2F& comment=I+do+not+like+the+MyGellery+plug-in.& submit=Submit+Comment& comment_post_ID=4

• author : 댓글을 남긴 사람의 이름이며 사용자별로 다른 값을 가져야 한다.
• email : 이메일 주소며 사용자별로 다른 값을 가져야 한다.
• url : 댓글을 남긴 사람과 관련된 웹 사이트 주소며, 사용자별로 다른 값을 가져야 한다.
• comment : 사용자가 남긴 실제 댓글을 포함하는 텍스트 묶음이며, 사용자별로 다른 값을 가져야 한다,
• submit : 정적인 페이로드며 모든 사용자에 대해 알아야 한다.
• comment_post_ID : 고유한 값을 가진 숫자 필드며 댓글별로 고유해야 한다. 

주의 이 레시피는 실제 트래픽을 프로파일링해 입력 값 검증을 제공하는 과정에서 유용한 첫 단계로 활용될 수 있지만 완벽하지는 않다. 여기에는 다음과 같은 세 가지 주요 제한 사항이 있다. ■ 자동 재학습 미지원 주요 제한 사항은 자동 재학습을 지원하지 않는 것이다. 규칙이 프로파일링 단계에서 집행 단계로 넘어가면 계속 집행 단계로 남아있는다. 이는 여러분이 현재 자원의 기능을 업데이트할 수 있도록 정상적인 방법으로 코드를 수행했다면, 자원 수집 개체를 제거하고 다시 학습을 시작해야 한다는 의미다. ■ 영구 저장소 크기 제한 자원당 프로파일링하기 원하는 프로파일 특성의 수에 따라 SDBM 영구 저장소 크기 제한에 다다를 수 있다. 기본적으로 Modsecurity 영구 저장소 파일 내에서 약 800바이트에 저장공간을 사용할 수 있다. ■ 자원 예외 여러분이 특정 URL을 프로파일링에서 제외하려면, 주석 처리된 몇 개의 규칙을 활성화할 수 있다.

[ 레시피 1-2, 암호화 해시 토큰을 이용해 데이터 조작 방지 ]

이 레시피는 데이터 조작 공격을 방지하기 위해 ModSecurity를 이용해 아웃바운드 HTML 데이터에 추가적인 해시 토큰을 구현하는 방법을 보여준다.

 

웹 개발자는 데이터 조작을 방지하기 위해 웹 브라우저의 보안 매커니즘에 의존할 수 없다. 이 같은 경우 아웃바운드된 데이터가 후속 요청으로 돌아왔을 때 데이터가 조작되지 않았다는 것을 검증하는 외부 함수를 어떻게 구현할 수 있을까? 하나의 방법은 아웃바운드 HTML 응답 바디의 데이터를 피싱해 특정 위치에 추가적인 토큰 데이터를 삽입하는 것이다. 삽입된 데이터는 요청 매개변수 검증 토큰이라고 한다. 이것은 선택된 HTML 페이지 요소의 필수적인 암호화 해시다. 해시는 클라이언트가 데이터를 조작하려고 했다면 발견할 수 있도록 도와준다.

 

ModSecurity 지시자와 규칙

 

■ SecDisableBackendCompression

: 리버스 프락시 설정일 경우에만 필요하다.

웹 애플리케이션이 응답 데이터를 gzip 포맷으로 압축할 경우에만 사용되며, 우리가 응답 HTML 데이터를 파싱하고 수정하는 데 필요하다.

 

■ SecContentInjection, SecStreamOutBodyInspection

: 동시에 사용되며 원래의 버퍼링된 응답 본문이 수정되고 새롭게 교체될 수 있어야 한다.

 

■ SecEncryptionEngine, SecEncryptionKey, SecEncrytionParam, SecEncryptionMethodrx

: 기본적인 설정을 구성한다.

이 설정에서는 ModSecurity가 임의의 암호 키를 해시 값으로 사용하고 HTML href 요소를 정의된  정규 표현식과 일치하는 값으로 해시화한다.

 

■ SecRule

: 해시 토큰의 유효성을 검증하고 규칙 집행하는 데 사용된다.

 

보호가 적용되면, URI 또는 매개변수 페이로드네 대한 어떠한 변수라도 변경되는 경우 ModSecurity 경고를 발생시킨다. 완료되면 모든 href 링크 데이터에 전체 URI(어떠한 쿼리 문자 매개변수 데이터라도 포함)에 대한 해시 값이 포함된 rv_token이 포함돼 갱신된다.

 

해시 토큰 불일치

공격자가 매개변수 데이터를 변경하려고 시도하면 ModSecurity는 경고를 발생시킨다. 예를 들어 공격자가 홑따옴표(SQL 인젝션 공격을 데스트하기 위한 일반적인 방법)을 추가한다면 경고가 발생한다. 

 

해시 토큰 누락

공격자가 단순히 rv_token을 제거한다면, 이 또한 규칙에 의해 해당 시도에 대한 경고를 발생시킨다.

 

[ 레시피 1-3, OWASP ModSecurity CRS 설치 ]

이 레시피는 OWASP modSecurity CRS를 설치하는 방법과 웹 애플리케이션 공격 탐지 규칙을 빠르게 설정하는 방법을 보여준다.

 

OWASP ModSecurity CRS 개요

ModSecurity 자체적으로는 내장된 보호 기능이 없다. 따라서 유용하게 사용하기 위해서는 규칙으로 설정돼야 한다. CRS는 웹 애플리케이션에서 종종 발견되는 알려지지 않은 취약점에 대해서도 일반적인 공격 페이로드 감지 기능을 제공한다. 이처럼 일반적인 접근은 CRS가 공개 소프트웨어와 커스텀으로 제작된 웹 애플리케이션 모두를 보호할 수 있는 장점을 가진다.

 

핵심 규칙 내용

• HTTP 보호 : HTTP 프로토콜에 대한 위반 및 지역적으로 정의된 사용 규칙을 탐지
• 실시간 블랙리스트 조회 : 타사 IP 평판 기능 사용
• 웹 기반의 악성코드 탐지 : GSB API로 검사해 악의적인 웹 콘텐츠를 식별
• HTTP 서비스 거부 공격 보호 : HTTP 플로딩과 느린 HTTP 서비스 거부 공격을 방어
• 일반적인 웹 공격 보호 : 일반적인 웹 애플리케이션 보안 공격을 탐지
• 자동화 탐지 : 봇, 크롤러, 스캐너, 다른 표면적인 악성 행위를 탐지
• 파일 업로드에 대한 AV 스캐닝과 통합 : 웹 애플리케이션을 통해 악의적인 파일 업로드 탐지
• 민감한 데이터 추적 : 신용카드 사용 및 차단 누출을 추적
• 트로이 목마 차단 : 토로이 목마에 대한 접근을 탐지
• 애플리케이션 문제점 식별 : 애플리케이션의 잘못된 설정에 대한 경고
• 에러 탐지 및 숨김 : 서버로부터 보내지는 에러 메시지를 숨김

설정 옵션

아파치를 재시작하기 전에 modsecurity_crs_10_setup.conf.example 파일을 검토하고 갱신해야 한다. 이 파일은 CRS 동작 작 방식을 제어할 수 있도록 허용하는 중앙 설정 파일이다. 이 파일에서 다음과 같은 CRS 항목을 제어할 수 있다.

 

• 탐지 방식 : 전통적인 방식 대 이상 징후 점수 방식
• 이상 징후 점수 심각도 수준
• 이상 징후 점수 임계값 수준(차단)
• 차단 활성화/비활성화
• 로그 이벤트를 기록할 위치(아파치 error_log 또는 ModSecurity의 감사 로그)

동작 모드 변경을 위해서는 규칙 일부를 수정해야 한다. 특히 대부분의 규칙은 수행해야 할 액션을 개별적으로 지정하는 대신 포괄적인 block 액션을 사용한다. 이와 같은 변경은 seRules에서 상속받는 SecDefaultAction의 설정을 사용자가 쉽게 조정할 수 있도록 한다.

 

전통적인 탐지 모드(내장 규칙 개념)

전통적인 탐지 모드(또는 IDS/IPS 모드)는 새로운 기본 동작 모드다. 이는 모든 규칙의 로직이 자체 내장된 가장 기본적인 작동 모드다. HTTP 자체와 같이 개별적인 규칙은 상태를 저장하지 않는다. 이는 규칙 간 정보가 공유되지 않는 것과 기존 규칙 일체에 대해서는 어떤 규칙도 통찰력을 가지지 못한다는 것을 의미한다. 규칙은 탐지를 위해 현재의 한 가지 규칙 로직을 사용한다. 이와 같은 모드에서 규칙이 트리거 되는 경우 현재의 규칙에 지정된 와해/로그 행위를 수행한다.

 

전통적인 탐지 모드의 장단점

 

■ 장점

• 새로운 사용자가 탐지 로직을 상대적으로 이해하기 쉽다.
• 일치하면 추가적인 진행을 중지하므로 더 나은 성능(낮은 지연 시간/자원)이 가능하다.

■ 단점

• 규칙 관리 관점(오탐 처리 및 예외 구형)에서 최적이 아니다.
• 보안 관점에서 최적이 아니다.

이상 징후 점수 탐지 모드(공동 규칙 개념)

이 고곱 검사 모드는 공동 탐지 및 지연된 차단의 개념을 구현한다. 이 모드에서 검사 및 탐지 로직은 규칙에서 차단 기능과 분리된다. 개별적인 규칙은 탐지가 계속되도록 수행될 수 있다. 

 

이 동작 모드에서는 규칙이 일치하더라도 차단하지 않는다. 그 대신 ModSecurity의 setVar 액션을 통해 이상 징후 점수를 증가시킨다.

 

이상 징후 점수 심각도 수준

각 규칙은 지정된 심각도 수준이 있다. 이 설정은 크리티컬한 심각도(심각도 2레벨)를 가진 모든 CRS 규칙이 해당 규칙에 일치할 때마다 트랜잭션 이상 징후 점수를 5점 증가시킨다는 것을 의미한다. 규칙이 일치할 때마다 modsec_debug.log 파일에서 이상 징후 점수가 어떻게 동작하는지 확인할 수 있다.

 

이상 징후 점수 임계값 수준(차단)

다음 단계는 임계값 설정하는 것이다. 현재의 트랜잭션 점수가 임계값을 넘는다면 거부될 것이며, 두 개의 다른 임계값이 반드시 설정돼야 한다. 하나는 modsecurity_crs_49_inbound_blocking.conf 파일의 2단계 마지막에서 검증되는 인바운드 요청에 대한 값이다. 다른 하나는 modsecurity_crs_59_outbound_blocking.conf 파일의 4단계 마지막에서 검증되는 아웃바운드 정보 유출에 대해 설정되는 값이다.

 

위와 같이 설정한다면, 차단적인 관점에서 이상 징후 점수 모드는 전통적인 모드와 같은 역할을 한다. 모든 크리티컬 레벨의 규칙이 이상 징후 점수를 5점 올리기 때문에 최종적으로 하나의 크리티컬 레벨 규칙만 일치하더라도 차단이 발생한다.

 

차단 활성화/비활성화

SecRuleEngine 지시자는 전역적으로 차단 모드(on)와 탐지 모드(DetectionOnly)를 제어할 수 있다. 이상 징후 점수 탐지 모드의 경우 차단을 원하면 SecRuleEngine On을 설정하고 modsecurity_crs_10_setup.conf 파일의 TX 변수를 설정한다.

 

이제 이 변수가 설정됐으므로 modsecirity_crs_49_inbound_blocking.conf 파일 내의 규칙은 요청 단계의 마지막에서 이상 징후 점수를 검증하고 요청을 차단한다.

 

하위 카테고리 이상 징후 점수에 따라 검사/차단을 선택할 수 있는 것을 보여준다.

 

경고 관리 : 연관된 이벤트

CRS를 전통적인 탐지 모드로 동작시키는 경우 각각의 규칙은 개별적으로 로그 항목을 생성한다. 보안 분석가에게는 트랜잭션 심각도에 대해 결정할 수 있도록 연관된 하나의 이벤트만 생성되고 기록되는 것이 유용하다.

 

이를 달성하기 위해 CRS는 연관 이벤트 모드로 동작할 수 있다. 각각의 규칙은 modsec_audit.log 이벤트 메시지를 생성하지만 error_log 파일에는 기록하지 않는다. 이러한 규칙들은 전체적인 이상 징후 점수에 이바지하는 기본 또는 참조 이벤트로 여겨진다. 사용자가 어떤 개별적인 이벤트가 전체적인 이상 징후 점수 및 이벤트 지정에 이바지했는지 알고 싶은 경우 감사 로그에서 검토될 수 있다. 이 같은 기능을 사용하기 위해서는 간단히 modsecurity_crs_10_setup.conf의 SecDefaultAction 라인을 편집하면 된다.

 

이상 징후 점수 탐지 모드의 장단점

 

■ 장점

• 차단에 대한 향상된 확신. 더 많은 탐지 규칙이 이상 징후 점수에 기여하므로, 점수가 높을수록 악성적인 트랜잭션을 차단하는 데 더욱 확신을 가질 수 있다.
• 사용자 환경에 맞게 임계값을 적절하게 설정할 수 있다. 사이트별로 차단을 위한 다른 임계값을 가질 것이다.
• 낮은 등급의 이벤트가 개별적으로는 무시되더라도, 몇 개의 낮은 등급 이벤트가 모여 경고를 발생시킬 수 있다.
• 하나의 연관된 이벤트는 경고 관리를 하는 데 도움을 준다.
• 전체적인 이상 징후 점수 임계값을 증가시켜 예외를 쉽게 처리할 수 있다.

■ 단점

• 일반 사용자에게는 더운 복잡하다.
• 적절한 분석을 위해서는 로그 모니터링 스크립트가 업데이트될 필요가 있다.

경고 관리 : 인바운드/아웃바운드 상관관계

보안 분석가에게 당면한 중요한 경고 관리 문제는 우선순위를 매기는 것이다. 사고 대응 관점에서 많은 ModSecurity/CRS 사용자는 어떤 경고를 검토해야 하고 어떤 후속 조치를 취해야 하는지 파악하는 데 어려움을 겪는다. 이는 여러분이 ModSecurity를 탐지 모드로 사용할 때 특히 사실로 다가온다. 왜냐하면 경고는 발생하지만, 능동적으로 공격이나 정보 유출을 차단하지 않기 때문이다. 

 

OWASP ModSecurity CRS를 이상 징후 점수 모드로 사용하면, 트랜잭션 문제에 대한 자세한 정보를 얻기 위해 규칙 일치의 상관관계라는 이점을 얻을 수 있다.

 

확인된 인바운드 공격이 가질 수 있는 가장 높은 심각도는 2(크리티컬)이다. 높은 심각도(1 또는 0)를 얻기 위해서는 상관관계를 이용해야 한다. 요청 및 응답의 마지막 단계에서 CRS는 최종 규칙 일치 메시지 데이터를 저장한다.

 

인바운드 공격이 탐지됐자면, 아웃바운드 애플리케이션 상태 코드 에러가 발샹하거나 정보 유출 이벤트가 탐지된 경우 전테적인 이벤트의 심각도는 다음 중 하나로 상향된다.

 

• 0, 응급(EMERGENCY) : 인바운드 공격과 아웃바운드 유출이 존재할 경우 이상 징후 점수의 상관관계에 따라 발생한다.
• 1, 경고(ALERT) : 인바운드 공격과 아웃바운드 애플리케이션 레벨의 오류가 존재한느 관계에서 발생한다.

[ 레시피 1-4, 침입 탐지 시스템(IDS)의 시그니처와 통합 ]

이 레시피는 공개된 Snort IDS 웹 공격 시그니처를 ModSecurity와 통합하는 방법을 보여준다.

 

ET의 Snort 웹 공격 규칙

웹 애플리케이션 취약점 및 공격과 연관된 몇 가지의 Snort 규칙 파일이 있다.

• emerging-web_server.rules
• emerging-web_specific_apps.rules

이 웹 공격 규칙을 검토하면 /vehiclelisting.asp 페이지에서 아마도 vehicle 매개변수 페이로드에 SQL 인젝션 취약점이 있다고 결론 내릴 수 있다. 이는 웹 요청 내의 어느 곳에 인잭션 포인트가 있는지 알려준다. 정규 표현식 검사는 특정한 SQL 값을 찾는다. 이 데이터는 공격을 탐지하기 위해 어떤 데이터를 찾는지 알려준다.

 

• 인젝션 포인트에 대한 규칙이 오래된 Snort의 uricontent 키워드를 사용하므로 정확도는 적합하지 않다.
• 정규 표현식 분석은 vehicleID 매개변수 데이터로만 한정되지 않는다.
• 정규 표현식은 가능한 SQL 인젝션 공격 데이터의 작은 일부분을 찾기 때문에 포괄적이지 않다.

알려진 취약점에 대한 공격의 가치

OWASP ModSecurity CRS에서 사용되는 일반적인 공격 페이로드 탐지와 달리, 이와 같은 ET Snort 규칙은 공개된 소프트웨어의 취약점 정보를 기반으로 개발된다. 알려진 취약점에 대한 공격을 식별하는 것은 다음과 같은 시나리오에서 가치를 가진다.

 

• 대상 애플리케이션을 사용하고 있는 경우 위협 레벨을 향상하고 오탐을 줄이고 궁극적으로 차단에 대한 향상된 신뢰성을 제공할 수 있다.
• 대상 소프트웨어를 사용하지 않더라도 성공의 기회와 상관없이 알려진 취약점을 악용하려는 시도에 대해 알고 싶을 것이다.

Snort 시그니처를 Modsecurity 규칙의 언어로 변환

 

1. SecRule은 취약한 자원과 일치하는지 확인하기 위해 요청 라인 데이터를 검사한다.

2. debug 로그에서 최종 규칙이 어떻게 처리되는지 보여준다.

 

[ 레시피 1-5, 베이지안(Bayerian) 공격 페이로드 탐지 사용 ]

이 레시피는 악성 데이터를 식별하기 위해 HTTP 매개변수 페이로드에 대해 베이지안 분석을 통합시키는 방법을 보여준다.

 

웹 공격을 탐지하기 위해 베이지안 분석 대응

베이지안 텍스트 분류기는 스팸 메일을 탐지하기 위해 오랫동안 사용됐다. 왜 웹 트래픽에 대해 악성 요청을 식별하기 위해 동일한 유형의 분석을 사용하지 않았을까? 이메일 분석부터 HTTP 요청 매개변수 검사까지 일반적인 개념은 직접 적용 가능하다. 

• ham vs. spam : 우리의 구현에서 ham은 악의적이지 않은 트래픽으로 간주하고 spam은 공격 페이로드로 간주한다.
• 입력 소스 : 베이지안 분류기는 일반적으로 OS의 여러 줄 텍스트로 구성된 텍스트 파일(이메일 메시지)를 검사한다. ModSecurity의 PoC 구현에서 OS의 텍스트 파일을 베이지안 분류기에 전달하는 것은 너무 많은 지연을 발생시킬 수 있으므로 우회해야 한다. 그 대신 텍스트를 임시 변수에 저장하고 루아 API를 사용하는 방식으로 데이터를 요청으로부터 베이지안 분류기로 직접 전달한다.
• 데이터 포맷 : 이메일 메시지는 MIME 헤더를 상단에 두고 메시지의 바디가 오는 특정한 양식을 가지고 있다. 이 포맷은 분류기의 전반적인 점수에 영향을 미칠 수 있다. ModSecurity와의 현재 구현에서는 개별적인 매개변수로부터 텍스트 페이로드만 전달한다. 이 작은 데이터 집합은 최종 분류에 영향을 미칠 수 있다.

지속적인 Moonrunner 사용

Modsecurity 구성 요소를 프로덕션 환경에 배포하고 나면 Moonrunner는 유용한 도구다. 두 개 분류기 데이터베이스 학습 상태를 확인하기 위해 주기적으로 stats 검사를 수행할 수 있다. 또한 Moonrunner를 사용할 때, 만약 ModSecurity가 부적절하게 페이로드를 판별한다면 감사 로그로부터 가져온 데이터를 이용해 수동으로 재학습시킬 수 있다.

 

베이지안 분석의 장점

베이지안 분석을 블랙리스트 정규 표현식 검사와 함께 사용하면 두 가지 장점이 있다.

 

• 블랙리스트 필터를 초기 공격 시도를 식별하는 데 사용하고, 식별한 페이로드를 베이지안 분류기가 spam이라고 실제적으로 학습하는 데 사용한다. 사실 공격자가 우리의 탐지 로직을 학습시켜주는 것과 같은 효과를 낸다. 정규 표현식을 회피할 수 있는 마지막 페이로드는 탐지된 기존의 페이로드와 매우 유사하다는 것을 기억하라. 일반적으로 단지 한 개의 글자만 차이가 난다.
• 이원적인 결과를 주는 대신 베이지안 분석은 페이로드가 악성인 확률을 알려준다. 이와 같은 접근으로 페이로드가 악성일 가능성을 식별하는 데 넓은 척도를 가질 수 있다.

베이지안 분석과 ModSecurity의 통합

 

첫 번째 단계 : ham과 spam 데이터베이스 파일이 아파치 사용자에 대해 읽기/쓰기 권한을 가지는지 확인하는 것이다.

두 번째 단계 : 활성화된 규칙에 modsecurity_crs_48_bayes_analysis.conf 파일을 추가해 활성화시키는 것이다.

 

[ 레시피 1-6, 전체 HTTP 감사 로깅을 활성화 ]

이 레시피는 ModSecurity 감사 엔진을 사용해 전체적인 HTTP 트랜잭션 데이터를 취득하는 방법을 보여준다.

 

전체 감사 로깅을 하나의 파일로 활성화

침해 사고 대응 프로세스를 위해 다양한 데이터를 확보하길 원하는 경우 HTTP 요청 및 응답 트래픽 모두에 대해 전체 감사 로깅을 활성화해야 한다.

 

SecAuditLogParts는 캡처하는 각각의 트랜잭션 요소를 정의한다.

• A : 감사 로그 헤더
• B : 요청 헤더
• C : 요청 바디
• E : 의도된 응답 바디
• F : 응답 헤더
• H : 감사 로그 트레일러
• Z : 감사 로그 푸터

전체적인 트랜잭션 데이터가 캡처되면 공격자가 어떤 데이터를 유출했는지 알아차리는 데 도움이 된다.

 

전체 감사 로깅을 별도의 파일로 활성화

모든 트랜잭션 데이터를 SecAuditLogType Serial 지시자 설정과 함께 하나의 파일로 기록하는 것은 편리하지만 두 가지 단점이 있다.

 

1. 웹 애플리케이션이 받는 트래픽의 양에 따라 파일 크기가 매우 빠르게 증가할 것이다.

2. 잠재적인 문제는 성능이다.

 

각각의 트랜잭션은 아파치 mod_uniqueid 해시 값을 파일 이름에 이용해 식별을 돕는다. 각각의 파일은 하나의 트랜잭션에 대한 데이터를 보유한다는 점을 제외하고는 Serial 모드와 동일한 데이터를 보유한다.

 

[ 레시피 1-7, 관련된 트랜잭션만 로깅 ]

이 레시피는 보안 관점에서 관련된 것으로 간주되는 트랜잭션만 기록하도록 ModSecurity를 설정하는 방법을 보여준다.

 

전체적인 HTTP 감사 로깅을 이용하는 것을 강력히 권장한다. 하지만 웹 앱플리케이션에서 전체적인 HTTP 트랜잭션 데이터를 로깅하는 것이 불가능할 수 있음을 이해한다. 모든 데이터를 기록하지 않지로 결정한 경우 관련된 트랜잭션만 기록하도록 ModSeucurity를 설정할 수 있다. SecAuditEngine 지시자 값을 On에서 RelevantOnly로 변경하는 경우 ModSecurity는 단지 두 가지 시나리오의 경우에만 감사 로그를 생성한다.

 

• SecRule 지시자 중 하나라도 일치하는 경우
• SecAuditLogrelevantStatus 지시자에서 정규 표현식으로 정의한 HTTP 응답 코드로 웹 서버가 응답하는 경우

SecAuditEngine RelevantOnly SecAuditLoglevantStatus "^(?:5|4(?!04))"

위와 같이 설정한 경우 일반적인 ModSecurity SecRule이 일치하는 경우뿐만 아니라 HTTP 응답 상태 코드가 500번대(서버 오류) 또는 404 Not Found 이벤트를 제외한 400번대(사용자 오류)인 경우 감사 로그가 생성된다.

 

[ 레시피 1-8, 정적 콘텐츠에 대한 요청인 경우 무시 ]

이 레시피는 정적 자원에 대한 HTTP 요청인 경우 감사 로깅을 제외하도록 설정하는 방법을 설명한다.

 

모든 HTTP 트랜잭션을 기록하는 것은 침해 사고 대응 관점에서 이상적이다. 그러나 일부 조직은 성능과 지연을 개선하고 필요한 로깅의 양을 줄이기 위해 정적 자원 요청에 대해 검사하고 로깅하지 않도록 결정할 수 있다. 정적 자원(ex, 이미지 파일) 유형에 대한 요청이 발생하는 경우 매개변수가 없으므로 잠재적인 공격면이 많이 줄어든다는 이론이다. 매개변수 페이로드는 내부 처리를 위해 사용자 입력을 허용하는 동적 자원에 공격 데이터를 전달하는 주요한 인젝션 포인트로 사용된다. 만약 정적 자원 요청에 대해 검사 및 로깅하는 것을 비활성화하려면 어떠한 매개변수 데이터도 전달하지 않는 것을 보장하기 위해 우선적으로 요청 구성 요소를 분석해야 한다.

 

연결된 규칙 집합은 다음과 같은 작업을 통해 요청 세부 사항을 확인한다.

 

• 요청 방식이 GET 또는 HEAD인지 확인한다. 만약 다른 값이라면 데이터를 변경하고자 하는 동적 요청 방식이므로 해당 요청은 기록돼야 한다.
• 물음표를 검사해 URI에 쿼리 문자열이 없는지 확인한다.
• ARGS 컬렉션의 존재 여부를 검사해 쿼리 문자열 또는 요청 바디에 매개변수가 존재하지 않는 것을 확인한다.
• Content-Length와 Content-Type 요청 헤더가 존재하는지 검사해 요청 바디가 없는 것을 확인한다.

모든 규칙이 일치하는 경우 마지막 SecRule은 동적으로 규칙 및 검사 엔진을 비활성화하도록 굵게 표시된 두 개의 ctl 액션을 수행한다.

 

주의 정적 자원 요청에 대해 검사 및 로깅을 비활성화하는 이유는 명확하지만, 주의하면서 접근해야 한다. 이와 같은 규칙은 잠재적인 공격면을 프로파일링하는 데 도움이 되지만 완벽하지는 않다. 여전히 열려 있는 주요 공격 벡터 위치는 쿠키다. 애플리케이션이 쿠키를 사용한다면 공격에 대한 잠재적인 벡터를 열어두는 것이다. 그러나 Cookie:request header의 존재 여부 검사를 포함하도록 제외 규칙 예시를 업데이트하는 경우 쿠키가 정적 이미지 요청을 위해 보내지므로 원했던 성능적인 향상은 달성하지 못할 것이다.

[ 레시피 1-9, 로그에서 중요한 데이터 난독화 ]

이 레시피는 감사 로그에서 캡처된 중요한 데이터를 난독화하기 위해 ModSecurity를 이용하는 방법을 보여준다.

 

HTTP 감사 로그는 비밀번호 또는 신용카드 데이터와 같이 일부 중요한 사용자 데이터도 캡처될 수 있다는 딜레마를 가지고 있다. 우리는 트랜잭션을 기록하길 원하지만, 이 로그에 접근할 수 있는 누군가에게 중요한 정보가 노출되는 것을 원하지 않는다. ModSecurity는 감사 로그 안에서 선택된 데이터를 난독화하는 데 사용할 수 있는 몇 개의 다른 규칙 액션을 가지고 있다.

 

로그인 비밀번호

HTML 소스 코드를 보면 제출된 비밀번호는 pwd라는 매개변수를 통해 전달되는 것을 알 수 있다. 비밀번호 페이로드를 난독화하길 원한다면, 다음과 같은 예제 규칙을 ModSecurity sanitiseArg 액션을 통해 추가할 수 있다.

sanitiseArg:pwd

C 색션의 굵게 표시된 데이터에서 확인할 수 있듯이 pwd 매개변수 페이로드는 이제 별표로 난독화됐다.

 

신용카드

웹 애플리케이션에서 사용자가 신용카드 데이터를 전송하는 전자 상거래를 수행하는 경우 해당 데이터를 감사 로그 안에서 난독화해야 한다. 다음의 ModSecurity 규칙은 어떤 페이로드라도 @VeirtyCC 연산자 검사를 통과한다면 소독 처리한다.

 

[ 레시피 1-10, Syslog를 사용해 중앙 로그 호스트에 경고 전송 ]

이 레시피는 Syslog를 사용해 중앙 로깅 호스트로 경고 데이터를 전송할 수 있도록 아파치를 구성하는 방법을 보여준다.

 

ModSecurity의 기본 로깅 매커니즘은 로컬 파일시스템을 저장소로 사용한다. 짧은 한 줄의 경고 메시지가 자동으로 아파치 ErrorLog 지시자에 기술돼 있는 위치에 기록되는 방식이다. 규모가 작은 조직에서는 이러한 접근 방식이 정상적으로 동작하지만, 모니터링해야 하는 웹 서버 팜이 있는 경우라면 금세 경고를 추적 관리 하는 것이 불가능한 상태가 된다. 이와 같은 상황이라면 error_log 데이터를 로컬 Syslogd 프로세스가 처리하도록 아파치 설정을 쉽게 재구성할 수 있다.

 

새로운 설정은 아파치의 모든 에러 메시지를 local7 퍼실리티를 이용해 로컬 syslog 프로세스로 전송한다. 다음 단계는 syslog.conf 파일에 새로운 항목을 추가하는 것이다.

 

$ grep ErrorLog httpd.conf ErrorLog syslog:local 7

$ grep local7 /etc/syslog.conf

두 개의 항목을 syslog.conf 파일에 추가했다. 첫 번째 항목은 단순히 아파치 error_log 데이터를 일반적인 로컬 파일 위치에 재라우팅하는 것이다. 두 번째 항목은 모든 동일한 데이터를 IP 주소 192.168.1.200을 가진 중앙 로깅 호스트에 기본 UDP 프로토콜(포트 514)을 사용해 전송하는 것이다. 이러한 설정이 추가된 후 Syslogd 서비스를 재시작해야 한다. 이와 같이 설정이 완료되면 아파치 error_log 데이터는 중앙 로깅 호스트로 전송돼야만 한다.

 

ModSecurity 경고들이 중앙 집중화되면 전반적인 웹 아키텍처에 걸쳐 발생하는 이벤트 정보를 추가 분석하고 경향 정보를 파악하기 위해 사용자 정의된 검색 및 경고 매커니즘이 구현될 수 있다.

 

[ 레시피 1-11, ModSecurity의 AuditConsole 사용 ] 

이 레시피는 검사 로그의 중앙 집중식 로깅을 위해 ModSecurity AuditConsole을 구성하는 방법을 보여준다.

 

아파치 error_log 파일로 전송된 짧은 한 줄의 ModSecurity 경고 메시지를 syslog릉 통해 전송함으로써 중앙 집중화하는 방법을 보여줬다. 이러한 접근 방법도 좋다. 하지만 이 방법의 가장 큰 단점은 중앙 집중되는 로그가 감사 로그 파일에 기록되는 데이터의 오직 일부분이라는 점이다. 따라서 경고 메시지의 정확도를 높이려면 전체 감사 로그 파일 데이터를 검토해야 한다.

 

설치를 끝낸 후, 모든 설정을 완료한 후 아파치를 재시작하면 새로운 감사 로그 파일이 AuditConsole 호스트로 실시간으로 전송된다. AuditConsole을 사용해 관심이 있는 이벤트에 대해 조회, 정렬, 검색을 할 수 있며 전체 감사 로그 상세 내역을 볼 수 있다.

 

 

---

출처: ModSecurity를 활용한 웹 애플리케이션 방어 레시피, 라이언 바넷 지음