NGINX App Protect WAF Security Log

NGINX App Protect WAF Security Log 에 대해 알아보세요.

목차

1. NGINX App Protect WAF Security Log 개요
2. nginx.conf 지시문
3. NGINX App Protect WAF Security Log 설정 파일
4. Syslog 전송
5. 초기 설정 파일
6. 유효한 Security Log 속성
7. 차단 관찰 가능성

1. NGINX App Protect WAF Security Log 개요

Security logs(Request logs 혹은 Traffic logs로도 칭하는)는 HTTP 요청/응답, NGINX App Protect WAF가 이를 처리하는 방법, 그리고 구성된 정책 매개변수에 따라 수행된 최종 결정에 대한 정보를 포함합니다. 정책 설정은 Security log 에 포함될 정보를 정의하며, 여기에는 위반, 공격 서명, 기타 기준에 따라 요청이 통과, 차단 또는 경고되는지 여부가 포함됩니다.

NGINX App Protect WAF는 NGINX의 기본 로깅 메커니즘인 access 로깅 메커니즘 대신, 자체 로깅 메커니즘을 사용해 요청 로깅을 수행합니다.

Security log에는 다음과 같은 속성이 있습니다.

• 로그 설정 : security_log.json 파일을 참조하는 app_protect_security_log 지시문
• 설정 컨텍스트 : nginx.conf: http, server, location
• 파일 목적지 : 파일의 목적지를 stderr, 로컬 파일의 절대경로, syslog, 혹은 Netcat과 pipe를 사용하여 로그를 리다이렉트 할 수 있습니다.

nc -vv -l “[ip]” “[port]” > “[name_of_file]” 2>&1

• Syslog 목적지

2. nginx.conf 지시문

app_protect_security_log_enable

이 지시문은 해당 컨텍스트에서  security logging의 활성화 여부를 설정합니다.

Security log 속성은 app_protect_security_log 지시문에 의해 결정됩니다. 이 지시문은 http, server, location 컨텍스트에서 사용할 수 있습니다. 컨텍스트에 지시문이 존재하지 않을 경우, 상위 컨텍스트에서 상속됩니다: location은 server, server는 http로부터 상속받습니다. 이러한 컨텍스트 중 어느 곳에도 지시문이 없으면, 해당 컨텍스트에 대한 로깅은 비활성화됩니다.

• Syntax: app_protect_security_log_enable on | off
• Levels: http, server, location
• 예시: app_protect_security_log_enable on

app_protect_security_log

Security log 속성은 app_protect_security_log 지시문이 활성화된 경우 해당 지시문에 따라 결정됩니다. 이 지시문은 http, server, location 컨텍스트에서 사용할 수 있습니다. 이 지시문은 단일 컨텍스트에서 여러 번 사용할 수 있으며, 컨텍스트에 사용된 모든 로그가 사용됩니다. 컨텍스트에 지시문이 존재하지 않을 경우, 상위 컨텍스트에서 상속됩니다: location은 server, server는 http로부터 상속받습니다. 이러한 컨텍스트 중 어느 곳에도 지시문이 없으면, 기본 설정이 적용됩니다.

• Syntax: app_protect_security_log [LOG-CONFIG-FILE] [DESTINATION]
• Levels: http, server, location
• 예시:

app_protect_security_log "/etc/app_protect/conf/log_default.json" stderr;
app_protect_security_log "/etc/app_protect/conf/log_default.json" /var/log/app_protect/security.log;
app_protect_security_log "/etc/app_protect/conf/log_default.json" syslog:server=localhost:514;
app_protect_security_log "/etc/app_protect/conf/log_default.json" syslog:server=my-specific-machine-name:514;
app_protect_security_log "/etc/app_protect/conf/log_default.json" syslog:server=192.168.12.34:514;
app_protect_security_log "/etc/app_protect/conf/log_default.json" syslog:server=my.domain.com:514;

stderr 을 사용할 경우, bd-socket-plugin 프로세스가 stderr 출력을 파일로 리다이렉트 하지 않도록 해야합니다.

Note:

– stderr 을 사용할 경우, bd-socket-plugin 프로세스가 stderr 출력을 파일로 리다이렉트 하지 않도록 해야 합니다.
– 관리자 가이드의 Docker entrypoint.sh 시작 스크립트를 사용하는 경우, stderr을 리다이렉트 하지 않도록 해야 합니다.
– 서비스 시작 시 nginx-app-protect.service의 서비스 시작 파일이 stderr을 리다이렉트 하지 않도록 해야 합니다.

3. NGINX App Protect WAF Security Log 설정 파일

Security log 설정 파일은 JSON 형식이며, 두 부분으로 구성됩니다.

1. filter : 어떤 요청이 로깅될지 정의합니다.
2. content : 메시지가 어떻게 포맷될지 정의합니다.

Filter

Filter는 필수지만, 비워둘 수 있습니다.

Content

설정 파일의 이 부분은 로깅할 내용, 메시지의 형식, 크기 제한을 지정합니다.

Content는 필수입니다. Content 필드 전체 혹은 속성 중 일부가 정의되지 않으면, 시스템에서 정의한 기본값이 사용됩니다.

예제

기본 로깅 내용

/etc/app_protect/conf/log_default.json의 내용입니다. app_protect_security_log_enabled on으로 설정되고, app_protect_security_log가 설정되지 않았을 때 기본적으로 사용됩니다.

{
    "filter": {
        "request_type": "illegal"
    },
    "content": {
        "format": "default",
        "max_request_size": "2k",
        "max_message_size": "5k"
    }
}

위반 사항이 있는 요청을 키 – 값 형식으로 기록

{
    "filter": {
        "request_type": "illegal"
    },
    "content": {
        "format": "user-defined",
        "format_string": "client_ip=%ip_client%,client_port=%src_port%,request=%request%,violations=%violations%,signature_ids=%sig_ids%",
        "max_request_size": 2000,
        "max_message_size": "5k"
    }
}

로그 상태 변경 요청

{
    "filter": {
        "request_type": "all"
    },
    "content": {
        "format": "default",
        "max_request_size": "2k",
        "max_message_size": "5k"
    }
}

자세한 사용자 정의 메시지

{
    "filter": {
        "request_type": "illegal"
    },
    "content": {
        "format": "user-defined",
        "format_string": "Request ID %support_id%: %method% %uri% received on %date_time% from IP %ip_client% had the following violations: %violations%",
        "max_request_size": "2k",
        "max_message_size": "5k"
    }
}

Escaped Character와 사용자 지정 접두사 / 구분 기호 / 접미사가 있는 로그

{
    "filter": {
        "request_type": "all"
    },
    "content": {
        "format": "default",
        "max_request_size": "2k",
        "max_message_size": "5k",
        "escaping_characters": [
      	    {
                "from": "/",
                "to": "|"
            }
        ],
        "list_prefix": "[",
        "list_delimiter": "::",
        "list_suffix": "]"
    }
}

마지막 예제 참고 사항:

• security log의 목록 요소 문자열에서 / 는 | 로 대체됩니다.
  예 : string/another_string는 string|another_string로 대체됩니다.
• 모든 리스트는 [ 로 시작되고 ] 로 끝나며, 리스트의 각 요소는 :: 로 구분됩니다.
  예 : first,second,third는 [first::second::third]로 기록됩니다.

NGINX Format Strings

만약 format 값이 default 혹은 grpc인 경우, 메시지는 Available Security Log Attributes에 명시된 속성으로 구성된 쉼표로 구분된 키-값 형식으로 나타납니다. grpc 형식은 gRPC 전용 필드와 요청 본문을 Base64로 인코딩하여 헤더와 분리하여 포함합니다. 반면, default 형식은 요청 전체를 하나의 필드에 원래 인코딩으로 포함합니다.

default, grpc 문자열은 모두 다음과 같이 시작합니다:
“attack_type=\”%attack_type%\”,blocking_exception_reason=\”%blocking_exception_reason%\”,…”

4. Syslog 전송

Syslog 전송은 TCP로 이루어집니다. 현재는 SSL/TLS가 지원되지 않아 보안이 적용되지 않습니다. 로그를 원격 목적지로 직접 전송하지 않고, NGINX App Protect WAF와 같은 pod 혹은 VM에 있는 로컬 syslog 서버를 통해 프록시하는 것을 권장합니다. 로컬 syslog 서버는 로그를 원격 목적지로 보안 채널을 통해 전달합니다. 로그가 전송되는 동안 중간에서 가로채거나 변경하려는 공격을 방지하기 위해 상호 인증 TLS(mTLS)를 사용하는 것을 권장합니다.

필터와 일치하는 모든 요청이 실제 목적지에 도달한다고 보장할 수 없습니다. 특히 시스템이 들어오는 트래픽으로 인해 과부하가 걸리는 경우, 일부 로그 레코드가 누락될 수 있습니다.

5. 초기 설정 파일

NGINX는 /opt/app_protect/share/defaults/ 경로에 다음 구성으로 예시 설정을 제공합니다.

6. 유효한 Security Log 속성

아래의 표는 security log에 생성되는 속성을 나열합니다. 사용자 정의 로그를 사용할 때(예: format=user-defined), 아래 목록의 항목을 추가하거나 제거할 수 있습니다. 기본 제공 형식인 default, grpc형식에 해당 속성이 포함되는지 표에 명시되어 있습니다.

7. 차단 관찰 가능성

NGINX App Protect 정책이 Transparent 모드로 시행되면, Blocking 모드가 True로 설정될 경우 어떤 트랜잭션이 차단될지 알기 쉽습니다. 그리고 어떤 위반 사항과 서명이 해당 트랜잭션을 차단하도록 했는지 알 수 있습니다.

이를 용이하게 하기 위해, NGINX App Protect는 JSON 형식 데이터를 포함하는 json_log라는 새로운 security log 필드를 도입합니다. 이 필드는 트랜잭션과 연관된 위반 사항, 적용할 수 있는 서명 이름, ID를 포함합니다. 이 필드는 위반 사항/서명 설정에 따라 특정 위반 사항/서명이 차단을 발생시킬지 여부를 나타냅니다. (isBlocked 속성에 나타남)

감지된 각 서명은 VIOL_ATTACK_SIGNATURE 위반 사항과 isBlocked 불리언 속성을 포함한 JSON 블록으로 보고됩니다.

다음은 여러 위반 사항과 서명이 포함된 json_log 필드의 예제입니다.

{
  "violations": [
    {
      "enforcementState": {
        "isBlocked": false
      },
      "violation": {
        "name": "VIOL_URL_METACHAR"
      }
    },
    {
      "enforcementState": {
        "isBlocked": true
      },
      "violation": {
        "name": "VIOL_RATING_THREAT"
      }
    },
    {
      "enforcementState": {
        "isBlocked": true
      },
      "signature": {
        "name": "XSS script tag (URI)",
        "signatureId": 200000099
      },
      "violation": {
        "name": "VIOL_ATTACK_SIGNATURE"
      }
    },
    {
      "enforcementState": {
        "isBlocked": true
      },
      "signature": {
        "name": "XSS script tag end (URI)",
        "signatureId": 200000093
      },
      "violation": {
        "name": "VIOL_ATTACK_SIGNATURE"
      }
    }
  ]
}