Configuring a client IP header

AAP automatically attempts to resolve http.client_ip from several well-known headers, such as X-Forwarded-For. If you use a custom header for this field, or want to bypass the resolution algorithm, set the DD_TRACE_CLIENT_IP_HEADER environment variable. If this variable is set, the library only checks the specified header for the client IP.

Track authenticated bad actors

Many critical attacks are performed by authenticated users who can access your most sensitive endpoints. To identify bad actors that are generating suspicious security activity, add user information to traces by instrumenting your services with the standardized user tags. You can add custom tags to your root span, or use instrumentation functions.

The Datadog Tracing Library attempts to detect user login and signup events when compatible authentication frameworks are in use, and AAP is enabled.

Read Tracking User Activity for more information on how to manually track user activity, or see how to opt out of the automatic tracking.

Exclude specific parameters from triggering detections

There may be a time when an AAP signal, or a security trace, is a false positive. For example, AAP repeatedly detects the same security trace and a signal is generated, but the signal has been reviewed and is not a threat.

You can add an entry to the passlist, which ignore events from a rule, to eliminate noisy signal patterns and focus on legitimately security traces.

To add a passlist entry, do one of the following:

• Click on a signal in AAP Signals and click the Add Entry link next to the Add to passlist suggested action. This method automatically adds an entry for the targeted service.
• Navigate to Passlist Configuration and manually configure a new passlist entry based on your own criteria.

Note: Requests (traces) that match a passlist entry are not billed.

Data security considerations

The data that you collect with Datadog can contain sensitive information that you want to filter out, obfuscate, scrub, filter, modify, or just not collect. Additionally, the data may contain synthetic traffic that might cause your threat detection be inaccurate, or cause Datadog to not accurately indicate the security of your services.

By default, AAP collects information from security traces to help you understand why the request was flagged as suspicious. Before sending the data, AAP scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a <redacted> flag. This enables you to observe that although the request was suspicious, the request data was not collected because of data security concerns. User-related data, such user IDs of authenticated requests, are not part of the data being redacted.

To protect users’ data, sensitive data scanning is activated by default in AAP. You can customize the configuration by using the following environment variables. The scanning is based on the RE2 syntax. To customize scanning, set the value of these environment variables to a valid RE2 pattern:

• DD_APPSEC_OBFUSCATION_PARAMETER_KEY_REGEXP - Pattern for scanning for keys whose values commonly contain sensitive data. If found, the values and any child nodes associated with the key are redacted.
• DD_APPSEC_OBFUSCATION_PARAMETER_VALUE_REGEXP - Pattern for scanning for values that could indicate sensitive data. If found, the value and all its child nodes are redacted.

Datadog.configure do |c|
  # ...

  # Set custom RE2 regexes
  c.appsec.obfuscator_key_regex = '...'
  c.appsec.obfuscator_value_regex = '...'
end

The following are examples of data that are flagged as sensitive by default:

• pwd, password, ipassword, pass_phrase
• secret
• key, api_key, private_key, public_key
• token
• consumer_id, consumer_key, consumer_secret
• sign, signed, signature
• bearer
• authorization
• BEGIN PRIVATE KEY
• ssh-rsa

See APM Data Security for information about other mechanisms in the Datadog Agent and libraries that can also be used to remove sensitive data.

See Automatic user activity event tracking modes for information on automatic user activity tracking modes and how to configure them. See how Datadog libraries allow you to configure auto-instrumentation by using the DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE environment variable with the short name for the mode: ident|anon|disabled.

Configure a custom blocking page or payload

차단된 요청에는 JSON 또는 HTML 콘텐츠가 포함됩니다. Accept HTTP 헤더가 text/html과 같은 HTML을 가리키는 경우 HTML 콘텐츠가 사용되고, 그렇지 않으면 JSON이 사용됩니다.

두 콘텐츠 세트 모두 Datadog Tracer 라이브러리 패키지에 포함되어 로컬로 로드됩니다. GitHub의 Datadog Java 트레이서 소스 코드에서 HTML 및 JSON에 대한 템플릿 예를 참조하세요.

HTML 및 JSON 콘텐츠는 모두 애플리케이션 배포 파일 내의 DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML 및 DD_APPSEC_HTTP_BLOCKED_TEMPLATE_JSON 환경 변수를 사용하여 변경할 수 있습니다.

예시:

DD_APPSEC_HTTP_BLOCKED_TEMPLATE_HTML=<path_to_file.html>

또는 구성 항목을 사용할 수 있습니다.

Java인 경우 다음을 추가합니다.

dd.appsec.http.blocked.template.html = '<path_to_file.html>'
dd.appsec.http.blocked.template.json = '<path_to_file.json>'

Ruby인 경우 다음을 추가합니다.

# config/initializers/datadog.rb

Datadog.configure do |c|
  # text/html 차단 페이지를 구성하려면
  c.appsec.block.templates.html = '<path_to_file.html>'
  # 애플리케이션/json 차단 페이지를 구성하려면
  c.appsec.block.templates.json = '<path_to_file.json>'
end

PHP인 경우 다음을 추가합니다.

; 98-ddtrace.ini

; 차단된 요청에 대해 제공되는 HTML 출력을 사용자 정의합니다.
datadog.appsec.http_blocked_template_html = <path_to_file.html>

; 차단된 요청에 대해 제공되는 JSON 출력을 사용자 정의합니다.
datadog.appsec.http_blocked_template_json = <path_to_file.json>

Node.js인 경우 다음을 추가합니다.

require('dd-trace').init({
  appsec: {
    blockedTemplateHtml: '<path_to_file.html>',
    blockedTemplateJson: '<path_to_file.json>'
  }
})

기본적으로 차단된 작업에 대한 응답으로 표시되는 페이지는 다음과 같습니다.

Further Reading

추가 유용한 문서, 링크 및 기사:

Protect against Threats with Datadog App and API ProtectionDOCUMENTATION Out-of-the-Box App and API Protection RulesDOCUMENTATION Adding user information to tracesDOCUMENTATION Troubleshooting AAPDOCUMENTATION How App and API Protection Works in DatadogDOCUMENTATION